PDOS modules

[[e-mail]]

I don't like using the "far" keyword. It's not standard C.

I don't mind running a utility that resolves all the
offsets so that an image can be loaded into a
specific area of memory.

I don't mind my boot sector loading 58 sectors, the
maximum possible.

Currently PDOS/386 consists of a boot sector, a
16-bit tiny-memory model IO.SYS and a 32-bit
a.out MSDOS.SYS.

It occurs to me that I might be able to replace
IO.SYS with a huge memory model program
that has been pre-processed to load at a fixed
address.

MSDOS.SYS is more than 64k in size, but that's
fine if it is being handled by the huge memory
model IO.SYS - that's what huge is for.

Because IO.SYS is executed in real mode, and
makes the switch to protected mode (and also
does the return), I'm assuming there is no trickery
to enable it to be a 32-bit program instead of a
16-bit program. Even if it was 32-bit, it wouldn't
help, as real mode will constrain it to only using
16-bit offsets. Note that I'm only interested in
80386, not "unreal mode".

For PDOS/86, I think that can also be huge
memory model for the kernel, MSDOS.SYS.

I have looked here:

https://github.com/tkchia/gcc-ia16

and huge memory model is not yet supported as
far as I can tell.

Maybe that is actually an opportunity. I would like
size_t to be 32-bits in huge memory model, which
is something that existing MSDOS C compilers do
not do.

This would allow nice clean 32-bit programs to be
written, even on an 8086. While the OS would still
support executing the other memory models, which
is where any performance bottleneck is likely to be
anyway.

Any thoughts?

Thanks. Paul.

[[e-mail]]

Post by ***@gmail.com
This would allow nice clean 32-bit programs to be
written, even on an 8086.

Clarification - they would still be "16-bit programs"
(does the word even have any meaning?) but
C data pointers would effectively be 32-bit (code
pointers would also be 32-bit, but still normal
segmentation, as it is not necessary to have
functions bigger than 64k in size, and I'm not sure
that could be made to work anyway).

"int" would still be 16-bit, so the model would be
like the 68000.

BFN. Paul.

[Rod Pemberton]

On Sat, 27 Feb 2021 15:48:57 -0800 (PST)

Post by ***@gmail.com
I don't like using the "far" keyword. It's not standard C.
I don't mind running a utility that resolves all the
offsets so that an image can be loaded into a
specific area of memory.
I don't mind my boot sector loading 58 sectors, the
maximum possible.
Currently PDOS/386 consists of a boot sector, a
16-bit tiny-memory model IO.SYS and a 32-bit
a.out MSDOS.SYS.
It occurs to me that I might be able to replace
IO.SYS with a huge memory model program
that has been pre-processed to load at a fixed
address.
MSDOS.SYS is more than 64k in size, but that's
fine if it is being handled by the huge memory
model IO.SYS - that's what huge is for.
Because IO.SYS is executed in real mode, and
makes the switch to protected mode (and also
does the return), I'm assuming there is no trickery
to enable it to be a 32-bit program instead of a
16-bit program. Even if it was 32-bit, it wouldn't
help, as real mode will constrain it to only using
16-bit offsets. Note that I'm only interested in
80386, not "unreal mode".

Wouldn't a 32-bit IO.SYS reduce switches back
into real mode to execute IO.SYS code?

Post by ***@gmail.com
For PDOS/86, I think that can also be huge
memory model for the kernel, MSDOS.SYS.
https://github.com/tkchia/gcc-ia16
and huge memory model is not yet supported as
far as I can tell.

...

Post by ***@gmail.com
Maybe that is actually an opportunity. I would like
size_t to be 32-bits in huge memory model, which
is something that existing MSDOS C compilers do
not do.

What do you need size_t for? I.e., shouldn't you
be avoiding using sizeof() and offsetof()? Or, are
you just indicating that you want a flat memory model?

From the description of the "Intel memory model"
page on Wikipedia, huge pointers should be
required, instead of far pointers, for C to function
correctly, when using 32-bit pointers with 16-bit code,
because C requires that pointers to the same location
compare equal. The Wikipedia page says huge pointers
can do that, but far pointers can't.

https://en.wikipedia.org/wiki/Intel_Memory_Model

Post by ***@gmail.com
This would allow nice clean 32-bit programs to be
written, even on an 8086. While the OS would still
support executing the other memory models, which
is where any performance bottleneck is likely to be
anyway.
Any thoughts?

The code won't be 32-bit, but 16-bit. Only the
pointers will be 32-bit.

--

[[e-mail]]

Post by Rod Pemberton

Post by ***@gmail.com
Because IO.SYS is executed in real mode, and
makes the switch to protected mode (and also
does the return), I'm assuming there is no trickery
to enable it to be a 32-bit program instead of a
16-bit program. Even if it was 32-bit, it wouldn't
help, as real mode will constrain it to only using
16-bit offsets. Note that I'm only interested in
80386, not "unreal mode".

Wouldn't a 32-bit IO.SYS reduce switches back
into real mode to execute IO.SYS code?

I need to switch back to real mode in order to do
BIOS calls.

It is IO.SYS that does that for me.

Post by Rod Pemberton

Post by ***@gmail.com
Maybe that is actually an opportunity. I would like
size_t to be 32-bits in huge memory model, which
is something that existing MSDOS C compilers do
not do.

What do you need size_t for? I.e., shouldn't you
be avoiding using sizeof() and offsetof()? Or, are
you just indicating that you want a flat memory model?

Yes, that is correct. I am effectively after a flat
memory model for the 8086.

Maybe I should have worded it like that instead.

I want to be able to use my memory management
routines to e.g. allocate 200k of memory, and then
have size_t x = 200k; and go p = p + x;

Post by Rod Pemberton
From the description of the "Intel memory model"
page on Wikipedia, huge pointers should be
required, instead of far pointers, for C to function
correctly, when using 32-bit pointers with 16-bit code,
because C requires that pointers to the same location
compare equal. The Wikipedia page says huge pointers
can do that, but far pointers can't.

Ok, so I want all data pointers to be huge in IA16 GCC.
Is that a reasonable thing to ask for?

Thanks. Paul.

[Rod Pemberton]

On Sun, 28 Feb 2021 13:35:03 -0800 (PST)

Post by ***@gmail.com

Post by Rod Pemberton

Post by ***@gmail.com
Because IO.SYS is executed in real mode, and
makes the switch to protected mode (and also
does the return), I'm assuming there is no trickery
to enable it to be a 32-bit program instead of a
16-bit program. Even if it was 32-bit, it wouldn't
help, as real mode will constrain it to only using
16-bit offsets. Note that I'm only interested in
80386, not "unreal mode".

Wouldn't a 32-bit IO.SYS reduce switches back
into real mode to execute IO.SYS code?

I need to switch back to real mode in order to do
BIOS calls.
It is IO.SYS that does that for me.

Do you remember Mike Gonta's AeBIOS?

https://board.flatassembler.net/topic.php?t=12372
"aeBIOS is wrapper over normal BIOS which provides protected mode
interface"
"aeBIOS is a 32 bit protected mode BIOS extender"

https://groups.google.com/g/alt.os.development/c/WHhLdLCpMgA
"aeBIOS provides a subset of the most commonly used standard BIOS
functions"

http://codejar.pldev.org/aen/pdbios32?i=1
"pdBIOS32 is a public domain 32 bit protected mode BIOS extender"
"aeBIOS top 43 general purpose (BIOS) functions list: ..."
"Plus the hardware and exception interrupts. "

Post by ***@gmail.com
Ok, so I want all data pointers to be huge in IA16 GCC.
Is that a reasonable thing to ask for?

I'm only aware of .codeg16cc directive.

".code16gcc provides experimental support for generating 16-bit code
from gcc, and differs from .code16 in that call, ret, enter, leave,
push, pop, pusha, popa, pushf, and popf instructions default to 32-bit
size"

--

[wolfgang kern]

Post by ***@gmail.com
I need to switch back to real mode in order to do
BIOS calls.
It is IO.SYS that does that for me.

If you run your own OS then you know where things are.
my switches to/from any mode are only a few bytes each.
__
wolfgang

[JJ]

Post by ***@gmail.com
I don't like using the "far" keyword. It's not standard C.
I don't mind running a utility that resolves all the
offsets so that an image can be loaded into a
specific area of memory.
I don't mind my boot sector loading 58 sectors, the
maximum possible.
Currently PDOS/386 consists of a boot sector, a
16-bit tiny-memory model IO.SYS and a 32-bit
a.out MSDOS.SYS.
It occurs to me that I might be able to replace
IO.SYS with a huge memory model program
that has been pre-processed to load at a fixed
address.
MSDOS.SYS is more than 64k in size, but that's
fine if it is being handled by the huge memory
model IO.SYS - that's what huge is for.
Because IO.SYS is executed in real mode, and
makes the switch to protected mode (and also
does the return), I'm assuming there is no trickery
to enable it to be a 32-bit program instead of a
16-bit program. Even if it was 32-bit, it wouldn't
help, as real mode will constrain it to only using
16-bit offsets. Note that I'm only interested in
80386, not "unreal mode".
For PDOS/86, I think that can also be huge
memory model for the kernel, MSDOS.SYS.
https://github.com/tkchia/gcc-ia16
and huge memory model is not yet supported as
far as I can tell.
Maybe that is actually an opportunity. I would like
size_t to be 32-bits in huge memory model, which
is something that existing MSDOS C compilers do
not do.
This would allow nice clean 32-bit programs to be
written, even on an 8086. While the OS would still
support executing the other memory models, which
is where any performance bottleneck is likely to be
anyway.
Any thoughts?
Thanks. Paul.

Unless you found a C compiler which support changing the target platform
using a directive, you won't be able to mix real mode and protected mode
program, and produce the module in a single compilation task.

Protected mode OSes usually separate the OS leader part (i.e. the
bootstrap), and the OS itself. Then after they're compiled, use them as is,
or stich them into a single module. Unless the OS is completely written in
Assembly.

Either way, a trickery is needed. Either a tool does it for you, or you do
it yourself.

In your case, IO.SYS would be the 16-bit real mode OS loader, and MSDOS.SYS
would be the 16/32 bit protected mode OS. The OS loader would load
MSDOS.SYS, prepare the GDT, then switches to 16/32 bit protected mode, using
entry point in MSDOS.SYS.