Initial state of x86 registers after BIOS initialization

[mrrobot]

I'm writing a bootloader and found a difference between bochs and actual hardware (Pentium 133). On bochs all segment registers are zeroed, so I can put some code in memory using mov commands, and then run it by simply jumping. However on an actual PC the ds is not 0 and must be zeroed manually.

Is the initial state of registers (both data and segment) somehow standarized (like 0x7c00 initial address), or does it vary from BIOS to BIOS?

[MichaelFarthing]

Everything is unreliable with the possible exception of dl. Even cs:ip might vary between 0:7c00 and 7c0:0

[glauxosdever]

Hi,

Is the initial state of registers (both data and segment) somehow standarized (like 0x7c00 initial address), or does it vary from BIOS to BIOS?

You should almost never assume anything about the initial state of registers. The only known to me exception is the "dl" register, which holds the drive number you should use when invoking "int 0x13".

As for the 0x7C00 initial address, it can be 0x0000:0x7C00, 0x07C0:0x0000, 0x0700:0x0C00, 0x00C0:0x7000, or any other combination of segment:offset with the same effective address.

Hope this helps.


Regards,
glauxosdever

[mrrobot]

Thanks! I didn't think about multiple possible encodings of 0x7c00, I guess I wasn't so unlucky then.

[BrightLight]

Your boot sector code should always start by disabling hardware interrupts (CLI instruction), a far jump to fix the CS:IP combination whatever they may be, setting up the DS, ES, FS, and GS registers, and SS:SP as well. Then, it should store the BIOS boot drive number from DL to a memory location and re-enable hardware interrupts (STI instruction.)

[BenLunt]

Your boot sector code should always start by disabling hardware interrupts (CLI instruction), a far jump to fix the CS:IP combination whatever they may be...

In my opinion, there is no need to "fix" the cs:ip register pair. As long as you do not use the cs: data override and always use relative jumps, there is no need to "fix" the cs:ip register pair, ever. Your boot code could really not care any less what the cs:ip register pair is. It knows that it is at absolute address 0x07C00, so as long as the other segment registers are set accordingly, there is no reason to adjust the cs:ip registers.

Just my opinion,
Ben
http://www.fysnet.net/osdesign_book_series.htm

[Octocontrabass]

There's also no need to disable interrupts. The CPU automatically prevents interrupts for one instruction following any instruction that sets SS, so you can set SS and SP without disabling interrupts. None of the other steps listed there require interrupts to be disabled at all.

For example:

Code: Select all

mov ss, ax
mov sp, 0x7c00

You can use a code sequence like this even with interrupts enabled and there will be no problem.

[BrightLight]

In my opinion, there is no need to "fix" the cs:ip register pair. As long as you do not use the cs: data override and always use relative jumps, there is no need to "fix" the cs:ip register pair, ever. Your boot code could really not care any less what the cs:ip register pair is. It knows that it is at absolute address 0x07C00, so as long as the other segment registers are set accordingly, there is no reason to adjust the cs:ip registers.

OK, let's say for example BIOS loaded me with CS:IP 0x07C0:0x0000 and I have (ORG 0x7C00) in the beginning of my assembly file. When I call a function from within my code (e.g. CALL 0x7C60) the execution will go to 0x07C0:0x7C60, and most likely will execute garbage until the CPU triple faults. The relative jump can only target 127+/128- bytes -- the boot sector can be up to 512 bytes (2048 for CD) and thus fits more than this.
Conclusion: I stick to my first statement; setting CS:IP is important in the beginning of a boot sector program.

[Octocontrabass]

OK, let's say for example BIOS loaded me with CS:IP 0x07C0:0x0000 and I have (ORG 0x7C00) in the beginning of my assembly file. When I call a function from within my code (e.g. CALL 0x7C60) the execution will go to 0x07C0:0x7C60,

That CALL instruction is encoded with a relative offset, so the destination is 0x07C0:0x0060. There is no problem.

The relative jump can only target 127+/128- bytes

JMP is available with 8, 16, and 32-bit relative offsets in real mode (even though a 32-bit offset is useless). There is no problem.

[BrightLight]

Oops, my bad.