32-bit registers and BIOS

[Antti]

What if I had BIOS running at boot time (e.g. interrupts enabled, timer ticking, etc.), would I trust it not to change upper parts of 32-bit general purpose registers? For example, if I set "mov eax, 0x10000000", would the register value be absolutely safe? I know that triggering a software interrupt, like "int 0x10", might change upper parts of registers if a BIOS implementation is buggy. What about just running the system, i.e. without software interrupts?

Code: Select all

        mov eax, 0x10000000     ; Use upper part to store information

        ; a lot of 16-bit code, timer ticks etc.
        ; no software interrupts

        and eax, 0xFFFF0000
        cmp eax, 0x10000000     ; Check stored information
        je ok
error:  jmp error               ; Is this likely?
ok:

I already decided that I will not use this method but I started wondering whether this would be safe or not. I would not be too surprised if there existed a BIOS implementation that had problems with this.

[alexfru]

It would be a terrible thing for BIOS interrupt handlers to do, to just randomly and totally unexpectedly corrupt the state of the program they interrupt and thus prohibit any use of 32-bit registers that are there for you to use.

So, while I wouldn't give a 100% guarantee here, I bet you should be safe. In the DOS era, people often did use 32-bit registers in real mode and it was fine if not always, most of the time.

[Antti]

In the DOS era, people often did use 32-bit registers in real mode and it was fine if not always, most of the time.

This is a good point for trusting the BIOS but it still feels uncomfortable. Better to avoid it anyway and make an excuse for using some other method.

[Combuster]

I wouldn't be surprised if there exists a bios bug that trashes the top half during a firmware call on some specific motherboard. The question is rather, should you cover for that?

[Antti]

Should I cover for that? Perhaps not actively but passively. If using another way solves the potential problem as a side effect, it is just an extra profit.

[AbstractYouShudNow]

When switching from protected mode to real mode and back for bios interrupts, grub saves the upper half of 32-bit registers too, so I guess you should do that too.

[Bender]

Do you care about the BIOS's handlers? You could always do a "CLI" to disable all hardware interrupts, and use extended registers with no worries, it's always good to push 32-bit registers before executing a BIOS Interrupt as others have mentioned. Another way is that you could replace the BIOS (Timer/Keyboard/....) handlers yourself. (Not sure if that could be considered *safe*, it may even mess up the entire system.)
I too have a doubt about this, is it possible for SMM code to do all this? That'd be much worse.

[onlyonemac]

From what I've read, most BIOSes will trash the upper half of the 32-bit registers. That (apart from numerous other reasons) was what made me steer clear of using unreal mode for my OS, since the main driving factor behind my decision for real mode was that I could still use the BIOS.

[alexfru]

SMIs must not trash regs. SMIs can interrupt 32-bit and 64-bit code.
I don't remember, but the CPU might actually (and probably should) save/restore some regs when entering and leaving SMM. For one thing, the CPU mode and segement regs must be changed (and probably the stack).

[Combuster]

The difference is that hardware interrupts and SMM in particular are independent of whatever code was running beforehand. If one of these trashes something, you get random crashes, and people will complain.

When code actively calls the BIOS by interrupt, it always happens from a very limited range of locations. So if a call trashes the lower half, DOS would break and people would complain. If it only trashes the upper half, the vast majority of 16-bit code won't notice. And the cases that ever happened to matter are easily fixed.