[Nasm-devel] Redundant prefixes and addressing

[H. P. A. <hp...@zy...>]

I've been working on revamping the address-generation code, and I have
gotten it *almost* where it needs to be (it still accepts stuff like
"mov ebx,[qword foo]", which it shouldn't.)

However, in getting it to this point I made a change which probably was
a bad one in retrospect: I outlawed conflicting prefixes.

In particular, something like:

	a16 a16 a16 a16 nop

... will get collapsed to a mere "a16 nop", and "lock rep nop" will be
illegal (lock and rep are not allowed on the same instruction.)

The motivation came from the observation that NASM handled
user-specified prefixes very discongruently from the instruction itself,
e.g. it would accept things like "a16 mov eax,[esi]", and "a16 mov
eax,[bx]" would get a second prefix added.

I'd like to have opinions on the preferred way to do this -- one option
is to treat e.g. "a32" before as a user-specified prefix "tack this to
the beginning of the instruction and be done with it", and require it to
be inside the brackets in order for it to affect the real instruction
generation, i.e. "a32 mov ax,[bx]" would be accepted, but "mov eax,[a32
foo]" would be required to generate the 6-byte 67 A1 +addr32 form in
64-bit mode.

	-hpa