Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!daver!bungi.com!news
From: culberts@hplwbc.hpl.hp.com (Bruce Culbertson)
Newsgroups: comp.sys.nsc.32k
Subject: Minix comments
Message-ID: <9008131835.AA06211@hplwbc.hpl.hp.com>
Date: 13 Aug 90 18:35:50 GMT
Sender: news@daver.bungi.com
Lines: 50
Approved: news@daver.bungi.com

Jyrki writes:

> Oh yes, I shuld warn you: when using the gcc 1.35 which comes with
> the Bruce's port, GNU make and fileutils didn't work.  I suspected the
> libraries or the old version of gcc; then I got gcc 1.37.92 working
> and tried again and both make and fileutils worked just fine.  So
> before spending that much time on debugging, you should get a new
> version of gcc.

I do not want people to get the impression that I am sending out
an unreliable compiler.  I have compiled an enormous amount of code
with it and it has worked exquisitely.  It has only one bug which I
have seen -- and 1.37 has the same bug.  1.37 has virtually the same
backend.  I am certainly not opposed to upgrading but have given it
a low priority because 1.35 has proved to be so reliable.  Perhaps
Jyrki could provide some more specific information.

> ...we're having trouble with minix's arg list limitations; often we
> get 'exec: Arg list too long')

Pc532 Minix, as distributed, has this problem 90% fixed.  That is, 90%
of the work done, 0% of the benefit realized.  Sigh.

MS-DOS Minix relocates the environment in a fixed size buffer in the OS,
making the limitation hard to fix.  Pc532-Minix OS code will copy an
arbitrary size environment -- the only limitation is in the library
routine exec.c.  Exec.c assembles the environment into a contiguous
block.  It does this in a fixed size buffer (and should continue to do
so to avoid a break system call in the usual case).  This usually
succeeds (I have never had it fail but I am not using GNU make).  New
code is needed, however, to handle the case where the buffer is not big
enough.  When this happens, a break call should be made to allocate a
considerably larger buffer.  Anyone want to fix this and post a new
routine for the rest of us?

By the way, I am now using the 1.5.10 version of FS.  Here are some
benchmarks.

	1.3 FS		1.5 FS		Benchmark
	---------------------------------------------------------
	8.0		8.0		cp /lib/cc1 /dev/null
	37.0		17.0		cp /lib/cc1 /tmp/tmp

Compiles are noticeably faster with this new version.  I am using a very
funky old disk so others may get better results.  John Connen has also
made considerable progress with 1.5.  The entire 1.5 system may be ready
to distribute in a month.  That's a crude guess.

Regards,
Bruce Culbertson