[fpc-pascal] rotating bits

[Florian Klaempfl]

Michael Van Canneyt wrote:
> 
> On Thu, 25 May 2006, Florian Klaempfl wrote:
> 
>> Tomas Hajny wrote:
>>> On 25 May 06, at 0:10, ϸňđ Ęîńŕđĺâńęčé ń mail.ru wrote:
>>>
>>>>>> First parameter is in eax, second in edx (third one is ecx)
>>>> TH> Yes, of course, sorry for confusion... :-( Anyway, loading of the first
>>>> TH> parameter can be still skipped (and the stack frame is probably not useful
>>>> TH> in this case either). So you'd get:
>>>> TH> function brol(b: byte; c: byte): byte; assembler; nostackframe;
>>>> TH> asm
>>>> TH>   movb  %dl,%cl
>>>> TH>   rolb  %cl,%al
>>>> TH> end ['cl'];
>>>> TH> Tomas
>>>>
>>>> 1. So, is there any problem with including this functions and bit checks
>>>> (bt./bs. in intel assembler: writing (a and (1 shl i)) isn't great too)?
>>> 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)?
>> - they must be available for all cpu platforms, so we need at least a
>> generic implementation
>> - for an efficient implementation, this needs a compiler patch so the
>> compiler can really efficiently inline
> 
> I don't think these functions are so useful that they warrant a compiler patch.

They give the programmer access to CPU instructions which can speed up
certain algorithms without the need to write assembler.

> We can include them in some separate unit, but I would highly object against 
> putting them in the system unit.

They make no sense then. Going through the whole calling sequence is
slower imo than or'ing shl/shr:
function brol(b: byte; c: byte): byte;inline;
  begin
    result:=(b shr (8-c)) or (b shl c);
  end;

which can be inlined perfectly by the compiler.

That's also why I added the endian conversion functions to the system
unit, e.g. the compiler can benefit a lot if they are implemented in a
CPU dependend way.