Groups | Search | Server Info | Login | Register

Groups > alt.os.development > #18751

Re: PC BIOS (was [OSDev] How to switch to long mode in x86 CPUs?)

Show all headers | View raw

Salvador Mirzo <smirzo@example.com> writes:

> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> [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.
>
> 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.

Back to alt.os.development | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: PC BIOS (was [OSDev] How to switch to long mode in x86 CPUs?) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-02 16:01 +0000
  Re: PC BIOS (was [OSDev] How to switch to long mode in x86 CPUs?) Salvador Mirzo <smirzo@example.com> - 2025-03-08 14:24 -0300
    Re: PC BIOS (was [OSDev] How to switch to long mode in x86 CPUs?) Salvador Mirzo <smirzo@example.com> - 2025-03-08 14:39 -0300
      Re: PC BIOS (was [OSDev] How to switch to long mode in x86 CPUs?) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-09 01:52 +0000

csiph-web