Xref: utzoo comp.sys.amiga:28676 comp.sys.amiga.tech:3553
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!agate!eris.berkeley.edu!mwm
From: mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: C Compilers
Message-ID: <19774@agate.BERKELEY.EDU>
Date: 1 Feb 89 07:24:51 GMT
References: <496@geocub.UUCP> <30997@vax1.tcd.ie> <7261@batcomputer.tn.cornell.edu> <3342@sugar.uu.net>
Sender: usenet@agate.BERKELEY.EDU
Organization: Missionaria Phonibalonica
Lines: 95

<I haven't examined the code generated by Lattice, but Aztec's leaves much to 
<be desired.  It's frustrating to see the compiler moving values from a
<perfectly useful d-register into another d-register to perform a calculation
<on it.  Also, it does stuff like dereferencing a chain of pointers
<p->q->bar on every reference -- even if it already has the address it needs
<sitting in a 

Lattice 4.0 was doing a nice job of saving temporary values -
including references. At least in the cases I looked at, which were of
the form:

	if (long->messy->pointer->chain <cmp> magic_value)
		long->messy->pointer->chain = magic_value ;

It would only chase through the pointer once. That meant I didn't have
to go convert all of those to:

	tp = &long->messy->pointer->chain ;
	if (*tp <cmp> magic_value) *tp = magic_value ;

Which is a major win as far as I'm concerned.

<I talked to Aztec tech support on the phone recently, though, and they say 
<that a new version, scheduled for release in March (but it'll probably slip
<by months -- they're pretty bad about doing that) which is full ANSI,

The one time I looked at Aztec, I decided it wasn't worth fooling with
after finding three bugs in the compiler on the first project I was
working on - one of which couldn't be worked around. Because of that,
I don't have any kind of feel for how well they deliver on promises
like "full ANSI".  I'd be interested in hearing how well they do;
especially on the nitpicky little details (type of main correct?
return XX from main? stdargs treatmenat? predefined symbols? obscure
ANSI functions?). 

>Everyones talking about the precompiled .h-files in Lattice.
>Manx did this since V. 3.4 and it saved me a LOT of time when 
>Lattice didnt even know what it was :-)

Yup - Manx having them undoubtedly caused Lattice to put them in.
Likewise, Lattice going ANSI probably had something to do with Aztec
doing the same thing. Trouble is, Aztec still hasn't figured out what
prototypes are - and they've saved me a LOT of time.

>Hoever, I think you should wait for Manx 4.1. to compare to 
>Lattice 5.0. 

Lattice did a disgusting thing with 5.0, and forced me to purchase the
"Compiler Companion" with the update. I was upset enough about this to
call Aztec to see if when 4.1 was going to be out. Answer: 2nd quarter
of '89. 5.0 came out before Xmas of '88. I need ANSI features _now_,
not three months from now. So guess who got my check? And when 4.1
comes out, I'll compare it to what Lattice is shipping _then_, not
what they're promising in three months. Vaporware is always _going_ to
be better than real product - at least until the vaporware gets here.

Now, as for that "Compiler Companion". Several people have mentioned
it. I think it sucks - and would rather not have had to purchased it.
LMK is ok - and even lets you specify a file to search for default
rules (which is why I'm using it). Other than that, they were a waste
of disk space. All the little utilities are verbose, and don't really
work very well together (nuts - you can't even feed the output of grep
to itself in a usefull manner), except where they were force-fit.
Whoever wrote them got the Unix tools, but didn't get the philosophy
that makes them work well. Worse yet, those tools are bigger and
slower (though sometimes not until I've recompiled with 5.0) than the
pd versions on the fish disks. Finally, there's LSE: an editor that
manages to be both bigger, slower & less powerfull than mg. Among it's
sins are 1) understands vertical overscan, but not horizontal
overscan; 2) isn't very configurable; 3) can't edit enough files; 4)
only two windows, which must split equally; 5) no ARexx interface
(even though the debugger has one!) 6) Not very well amigafied - at
which point I gave up on it. While I'm at it, I'd like to point out
that the debugger sorta sucks when it comes to "Amiga" interface.
Opening windows for string requesters? SubMenus with two entries: "On"
and "Off" (meaning it's faster to enter the keyboard command even when
I've _already_ got the mouse in my hand)? Just like the Unix
utilities, whoever did this seems to have gotten the look, but not the
soul, of what the tools should be.

<It's a good thing there are two C vendors for the Amiga.  If there were only
<one it's doubtful it'd be as good as the two are, although I do not
<think either meets the standards of the cardinal IBM PC C-compilers.

I don't use IBM C compilers; but Lattice 4.0 and later are better than
the "pcc" shipped with most versions of Unix. And I agree that there
being two compilers for the Amiga probably made that happen.

	<mike

--
Il brilgue: les toves lubricilleux			Mike Meyer
Se gyrent en vrillant dans le guave,			mwm@berkeley.edu
Enmimes sont les gougebosqueux,				ucbvax!mwm
Et le momerade horsgrave.				mwm@ucbjade.BITNET