jca@pnet01.cts.com (John C. Archambeau) (02/22/90)
The problem isn't the fact that we need a C compiler with source per se for PC
Minix, it's the fact that we have a real pain in the gulliver of an
architecture to work from with respect to memory management. I'm one of the
people around here that would LOVE to see a large model C compiler for PC
Minix, but the problem is that PC Minix is only aware of tiny (64k) and small
(64K code/64K data) memory models. If one wants a large model C compiler, one
first must modify the memory management scheme of Minix to accommodate the
juggling of multiple segments for code and/or data. It's not JUST an "I need
to port a C compiler" problem. It can be done, but very painfully. There are
also some ways around it by faking virtual memory (via LIM EMS 4.0 or actual
swapping). I don't expect to see any large model C compilers or PC Minix
supporting large model programs till a 386 version is out (what's the status
on that Mr. Evans?) with an appropriate memory management scheme. GCC has
been ported to the 386 environment, so it's now a matter of Minix being
hammered into a 386 memory management scheme. The 286 is brain damaged, but
one could try to attempt large model programs with it, but those of us who
have used a Unix based OS on a 286 and 386 know hands down that the 386 is
better suited for it.
I am no compiler expert by any means, but I have taken a compiler construction
course and I do know the pains in writing a compiler and I do know that
getting one to fit in a small memory model is a very meticulous and
painstaking process. The PC Minix compiler wasn't even developed on an IBM PC
to begin with, but a much larger machine. I do know that the Amsterdam
Compiler Kit is available for Sun Workstations since I have seen it in the Sun
Catalyst. If you want to develop a compiler for PC Minix, you'd have to cross
compile it from MS-DOS or another operating system to get the job done. Minix
C just can't handle that big of a job.
That's my little bit on the C compiler matter. I may not like its performance
and what it can do, but it is better than no compiler at all.
// 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
**--------------------------------------------------------------------------*
*/jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (02/23/90)
The question that I keep thinking is, since it is so much work to develop a compiler, and since someone a few months ago posted a whole pile of stuff to help with cross compiling on Turbo C, why aren't more people going this route? I realize it would be pretty inconvenient if the only way to do c programming was to go to MS DOS, and then boot back into Minix. But for the purposes of compiling Minix itself, wouldn't it be advantageous to get the better code generated by Microsoft C or Turbo C? I have to admit that I have not yet done anything with Minix except insert the floppies and watch it boot. But I have been collecting the 1.5.0-3 upgrades, and have been following the newsgroup with interest ever since taking an OS course where we studied the code closely... So what are the problems with cross compiling? Do the problems go beyond the question of convenience? -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (03/11/90)
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? Ken Hendrickson N8DGN kjh@usc.edu ...!uunet!usc!pollux!kjh
jca@pnet01.cts.com (John C. Archambeau) (03/12/90)
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 **--------------------------------------------------------------------------* */
cagney@chook.ua.oz (Andrew Cagney - aka Noid,285,5585,3362395) (03/12/90)
From article <1805@crash.cts.com>, by jca@pnet01.cts.com (John C. Archambeau): > kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: > [stuff deleted] > 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. eg me, Chew & Mullen. Don't get so excited about using the Turbo-C or MS-C tools... There are also problems... 1. You need to convert the minix assembler to MS or Turbo assembler (s2asm posted late last year worked for 1.4a, Mullen posted the assembler for 1.3). 2. Linking can be very hard, the file needs to be just right for it to be accepted by build and then work. How much do you know about segments and magic numbers... 3. You need to copy the files from minix to dos. 4. For minix 1.5.x you need a different version of cpp to that supplied by Borland (If you are using TurboC). The assembler files are run through cpp. 5. You need to rewrite the make files. So why do it? 1. You get a fast compiler, it takes minuits not hours to compile something... (It can also compile kermit :-) 2. You get a (very close to ANSI :-) compiler Why not do it? 1. You loose MINIX's native compilation environment. If you like :-) unix this is a KILLER! Remember the make files... 2. It is harder to do upgrades under dos. Remember the patches... 3. People are starting to write developement environments for minix that run under minix (eg shoelace & db). What dos equivalents... In summary, cross compiling win's on the speed of a compile but looses by not being MINIX's native environment. If you are always re-compiling the kernel or have the sources on a big machine then DOS may be worth it. However, if you are a new user upgrading minix I'd stick to MINIX & the ACK C compiler, at least you know that it will work (even if its slow getting there). Andrew Cagney cagney@cs.ua.oz.au BTW: For MINIX 1.3 & 1.4 I used a big machine for the patches and then cross complied it using TurboC/TASM. I haven't yet got to doing this for 1.5.x. s2asm written by Earl Chew, Bruce Evans & myself translates minix assembler into either MS or Turbo assembler. mcc is a front end to Turbo C. The original was written by Mullen, I posted an upgrade late last year. I'll make another upgrade available, for 1.5.5 when I get to it, if there is the demand (don't hold your breath).