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
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
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
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
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.
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
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
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 on
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
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
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
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 implementation,
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
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,
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
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 pollution
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 -
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
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
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 -
đŁÔŇ ëĎÓÁŇĹ×ÓËÉĘ 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
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
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
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
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
Пётр Косаревский 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
Jonas Maebe wrote:
On 24 mei 2006, at 17:09, Đ#65533;Ń#65533;Ń#65533;Ń#65533;
Đ#65533;ĐžŃ#65533;Đ°Ń#65533;овŃ#65533;киК 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
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
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;
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!)
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
31 matches
Mail list logo
