From: noemail@basdxcqvbe.com
On Tue, 6 Jul 2021 06:35:44 -0700 (PDT)
"muta...@gmail.com" wrote:
> On Tuesday, July 6, 2021 at 10:39:09 PM UTC+10, muta...@gmail.com
> wrote:
> > > Are you saying you intend to enable the A20
> > > line via the BIOS Int 15h, AX=2401h call, so
> > > as to make PDOS hardware independent? ...
>
> > Yep, exactly.
>
> BTW, does an OS being hardware-independent actually
> open up any possibility?
>
> It just "seems nice" to me that there isn't a skerrick of
> hardware that is required other than the 80386 and
> some memory.
Yes, it always "seems nice" to most programmers to
fully abstract away the hardware. This same innate
desire exists for those arguing about C on comp.lang.c.
I suspect that part of this may be because most
programmers don't have a strong background in
electronics, hence have some difficulty in programming
hardware devices.
In the case of C, it's bad (IMO) to abstract away the
underlying hardware, because C must be implemented
on real hardware, and the C machine model fits only
a few standard architectures really well, since it was
only designed to fit two. It was forced upon numerous
other architectures, particularly mainframes, which
were not suited to the language implementation, and
this resulted in much C behavior that isn't defined
or is implementation defined. Fortunately, byte
addressed, contiguous memory, pointer sizes matching
integer sizes, von Neumann architecture, micro-processors
work really well with C, which is what we have today.
In the case of an OS, it's still bad in IMO to abstract
away the hardware, as you must do what is necessary
for the OS to function correctly. So, you have to
deal with the cards that were dealt.
> But is there some hardware (or non-hardware?) where
> such an OS design would be useful?
>
There are all sorts of memory-mapped devices, e.g.,
LFB, and there were devices that could only be
accessed via BIOS, e.g., BIO32 directory, VESA.
Useful? ... That's somewhat arbitrary. That
depends on what people like or can tolerate or
can comprehend.
Personally, I think memory mapped devices work well
with Unix's "everything is a file" concept, which
was inherited by the C programming language via
file I/O functions and typedef'd structs (overlays).
And, I think interrupts (pre-emptive multi-tasking)
doesn't work well with C, because C has no built-in
mechanism to support interrupts. Yield based methods
(cooperative multi-tasking) works better. As for
port I/O, again, C has no mechanism, but non-primitive
C compilers easily support this either directly
or via inlined assembly.
> I know other people who state that the hardware is
> more reliable than the BIOS, but what do you actually
> find if you go the BIOS-only route?
Not sure. DOS made BIOS work.
The BIOS was supposed to hide away or abstract
the specific details of programming hardware
which was unique to a particular motherboard
or chipset so the programmer didn't have to
deal with it.
The down side was that there was no guarantee
the BIOS function works correctly or consistently,
as there were many different implementations.
I think that is why most programmers, including
me, preferred directly programming hardware with
published standardized interfaces.
> (Or use UEFI exclusively).
I'm not familiar with UEFI, other it seems there
is an option to disable it, once the OS takes
control, which I would likely enable.
> Is there some niche market opened up?
>
No idea.
--
What is hidden in the ground, when found, is hidden there again?
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
