Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!psuvax1!rutgers!njin!princeton!notecnirp!nfs
From: nfs@notecnirp.Princeton.EDU (Norbert Schlenker)
Newsgroups: comp.os.minix
Subject: Re: Minix needs a C compiler with source
Message-ID: <24304@princeton.Princeton.EDU>
Date: 19 Feb 90 19:39:50 GMT
References: <1050@trlluna.trl.oz> <429@fwi.uva.nl> <11528@nigel.udel.EDU>
Sender: news@princeton.Princeton.EDU
Reply-To: nfs@notecnirp.UUCP (Norbert Schlenker)
Organization: Dept. of Computer Science, Princeton University
Lines: 93

I'm going to batch some comments regarding this thread.

|In article <429@fwi.uva.nl> croes@fwi.uva.nl (Felix A. Croes) writes:
|In article <1050@trlluna.trl.oz> greg@ait.trl.oz (Greg Aumann) writes:
|>It is becoming more and more obvoius that Minix needs a C compiler with
|>source that can be distributed without restrictions and modified
|>easily.  Problems caused by the current ACK compiler are that it is
|>difficult to get bugs fixed.  There is little hope of seeing desirable
|>extensions such as ANSI conformance etc.  Also you cannot look at the
|>source and learn about compilers.  The original intention of using
|>minix to teach OS courses or for self study could apply equally well to
|>compilers if the source were available and readable.  Note when I write
|>compiler I also mean to include an assembler and a loader.
|
|The current compiler will be replaced by an ANSI C compiler in 2.0 - again, not
|in source. On all other points, I agree.
|
|[description of ideal Minix compiler deleted]
|The ideal Minix compiler would be public domain (of course).

Here's another vote in favour of all of the above.  As for the ANSIness of the
2.0 compiler, that is a secondary consideration.  The big problem with the 
Minix compilers is that source is not really available and that there is no
real facility for bug fixes.  I have always received polite responses to my
bug reports from Andy and/or Ceriel; almost invariably, the bugs have been
reported previously by others and are fixed in the next release.  BUT the next
release is just too far away, much too far away.  I have almost resorted to 
cross-compilation under DOS, but have resisted so far.  I know that many others
have simply given up on the ACK compiler.

|Gcc is too big, period. The ACK idea is fine, when trimmed down to what it
|really is all about: using EM as an intermediate language.

Agreed.

|...
|A friend of mine is presently working on a ANSI C front end. Another friend is
|working on a 68000 code generator. I have already written a loader for Minix ST
|(shouldn't be too difficult to port it to the PC, once asld is split in a loader
|and an assembler), and I an thinking about writing a C++ front end.
|...
|Felix Croes    (croes@fwi.uva.nl)

Fine ideas.  I believe that the 2.0 cc will have separate assembler and loader,
after which I think the process becomes much simpler.  Felix's loader would be
ported fairly easily (at least it looked that way to me when I saw it).  An
assembler, while by no means trivial in a general sense (e.g. if you want useful
macros), isn't hard once you have an object file format to translate to.  And
once we have that, a code generator that maps EM code to assembly cannot be too
far behind (aren't all you 80386 owners using Minix tired of the inability to
use 32 bit facilities?).  As for cpp/cem, I would happily leave them as is, not
wanting personally to get involved in all that grotty stuff.

I can easily imagine Minix cc (PC version) being almost entirely replaced in
short (and reverse) order.

In article <11528@nigel.udel.EDU> INFO-MINIX@UDEL.EDU writes:
|As to compilers with source:
|The sozobon compiler/optimizer/assembler/linker is freely available, I
|have tested it and found only two errors (but: they were catastrophic when
|hosting the compiler on a Sun386i workstation).
|BUT: I see little chance to hack a INTEL 8088 version from it.
|(and: I wont bet it fits into 64K).

Having looked at the Sozobon compiler myself, I have to say that I see
little hope as well.  I had hopes of using it, but the code generation and
register allocation, nominally cleanly separated in the code, are actually
spread throughout the compiler.  There also seems to be heavy dependence on
the large number of registers and orthogonality of the 680x0 instruction set
(not that I think those are bad things - but 80x86 CPU's don't qualify in
either regard).

The Sozobon compiler is also not ANSI, and making it ANSI looks like a lot of
work.

With regard to the size, that's not really a problem.  I couldn't get PC Minix
cc to compile the Sozobon compiler, but there is no problem compiling it under
DOS (using Microsoft C) and the total executable size is only ~90K (with all the
debugging code included).  Quite a creditable piece of work.

|2.) I have written an 68000 compiler derived from some raw Material I got
|by email (original Author: M. Brandt). It now handles signed and unsigned
|char/short/long and float/double, but double being a synonym for float.
|I have compiled MINIX with it successfully during a MINIX port I've
|completed now, but I feel there are some problems left. In a few weeks
|I will send the compiler to the referees. It does everything in core,
|avoiding intermediate files, it is optimizing and maps frequently occuring
|expressions on registers, thus yielding 1008 (Version 2.1) dhrystones
|with or without the register attribute.

Interesting.  How hard would it be to add code generation for the 80x86 family?

Norbert