Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!pasteur!helios.ee.lbl.gov!nosc!crash!pnet01!jca
From: jca@pnet01.cts.com (John C. Archambeau)
Newsgroups: comp.os.minix
Subject: Re: C compilers and large code/data...
Message-ID: <1805@crash.cts.com>
Date: 11 Mar 90 18:56:01 GMT
Sender: root@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 66

kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes:
>In article <1609@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes:
>>cross compile it from MS-DOS or another operating system
>
>Is it possible to use Microsoft C 5.0 to cross compile stuff for minix?
>How would you do this?  Would you have to generate assembly code, and
>then assemble it on the minix assembler?

Way back in the pre 1.3 days, it was common practice to cross compile the
Minix OS from an MS-DOS C compiler whether it be Borland, MS, Zortech, or
Aztec.  Here's the basic process:

1. Create a Minix library.  Do NOT use your MS C library, the Minix
   library is needed.  The reasons are obvious, the MS C library is
   for MS-DOS and OopS/2, not Minix.

2. Compile the Minix kernel utilities (such as build) along with the ones
   you need to cross compile from DOS (dos2out) which puts your executables
   in the Minix a.out format.

3. Compile each module of the kernel.

4. Crank it through dos2out which does the EXE to a.out conversion.  Build
   expects a file in the Minix a.out format.

5. Run build.

Now this is just a basic overview of how it is done, it is not complete and
you will run into some idiosyncratic problems.  One problem I found was the
switch code generated by Turbo C 1.5.  But other people have managed to
generate the Minix kernel via TC 1.5, so I finally broke down and called
Borland.  The engineer I talked to wasn't aware of such a problem with 1.5 and
directed me to get the patch kit for 1.5, which was primarily for the graphics
libraries anyway.  

There are some advantages to cross compiling.  One, you get more optimal code.
 
1. You get more optimal code which is good.

2. You can use register variables.  The Minix C compiler doesn't do any
   register variable allocation at all.  So if you think you'll need
   a register variable, you're going to have to cross compile to use it.

3. You can generate code for the 80x87.  But there are caveats with that
   since the Minix kernel doesn't support the 80x87, so you have to keep
   it happy when things such as a process using the '87 is put to sleep
   so another can use the CPU (and possibly the '87).  I don't know the
   mechanics of how the '86 and '87 interact, and I know the interaction
   varies whether you're using an '87, '287, or '387 because of various
   idiosyncratic problems.  Also, any FP emulation package you use with
   your MS-DOS C compiler will not work on the Minix side unless you
   tweak it and recompile it for Minix (most C compiler vendors don't
   release their FP emulation library anyway), but there is some hope,
   an FP emulation library was posted not too long ago and it's probably
   in a Minix archive near you.
 
     // JCA

 /*
 **--------------------------------------------------------------------------*
 ** Flames  : /dev/null                     | My opinions are exactly that,
 ** ARPANET : crash!pnet01!jca@nosc.mil     | mine.  Bill Gates couldn't buy
 ** INTERNET: jca@pnet01.cts.com            | it, but he could rent it.  :)
 ** UUCP    : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
 **--------------------------------------------------------------------------*
 */