Sujet : Re: PC BIOS (was [OSDev] How to switch to long mode in x86 CPUs?)
De : cross (at) *nospam* spitfire.i.gajendra.net (Dan Cross)
Groupes : comp.lang.c alt.os.developmentSuivi-à : alt.os.developmentDate : 02. Mar 2025, 17:01:08
Autres entêtes
Organisation : PANIX Public Access Internet and UNIX, NYC
Message-ID : <vq1vc4$17o$1@reader1.panix.com>
References : 1 2 3 4
User-Agent : trn 4.0-test77 (Sep 1, 2010)
[Note: Followup-To: alt.os.development]
In article <
87v7ssi2ec.fsf@example.com>,
Salvador Mirzo <
smirzo@example.com> wrote:
scott@slp53.sl.home (Scott Lurndal) writes:
"Paul Edwards" <mutazilah@gmail.com> 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.
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.
- Dan C.