Page 1 of 1

OSDEV WIkI Babystep tutorial

Posted: Wed Apr 18, 2012 9:47 pm
by TreahBlade
Hello I wanted to bring up a question here about the below code from the Babystep4 page.

Code: Select all

[ORG 0x7c00]      ; add to offsets
   xor ax, ax    ; make it zero
   mov ds, ax   ; DS=0
   mov ss, ax   ; stack starts at 0
  mov sp, 0x9c00   ; 200h past code start <-- code in question


From what I understand of the stack and from the Intel information, the stack pointer is decremented when things are placed on the stack. So if the boot loader code starts at 0x07c0:0x0000 and extends to 0x07C0:0x0200 <-- sorry this is in real mode format :), and the stack pointer is sitting at address 0x0000:9C00 which would be where the code for the boot loader ends wont putting anything on the stack cause it to move into memory that contains the boot loader?

The reason I say the SP is sitting where it is is because 0x0000:0x9c00 is the same address that 0x07c0:0x0200 is.

Its odd really there seam to be alot of confusion on the internet about how the stack pointer behaves when things are placed on it.

Re: OSDEV WIkI Babystep tutorial

Posted: Wed Apr 18, 2012 10:36 pm
by sounds
0x07c0:0x0000 = 0x0000:0x7c00 right?

So 0x07c0:0x0200 = 0x7c00 + 0x0200

That would be 0x7e00

Re: OSDEV WIkI Babystep tutorial

Posted: Wed Apr 18, 2012 10:50 pm
by TreahBlade
Yes you right ****...... Sorry I am still getting used to the whole 0x07c0 as a selector and you have to multiply this by 16 or 10 in hex.


So my original statement is wrong
0x0000:0x9c00 is not the same as 0x07c0:0x0200

but the comment there is wrong too tho. if the SS is 0x0000 and the SP is 0x9C00 that's not 200h past the boot loader code
its 2000h past the boot loader code start :P. So in this case the stack would work correctly.


Something to think about is if SS is set to 0x07c0 and the SP is set to 0xFFFF bochs likes to puke with segment limit violation errors... sometimes

Re: OSDEV WIkI Babystep tutorial

Posted: Thu Apr 19, 2012 12:55 am
by iansjack
You are overcomplicating the situation and confusing yourself.

[ORG 0x7C00] means that the code starts at CS:0x7C00; CS is always set to 0 to start with. So the code starts at linear address 0x&7C00 and extends for 0x200 bytes (but - an important but - most of that code is just padding). The stack starts at 0:0x9C00 and will grow downwards. Anything put into the stack will indeed write to memory "used" by the boot loader; but the boot loader isn't 0x200 bytes long. Ignoring the two-byte signature at the end (which a floppy disk needs to identify it, but can be safely overwritten once the code is in memory), the last part of the 0x200 bytes of code is just a series of zeros.

So there is a little space for the stack to grow downwards, and this simple example only needs a little space. Once a boot loader has done its job, the first thing that the code proper will do is to set up more reasonable values for CS, DS, and SS, or it will jump to protected mode where all bets are off.

(Note. The tutorial is wrong when it says the stack isn't used. There are some subroutine calls which will write to the stack.)

Re: OSDEV WIkI Babystep tutorial

Posted: Thu Apr 19, 2012 2:24 am
by Rudster816
Some old\broken BIOS's might boot you by jumping to 0x07C0:0x0000. You're also not interrupt safe until you have a stack setup.

Code: Select all

ORG 0x7C00
BITS 16

start:
	cli
	jmp 0x0:setcs
setcs:
	xor ax, ax
	mov ds, ax
	mov es, ax
	mov fs, ax
	mov gs, ax
	mov ss, ax
	mov sp, 0x9C00
	sti
	cld
	
	....
That is probably the safest way to startup.

Re: OSDEV WIkI Babystep tutorial

Posted: Thu Apr 19, 2012 5:19 am
by bluemoon
To setup flag to known state I use this instead:

Code: Select all

push word 2
popf