OSDev.org

Excluding the boot sector (because of size limits), I have come to the conclusion that all BIOS interrupt calls should be routed via wrapper procedures: all registers (including segments) are saved, input parameters are set, all irrelevant registers are cleared, a call is made, registers are saved (return values), and original register values are restored. If the CPU is at least 32-bit, the high bytes of registers are taken into account.

Is this inefficient? It surely is but I believe it is worth it. We are only talking about boot loaders here and the efficiency is not extremely critical. The main benefit: this will forcibly drive off many bugs. When BIOS interrupts calls are always made from the known state, it is also quite clean for BIOS (not that it matters). Here is an example:
What if we had tested this extensively and noticed that it works and we then made a change:
The line "[assembly code...]" always left certain values to some registers but now we added the line "[UPDATED assembly code...]" that makes this whole thing unstable. Of course, we should not have any problems with this but the reality is different. We might have "accidentally" left good register values from previous code and that made it work. If we set all registers to known values before a call, it would be much more robust.

Especially for us, because usually we are not able to test our code on every computer, this would be an easy way to get rid of some hidden bugs. Also, this would not significantly increase the size of code. Only the efficiency would decrease a little bit.

Hi,

I can think of following approaches to solve the problem

• Macros :- Write macros that store and restore registers and calling the bios service instead of making an int call directly .
• Patch the real mode interrupt table :- it should be pretty easy, make it execute your function first
• Add your own safe interrupt handler function :- this also is straightforward and use it instead of the standard ones - like the MS DOS 21h

--Thomas

I also wouldn't worry about the performance. The code you are talking about will not make any noticeable difference in boot up time, unless you are calling one of these BIOS calls thousands of times.

Most BIOS functions are called once when booting up. A few may be called around 10-20 times, but nothing near what you would need to worry about.

Keep in mind that almost all BIOS calls have multiple return values that you are going to need to read. Just simply overwriting them with the saved register values won't do you much good. You will need to come up with a way to 1) save the current registers, 2) call the BIOS method, 3) save the important registers (or all registers), and then 4) restore the original register values.

Step 3 is going to be interesting. Either you will need to come up with a solution that works for all BIOS calls (probably saving all registers), or you will need to write custom wrappers for each BIOS call that saves the important registers for the caller to use, or you are going to have to come up with some way for the caller to specify which registers it needs saved, which is probably way more complicated than you want to go.

But, I say go ahead and give it a try. Maybe you can provide us all with a safe BIOS wrapper.

If you can make it work for 32-bit callers, that would be even better...

SpyderTL wrote:But, I say go ahead and give it a try. Maybe you can provide us all with a safe BIOS wrapper.

If you can make it work for 32-bit callers, that would be even better... [-o<

This would't be impossible but the problem is it's still relying on 16 bit code at some point so it's either use a vm86/emulator or drop to real mode.

This is pretty common behavior among sensible bootloader projects (especially those which desire to not be entirely confined to the legacy BIOS architecture)

Owen wrote:This is pretty common behavior among sensible bootloader projects (especially those which desire to not be entirely confined to the legacy BIOS architecture)

Just wanted to add to your post, what you linked is where a general bios_int_call is used, which has some of the techniques mentioned in it. See bios_int_call here https://github.com/gdboot/gandr/blob/ma ... services.c

- Monk

I linked to three source files.

Owen wrote:I linked to three source files.

I see that now.

- Monk