🚀 go-pugleaf

In article <2053@pdxgate.UUCP>, berggren@eecs.cs.pdx.edu (Eric Berggren) writes:
|> 
|>   I am in the midst of a small war debating whether or not one should
|> use system BIOS where it is available. One side is arguing compatibility
|> and the other side is pushing performance. At one time, I was for BIOS on
|> everything, but after experience and readings of various articles, I
|> currently stand on the side of direct hardware interfacing. Many operating
|> systems do not use BIOS, because one is not available, and interfacing
|> is done through device drivers (whether BIOS is there or not). 
|> 
|>    Anyway, as to the question, do the 386 PC versions of Mach use the
|> BIOS? What were the arguments? (if other than those mentioned above)
|> ...
|>   Eric Berggren             |  "The force of the 'Dark Side' eminates from 

Well, the standard Mach 2.5 and Mach 3.0 don't use BIOS at all (except
for booting). After the kernel has started execution BIOS is not used
at all.

The versions of Mach 2.5 and Mach 3.0 that I have running on the IBM
PS/2 machines use ABIOS (Advanced Bios) which is designed for
multitasking operating systems (the standard BIOS or CBIOS is single
threaded - which basically means that you can only start one BIOS
operation at a time, which is undesirable if you want to be able to do
hard disk I/O while reading the floppy). Unfortunately ABIOS has a 16
bit interface so the system has to switch from 32 bit to 16 bit mode to
talk to ABIOS, adjusting descriptors and stack pointers in the
process.

In practice the performance is pretty reasonable, and certainly not as
bad as it would be going in and out of real mode to talk to CBIOS.

The main reason that I used ABIOS was that it provides a measure of
device independence (I can run on ST506, IDE, ESDI, and SCSI disks with
the exact same driver), and makes it much more feasible to provide the
source as the ABIOS interfaces are publicly documented (the actual
hardware often isn't).

So, I'd say the advantages are:

1. portability and flexibility (new machines will probably just boot up
    with little or no code changes).
2. documented, published interfaces 
3. simpler drivers
4. potential for "shrink-wrap" operating system that doesn't care 
   what the underlying hardware is so long as it has an ABIOS to talk
   to.

The potential disadvantages are:

1. performance (so far this hasn't seemed to be a problem)
2. additional complexity (in the sense that you have two pieces of code
   that have to communicate and interrupt and error handlers have to
   know about interrupts in 16bit mode etc.). You also have to initialize
   ABIOS from CBIOS (we do this in the boot code).
3. the initial drivers are probably harder to write and debug than drivers
   that go directly to the hardware.
4. you may not be able to take advantage of high-function adapters if
   the ABIOS doesn't let you get to those features.

----------------------------------------------------------------
The above views are my own, not those of my employer.
Bill Webb (IBM AWD Palo Alto, Ca.), (415) 855-4457.
UUCP: ...!uunet!ibmsupt!webb INTERNET: webb@ibminet.awdpa.ibm.com