Re: Linux, X, ld, gcc, linking, shared libraries and stuff
From: Herbert Kleebauer (klee_at_unibwm.de)
Date: 03/29/05
- Next message: Betov: "Re: Linux, X, ld, gcc, linking, shared libraries and stuff"
- Previous message: Betov: "Re: Linux, X, ld, gcc, linking, shared libraries and stuff"
- In reply to: Frank Kotler: "Re: Linux, X, ld, gcc, linking, shared libraries and stuff"
- Next in thread: Betov: "Re: Linux, X, ld, gcc, linking, shared libraries and stuff"
- Reply: Betov: "Re: Linux, X, ld, gcc, linking, shared libraries and stuff"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 29 Mar 2005 10:27:41 +0200
Frank Kotler wrote:
> Herbert Kleebauer wrote:
>
> ...
> > but only shows, that RosAsm (in opposite to NASM) isn't able
> > to solve the problem with the two different push instructions.
>
> To be fair, lets say that RosAsm "doesn't" do this, rather
But then the answer is: RosAsm "doesn't" do it by intention
> than "isn't able to".
But here the answer maybe is: I will show you that RosAsm
also can do it (just wait for the next release).
> it). The only thing RosAsm doesn't do is provide a way for
> the user to say "no, I really want the stupid long form", if
> the operand will fit in a signed byte (other than db ...).
I have given other examples for different encoding for
the same instruction where RosAsm doesn't select the
shortest encoding. This shows, that it isn't done by intention
but because there is a problem with the same name for
different instructions.
> RosAsm's users may be "missing something" from the lack of
> this "feature", but they aren't missing *much*! Arguably,
I don't think RosAsm users are missing something, RosAsm itself
is missing something. It's like as with modern cameras. No
professional photographer would buy a camera which doesn't
allow a manual setting of all the parameters even if he just
always use the automatic mode. It is not because you want to
use it but because you want to be able to use it.
> they have to know to ask for it. With a default to the
> signed byte form, and the ability to specify the dword form,
> Nasm would have had it right (IMO), but it's an imperfect
> world...
I think NASM had it right, if it would use different names
for the different instructions. It's like the short and long
branches. Use a "br.b" for a byte offset and a "br.l" for
a 32 bit offset or simple a "br" if the assembler should decide.
This would be a "PUSH" for the assembler optimized form,
a "PUSH.B" for the sign extended byte push and a "PUSH.L"
for a 32 bit push. (And when implementing this, move also
the size information for all the other instructions from
the operand to the opcode).
> In an ideal world... we would all be very lost and confused,
> because it would be *nothing* like what we're used to!
We don't need an ideal world, it would be sufficient to
get rid of the Intel syntax (as far as assembly programming
is concerned).
- Next message: Betov: "Re: Linux, X, ld, gcc, linking, shared libraries and stuff"
- Previous message: Betov: "Re: Linux, X, ld, gcc, linking, shared libraries and stuff"
- In reply to: Frank Kotler: "Re: Linux, X, ld, gcc, linking, shared libraries and stuff"
- Next in thread: Betov: "Re: Linux, X, ld, gcc, linking, shared libraries and stuff"
- Reply: Betov: "Re: Linux, X, ld, gcc, linking, shared libraries and stuff"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
