OR SP,SP ?

Programming, for all ages and all languages.
Post Reply
asmfreak
Posts: 6
Joined: Wed Jan 02, 2008 11:41 am

OR SP,SP ?

Post by asmfreak »

I am just disassembling the Int 16h handler provided by my BIOS. I came across the following instruction:

Code: Select all

or sp,sp
Has anyone ever seen something like that ? Since it doesn't change the SP register, the only purpose I could think of would be to clear the zero flag, because SP will usually not be zero. This would seem logical, because functions 01h and 11h need to return with the zero flag set or cleared, depending on the state of the keyboard buffer, and because I also encountered the following line

Code: Select all

cmp sp,sp
which again doesn't change the SP register but always sets the zero flag, regardless of the value of SP.

But is it really safe to assume that SP will NEVER be zero ?
User avatar
AJ
Member
Member
Posts: 2646
Joined: Sun Oct 22, 2006 7:01 am
Location: Devon, UK
Contact:

Post by AJ »

Hi,

That is indeed strange. I wonder what the context is? It's not just to test whether SP = 0, is it (is the next instruction a jz or a jnz)? In real mode, it would certainly not be safe to assume that SP is never zero (although you may want to test if it is, because that would mean that you are about to overrun the stack segment, IIRC).

Cheers,
Adam
asmfreak
Posts: 6
Joined: Wed Jan 02, 2008 11:41 am

Post by asmfreak »

AJ wrote:That is indeed strange. I wonder what the context is? It's not just to test whether SP = 0, is it (is the next instruction a jz or a jnz)?
After a few other instructions the interrupt handler returns with IRET 2, so the state of the flags register is returned to the code that called Int 16h.
AJ wrote:In real mode, it would certainly not be safe to assume that SP is never zero (although you may want to test if it is, because that would mean that you are about to overrun the stack segment, IIRC).
I have never defined a stack myself. I know that every PUSH/PUSHF/CALL/INT instruction decrements SP, and the most straightforward solution would be of course to define zero as the stack limit. But wouldn't it be possible to define a stack that "wraps" around to FFFEh after reaching a value of 0000h, like this:

Code: Select all

FFFE
FFFC
...
E002
E000 <- Stack limit

Unused
Memory

1FFE <- Starting address
1FFC
...
0002
0000
I know this seems far-fetched, but I don't think any exception is raised in real mode, if SP contains 0 and one of these instructions is executed.

Is it a kind of "unwritten" programming rule that the stack must occupy a contiguous block of memory, so that a value of zero will only occur just before a stack overrun ? I wonder why they don't use a more complicated but more reliable method of clearing the zero flag.
User avatar
JamesM
Member
Member
Posts: 2935
Joined: Tue Jul 10, 2007 5:27 am
Location: York, United Kingdom
Contact:

Post by JamesM »

But wouldn't it be possible to define a stack that "wraps" around to FFFEh after reaching a value of 0000h, like this:
This is the exact reason the A20 hack had to be created...
User avatar
JAAman
Member
Member
Posts: 879
Joined: Wed Oct 27, 2004 11:00 pm
Location: WA

Post by JAAman »

JamesM wrote:
But wouldn't it be possible to define a stack that "wraps" around to FFFEh after reaching a value of 0000h, like this:
This is the exact reason the A20 hack had to be created...
not quite...


yes, it does 'wrap around' just like that, but the A20 'hack' has a completely different purpose and doesnt affect this at all
Post Reply