[Nasm-devel] Is that a bug? add ax, 10

[Tim Petschauer]

@mods:

Sorry, used the wrong sender address the first time.


Hey there,


I stumbled upon something that might be a bug in the selection of the 
correct, i.e. shortest, bytecode for adding 8 bit immediates to a larger 
accumulator. At least in the 'bits 16' mode which I'm using at the moment.

Examples follow:

bits 16

add ax, 10    ---> 83 c0 0a

add ax, 1000 ---> 05 e8 03

So for the first instruction the opcode for "add rm16, imm8" is choosen, 
but I think "add reg_ax, imm" can be a byte shorter if it is not wide.

The second instruction is working as expected.


So if that's a bug, I have a couple thoughts on how to fix it:

Since the instuction matching works by moving sequentially through all 
the ADD instructions and "add rm16, imm8" is listed before the "add 
reg_ax, imm" the matcher would stop at the first match and just use what 
it had found.

However, since there is not explicit "add reg_ax, imm8" opcode in the 
instruction data files, the accumulator addition might produce 3 bytes 
anyway and all of this wouldn't matter, except someone saw the need to 
implement such an opcode (or maybe the "add reg_ax, imm8" already can 
handle 8 bits).

I skimmed the data files for the related instructions (or, adc, sbb ...) 
and they seem to have the same structure, so this probably isn't a bug. 
But I wanted to ask about it anyway so I might get an answer why this 
handling of 8bit adds to a 16 bit accumulator was choosen.

Best regards

Tim Petschauer