OSDev.org

I've run into a but of a problem with NASM, it seems to complain that: Exceeds values storable in a byte.
Since an unsigned 8 bit integer can store values up to 0xFF, I think NASM is treating bytes as signed.
All it's doing is spitting out a bunch of warnings, the code itself runs fine.

However, the warnings are incredibly annoying.
I try to never have any (-Wall, -Wextra and -Werror help).

Is there any concept of unsignedness in NASM? Google hasn't been very helpful,
And the Wiki page mentions nothing on the matter.
All else aside, having a way of getting NASM to shut up about the warning would be nice.
Cheers.

Your question might best be posted to the NASM forum
http://forum.nasm.us/

In 16 bit assembly I push "words"
In 32 bit assembly I push "dwords"
I have no knowledge of 8 bit assembly.

TomT

@OP: Bytes are just bytes.

*Integer literals*, on the other hand...


@up: your post gave me some amount of WTFs. "8 bit assembly"? Was there any mention of 8 bit assembly?

According to the x86 manual, push imm8 do sign extend imm8 to current operand size. 128 is indeed over the signed range and it's reasonable for such warning. See volume 2 for detail.

bluemoon wrote:According to the x86 manual, push imm8 do sign extend imm8 to current operand size. 128 is indeed over the signed range and it's reasonable for such warning. See volume 2 for detail.

Makes sense.
In any case, I got around the whole thing by using equivalent signed values (bitwise).
Thank for the help.

EDIT:
PS. If any one runs into the issue; 2's compliment.

Sooo...why not just push a dword?

Nessphoro wrote:Sooo...why not just push a dword?

Why waste stack space and possibly trash your stack if the function being called expects a byte?

m12 wrote:

Nessphoro wrote:Sooo...why not just push a dword?

Why waste stack space and possibly trash your stack if the function being called expects a byte?

Ah, I was expecting that.

In Protected Mode, the stack is push/pop is extended to 4 bytes (for the most part).
When you push 1 byte, on the stack it counts as four regardless.
If a function expects a byte (pop byte) then it will only take the lowest value (since 32-bit is little endian, the low byte is stored first, therefore it is poped first)

So, in reality, you're just making your life harder by using a push byte.

Hi,

Nessphoro wrote:So, in reality, you're just making your life harder by using a push byte.

If you push a byte then pop a byte, it won't matter if the CPU sign extends or zero extends and the opcode will be shorter (2 bytes).

If you push a word or dword then pop a byte, it won't matter if you sign extend or zero extend and the opcode will be longer (5 bytes).

If you push a byte then pop a word or dword, it will matter that the CPU sign extended it (e.g. "push byte 128" then "pop eax" means EAX != 128), which is why NASM gives a warning.

You can disable warnings about number overflows at the command line (e.g. "nasm -w-number-overflow"). This is probably a bad idea, because you might miss problems that you don't know about just to suppress a warning you do know about. You can also disable and enable warnings for any lines of code you want. For example:
This is probably the best way - disable the warning for that one instruction, keep warnings for everything else in case, and still get a short 2-byte opcode.


Cheers,

Brendan

The problem arises when you try to mix asm and C code.

When you push a byte that is over 127 it will be sign extended (NASM treats that number as two's complement, aka negative) and since the number is stored as dword at the stack, when read from C it will be negative even though you might of pushed like 0x80, which clearly is positive.

Can you pop a byte ?

I dont see that in my Intel manual

You can pop a word, dword or qword depending on the address size attributes of the stack segment.

I program x86 in pmode so

push byte 0x80
pop eax
results in eax=0xffffff80

Thanks for pointing out the sign extend properties of push !

TomT

pop al
pop byte ptr [eax]

Both of these will pop a quantity determined by the stack's size attribute and extract the least significant 8 bits