[fpc-pascal] rotating bits

[Jonas Maebe]

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. 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).

>> 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.


Jonas