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: NNTP-Posting-Host: alwayscold.darkness.arcticnet.no To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk "Gurunandan R. Bhat" wrote: >On Sat, 15 Nov 1997, Ove Kaaven wrote: >> "Gurunandan R. Bhat" 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.