Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #18744 > unrolled thread

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

Back to article view | Back to alt.os.development

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

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

[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.

[toc] | [next] | [standalone]

#18750

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?

[toc] | [prev] | [next] | [standalone]

#18751

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.

[toc] | [prev] | [next] | [standalone]

#18754

In article <87zfhvbewt.fsf@example.com>,
Salvador Mirzo  <smirzo@example.com> wrote:
>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.

No need to apologize; discussion is good.  As you noted, Scott
gave a really great answer in the other subthread.

I do think there's utility in going back to the points you
raised above; specifically that it's a "not-so-bad idea."  The
point that I was trying to make was that it was a not-so-bad
idea for the specific context it was created in; the issue was
that too many people tried (and, frankly, continue to try) to
stretch that ridiculously far outside of that context.

In a purely academic sense, interfaces are good; they allow us
to decouple systems, which makes everything more flexible and
resilient to change.  The problem with the BIOS itself is that
that particular interface isn't good, as outlined elsewhere in
the thread.

	- Dan C.

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.development

csiph-web