From: smirzo@example.com   
      
   Salvador Mirzo  writes:   
      
   > cross@spitfire.i.gajendra.net (Dan Cross) writes:   
   >   
   >> [Note: Followup-To: alt.os.development]   
   >>   
   >> In article <87v7ssi2ec.fsf@example.com>,   
   >> Salvador Mirzo   wrote:   
   >>>scott@slp53.sl.home (Scott Lurndal) writes:   
   >>>> "Paul Edwards"  writes:   
   >>>>>Do you consider the concept of a BIOS (as seen as the IBM PC),   
   >>>>>"legitimate to use"   
   >>>>   
   >>>> In the abstract, possibly.  But the last half century has   
   >>>> shown that BIOS as an I/O abstraction layer was a bad idea   
   >>>> from the start.   
   >>>   
   >>>Would you elaborate or point out an article or book that could clarify   
   >>>the ideas that have made you to make such remark?  Sounds interesting.   
   >>   
   >> This isn't really on-topic for comp.lang.c, so I'm cross-posting   
   >> to alt.os.development and setting Followup-To: to redirect   
   >> there.   
   >   
   > Cross-post obeyed.   
   >   
   >> The thing about the "BIOS" is that it is the product of a   
   >> specific context in computer history.  Early PCs were all   
   >> weirdly idiosyncratic, so Kildall created it to provide an   
   >> abstraction layer for CP/M, isolating relatively portable parts   
   >> from the machine specific bits.   
   >>   
   >> But this had an interesting side effect that was also related to   
   >> the historical context.  Early PCs were mostly built around   
   >> microcontroller CPUs and were seriously RAM constrained; the   
   >> original IBM PC shipped with something like 128KiB of RAM.  A   
   >> useful property of the BIOS, as an abstraction layer between   
   >> the OS and the hardware, was that it could be be moved into ROM,   
   >> thus freeing up precious RAM resources for actual programs.   
   >>   
   >> But it was always sort of a lowest-common denominator   
   >> implementation, tailored to the needs of a specific operating   
   >> system (first CP/M, then the various incarnations of DOS in the   
   >> IBM PC), so it runs in 16-bit mode and so on.  As such makes a   
   >> poor basis for IO in more advanced operating systems, which   
   >> generally want to be in charge of how IO is handled and what   
   >> state an IO device is in themselves.  Such systems provide   
   >> drivers that are redundant with whatever services the BIOS   
   >> provides, but better suited to their uses, so the BIOS confers   
   >> no real benefit for them.   
   >>   
   >> I don't know that there are many books/articles/whatever that   
   >> discuss this in detail, but folks who build real systems run   
   >> into BIOS limitations pretty quickly. In particular, once you   
   >> want to start doing things like multiplexing concurrent IO   
   >> operations across devices, the whole synchronous BIOS model   
   >> breaks down.   
   >   
   > But Scott Lurndal said it was a bad idea and, from what you say, it   
   > seems like a not-so-bad idea.  It could be stored in ROM, leaving up RAM   
   > for the OS and the users; it hid machine-specific details from the OS,   
   > creating an abstraction.  And I believe the BIOS doesn't stop the OS   
   > from talking directly to the machine, so it's not an obstacle either.   
   > What am I missing?   
      
   Apologies.  I needed to fetch more articles before posting this one.   
   There's another thread (with the same subject) that pretty much answers   
   my question here.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)