Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!munnari.oz.au!cluster!metro!natmlab.dap.csiro.au!ditsyda!evans From: evans@ditsyda.oz (Bruce Evans) Newsgroups: comp.os.minix Subject: Re: Minix needs a C compiler with source Message-ID: <2464@ditsyda.oz> Date: 24 Feb 90 17:51:25 GMT References: <1050@trlluna.trl.oz> <429@fwi.uva.nl> <11528@nigel.udel.EDU> <24304@princeton.Princeton.EDU> Reply-To: evans@ditsyda.oz (Bruce Evans) Organization: CSIRO DIT Sydney, Australia Lines: 167 In article <24304@princeton.Princeton.EDU> nfs@notecnirp.UUCP (Norbert Schlenker) writes: >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 Leave the ANSI compilers to the big boys, or use gcc. It is a lot of work to write a compiler, and much harder when a detailed standard has to be met. >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 Gcc is impressive:) in this respect as in others. There have been about 4 versions in the last year and you can read a 180K list of changes for bugs and improvements over that period. I doubt gcc had relatively more bugs than ACK a year ago. >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. Felix Croes writes: >|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. The small compilers don't seem to use much technology (lex, yacc, rtl or intermediate languages). This keeps them small at the expense of flexibility and time to write. Mine avoids intermediate steps for speed too. --- Here is a short review of various worthwhile "free" compilers that I know about. I run a 32-bit Minix system on a 386. I wrote a compiler for this (bcc) and use it for most things. I use gcc for code with ANSI C, bitfields or floating point, and to get better error reports and (rarely) faster binaries. Most of the free compilers are for the 68000. I ran them but could not test the output. Quite likely I did not set them up to best advantage. PDC (68000) ----------- /* PDC Compiler - A Freely Distributable C Compiler for the Amiga * Based upon prior work by Matthew Brandt and Jeff Lydiatt. * * PDC Compiler 3.30 Copyright (C) 1989 Paul Petersen and Lionel Hummel. * PDC Software Distribution (C) 1989 Lionel Hummel and Paul Petersen. * * This code is freely redistributable upon the conditions that this * notice remains intact and that modified versions of this file not be * distributed as part of the PDC Software Distribution without the express * consent of the copyright holders. */ This appears tp have the same base as Cristoph van Wuellen's compile. I got it in a zoo package with a lot of other stuff: (output from du) 30 PDC/Bind 65 PDC/CCX 44 PDC/Dasm 154 PDC/LibSrc/Math 16 PDC/LibSrc/Misc 18 PDC/LibSrc/Startup 46 PDC/LibSrc/StdIO 42 PDC/LibSrc/StdLib 62 PDC/LibSrc/StringLib 63 PDC/LibSrc/SysIO 417 PDC/LibSrc 26 PDC/Libr 69 PDC/Make 1 PDC/PDC/manx_include 492 PDC/PDC 148 PDC/bin 1300 PDC PDC/bin contains a compiler (PDC) (only). This contains a preprocessor but not a compiler driver. It was compiled with bcc after a little editing. Sozobon (68000) --------------- /* Copyright (c) 1988 by Sozobon, Limited. Author: Johann Ruegg * * Permission is granted to anyone to use this software for any purpose * on any computer system, and to redistribute it freely, with the * following restrictions: * 1) No charge may be made other than reasonable charges for reproduction. * 2) Modified versions must be clearly marked as such. * 3) The authors are not responsible for any harmful consequences * of using this software, even if they result from defects in it. */ I have an incomplete version from comp.sources.atari.st. 208 soz/hcc 136 soz/top 139 soz/bin 486 soz The bin directory contains a compiler (hcc) and a peephole optimizer (top). These were compiled a while ago; I forget how. gcc (alliant, convex, i386, i860, m68k, m88k, mips, nsc32k, pyr, sparc, spur, tahoe, vax) ---------------------- Gcc was written by Richard Stallman and many elves. The copyright is readily available and too big to include here. 1770 gcc/config 8309 gcc This includes about 1MB of objects. It is a really good compiler, but too big to run on an 80286 or worse. bcc (6809, 8086, 80386) ----------------------- This is not exactly free (yet). Binaries are free. 24 as/work 17 as/bin 17 as/obj 12 as/6809 413 as 2 ld/6809 93 ld 56 sc/.examples 2 sc/6809 549 sc The sizes include objects and some junk. This once ran and compiled itself (in 4 minutes) in 40K text+data and 16K heap+stack on a 6809. It should be easily portable to a 68000 at the expense of poor code generation (1 data register. The 80*86 code is harmed surprisingly little by this). --- To see how much space these take, I compiled kernel/tty.c - the biggest program in the kernel. I reduced the stack allocation for everything to find the minimum. text data bss stack 127852 13248 5200 160000 PDC 81128 3688 2652 225000 hcc (sozobon) 498384 7336 18224 270000 cc1 (main pass of gcc) 50316 2072 13484 170000 cpp (preprocessing pass of gcc) 64656 5472 11700 135000 sc (mine) 58864 5100 6832 30000 sc (16-bit, needs separate cpp to fit) Everything except gcc was compiled with bcc, so these size would shrink 20% with a better compiler or one making more space optimizations. Gcc was compiled with itself and suffers a 10% size penalty from my assembler not being able to determine branch lengths. Compile times and word counts for the output (tty.s) (with no optimization) were real user+sys lines words chars 15 13.89 2774 5319 40168 PDC 9 6.46 2383 4641 33872 hcc (might have -O) 16 9.11 2279 5809 39672 cpp+cc1 3:-) 2.41 3121 5831 34140 sc (mine) 3 1.64 sc (16-bit, on preprocessed file) 8 5.22 cpp (ACK cpp pass for 16-bit sc) 27 22.34 Minix cc Differences in the disk cache size and state make the real times untrustworthy. -- Bruce Evans evans@ditsyda.oz.au