Mail Archives: djgpp/2006/03/11/13:30:27
Florian Liebig <FlorianLiebigEMD AT compuserve DOT de> wrote:
> the only thing that really makes headaches do occur is that i do not
> really know much about djgpp compiler designs.
There is no "compiler design" for DJGPP. Actually, for what you want
to do, you won't be using DJGPP at all. You'll be (ab)using its
version of GCC as a cross-compiler.
> do you know a good faq for me ?
"Using and porting GCC", which is bascially all the documentation
about GCC compiler internals you're ever likely to find (other than
the GCC source itself, that is).
> but nearly all things that I did was designed for 16bit dos or 16bit
> os-independant.
There's not really any such thing as "16-bit OS-independant". The
restriction to 16-bits already implies a dependance on the family of
OSes that qualify as "16-bit".
> so the c startup things are kind of that 'exec' - function job, hm ?
No. They do exactly that part of the job that 'exec' doesn't do.
Which is why you need them even in a freestanding implementation,
where there's nothing running on the CPU that you didn't put there ---
so no other program to exec() yours, either.
Startup code is the stuff that makes it possible for main() to run.
From the point-of-view of a C programmer, this covers stuff like
setting up space for all variables of static storage duration,
initialize them to their defined values, initialize the stack, the
heap, and so on. With C++ as a mental model, think about who's going
to call all those constructors of static objects: that's the startup
code.
If you want to really understand how this is done, have a look at the
boot-up code of an open-source OS of your choice (Linux, *BSD,
FreeDOS). You may need some understanding of the job of a PC's BIOS,
too.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -