cgs@umd5.umd.edu (Chris G. Sylvain) (04/03/89)
In article <29177@bu-cs.BU.EDU> madd@buit4.bu.edu (Jim Frost) writes: > >OS/2 cannot make use of a blocking BIOS, which is the normal one in >PC's. There are two simple approaches to getting around this: the >first is to put in a non-blocking BIOS (in addition to the normal one) > [.lots deleted.] Interesting, well written article.. But, whoa! Just minute.. "blocking BIOS is the normal one in PC's", huh? Please, name your source. My source, _The IBM PC From the Inside Out/Includes the PC AT_ by Sargent and Shoemaker, Addison-Wesley, ISBN 0-201-06918-0 (so it's a good book, and you might what it for your library), clearly states that in the PC interrupt handlers (almost) invariably reenable interrupts upon entry. Doesn't sound like a "blocking BIOS" to me.. Would you explain "blocking BIOS" further, please? -- --==---==---==-- .. Beware the Jubjub bird, .. ARPA: cgs@umd5.UMD.EDU BITNET: cgs%umd5@umd2 UUCP: ..!uunet!umd5.umd.edu!cgs
bcw@rti.UUCP (Bruce Wright) (04/08/89)
In article <4652@umd5.umd.edu>, cgs@umd5.umd.edu (Chris G. Sylvain) writes: > > Interesting, well written article.. > But, whoa! Just minute.. "blocking BIOS is the normal one in PC's", huh? > > Please, name your source. > > My source, _The IBM PC From the Inside Out/Includes the PC AT_ by Sargent > and Shoemaker, Addison-Wesley, ISBN 0-201-06918-0 (so it's a good book, and > you might what it for your library), clearly states that in the PC interrupt > handlers (almost) invariably reenable interrupts upon entry. > > Doesn't sound like a "blocking BIOS" to me.. Would you explain "blocking BIOS" > further, please? > -- Since nobody else seems to be explaining this I might as well put in my two cents worth. Writing device drivers and other such low-level operating system types of things for various multi-tasking operating systems is much of what puts food on my table, so I have some idea of what I'm talking about. It is certainly well-behaved for an interrupt handler to enable interrupts on entry, but this is not exactly what is meant by a blocking BIOS - it is addressed at a totally different problem, namely maximum interrupt latency, the maximum amount of time between the time that a device requests an interrupt and the time that the device driver software handles the interrupt. (on the PC hardware, the interrupt handler must explicitly re-enable interrupts ... on a "real" big computer this is often handled implicitly by the interrupt handling hardware itself). The term "blocking BIOS" refers to the fact that when an application program (and in this context on the typical PC, MS-DOS qualifies as an application since it uses the ROM-BIOS for its low-level functions) makes a request to the BIOS, the BIOS does a busy wait until the I/O is completed. Typically, a PC BIOS will either go into a poll loop looking directly at the hardware, or it will enable a hardware interrupt and look for a flag set by the interrupt handler indicating that it has completed processing. In order to be a true non-blocking BIOS, there would have to be a special call to queue a request to the BIOS (which would return IMMEDIATELY rather than wait for completion), and then some mechanism by which the caller is notified when the request completed - say by specifying a flag to be set or a subroutine to be called (the latter is probably more useful). This sort of thing would allow true multitasking; it would also be useful for overlapped I/O on a single tasking operating system like MS-DOS (which would allow, for example, I/O to procede simultaneously on the floppy and the hard drive). Of course, there are packages which do this sort of thing on the PC - but they have to "roll their own". Unfortunately on the PC you can't rely on something like a PIRQ (programmed interrupt request - a request for a software-initiated interrupt at a lower priority than the hardware interrupt being serviced), so some of the more elegant ways of doing this sort of thing are not available. One common multitasking implementation for an environment lacking a PIRQ vectors ALL interrupt returns through one 'interrupt exit' routine which does checking for whether one of the exiting interrupts has done anything 'significant', and if so it does whatever necessary to alter the task priorities and dispatch the highest priority task. Now it would be possible (but not required) to implement some of the functions of the PC BIOS in a not-strictly-blocking manner, though to maintain compatibility you would have to make it look to the caller as if it were a blocking BIOS. For example, you can implement a serial I/O BIOS which queues characters to the output port and returns immediately if it could insert a character in the queue without waiting for it to actually be sent out. Similarly, you could put the input characters into a ring buffer which could be read before the BIOS tried to read the hardware. Although such an implementation would be a vast improvement over the usual PC BIOS (much less probability of data overrun on the serial line), it is still not quite a non-blocking BIOS because if the output buffer is full it will still wait. A non-blocking BIOS would return 'insufficient memory' if it could not queue the request. Also, it only handles the serial line and does nothing about the keyboard, disk, etc. I hope this is reasonably intelligible -- it is not intended to be a complete description of multitasking and similar issues, just an overview of the subject with an emphasis on the PC. BTW, the PC architecture is sufficiently ugly that although multitasking is quite possible it's still something of a crock -- even on a 386. Bruce C. Wright