#6 need a way to specify the SIB scale
Currently there is no way to force the use of a SIB
byte with a particular scale. I suggest SIB0, SIB1,
SIB2, and SIB3, as demonstrated by the following
example:
mov eax,[ eax] ; works
mov eax,[ byte eax] ; works
mov eax,[ dword eax] ; works
mov eax,[ nosplit eax] ; see bug 560953 :-)
mov eax,[ sib0 eax]
mov eax,[ sib1 eax]
mov eax,[ sib2 eax]
mov eax,[ sib3 eax]
mov eax,[ byte sib0 eax]
mov eax,[ byte sib1 eax]
mov eax,[ byte sib2 eax]
mov eax,[ byte sib3 eax]
mov eax,[dword sib0 eax]
mov eax,[dword sib1 eax]
mov eax,[dword sib2 eax]
mov eax,[dword sib3 eax]
should result in
8B00
8B4000
8B8000000000
8B040500000000
8B0420
8B0460
8B04A0
8B04E0
8B442000
8B446000
8B44A000
8B44E000
8B842000000000
8B846000000000
8B84A000000000
8B84E000000000
Geez, sixteen ways of coding one instruction... :-)
Logged In: YES
user_id=58697
Moving to feature request. Probably post-0.99.
Logged In: YES
user_id=363603
I'm going to take a look at this. If it's anything like the
NOSPLIT request, it shouldn't be all that difficult to sort out (it
will involve more code, but I think only one more area of code
will be affected).
Logged In: NO
You could try the following implementation.
In nasm.h, add EAF_SIB0=0x10, EAF_SIB1=0x20, EAF_SIB2=0x40, and EAF_SIB3=0x80.
In parser.c, add support for the SIB0, SIB1, SIB2, and SIB3 qualifiers. They'd set the EAFs.
In assemble.c, use the four new EAFs to determine which SIB scale is to be used.
Last but not least, document the new qualifiers. Including their precedence versus NOSPLIT.
Logged In: YES
user_id=363603
That's the first thing I tried, but when I do just that any
instruction that uses the SIBx qualifier generates an error. I
have each of the examples below in my test file, and each of
them generates the error
error: parser: expecting ]
for each line that has an SIBx ea qualifier. I'm still looking into
why.
Logged In: YES
user_id=363603
I've narrowed it down to the fact that the first specifier that is
not recognised is the 9th element in the enum that defines
them. That gives me some hints of what to look for (not sure
where yet, but at least I'm getting there). Additionally, it looks
like I'm going to have to rewrite part of the ea generationcode,
as currently it will only allow one specifier for the ea, and
where I've got it corectly assembling sib0 and sib1, it won't
assemble "byte sib0" or "bytesib1". That's academic until I
get it working with sib2 and sib3 as well without breaking
anything else though :)
Logged In: YES
user_id=363603
I have sorted out part of the problem, and I now have apatch
that will allow the use of SIBx qualifiers on their own, but
using them with BYTE and DWORD is going to take a lot
more work. Im submitting my current patch to the mailing list
for comment, and may ahve it upladed in the next day or so,
but to have it work alongside BYTE and DWORD will mean
some existing code needs rewriting.
As rewriting existing code to the extent that I think is needed
for this will affect other code (risking breaking it even), I'm
propsoing to postpone this until after 0.99 has been released,
unless I'm told it should be cnsidered urgent.
If you want my current patch before it is approved or more
work is done on it, then tell me your email address and I'll
send it to you. The NOSPLIT enhancement is included in
0.98.34, and the current patch adds the next 4 lines ofyour
requested code. ie:
mov eax,[ sib0 eax]
mov eax,[ sib1 eax]
mov eax,[ sib2 eax]
mov eax,[ sib3 eax]
I don't ecxpect the remaining code to be too difficult, the main
reason I proposeto postpone it is because of the risk of
breaking other code at the same time, which would in turn
affect the release time of 0.99. This patch only adds a few
options and does not risk any other code :)
Logged In: YES
user_id=363603
OK, I have a full patch for this item now. It's currently being
tested, if you want to help test it let me know.
It turned out to be simpler than I expected, as including
options to use size overrides with the SIB qualifiers just
meant changing an "if" to a "while" - saved a lot of hunting
around, when 15 minute rest triggered that brainwave :)
Logged In: YES
user_id=804543
Originator: NO
As discussed on the nasm-devel mailing list
earlier today, the A0-A3 MOVs will require
special treatment.
That is, if MOV is used with AL/AX/EAX/RAX
as one operand, and an effective address as
the other operand, and said EA consists of
just a displacement (i.e. just [disp] -- no
registers), but said EA contains a SIB[0123]
qualifier, then the assembler must...
1) not pick the A0-A3 encoding, or
2) pick A0-A3, but warn that SIB[0123] got ignored, or
3) cause an error.
While 1) is the most user friendly choice, 2)
or 3) may have to be picked for performance
reasons: slowing down the critical matching
loop for this special case may be undesired.
I plan to look into the details...
changes for A0-A3 MOV special treatment
Logged In: YES
user_id=804543
Originator: NO
Attached find the necessary changes for
the special treatment of A0-A3 MOVs.
As it turns out, they don't result in a
performance degradation after all -- at
least not for me. :)
File Added: mov_a0_a3_vs_sib01234.changes