[fpc-pascal] rotating bits

[Florian Klaempfl]

Jonas Maebe wrote:
> 
> On 27 May 2006, at 11:01, Bisma Jayadi wrote:
> 
>>> I agree with Michael. And I think the line is clearly drawn. The FPC 
>>> (and more importantly the language syntax itself) design goal, as I
>>> understand it, is to be, as much as possible, platform and
>>> architecture independent and
>>
>> I believe the bit rotation support can be made platform and
>> architecture indepedent. This operation obviously needed regardless
>> the platform or the architecture. It is very important for calculation
>> algorithms and the implementation (e.g. simulation, graphics,
>> encoding, math, etc) and that's why it IS available almost on all
>> modern architectures. Is there any platform/architecture that does not
>> require or provide this operation?
> 
> It is possible to implement a peephole optimization to change the
> shift/or into the native variant of rol/ror if it exists. 

The code currently generated is rather lengthy.

> And I don't
> think any architecture apart from x86 support rol/ror for anything but
> the native word size (at least ppc doesn't).

But it can be done on ppc with two rlw* instructions which is also ok,
no? But dword ror/rol is anyways enough for md5, sha et al iirc.

> 
>>> doesn't need to be "polluted" by adding esoteric functions/(worst
>>> yet)operators becuase they are neat on one particular type of machine
>>> and we just program around them everywhere else.
>>
>> As function it'll pollute pascal syntax,
> 
> Functions never pollute a syntax, since they are inherently part of the
> syntax.
> 
>> but not if it is as operator. And clearly the bit rotation operation
>> is not esoteric. It's just like the reason why shl/shr operator exist.
>> Make rol/ror as operator even make FPC syntax more clear and clean. If
>> shl/shr can exist as operator, then why ror/rol can't?
> 
> As explained earlier, for rol/ror the size of the operands matters. For
> shl/shr it doesn't, and the compiler can covert all operands to the
> native word size before performing the operation (just like it does for
> all other mathematical and logical operations).
> 
>> The problem is... almost everyone need it.
> 
> That is not true, unless almost everyone implements cryptographic
> algorithms.
> 
>> Even the compiler itself! Like what Florian has told us in this
>> thread. :)
> 
> No, the compiler doesn't need it. The post from Florian was about a unit
> in packages.
> 

Actually it does, but it's neither speed critical nor used on all
platforms: search for rotl in
http://svn.freepascal.org/svn/fpc/trunk/compiler/arm/cpubase.pas