From:	ovek AT arcticnet DOT no (Ove Kaaven)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Bug in NASM (possibly old)
Date:	Sun, 16 Nov 1997 05:58:07 GMT
Organization:	Arctic Net AS
Lines:	53
Message-ID:	<346e867f.46217080@news.arcticnet.no>
References:	<Pine DOT LNX DOT 3 DOT 91 DOT 971114231102 DOT 1415A-100000 AT aditya DOT unigoa DOT ernet DOT in>
NNTP-Posting-Host:	alwayscold.darkness.arcticnet.no
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

"Gurunandan R. Bhat" <grbhat AT unigoa DOT ernet DOT in> wrote:

>On Sat, 15 Nov 1997, Ove Kaaven wrote:
>> "Gurunandan R. Bhat" <grbhat AT unigoa DOT ernet DOT in> wrote:
>> 
>> >	When I push a segment register 
>> >	push cs
>> >	the stack pointer gets decremented by 4 instead of 2. 
>> 
>> I don't use NASM myself, but this is not a bug. This is correct
>> behaviour. When you are working in 32-bit protected mode, all
>> quantities pushed onto the stack must be 32-bit (4 bytes) to avoid
>> misaligning the stack.
>
>Thank you for pointing this out. What I should have added is that while 
>"push cs" pushes a 4-byte quantity, "pop cx" pops a 2-byte one. I would 
>have expected the behaviour to be consistent, especially since cs cannot 
>be extended :) 

The Intel instruction set has no means of pushing/popping a 32-bit
zero-extended 16-bit general register with only one instruction. You
have to use "pop ecx" to pop the entire 32-bit value.

Accessing a segment register as 32-bit, however, will apparently
always behave as if it was zero-extended to 32-bit.

It would seem this 16-bit segment register business creates a whole
lot of confusion, and I'm sure Intel themselves are aware of it...

>> Using 16-bit push/pops on a 32-bit stack is
>> generally not acceptable. I suggest fixing your GAS equivalent to read
>> 
>> pushl %cs
>> 
>
>Will remember that. Though I have seen pushw's in the DJGPP sources.

Though it is possible to get away with it, this is not good practice,
is somewhat slower (from both the 16-bit prefix byte and the
misalignment), and definitely not recommended by Intel. But I doubt
anyone will bother to fix that unless someone get troubles with it,
which isn't very probable (unless the Alignment Check Fault is enabled
for some reason, which also isn't very probable).

>The 
>good news is that the authors of NASM have released 0.96 yesterday with 
>extensive documentation and a mention of the fact that "push  sreg" 
>pushes 4 bytes while "push reg16" pushes 2-bytes. They have rferred to 
>this (feature) behaviour as "slightly odd" :)

The Intel x86 architecture itself is "slighly odd"... and NASM is just
an assembler for it. Not their fault.

- Raw text -