> > Tomas Hajny wrote: > > > I guess there is no problem in including it. The > > > only questions from my point of view are: > > > > > > 1) Are they useful in general, so that it would > > > make sense to include them either in FPC itself > > > (as opposed to some standalone unit)?
Well, they are useful for specific tasks and algorithms. There were reasons to include them in i386 architecture. But they are obviously less common, than shl/shr. My answer on question two explains, why their place is in units. > > > 2) If they are to be included, should they be > > > included as functions, or possibly even as > > > operators (similarly to existing shl/shr)? Shl/shr already have a little issue: var b0,b1: byte; begin b0:=70; b1:=b0 shl 3; end. emits warning. They do not really pay attention (on intention?) to the size of what they shift. Rol/ror should pay great attention to the size of data they shift. They cannot be implemented in the same manner. > > > 3) If we decide to include them as functions, > > > where (which unit)? Any rtl unit without a lot of $defines, overloading and redefinings should fit. Functions should have names, indicating size: unexpected typecasting may be fatal. > > - they must be available for all cpu platforms, so we need at least a > > generic implementation Even I have supplied some bulky implementation in one of the previous messages (I only wanted them to work, because my knowledge of FPC intrinsics is obviously not enough to ensure fast work). > > - for an efficient implementation, this needs a compiler patch so the > > compiler can really efficiently inline Maybe, it should be done regardless of "rotating bits" topic. > I don't think these functions are so useful that they warrant a compiler > patch. > We can include them in some separate unit, but I would highly object against > putting them in the system unit. > Michael. I don't understand any of your arguments, but it doesn't matter much. Any rtl unit without much overhead suits great: I mean, including them to objfpc or sysutils would be strange. _______________________________________________ fpc-pascal maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
