Smaller C huge model linker

[[e-mail]]

I have had enormous success with Smaller C.
I can now build MSDOS executables with no
limitation I know of, except that I haven't yet
implemented the floating point support
functions. That's not a high priority for me yet,
as I'm not using floating point.

What is of more interest to me is whether I can
use this to produce a real mode loader.

My boot sector only loads 3 sectors (same as
MSDOS), so I can't do all the relocations at the
beginning. However, my loader code doesn't
use data variables that I can see, as far as
loading itself, so I can probably do the relocation
after it has self-loaded.

But since I am hardcoding load addresses
anyway, I thought I may as well just generate an
executable with the relocations already done
assuming a particular location.

But when I looked at the smlrl documentation it said:

You can specify the "origin" for Windows, Linux, MacOS and flat executables.

I'm using huge, not flat. I guess the data areas will
all be flat, and my code is less than 64k so cs will
never need to change, and in fact I guess I really
want a memory model where cs is never touched
and all calls are "near".

I can probably change the bootloader code to load
the full 58 sectors instead of just the first 3 so
self-loading is not an issue.

But I'm basically out of my depth and I'd like to know
where I stand.

Also note that currently I'm just talking about the
loader, which I call IO.SYS. And I'd like to try it with
the 32-bit MSDOS.SYS first. But later I will do the
16-bit MSDOS.SYS with a different loader executable,
and since MSDOS.SYS will be Smaller C huge memory
model, it would be nicer if I could do a far call, so if
the loader is using far code pointers, that would look
nicer.

And MSDOS.SYS 16-bit will be at a fixed location too,
so it could also be built with relocations already done
too. But it has more than 64k of code so it can't be
done with near code pointers.

BFN. Paul.

[Alexei A. Frounze]

Post by ***@gmail.com
I have had enormous success with Smaller C.
I can now build MSDOS executables with no
limitation I know of, except that I haven't yet
implemented the floating point support
functions. That's not a high priority for me yet,
as I'm not using floating point.
What is of more interest to me is whether I can
use this to produce a real mode loader.

Sure.

Post by ***@gmail.com
My boot sector only loads 3 sectors (same as
MSDOS), so I can't do all the relocations at the
beginning. However, my loader code doesn't
use data variables that I can see, as far as
loading itself, so I can probably do the relocation
after it has self-loaded.

I've written a FAT12/16/32 boot sector (effectively, 3
variants of the same), that is, one boot sector
that can load an entire DOS .COM or .EXE and run it.
That includes .EXE relocation (not needed in your
case since there aren't any standard relocations in
Smaller C-made .EXEs).

Post by ***@gmail.com
But since I am hardcoding load addresses
anyway, I thought I may as well just generate an
executable with the relocations already done
assuming a particular location.
You can specify the "origin" for Windows, Linux, MacOS and flat executables.
I'm using huge, not flat. I guess the data areas will
all be flat, and my code is less than 64k so cs will
never need to change,

Says who? The compiler produces far calls and far returns
in the huge and unreal memory models and function
pointers are transformed into segment and offset pairs,
in which the offset is less than 16, just like with data pointers.
You can readily see this in the startup relocation code.

Alex

[[e-mail]]

Post by Alexei A. Frounze

Post by ***@gmail.com
You can specify the "origin" for Windows, Linux, MacOS and flat executables.
I'm using huge, not flat. I guess the data areas will
all be flat, and my code is less than 64k so cs will
never need to change,

Says who? The compiler produces far calls and far returns
in the huge and unreal memory models and function
pointers are transformed into segment and offset pairs,
in which the offset is less than 16, just like with data pointers.
You can readily see this in the startup relocation code.

Ok, I didn't consider function pointers.

Do you agree that if I am loading to a fixed address in
memory that the linker could theoretically produce a
huge memory model image, so that I don't need to do
full blown relocations for either code or data at runtime?

Is it correct that there is currently no way to get smlrl
to do that?

If so, I think that means I have no choice but to do the
relocations at the beginning at runtime, which means I
will need to change my boot sector to read the full
58 sectors.

Thanks. Paul.