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

    From Dan Cross@21:1/5 to smirzo@example.com on Sun Mar 2 16:01:08 2025
    XPost: alt.os.development

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)