mmdf@udel.UUCP (06/03/88)
According to ast:
No concessions are being made to MS-DOS or any of its compilers.
A number of people have said that the MINIX
C compiler is slow. Since I don't have (or want) any MS-DOS compiler, I
can't make a comparison, but I did run the following timing test. I removed
all the .s files from fs and typed: time make. The 20 compilations plus
the link took 5:57 real time on my Z-248, which has 1.5 MB RAM and an ST-225
hard disk (70 msec access time). It seems to me that this isn't so awful.
Obviously a PC will be slower, but that should hold proportionally for all
compilers.
I have a copy of Minix I purchased right after the textbook came out. In order
to get it to run on my hard disk (I use genuwine PC-ATs) I had to start
recompiling Minix out of the box. The performance of the C compiler was
horrendous. To make the kernel was something which seemed I recall took on the
order over 1/2 hour. While the system was running on floppy disks, it didn't
appear to be I/O bound on floppy disks. Compiling things like printf("hello
world\n") took noticable amounts of time (on the order of a minute). Still does
with my distribution C compiler. Which is why I stopped using the Minix C
compiler. Which is why I'm (somewhat) anxiously looking for other solutions to
native compiling on Minix (gcc? small-c?).
Andy reports make fs takes 5:57. On my 8Mhz AT with Aztec, it takes a shade
under 5 minutes. 5:57 is more than acceptable. What I don't understand is
why my Minix C compiler out of the box is so bad. I may look at the problem
some more -- maybe one of the sizes is wrong so one of the programs is doing
byte by byte I/O (instead of buffered). Anyone out there have any answers? I
may start timing each pass and see what's going on my system. HELP!!
BTW -- At the moment, I'm finding the dreaded Ms/Dos far pointers most useful.
Instead of the S/D/T segments, I'm going to start having kernel/fs/mm handle 32
bit pointers and map in user space before operating on it. This will lead to
the ability to run more complicated memory models (specifically 1 64K code
segment/1 64K initialized data/1 64K stack/N 64K heap segments for moderate N).
Anyone else doing this?
marty
ARPA: leisner.henr@xerox.com
GV: leisner.henr
NS: martin leisner:henr801c:xerox
UUCP: nsc!nscimg!amps!marty
rmtodd@uokmax.UUCP (Richard Michael Todd) (06/04/88)
In article <2855@louie.udel.EDU> Leisner.Henr@xerox.com (Marty) writes: >I have a copy of Minix I purchased right after the textbook came out. In order I assume that means v1.1. >to get it to run on my hard disk (I use genuwine PC-ATs) I had to start >recompiling Minix out of the box. The performance of the C compiler was >horrendous. To make the kernel was something which seemed I recall took on the >order over 1/2 hour. While the system was running on floppy disks, it didn't It's even worse on my system, a PC/XT clone. The first time I recompiled the kernel I sat down to watch Blake's 7. The tv show was finished before the compile was (~55 min.) Thing is, both Marty and I still have the v1.1 compiler. Is v1.2 much faster? Inquiring minds want to know. >compiler. Which is why I'm (somewhat) anxiously looking for other solutions to >native compiling on Minix (gcc? small-c?). Not likely. I can claim a good deal of experience with small-c, having ported it to my TRS-80 many years ago. If you don't mind having a compiler which only supports int, char, int *, char *, int [] and char [] types, small-C shouldn't be too difficult to port, especially if you start with a version already hacked to produce 8088 code (e.g. the one announced in this month's Byte). Frankly I don't think it's worth it. And from what I've heard porting GCC to the 8088 or 80286 would be decidedly non-trivial-- Richard Stallman didn't design his compiler to handle braindead architectures.... >may start timing each pass and see what's going on my system. HELP!! As I recall, the majority of the time is spent in cg and asld. (This from much experience pushing F1 to see what the machine was up to, and not terribly scientific.) >bit pointers and map in user space before operating on it. This will lead to >the ability to run more complicated memory models (specifically 1 64K code >segment/1 64K initialized data/1 64K stack/N 64K heap segments for moderate N). >Anyone else doing this? Hmm... sounds interesting. What would be even more interesting is some sort of overlay scheme with multiple code segments so we can have effective code sizes >64K. I don't really know enough about 286 architecture to know how feasible it would be... -- Richard Todd Dubious Domain: rmtodd@uokmax.ecn.uoknor.edu USSnail:820 Annie Court,Norman OK 73069 Fido:1:147/1 UUCP: {many AT&T sites}!occrsh!uokmax!rmtodd, but don't be surprised if I don't answer--our mailer is *very* *very* hungry :-<
dmk@dmk3b1.UUCP (David Keaton) (06/08/88)
Let's get some real numbers here. How many LINES of code BEFORE CPP are you talking about compiling? And how many CHARACTERS does that work out to AFTER CPP? And how long does it take to compile on the fastest configuration available? Once we get these numbers, we can start comparing it with other compilers. -- David Keaton dmk%dmk3b1@uunet.uu.net uunet!dmk3b1!dmk
HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) (01/04/89)
Over the long weekend I mostly upgraded Minix from 1.1 to 1.2. I say mostly because no matter what I try, I cannot get a good executable for the 1.2 version of make.c. The compiler either trashes the filesystem that I mount on /tmp or generates a binary that locks Minix solid. Any thoughts on what is going wrong? - Guy Helmer BITNET: HELMER@SDNET uucp: ghelmer@loft386 ...!killer!warble!loft386!ghelmer
news@heitis1.uucp (News Administrator) (09/14/90)
In the MINIX 1.5 release, are the full sources for the C compiler and assembler included with the system. I have been thinking of buying a copy, and this would be an additional selling factor to me 8-). TIA, brian
ast@cs.vu.nl (Andy Tanenbaum) (09/14/90)
In article <1990Sep13.202446.9777@heitis1.uucp> news@heitis1.uucp (News Administrator) writes: > >In the MINIX 1.5 release, are the full sources for the C compiler and >assembler included with the system. No. This hasn't changed from previous versions. The compiler itself has not changed since 1.3, and UniPress and Transmediair (see preface of the book) are still selling the sources. Andy Tanenbaum (ast@cs.vu.nl)