On 28 May 2006, at 15:51, Jonas Maebe wrote:
But it can be done on ppc with two rlw* instructions which is also
ok,
no?
I think it needs three: to to rotate left/right, one to insert the
overflow at the end/start, and one to mask the overfow at the end/
start.
No, two is actually indee
On 28 May 2006, at 15:45, Florian Klaempfl wrote:
It is possible to implement a peephole optimization to change the
shift/or into the native variant of rol/ror if it exists.
The code currently generated is rather lengthy.
Of course, but it's going to be a pretty consistent pattern which can
Jonas Maebe wrote:
>
> On 27 May 2006, at 11:01, Bisma Jayadi wrote:
>
>>> I agree with Michael. And I think the line is clearly drawn. The FPC
>>> (and more importantly the language syntax itself) design goal, as I
>>> understand it, is to be, as much as possible, platform and
>>> architecture
On 27 May 2006, at 11:01, Bisma Jayadi wrote:
I agree with Michael. And I think the line is clearly drawn. The
FPC (and more importantly the language syntax itself) design
goal, as I understand it, is to be, as much as possible, platform
and architecture independent and
I believe the bi
I agree with Michael. And I think the line is clearly drawn. The FPC (and
more importantly the language syntax itself) design goal, as I understand it,
is to be, as much as possible, platform and architecture independent and
I believe the bit rotation support can be made platform and architec
[EMAIL PROTECTED] wrote:
>
>> Michael Van Canneyt wrote:
>
>>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
>
> Michael Van Canneyt wrote:>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.
I agree with Micha
a := b ror c;
x := y rol z;
It would wreck havoc with typing. What should the result be of "1 ror
1"? $80? $8000? $8000? $8000? $8000 on 32 bit and
$8000 on 64 bit cpus?
I believe the compiler knows the datatype and make an appropriate rotate action
based o
> Adding new operators is much more work and error prone than
Agree. I never made a compiler, and I hope I won't, nor interested. :D
I did make a simple SQL engine, though. AFAIK, adding a new operator, especially
when a "similar" operator has existed before, wouldn't be too difficult. But, I
On 26 May 2006, at 16:36, Bisma Jayadi wrote:
Agree! Since these are very important and relatively commonly used,
I think it'd be better if they're implemented as new operators
("ror" and "rol") rather than as functions. Say we'll able to code
like this:
a := b ror c;
x := y rol z;
Just
Bisma Jayadi wrote:
>> That's the point why I want to include compiler support: rol/ror is very
>> important for several cryptographic algorithms.
>
> Agree! Since these are very important and relatively commonly used, I
> think it'd be better if they're implemented as new operators ("ror" and
> "
That's the point why I want to include compiler support: rol/ror is very
important for several cryptographic algorithms.
Agree! Since these are very important and relatively commonly used, I think it'd
be better if they're implemented as new operators ("ror" and "rol") rather than
as functions
> Well, if we're going in that direction anyway:
> Why not include all possible assembler instructions then ?
Because some of them are not designed for calculations. But ror/rol are.
> Let's be serious. You must draw the line somewhere.
> I think these instructions are so exotic, they are pollut
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
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)
>
> But the problem with ROR/ROL is that any real use over shr/shl uses a hard
> to model carry flag?
Ugh, I don't understand well, but the talk is about rotating bits, no low level
features like CF are requested (it doesn't mean very much if you rotate by
several bits).
Who talked about CF? I di
Marco van de Voort wrote:
>>> 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 impl
> >
> > 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 need
> > 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
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, loadi
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 (a
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> paramet
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
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 cas
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!)
__
>> 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
There is this page which might help some
http://www.merlyn.demon.co.uk/del-bits.htm
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
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
Пётр Косаревский 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)?
>> Y
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 y
> 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 seco
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,
> 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 seco
đŁÔŇ ëĎÓÁŇĹ×ÓËÉĘ 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)?
>>
> 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 - fpc-pascal@l
> 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
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 featur
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 - fpc-pascal@lists.freepascal.
38 matches
Mail list logo
