[fpc-pascal] rotating bits

[Florian Klaempfl]

Michael Van Canneyt wrote:
> 
> 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.

2002-07-23 21:42  michael <michael.vancanneyt at wisa.be>

	* packages/base/md5/: Makefile, Makefile.fpc, md5.pp, md5.ref,
	md5test.pp:

	+ Initial implementation

>From packages/base/hash/md5.pp

procedure rot(var x: Cardinal; n: Byte);

begin
  x:=(x shl n) or (x shr (32 - n));
end;

You even implemented a rol :)

That's the point why I want to include compiler support: rol/ror is very
important for several cryptographic algorithms.

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

The are somehow exotic but the key to speed up several cryptographic
algorithms.