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
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)
>
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
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
Пётр Косаревский 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 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
22 matches
Mail list logo
