From: noemail@basdxcqvbe.com
On Wed, 5 Jan 2022 15:40:27 +0000
James Harris wrote:
>
> After a long absence from OS development I recently returned to it -
> and it feels great to be doing this stuff again!!! The reason for the
> absence (other than life!) was that I was developing a language to
> write the OS in.
>
> Well, I now have a working compiler and a language which, while it is
> currently primitive, is usable.
>
> At this point it seems to me that there's an opportunity for a
> win-win. If I use the language to work on the OS then that will let
> me make progress on the OS while at the same time using the
> experience to provide useful feedback on how the language should
> develop.
>
> So that's what I plan to do, and the above is background to the query
> of this post, which is:
>
> What formats of image file are best for the OS itself?
>
> My compiler currently emits x86 32-bit code (and its output is
> readily linkable with other code which can be written in 32-bit
> assembly) so pmode is my target. I have enough 16-bit asm code to
> load the bytes of an image and switch to pmode but the next problem
> is what format the 32-bit image should have. AISI the options are:
>
> 1. Flat binary
>
> A 32-bit flat binary would be easy to invoke as I could just jump to
> its first byte. It would not be relocatable but it looks as though I
> could change my compiler so that as long as I avoid globals I can
> emit position-independent code - which could be handy! But I am not
> sure how to create a 32-bit flat binary. My copy of ld doesn't seem
> to support such an output, though maybe there's a way to persuade it.
>
> 2. Elf or PE
>
> Elf and PE have the opposite problem. Either of them should be easy
> to create but how would one invoke the image? Options:
>
> 2a. Extract the executable part (how?) for inclusion in the loadable
> image.
>
> 2b. Include the whole executable file, including the headers, and
> write some asm code to parse the headers and jump to the executable
> part of it.
>
> Or maybe there's another option. I've a feeling we've discussed this
> before but at the moment I cannot think of what we concluded. Plus, I
> need to work with what my compiler can produce (32-bit Nasm) which
> may be a new constraint.
>
> So, any thoughts on what format an OS image should have?
>
As long as your 16-bit OS loader code or GRUB etc can properly transfer
execution to your 32-bit OS image, does the format really matter? ...
E.g., I'm using two DOS C compilers (DJGPP, OpenWatcom) which produce
executable images for 16-bit MS-DOS plus 32-bit DPMI I.e., 16-bit DOS
stub plus 32-bit compiled C code intended for a DPMI host. Obviously,
these executables were never designed, nor intended to be a suitable
format for an OS image.
If I was using assembly or my own customizable tool chain, then I'd go
with a .COM or flat binary, but for 32-bit or 64-bit instead of 16-bit.
To transfer execution to your OS, you just need the appropriate
processor mode for the code (32-bit PM) to be set up and an entry point
to jump to. For GRUB, you can do that with a small header (Multiboot)
and a pinch of assembly which points to your OS' entry function.
Once your OS is in memory and running, it can re-configure, load or
re-load, or move around, whatever it wants, i.e., total control.
It might be easier, depending on what you're doing, to have a 16-bit
stub on the OS at the start. Then, your OS loader doesn't need to pack
in the code to setup 32-bit PM, as the OS can do the PM switch later on.
--
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
