C library in BIOS

[[e-mail]]

If we simplify everything to a 32-bit BIOS and a
32-bit OS and 32-bit applications, I can't see any
reason why the OS can't contains the entire C
library, and applications access that via some
appropriate pointer.

But can we go one step further and make the
BIOS a C library? So all hard disks are presented
as a single file. Perhaps the boot disk can be
already open at boot time so that you can start
doing fread() to read sectors straight away in
the boot sector. This will also avoid the need to
invent a BIOS interface. Perhaps internally things
will be smoother if people stick to buffer sizes
that are equal to or a multiple of the sector size
or cluster size. I think this will also cover CKD
mainframe disks where I currently use a "sector
size" of 18452 bytes to semi-optimize for a 3390.

I think we need 3 levels of privilege level - user,
OS and BIOS.

I also think that even on the 80386 we should
allow 64-bit longs to be used by applications
such as the OS which would ideally be able
to access disks greater than 4 GiB in size.

The applications that run under the OS could
still use 32-bit longs, and the OS should be able
to cope with the different memory models in
use.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
But can we go one step further and make the
BIOS a C library? So all hard disks are presented
as a single file. Perhaps the boot disk can be
already open at boot time so that you can start
doing fread() to read sectors straight away in
the boot sector. This will also avoid the need to
invent a BIOS interface.

And the CONFIG.SYS (or whatever) on the boot disk
(that only the OS understands) can contain a list of
devices that the BIOS actually recognizes, that you
can fopen(), such as "\\0x190". It is up to the OS
whether that device is designated to be the D drive
or whatever.

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
I also think that even on the 80386 we should
allow 64-bit longs to be used by applications
such as the OS which would ideally be able
to access disks greater than 4 GiB in size.

Actually, any reason why an OS for the 8086
shouldn't be huge memory model, with 32-bit
size_t, and 64-bit longs, so that it can access
large hard disks too?

We're running out of words (short/int/long)
though, so "int" would probably need to be
32-bit after all, otherwise there is nothing to
make size_t.

BFN. Paul.

[Rod Pemberton]

On Tue, 9 Mar 2021 10:02:49 -0800 (PST)

Post by ***@gmail.com

Post by ***@gmail.com
I also think that even on the 80386 we should
allow 64-bit longs to be used by applications
such as the OS which would ideally be able
to access disks greater than 4 GiB in size.

Actually, any reason why an OS for the 8086
shouldn't be huge memory model, with 32-bit
size_t, and 64-bit longs, so that it can access
large hard disks too?
We're running out of words (short/int/long)
though, so "int" would probably need to be
32-bit after all, otherwise there is nothing to
make size_t.

C also has "long long" (C99) and "char" too.

I've never really used "int" with C. My
recollection was that "int" usually maps onto
one of the other types, either "long" or "short",
as it must fit in-between the two in size. So,
the size for "int" is implementation dependent,
i.e., "unreliable" or "inconsistent" from the
programmer's point-of-view.

[[e-mail]]

Post by Rod Pemberton
C also has "long long" (C99) and "char" too.

I would like to go as far as I can with just C90.
Then I am probably more interested in seeing
the process repeated with Pascal rather than
C99.

Post by Rod Pemberton
I've never really used "int" with C. My
recollection was that "int" usually maps onto
one of the other types, either "long" or "short",
as it must fit in-between the two in size. So,
the size for "int" is implementation dependent,
i.e., "unreliable" or "inconsistent" from the
programmer's point-of-view.

ALL of the data types are unreliable. :-) There is
nothing preventing char to long all being 128 bits.
There are only minimums (char = 8, short = 16,
int = 16, long = 32). There's nothing wrong with
using int. It is advisable to use int if you are willing
to have your options potentially limited to 16 bits.
This way your program can be more efficient on a
16-bit platform, while being more useful on a
32-bit platform. That's the tradeoff.

BFN. Paul.

[Rod Pemberton]

On Tue, 9 Mar 2021 09:11:04 -0800 (PST)

Post by ***@gmail.com
If we simplify everything to a 32-bit BIOS and a
32-bit OS and 32-bit applications, I can't see any
reason why the OS can't contains the entire C
library, and applications access that via some
appropriate pointer.

Perfectly viable. Some user-space Linux OS
implementations only call the C library.

Post by ***@gmail.com
But can we go one step further and make the
BIOS a C library?

Do you mean C wrappers around BIOS functions,
or re-implement BIOS functions in C code?

Post by ***@gmail.com
So all hard disks are presented
as a single file. Perhaps the boot disk can be
already open at boot time so that you can start
doing fread() to read sectors straight away in
the boot sector. This will also avoid the need to
invent a BIOS interface. Perhaps internally things
will be smoother if people stick to buffer sizes
that are equal to or a multiple of the sector size
or cluster size. I think this will also cover CKD
mainframe disks where I currently use a "sector
size" of 18452 bytes to semi-optimize for a 3390.

The purpose of the BIOS was to hide hardware
dependent code from the OS, i.e., how to program
a specific chipset. Somewhere, some code must know
how to program the specific motherboard chipset.
I don't think it's a good idea for C library code
to do that. OS specific code is fine for that,
if you decide not to use the BIOS code.

[[e-mail]]

Post by ***@gmail.com
If we simplify everything to a 32-bit BIOS and a
32-bit OS and 32-bit applications, I can't see any
reason why the OS can't contains the entire C
library, and applications access that via some
appropriate pointer.

Perfectly viable. Some user-space Linux OS
implementations only call the C library.

Ok, great, I'm not barking up the wrong tree.

Post by ***@gmail.com
But can we go one step further and make the
BIOS a C library?

Do you mean C wrappers around BIOS functions,
or re-implement BIOS functions in C code?

Neither. I don't care what language the BIOS is
written in, so long as an fopen() function exists
and takes the same parameters defined by C90,
and fread() exists, and takes the same parameters,
etc etc.

Post by ***@gmail.com
So all hard disks are presented
as a single file. Perhaps the boot disk can be
already open at boot time so that you can start
doing fread() to read sectors straight away in
the boot sector. This will also avoid the need to
invent a BIOS interface. Perhaps internally things
will be smoother if people stick to buffer sizes
that are equal to or a multiple of the sector size
or cluster size. I think this will also cover CKD
mainframe disks where I currently use a "sector
size" of 18452 bytes to semi-optimize for a 3390.

The purpose of the BIOS was to hide hardware
dependent code from the OS, i.e., how to program
a specific chipset. Somewhere, some code must know
how to program the specific motherboard chipset.
I don't think it's a good idea for C library code
to do that. OS specific code is fine for that,
if you decide not to use the BIOS code.

I want to use the BIOS, but before I use the BIOS, I
want to change the BIOS.

I don't care how fopen() is implemented in the BIOS.
The first instruction in fopen() can be twiddling the
chipset. I don't care.

But as well as other people's implementation of fopen,
with the chipset-twiddling, I will provide a fake BIOS of
my own, as a separate project, which simply defines
fopen() as a pointer to a normal C library fopen() and
just opens a flat file, possibly as "r+w", which will be a
FAT-16 image.

This way when I'm running z/OS or whatever, I can run
my "fake BIOS" and then boot a FAT-16 flat file containing
a S/3X0 boot sector which then loads PDOS (a S/3X0
version, but different from my current S/3X0). And it will
run at native speed.

BFN. Paul.