optimizer artifacts...

[bird-yasm-spam@…]

Yasm 0.4.x (r1366) allows overriding the immediate size optimizing by specifying 'dword' on a push dword 0, or eax, dword ~2 and similar and then get the dword version instead of the sign extended byte version of the instructions. This no longer works with Yasm 0.6.0. Is there a different way of overriding this now or is it just a feature of the new optimizer code?

On the other hand mov eax, [ebx + 0] is no longer encoded as mov eax, [ebx] like yasm 0.4.x (r1366) did. I'm not entirely sure if this is intentional or not.

I'm not sure if this really a bug or more a sort of question / RTFM thing...

[peter@…]

Just like more recent versions of NASM, you now need to use the "strict" keyword in Yasm to truly force the operand size. E.g. push strict dword 0, or eax, strict dword 2.

I can't seem to easily reproduce the behavior you're seeing with mov eax, [ebx+0]. I get the same code generated for it and mov eax, [ebx]. Unless the "0" is really something else in your test code?

[bird-yasm-stam@…]

Thanks for the answer to my first question, as it turned out.

As for the 2nd issue, I think I simplified the example a bit too much. Here is a full length testcase:

struc MYSTRUC
    .zero resd 0
endstruc

foo:
    mov eax, [ecx + MYSTRUC.zero]
    ret

[peter@…]

Yes, I figured as much. The problem here is the way that struc is implemented:

[absolute 0]
MYSTRUC:
.zero resd 0

This is more difficult than some other cases to optimize due to it being a label rather than an EQU. I'll see if I can't fix this however. One other case that also will always generate a "0" immediate is:

label1:
label2:
mov eax, [ecx+label2-label1]

but this is probably a lower priority item, as it will pessimize quite a bit of code.

[peter]

(In [1842]) Move absolute section handling into NASM parser, removing all traces of it from libyasm core. Now absolute sections are tracked locally to the parser and the parser generates EQUs directly for labels in absolute sections.

Fixes #106 and #103.