Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!portal!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Comment on PD/Shareware C compiler
Message-ID: <1491@atari.UUCP>
Date: 9 May 89 18:50:30 GMT
References: <1048@orbit.UUCP> <1471@atari.UUCP> <703@forty2.UUCP>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 34

In article <703@forty2.UUCP> poole@forty2.UUCP (Simon Poole) writes:
> (If this was an attempt at a flame Allan, it was rather badly aimed).

It was NOT an attempt at a flame.  If I were trying to flame somebody in
particular, I hope there wouldn't be any doubt.  I misread an
attribution on a readme-type file with the distribution; the porting and
library credit really goes to JRD @ Stony-brook.SCRC.Symbolics.COM. 
However, I don't hold him responsible for the code quality.  The library
is another matter; it's a hodgepodge of PD stuff from around the world,
and he is the first to admit it.  Its argument parsing in crt0.s and
argument passing in exec.c are mutually inconsistent and actually
incompatible, and there are other omissions and inconsistencies. 

Why no-function-cse doesn't work, I don't know.  Function-cse (common
subexpression) means that the address of a function to be called is a
candidate for being put in a register, especially if it's used more than
once.  This means the "dumb" (pre-optimizer) pass puts it in a register,
generating this:

	lea	_foo,a0
	jsr	(a0)

A later, optimizing pass should notice that _foo is moved into a
register only once, then used in a sense where a register is not needed,
and "fold" that subexpression into "jsr _foo" as you would expect.  But
it doesn't.  And I couldn't turn this off with the documented switch
"-fno-function-cse." But that switch is missing.  Anyway, I look forward
to getting a newer version of the compiler, on tape from Bammi at CWRU
in Ohio, so this will all blow over soon.  Sorry to have been such a
boor. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt