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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
