Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Suggested improvement for Wasm: Removing register/label name conflicts
16 views
Skip to first unread message
Hans-Bernhard Bröker
Jan 25, 2012, 6:37:54 PM1/25/12
to
On 25.01.2012 17:39, Paul K. McKneely wrote:
> I don't know if there is a better place to suggest improvements
> for the wasm assembler.
That would be the contributors' newsgroup. X-post and F'up2 set.
> I am using a calling convention that does not place underscores
> in label names. As a consequence, I can't have variables and other
> label names that are the same as registers and other conflicting
> names etc.
Hmmm... sounds to me like you've just demonstrated that that calling
convention needs re-thinking.
> However, only memory addresses with label names
> should ever use a pointer qualifier such as "PTR WORD" preceding
> a memory label. If wasm was modified so that it would force the
> following label name to be interprested as a memory label, then its
> use could remove the restriction from using register names as memory
> identifiers.
I'm afraid you have that backwards. Just because in _one_ particular
use case register names can be disallowed safely, that doesn't mean you
can mix up register names with asm symbol names in _all_other_ use
cases. And only in the latter case would it be useful to allow this.
Unfortunately, wasm doesn't do this. If I write a statement
> such as...
>
> add ax,ptr word ax
>
> ...it just generates code for...
>
> add ax,ax
That's arguably a good thing. That whole WORD PTR nonsense is one of
the silliest pieces of assembly language syntax ever "invented", anyway.
> I don't know if there is a better place to suggest improvements
> for the wasm assembler.
That would be the contributors' newsgroup. X-post and F'up2 set.
> I am using a calling convention that does not place underscores
> in label names. As a consequence, I can't have variables and other
> label names that are the same as registers and other conflicting
> names etc.
Hmmm... sounds to me like you've just demonstrated that that calling
convention needs re-thinking.
> However, only memory addresses with label names
> should ever use a pointer qualifier such as "PTR WORD" preceding
> a memory label. If wasm was modified so that it would force the
> following label name to be interprested as a memory label, then its
> use could remove the restriction from using register names as memory
> identifiers.
I'm afraid you have that backwards. Just because in _one_ particular
use case register names can be disallowed safely, that doesn't mean you
can mix up register names with asm symbol names in _all_other_ use
cases. And only in the latter case would it be useful to allow this.
Unfortunately, wasm doesn't do this. If I write a statement
> such as...
>
> add ax,ptr word ax
>
> ...it just generates code for...
>
> add ax,ax
That's arguably a good thing. That whole WORD PTR nonsense is one of
the silliest pieces of assembly language syntax ever "invented", anyway.
Paul K. McKneely
Jan 25, 2012, 8:37:28 PM1/25/12
to
>> However, only memory addresses with label names
>> should ever use a pointer qualifier such as "PTR WORD" preceding
>> a memory label. If wasm was modified so that it would force the
>> following label name to be interprested as a memory label, then its
>> use could remove the restriction from using register names as memory
>> identifiers.
>
> I'm afraid you have that backwards. Just because in _one_ particular use
> case register names can be disallowed safely, that doesn't mean you can
> mix up register names with asm symbol names in _all_other_ use cases. And
> only in the latter case would it be useful to allow this.
I'm sure I can safely assume that wasm will never interpret
>> should ever use a pointer qualifier such as "PTR WORD" preceding
>> a memory label. If wasm was modified so that it would force the
>> following label name to be interprested as a memory label, then its
>> use could remove the restriction from using register names as memory
>> identifiers.
>
> I'm afraid you have that backwards. Just because in _one_ particular use
> case register names can be disallowed safely, that doesn't mean you can
> mix up register names with asm symbol names in _all_other_ use cases. And
> only in the latter case would it be useful to allow this.
_ax or ax_ as a register name. So it would be safe to use "word ptr"
to force memory label interpretation is all cases. The only use
for "word ptr" is for labels that represent memory locations anyway.
> Unfortunately, wasm doesn't do this. If I write a statement
>> such as...
>>
>> add ax,ptr word ax
>>
>> ...it just generates code for...
>>
>> add ax,ax
>
> That's arguably a good thing. That whole WORD PTR nonsense is one of the
> silliest pieces of assembly language syntax ever "invented", anyway.
designator such as ADD.W ax,label we are stuck with it.
The "word ptr" this is the only way to over-ride the size given
in the declaration for the label. Otherwise, you couldn't access
the low or high half of a DWORD without a freakin assembly error.
Paul K. McKneely
Jan 25, 2012, 8:41:58 PM1/25/12
to
Sorry. I got the "ptr word" backwards. It should have read "word ptr".
Paul K. McKneely
Jan 26, 2012, 8:38:07 AM1/26/12
to
> Hmmm... sounds to me like you've just demonstrated that that calling
> convention needs re-thinking.
For the developers of wasm or for my choice of calling conventions?
> convention needs re-thinking.
I'm not using the calling convention for its lack of changing the name
by adding underscores. I'm using it because I need its actually
interface characteristics. I can't change my calling convention just
to alter what is really a side effect. I need the actual interface method.
> That's arguably a good thing. That whole WORD PTR nonsense is one of the
> silliest pieces of assembly language syntax ever "invented", anyway.
is a register name and not a label representing memory. The size is already
implied in the register name itself and, besides, it is not being used as a
pointer ([eax] would be, but that is a different matter). And because you
don't even like the syntax, I am bewildered why you think that permitting
it is in your words "arguably a good thing".
Paul K. McKneely
Jan 26, 2012, 12:16:37 PM1/26/12
to
I just realized that syntax like "byte ptr" is used for
registers such as:
movsx ax,byte ptr al
In order to make what I suggested work you would
have to change this syntax to:
movsx ax,byte al
After all, al is not a pointer. But you still need to
specify the source's size when it is different from
the destination register even when the source is a
register.
registers such as:
movsx ax,byte ptr al
In order to make what I suggested work you would
have to change this syntax to:
movsx ax,byte al
After all, al is not a pointer. But you still need to
specify the source's size when it is different from
the destination register even when the source is a
register.
Wilton Helm
Jan 26, 2012, 2:30:14 PM1/26/12
to
>That whole WORD PTR nonsense is one of the silliest pieces of assembly
> >language syntax ever "invented", anyway.
Agreed. Intel wanted to avoid the #constant syntax that other assemblers
> >language syntax ever "invented", anyway.
were using and thought they could automatically figure out whether a
constant load or a memory load was intended. But it actually makes
programming less intuitive and mistakes easier to make and harder to spot.
You still can't get away from the fact that a label which refers to a memory
location may be a load from memory, or might need to be a pointer load
(constant).
But the bottom line for the OP is that Intel set the standard for x86
syntax, with some help from Microsoft and any one who does not conform
creates an island of incompatibility, that makes it all but impossible to
import code from anywhere else.
Myself I'd like a more Motorola like syntax with # and load and store
(instead of move). Or even better, syntax similar to Analog Devices DSPs
that made assembly language as close to C as possible instead of as
different as possible. But even I couldn't take the hit to legacy code.
Wilton
Hans-Bernhard Bröker
Jan 26, 2012, 4:26:22 PM1/26/12
to
On 26.01.2012 02:37, Paul K. McKneely wrote:
> I'm sure I can safely assume that wasm will never interpret
> _ax or ax_ as a register name. So it would be safe to use "word ptr"
> to force memory label interpretation is all cases. The only use
> for "word ptr" is for labels that represent memory locations anyway.
Or it could be a constant address expression involving a label.
> I'm sure I can safely assume that wasm will never interpret
> _ax or ax_ as a register name. So it would be safe to use "word ptr"
> to force memory label interpretation is all cases. The only use
> for "word ptr" is for labels that represent memory locations anyway.
Leif Ekblad
Jan 26, 2012, 5:32:38 PM1/26/12
to
What's wrong with this (it is perfectly legal and works with WASM):
movsx ax,al
There is no need to specify size when the source is a register.
This is different though:
movsx eax,[bx]
As there are two possible interpretations:
movsx eax,byte ptr [bx]
movsx eax,word ptr [bx]
OTOH, this is not ambigous:
movsx ax,[bx]
as the only possible interpretation is:
movsx ax,byte ptr [bx]
Leif Ekblad
movsx ax,al
There is no need to specify size when the source is a register.
This is different though:
movsx eax,[bx]
As there are two possible interpretations:
movsx eax,byte ptr [bx]
movsx eax,word ptr [bx]
OTOH, this is not ambigous:
movsx ax,[bx]
as the only possible interpretation is:
movsx ax,byte ptr [bx]
Leif Ekblad
Paul K. McKneely
Jan 27, 2012, 9:20:29 AM1/27/12
to
After reviewing what all has been said, it looks like changing
the syntax or even the meaning of syntax regarding "? ptr" is
not feasible. I have re-read the User Guide on the argument
passing options. The register passing options add a trailing
underscore to function names and a leading underscore to
data labels. Stack passing options add no underscores to label
names.
One thing that could address my concern is if there were a
switch that would force an additional underscore prefix to all
label names. This option would be turned off by default so it
would not affect legacy code or existing users not interested
in the option. With this, the only issue would be potential
conflict with symbols that the compiler already defines that
have leading underscores. Otherwise, it looks like the users
of my compiler will have to avoid datum names that conflict
with register names and other pre-defined labels.
Thank you all for all your input.
the syntax or even the meaning of syntax regarding "? ptr" is
not feasible. I have re-read the User Guide on the argument
passing options. The register passing options add a trailing
underscore to function names and a leading underscore to
data labels. Stack passing options add no underscores to label
names.
One thing that could address my concern is if there were a
switch that would force an additional underscore prefix to all
label names. This option would be turned off by default so it
would not affect legacy code or existing users not interested
in the option. With this, the only issue would be potential
conflict with symbols that the compiler already defines that
have leading underscores. Otherwise, it looks like the users
of my compiler will have to avoid datum names that conflict
with register names and other pre-defined labels.
Thank you all for all your input.
Paul K. McKneely
Jan 27, 2012, 9:53:31 AM1/27/12
to
>What's wrong with this (it is perfectly legal and works with WASM):
> movsx ax,al
> There is no need to specify size when the source is a register.
> This is different though:
> movsx eax,[bx]
You made a good point. It seems that registers really
> movsx ax,al
> There is no need to specify size when the source is a register.
> This is different though:
> movsx eax,[bx]
should never need "? ptr" syntax which was my point
to begin with. The size is implied in the register name
itself. And when you do an indirection such as [bx]
then the source operand is indeed in memory so the
syntax makes sense since [bx] is a pointer and the
size specifier is sometimes needed as you indicated.
Unfortunately, wasm permits:
movsx ax,byte ptr al
and interprets al as a register and not a label. That is
the problem because the programmer can't access
a variable named al. But since you never need to write
"? ptr" prefix before a register name (as you have
demonstrated), why would it be bad to alter the
assembler so that, when "? ptr" is encountered prior
to a label that happened to be the same as a register
name then the assembler would then recognize it as
a memory address instead of a register. However,
wasm doesn't allow you to create a public label in
memory such as ax and flags an error. Apparently,
register names are reserved words and can't be used as
variable or other label names. If I write:
ax: db "This is a test",0
...then wasm complains about the colon. For
_ax: db "This is a test",0
...there is no error. And when you write:
ax db "This is a test",0
...wasm does not complain. Looks like I can create
a label with a register name as long as I don't use a
colon. However, I can't access it because the following
generates an operand error complaint by wasm:
lea eax,byte ptr ax
Looks like there are inconsistencies in wasm and
in x86 assembly language beyond just Watcom.
0 new messages