[fpc-pascal] rotating bits

[Michael Van Canneyt]

On Thu, 25 May 2006, Florian Klaempfl wrote:

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

I program since 1984, and I have never seen these instructions used.

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

Well, if we're going in that direction anyway: 
Why not include all possible assembler instructions then ?

Let's be serious. You must draw the line somewhere.
I think these instructions are so exotic, they are pollution of the system unit.

Michael.