rotating bits

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

rotating bits

Пётр Косаревский
Is there high level operator/(inline)function for rotating bits?

Am I supposed to implement rotating bits (like ror/rol in i386 asm) by inline assembler or some ugly workarounds (shifts and or-s)?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: rotating bits

Jonas Maebe-2

On 24 mei 2006, at 10:56, Пётр Косаревский wrote:

> Is there high level operator/(inline)function for rotating bits?

No.

> Am I supposed to implement rotating bits (like ror/rol in i386 asm)  
> by inline assembler or some ugly workarounds (shifts and or-s)?

Yes. I think there's already a feature request to provide these  
operations, but no one worked on it yet.


Jonas_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re[2]: rotating bits

Пётр Косаревский
> On 24 mei 2006, at 10:56, Пётр Косаревский wrote:
> > Is there high level operator/(inline)function for rotating bits?
> No.
> > Am I supposed to implement rotating bits (like ror/rol in i386 asm)  
> > by inline assembler or some ugly workarounds (shifts and or-s)?
> Yes. I think there's already a feature request to provide these  
> operations, but no one worked on it yet.
> Jonas_______________________________________________

Why don't use this code?

{$INLINE ON}
interface
{$IFDEF CPUI386}
 function brol(b: byte; c: byte): byte; assembler; inline;
 function wrol(w: word; c: byte): word; assembler; inline;
 function lrol(l: longword; c: byte): longword; assembler; inline;
 function bror(b: byte; c: byte): byte; assembler; inline;
 function wror(w: word; c: byte): word; assembler; inline;
 function lror(l: longword; c: byte): longword; assembler; inline;
{$ELSE}
 function brol(b: byte; c: byte): byte; inline;
 function wrol(w: word; c: byte): word; inline;
 function lrol(l: longword; c: byte): longword; inline;
 function bror(b: byte; c: byte): byte; inline;
 function wror(w: word; c: byte): word; inline;
 function lror(l: longword; c: byte): longword; inline;
{$ENDIF}

implementation
{$IFDEF CPUI386}
 function brol(b: byte; c: byte): byte; assembler; inline;
   asm
   movb  b,%al
   movb  c,%cl
   rolb  %cl,%al
   movb  %al,result
   end ['al','cl'];
 function wrol(w: word; c: byte): word; assembler; inline;
   asm
   movw  w,%ax
   movb  c,%cl
   rolw  %cl,%ax
   movw  %ax,result
   end ['ax','cl'];
 function lrol(l: longword; c: byte): longword; assembler; inline;
   asm
   movl  l,%eax
   movb  c,%cl
   roll  %cl,%eax
   movl  %eax,result
   end ['eax','cl'];
 function bror(b: byte; c: byte): byte; assembler; inline;
   asm
   movb  b,%al
   movb  c,%cl
   rorb  %cl,%al
   movb  %al,result
   end ['al','cl'];
 function wror(w: word; c: byte): word; assembler; inline;
   asm
   movw  w,%ax
   movb  c,%cl
   rorw  %cl,%ax
   movw  %ax,result
   end ['ax','cl'];
 function lror(l: longword; c: byte): longword; assembler; inline;
   asm
   movl  l,%eax
   movb  c,%cl
   rorl  %cl,%eax
   movl  %eax,result
   end ['eax','cl'];
{$ELSE}
 function brol(b: byte; c: byte): byte; inline;
   var s,r: byte;
   begin
   s:=c and $7;
   r:=byte(b shl s);
   r:=r or byte(b shr (8-s)); // c may be over 8 and should be processed correctly
   brol:=r; // "result" is not supported in inline procedures
   end;
 function wrol(w: word; c: byte): word; inline;
   var s: byte; r: word;
   begin
   s:=c and $f;
   r:=word(w shl s);
   r:=r or word(w shr (16-s)); // c may be over 16 and should be processed correctly
   wrol:=r;
   end;
 function lrol(l: longword; c: byte): longword; inline;
   var s: byte; r: longword;
   begin
   s:=c and $1f;
   r:=longword(l shl s);
   r:=r or longword(l shr (32-s)); // c may be over 32 and should be processed correctly
   lrol:=r;
   end;
 function bror(b: byte; c: byte): byte; inline;
   var s,r: byte;
   begin
   s:=c and $7;
   r:=byte(b shr s);
   r:=r or byte(b shl (8-s)); // c may be over 8 and should be processed correctly
   bror:=r;
   end;
 function wror(w: word; c: byte): word; inline;
   var s: byte; r: word;
   begin
   s:=c and $f;
   r:=word(w shr s);
   r:=r or word(w shl (16-s)); // c may be over 16 and should be processed correctly
   wror:=r;
   end;
 function lror(l: longword; c: byte): longword; inline;
   var s: byte; r: longword;
   begin
   s:=c and $1f;
   r:=longword(l shr s);
   r:=r or longword(l shl (32-s)); // c may be over 32 and should be processed correctly
   lror:=r;
   end;
{$ENDIF}


Comments:
   I. style/consistency
      I didn't use all needed {$if}s: current code should word with range checks on both on i386 and not.
      {$Asmmode} was not used either.
      First symbol denotes type: while shl/shr emit longword, cyclic shifts shouldn't
      Endianness is not supported, because I don't understand, why it should be.
   II. performance
      "Result" is not supported in the inline mode.
      I don't know how to use "ret" to achieve the same goal with fewer commands.

Test:
{$INLINE ON}
program testb;
  uses commonthingies;
var i: byte;    b: byte;    w: word;    l: longword;
begin
write('Enter byte (dec):');readln(b);
for i:=0 to 16 do
  writeln('Orig:',binstr(b,8),'   Left:',binstr(brol(b,i),8),'   Right:',binstr(bror(b,i),8));
write('Enter word (dec):');readln(w);
for i:=0 to 32 do
  writeln('Orig:',binstr(w,16),'   Left:',binstr(wrol(w,i),16),'   Right:',binstr(wror(w,i),16));
write('Enter lw (dec)  :');readln(l);
for i:=0 to 64 do
  writeln('Orig:',binstr(l,32),'   Left:',binstr(lrol(l,i),32),'   Right:',binstr(lror(l,i),32));
end.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re[3]: rotating bits

Пётр Косаревский
>       I don't know how to use "ret" to achieve the same goal with fewer commands.

Well, if I get it right (and it works on my system), the last lines:
  movb %al,result etc. (6 times) should be commented out.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: rotating bits

Tomas Hajny
In reply to this post by Пётр Косаревский
đŁÔŇ ëĎÓÁŇĹ×ÓËÉĘ wrote:
>> On 24 mei 2006, at 10:56, đŁÔŇ ëĎÓÁŇĹ×ÓËÉĘ wrote:
>> > Is there high level operator/(inline)function for rotating bits?
>> No.
>> > Am I supposed to implement rotating bits (like ror/rol in i386 asm)
>> > by inline assembler or some ugly workarounds (shifts and or-s)?
>> Yes. I think there's already a feature request to provide these
>> operations, but no one worked on it yet.
>
> Why don't use this code?
 .
 .
>  function brol(b: byte; c: byte): byte; assembler; inline;
>    asm
>    movb  b,%al
>    movb  c,%cl
>    rolb  %cl,%al
>    movb  %al,result
>    end ['al','cl'];
 .
 .

With register calling convention (which is the default calling convention
in FPC 2.x), it can be reduced just to:

function brol(b: byte; c: byte): byte; assembler; inline;
asm
  rolb  %cl,%al
end;


(and similarly for all the other functions). The first parameter goes to
eax, the second to ecx, and the result is supposed to be in eax again.

Tomas

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re[4]: rotating bits

Пётр Косаревский
> With register calling convention (which is the default calling convention
> in FPC 2.x), it can be reduced just to:
> function brol(b: byte; c: byte): byte; assembler; inline;
> asm
>   rolb  %cl,%al
> end;
> (and similarly for all the other functions). The first parameter goes to
> eax, the second to ecx, and the result is supposed to be in eax again.
> Tomas

Well, I am jealous of your knowledge of the calling conventions.
Did you notice, that in default compiler mode "mov %al,result" does not work?

Anyway, why don't introduce these functions?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[4]: rotating bits

Jonas Maebe-2

On 24 mei 2006, at 16:11, Пётр Косаревский wrote:

>> function brol(b: byte; c: byte): byte; assembler; inline;
>> asm
>>   rolb  %cl,%al
>> end;
>> (and similarly for all the other functions). The first parameter  
>> goes to
>> eax, the second to ecx, and the result is supposed to be in eax  
>> again.
>> Tomas
>
> Well, I am jealous of your knowledge of the calling conventions.
> Did you notice, that in default compiler mode "mov %al,result" does  
> not work?

That is by design. "result" only works in Delphi and ObjFPC modes.  
Otherwise you should use the function name instead of "result".


Jonas

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re[4]: rotating bits

Пётр Косаревский
In reply to this post by Tomas Hajny
> With register calling convention (which is the default calling convention
> in FPC 2.x), it can be reduced just to:
> function brol(b: byte; c: byte): byte; assembler; inline;
> asm
>   rolb  %cl,%al
> end;
> (and similarly for all the other functions). The first parameter goes to
> eax, the second to ecx, and the result is supposed to be in eax again.
> Tomas

Did you test it?

It does not work for me (one-liner).

("result" line does not seem to be needed, but calling conventions used seem to be somewhat different).
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[4]: rotating bits

Jonas Maebe-2

On 24 mei 2006, at 17:09, Пётр Косаревский wrote:

>> function brol(b: byte; c: byte): byte; assembler; inline;
>> asm
>>   rolb  %cl,%al
>> end;
>> (and similarly for all the other functions). The first parameter  
>> goes to
>> eax, the second to ecx, and the result is supposed to be in eax  
>> again.
>> Tomas
>
> Did you test it?
>
> It does not work for me (one-liner).
>
> ("result" line does not seem to be needed, but calling conventions  
> used seem to be somewhat different).

First parameter is in eax, second in edx (third one is ecx)


Jonas_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: rotating bits

Florian Klämpfl
In reply to this post by Пётр Косаревский
Пётр Косаревский wrote:

>> On 24 mei 2006, at 10:56, Пётр Косаревский wrote:
>>> Is there high level operator/(inline)function for rotating bits?
>> No.
>>> Am I supposed to implement rotating bits (like ror/rol in i386 asm)  
>>> by inline assembler or some ugly workarounds (shifts and or-s)?
>> Yes. I think there's already a feature request to provide these  
>> operations, but no one worked on it yet.
>> Jonas_______________________________________________
>
> Why don't use this code?

The inline is useless, assembler procedures aren't really inlinable.

>
> {$INLINE ON}
> interface
> {$IFDEF CPUI386}
>  function brol(b: byte; c: byte): byte; assembler; inline;
>  function wrol(w: word; c: byte): word; assembler; inline;
>  function lrol(l: longword; c: byte): longword; assembler; inline;
>  function bror(b: byte; c: byte): byte; assembler; inline;
>  function wror(w: word; c: byte): word; assembler; inline;
>  function lror(l: longword; c: byte): longword; assembler; inline;
> {$ELSE}
>  function brol(b: byte; c: byte): byte; inline;
>  function wrol(w: word; c: byte): word; inline;
>  function lrol(l: longword; c: byte): longword; inline;
>  function bror(b: byte; c: byte): byte; inline;
>  function wror(w: word; c: byte): word; inline;
>  function lror(l: longword; c: byte): longword; inline;
> {$ENDIF}
>
> implementation
> {$IFDEF CPUI386}
>  function brol(b: byte; c: byte): byte; assembler; inline;
>    asm
>    movb  b,%al
>    movb  c,%cl
>    rolb  %cl,%al
>    movb  %al,result
>    end ['al','cl'];
>  function wrol(w: word; c: byte): word; assembler; inline;
>    asm
>    movw  w,%ax
>    movb  c,%cl
>    rolw  %cl,%ax
>    movw  %ax,result
>    end ['ax','cl'];
>  function lrol(l: longword; c: byte): longword; assembler; inline;
>    asm
>    movl  l,%eax
>    movb  c,%cl
>    roll  %cl,%eax
>    movl  %eax,result
>    end ['eax','cl'];
>  function bror(b: byte; c: byte): byte; assembler; inline;
>    asm
>    movb  b,%al
>    movb  c,%cl
>    rorb  %cl,%al
>    movb  %al,result
>    end ['al','cl'];
>  function wror(w: word; c: byte): word; assembler; inline;
>    asm
>    movw  w,%ax
>    movb  c,%cl
>    rorw  %cl,%ax
>    movw  %ax,result
>    end ['ax','cl'];
>  function lror(l: longword; c: byte): longword; assembler; inline;
>    asm
>    movl  l,%eax
>    movb  c,%cl
>    rorl  %cl,%eax
>    movl  %eax,result
>    end ['eax','cl'];
> {$ELSE}
>  function brol(b: byte; c: byte): byte; inline;
>    var s,r: byte;
>    begin
>    s:=c and $7;
>    r:=byte(b shl s);
>    r:=r or byte(b shr (8-s)); // c may be over 8 and should be processed correctly
>    brol:=r; // "result" is not supported in inline procedures
>    end;
>  function wrol(w: word; c: byte): word; inline;
>    var s: byte; r: word;
>    begin
>    s:=c and $f;
>    r:=word(w shl s);
>    r:=r or word(w shr (16-s)); // c may be over 16 and should be processed correctly
>    wrol:=r;
>    end;
>  function lrol(l: longword; c: byte): longword; inline;
>    var s: byte; r: longword;
>    begin
>    s:=c and $1f;
>    r:=longword(l shl s);
>    r:=r or longword(l shr (32-s)); // c may be over 32 and should be processed correctly
>    lrol:=r;
>    end;
>  function bror(b: byte; c: byte): byte; inline;
>    var s,r: byte;
>    begin
>    s:=c and $7;
>    r:=byte(b shr s);
>    r:=r or byte(b shl (8-s)); // c may be over 8 and should be processed correctly
>    bror:=r;
>    end;
>  function wror(w: word; c: byte): word; inline;
>    var s: byte; r: word;
>    begin
>    s:=c and $f;
>    r:=word(w shr s);
>    r:=r or word(w shl (16-s)); // c may be over 16 and should be processed correctly
>    wror:=r;
>    end;
>  function lror(l: longword; c: byte): longword; inline;
>    var s: byte; r: longword;
>    begin
>    s:=c and $1f;
>    r:=longword(l shr s);
>    r:=r or longword(l shl (32-s)); // c may be over 32 and should be processed correctly
>    lror:=r;
>    end;
> {$ENDIF}
>
>
> Comments:
>    I. style/consistency
>       I didn't use all needed {$if}s: current code should word with range checks on both on i386 and not.
>       {$Asmmode} was not used either.
>       First symbol denotes type: while shl/shr emit longword, cyclic shifts shouldn't
>       Endianness is not supported, because I don't understand, why it should be.
>    II. performance
>       "Result" is not supported in the inline mode.
>       I don't know how to use "ret" to achieve the same goal with fewer commands.
>
> Test:
> {$INLINE ON}
> program testb;
>   uses commonthingies;
> var i: byte;    b: byte;    w: word;    l: longword;
> begin
> write('Enter byte (dec):');readln(b);
> for i:=0 to 16 do
>   writeln('Orig:',binstr(b,8),'   Left:',binstr(brol(b,i),8),'   Right:',binstr(bror(b,i),8));
> write('Enter word (dec):');readln(w);
> for i:=0 to 32 do
>   writeln('Orig:',binstr(w,16),'   Left:',binstr(wrol(w,i),16),'   Right:',binstr(wror(w,i),16));
> write('Enter lw (dec)  :');readln(l);
> for i:=0 to 64 do
>   writeln('Orig:',binstr(l,32),'   Left:',binstr(lrol(l,i),32),'   Right:',binstr(lror(l,i),32));
> end.
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[4]: rotating bits

Tomas Hajny
In reply to this post by Jonas Maebe-2
Jonas Maebe wrote:
> On 24 mei 2006, at 17:09, ����
�О�а�ов�киК wrote:

>
>>> function brol(b: byte; c: byte): byte; assembler; inline;
>>> asm
>>>   rolb  %cl,%al
>>> end;
>>> (and similarly for all the other functions). The first parameter
>>> goes to
>>> eax, the second to ecx, and the result is supposed to be in eax
>>> again.
>>> Tomas
>>
>> Did you test it?
>>
>> It does not work for me (one-liner).
>>
>> ("result" line does not seem to be needed, but calling conventions
>> used seem to be somewhat different).
>
> First parameter is in eax, second in edx (third one is ecx)

Yes, of course, sorry for confusion... :-( Anyway, loading of the first
parameter can be still skipped (and the stack frame is probably not useful
in this case either). So you'd get:

function brol(b: byte; c: byte): byte; assembler; nostackframe;
asm
  movb  %dl,%cl
  rolb  %cl,%al
end ['cl'];


Tomas

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: rotating bits

L505
In reply to this post by Пётр Косаревский
There is this page which might help some
http://www.merlyn.demon.co.uk/del-bits.htm
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re[6]: rotating bits

Пётр Косаревский
In reply to this post by Tomas Hajny
>> 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)?

2. Are calling conventions a subject to change? Are there ways to know
about calling convention used (with {$ifdefs} e.g.)?

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re[4]: rotating bits

Пётр Косаревский
In reply to this post by L505
L> There is this page which might help some
L> http://www.merlyn.demon.co.uk/del-bits.htm

Thank you, it was interesting.

But it was not very helpful.

It's interesting, that they don't seem to care much about rotating
bytes or words. (Asm rotating 64-bits was fascinating!)

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re[6]: rotating bits

Tomas Hajny
In reply to this post by Пётр Косаревский
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)?

2) If they are to be included, should they be
included as functions, or possibly even as
operators (similarly to existing shl/shr)?

3) If we decide to include them as functions,
where (which unit)?

I personally don't have an answer for the first
question. What would be the typical use? For the
rest, my suggestion would be operators rather
than functions (if they are really needed), but
that would need somebody else than me to add the
appropriate compiler support (probably not a big
deal, I guess).


> 2. Are calling conventions a subject to change?

Possibly, although I wouldn't expect it any more.


> Are there ways to know
> about calling convention used (with {$ifdefs} e.g.)?

If you need to support pre-2.x versions (and
especially early 1.9.x betas when the change
happened), then you could use {$IFDEF REGCALL}.
For 2.x+, using {$CALLING REGISTER} can be used
to force that calling convention (regardless of
the default).

Tomas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: rotating bits

Florian Klämpfl
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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: rotating bits

Michael Van Canneyt


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.
We can include them in some separate unit, but I would highly object against
putting them in the system unit.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: rotating bits

Tomas Hajny
In reply to this post by Florian Klämpfl
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

Generic implementation in Pascal has already been provided in this thread
as well, so this isn't an issue.


> - for an efficient implementation, this needs a compiler patch so the
> compiler can really efficiently inline

Would this apply for the operator case too? Isn't it then similar to
shl/shr (which "just work" now as well - even without special inlining
support)?

Of course, this would only make sense if we're convinced about the general
usefulness of such operators.

Tomas

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: rotating bits

Florian Klämpfl
In reply to this post by Michael Van Canneyt
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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re[2]: rotating bits

Пётр Косаревский
In reply to this post by Michael Van Canneyt
> > 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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12