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 <[EMAIL PROTECTED]>
* 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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
