Thoughts needed

Kevin Ross kevinr at june.cs.washington.edu
Fri May 20 03:08:45 AEST 1988


In article <10889 at steinmetz.ge.com> davidsen at crdos1.UUCP (bill davidsen) writes:
>In article <3771 at lynx.UUCP> m5 at lynx.UUCP (Mike McNally) writes:
>| ``Reasonable'' is in the eyes of the reasoner.  Because (at least in
>| the 386 thing we have here) the AT hard disk controller does not use 
>| the DMA controller, the CPU must poll when transferring.  The MS-DOS
>                      ^^^^^^^^^^^^^^^^^
>  As I'm sure a lot of people will tell you, that's the way the beast is
>implemented, not the way it *must* be done. Xenix and OS/2 seem to be
>able to run just fine using DMA mode and interrupts. The problem is that
>MS-DOS is more or less a knock off of CP/M, and since it's not multi
>tasking it has nothing better to do with the CPU than wait.

Actually, DOS could have implemented a DMA transfer from the controller. I
think they really should have / or still should implement this. Sure, the
CPU might not have anything better to do than to wait for the CPU, but it
also should use DMA as the transfer mechanism when the IO is completed. 
This would definitely speed things up.

Another route they should have taken was to add a no busy wait option to 
the call. Then, at least, the CPU could be used for more productive jobs 
than sitting in a tight loop. When a program gets to a point where the 
data is crucial, it can call a wait routine. Of course, many programs
would not be able to deal with this, but how sweet it would be to have
the option. You could be working with a database routine that prefetchs
the next records while working on the current records. 

Ah, but then, hindsight makes for easy complaining.


Kevin Ross

kevinr at june.cs.washington.edu 	
..uw-beaver!june!kevinr

Home: ..uw-beaver!tikal!camco!carmine!kevin



More information about the Comp.unix.microport mailing list