Xref: utzoo comp.sys.misc:3221 comp.robotics:645 sci.electronics:17211 sci.engr:543
Path: utzoo!censor!geac!torsqnt!spv!sickkids!mark
From: mark@spv.UUCP (Mark Bartelt)
Newsgroups: comp.sys.misc,comp.robotics,sci.electronics,sci.engr
Subject: Re: C compiler for 68HC11
Message-ID: <433@spv.UUCP>
Date: 24 Jan 91 12:03:13 GMT
References: <1991Jan18.024240.14924@ncsuvx.ncsu.edu>
Reply-To: mark@spv.UUCP (Mark Bartelt)
Followup-To: comp.sys.misc
Organization: SPV Technologies, Toronto
Lines: 88

In article <1991Jan18.024240.14924@ncsuvx.ncsu.edu>
kirk@hobbes.catt.ncsu.edu (Kirk Krauss) writes:

> Anybody know where I can find a good C compiler (preferably ANSI)
> for the Motorola 68HC11 evaluation board (EVB) or compatible?
> I'm looking for a cross-compiler which runs on a PC or Mac and
> generates S-records for serial downloading to the EVB.

I have a recommendation for one to avoid:  Avocet's C11.  I've had the
misfortune of using it for the past couple months, and it's without a
doubt the buggiest C compiler I've ever used in my life.  Thus far I've
found nearly a dozen bugs.  About half were instances of incorrect code
being generated.  Several others were cases of the compiler rejecting
as syntactically incorrect a construct that was perfectly valid.  And
finally, there were a couple library routine bugs (though it's possible
that the compiler may have been botching the function call by passing
wrong arguments to the library routines; I haven't checked yet), and
one bug with the linker.  Oh, yeah, at least one documentation error in
the man pages as well.

A dozen bugs might not seem like much if one came across them over the
space of, say, a couple years.  But I've been using this compiler only
for a rather small project (less than 2000 lines of C code), and not
doing anything particularly obscure.  And the bugs are often in areas
so fundamental that it's hard to see how this compiler could have been
used for anything much more complex than a simulation of a $3.98 digital
watch.  For example

		x &= y;

works correctly if x and y are of type int, but generates bad code if
they're of type char.

		long x, y;
		x = y + 16L;

results in an incorrect value for the evaluated expression.

		int x;
		double y;

		y = (double)x;

assigns an incorrect value to y.  There are workarounds for all of these:

		x = x & y;
and
		long x, y, L16=16L;
		x = y + L16;
and
		y = (double)(long)x;

But still, the time spent (wasted) in tracking down the cause of one's
non-working program to yet another wretched compiler bug, and finding
a workaround, has been far more than I consider acceptable.  I don't
have a copy of my complete bug list with me at the moment, but would
be glad to send it to anyone who's really interested.

There are a couple of real howlers in their version of the C reference
manual.  For example, when discussing lvalues, they say:

   A point to note is that an expression of the form E1->memb is an
   lvalue only if E1 is an lvalue.

When I mentioned this to a friend, his instant response was "But ...
that's *horseshit*!"  Yes, indeed.  The above-quoted passage leads me
to believe that the people who wrote this compiler don't really have
an understanding of the C language.  Their product brochure claims

   Avocet C compilers are fully compatible with the new ANSI
   draft standard X3J11.

Right.

As for recommendations for *good* compilers for the 68HC11, the one
from Archimedes came highly recommended, though I haven't used it
myself so can't confirm how good it is.  Knowing what I know now,
though, I wish we'd gotten theirs; it's unlikely that it could be
as bad as the Avocet compiler.  ( Why did we choose Avocet in the
first place?  Well, it was cheaper, and the hardware guy who did
the board design reported that his colleagues had been using it
and were happy with it.  Just goes to show what happens when you
trust a hardware person's recommendation. ;-)

--

Mark Bartelt                                        SPV Technologies
mark@spv.uucp                                       Toronto, Ontario