From: cross@spitfire.i.gajendra.net
In article <87zfhvbewt.fsf@example.com>,
Salvador Mirzo wrote:
>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.
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.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
