karl@sugar.hackercorp.com (Karl Lehenbauer) (02/04/90)
I have had the new release of Aztec for a week now, and I'd like to share
my impressions after this short period.
First off, the new compiler claims to be fully ANSI-compliant. As far as I
know, it is. The thing I have most ravenously adopted is using function
prototypes. (You declare the data type of the arguments to functions in
your function definitions and the compiler verifies that the types match.)
They help the compiler catch a lot of bugs at compile time that you used
to have to debug at run time. (There was lint but who hardly anyone had a
copy on the Amiga?) In recompiling some old stuff, I found a couple errors
where I had done an fprintf("format string",vars), which has the strong
potential of crashing the machine or at least overwriting memory somewhere.
There are a couple of compiler switches to help you with prototypes by
reading your programs and generating prototype files. One switch allows
you to generate prototypes for your static functions and the other does
so for your global functions. They can be used together to get both.
This will work with old-style K&R declarations as well. Here is where I
found the only bug I've found so far -- it wrote into the prototype file
a parameter of "int foo" when the K&R-style argument was "register char *foo".
Anyway, what I've been doing is reading the static function prototypes back
into the program source and catting the external function prototypes into
a prototypes.h file.
The <functions.h> include file now uses prototypes for everything.
Command line arguments are totally different. The manual said this was
dictated by the ANSI standard. A -3 switch offers backwards compatibility
with the 3.6 compiler command line argument processing. A -5 switch selects
the new arguments (the default). These are toggles, so you can use both.
I am totally switching over to the new style.
The Manx compiler can now generate code to directly call Amiga library
routines, rather that having to call the glue routines normally linked
in through the libraries. With this and some other code they've provided,
they claim it is now super-easy to create Amiga shared libraries. I
haven't done it yet, but it's high on my list. Also through this facility
there is a way to create routines that get their parameters through registers
rather than from off the stack and tell the compiler to generate the code
to put the arguments in registers rather than on the stack. I think it'll
be useful for writing certain highly optimized stuff.
It now has all sorts of optimizations that you can select, a long-awaited
and much-anticipated option, considering how that some of the code generated
by the 3.6 compiler was rather poor. If all the usual optimizations (-so)
are selected, it will use a two-pass assembly to do branch optimizations,
define a _C_MACROS_ macro to replace some functions with macros (via #ifdefs
in include files), not generate stack-frame-manipulating LINK and UNLK
instructions if a function contains no local variables, delays popping
arguments (doesn't generate an add-to-stack-pointer instruction to clean up
the stack after every call with arguments), allocates registers based on
usage counts (and since it puts variables in registers, a lot of times
it can get them all in and end up not generating LINK and UNLK instructions
for subroutines that do have local variables.
The optimized code I've looked at is much improved over the unoptimized code
of either 3.6 or 5.0. A lot of things are in registers, which gets rid of
lots of "mov 16(a5),d1" and "mov d1,16(a5)"-type instructions. Also it's
not nearly as stupid about moving registers around when it didn't need to.
The old compile would do stuff like "mov d3,d1 add d1,d0" -- a lot.
The new one just does "add d3,d0".
Still missing is common subexpression elimination. That would be very nice,
but I can see how it's really tricky. Oh well. (Does Lattice do it? If
it does, I probably have to switch.)
I was somewhat surprised, however, to see that it does not short-circuit
branches (a conditional branch to an unconditional branch can be replaced
by a conditional branch to wherever the unconditional branch is to branch
to, for example) and it also generates some branches like this:
L1
.
.
bne L2
bra L1
L2
In this case, "bne L2" could be replaced by "beq L1" and the "bra" discarded.
Oh well.
The manual says it confuses sdb to try to debug optimized code, which makes
sense and is hardly a problem, but the manual seemed to say that sdb could
still do it. I haven't tried it or anything.
The update was fairly inexpensive for a major re-release, I think $85.00.
The manual is way improved over the very old versions. I had heard that Manx
had been shipping much improved manuals later on in the 3.6 era, but I never
got them. Anyway, the manual comes in one bound 800-page-or-so trade
paperback-style book. This contains the Aztec C User Guide, the Aztec
C Reference Manual, The Aztec C Library Manual, Aztec C UniTools and
the Aztec C Source Level Debugger. I presume it came in this style to make
copying harder. Updates are going to be a pain, though.
Oh yeah, there's a "quick fix" compiler switch where you can get into Z
or other editors with ARexx ports (don't know if Z actually has one), and
your editor can then drive around forwards and backwards through your errors.
I haven't tried it yet, but will soon, and I think it'll be OK as long as
you can see what the compiler error message was while you're editing.
Anyway, I'm quite pleased with the new release, but it was very late (at least
ten months from the first promised ship date I heard, plus they swore up and
down that it'd be shipped end of November, which is when they took my order).
I don't know if it can be said that Manx has now surpassed Lattice or rather
that they have merely caught up with them, but it's nice to get the improved
version and retain a known environment.
Later,
--
-- uunet!sugar!karl "As long as there is a legion of superheros, all else
-- can surely be made right." -- Sensor Girl
-- Usenet access: (713) 438-5018riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (02/04/90)
In article <5096@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: [description of lots of Manx 5.0 features deleted] >Still missing is common subexpression elimination. That would be very nice, >but I can see how it's really tricky. Oh well. (Does Lattice do it? If >it does, I probably have to switch.) Lattice does do some common subexpression merging. The compiler even does some simple cases without the optimizer turned on. >I don't know if it can be said that Manx has now surpassed Lattice or rather >that they have merely caught up with them, but it's nice to get the improved >version and retain a known environment. Your list of features looked a lot like a feature list for Lattice 5.0, with a few exceptions. It sounds like Lattice may still have an edge in optimization (or maybe not). Lattice isn't ANSI compliant in a few places, so Manx may have an edge there. Manx probably still has a big advantage in compile time. If Manx 5.0 is reasonably bug free, I'd give them a small edge in the compiler wars, but it's pretty close. Isn't competition wonderful? -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
johnm@spudge.UUCP (John Munsch) (02/07/90)
One thing that nobody has mentioned was the change in object format from 3.6 to 5.0. In the manual they just state that you will have to recompile "everything" in order to be compatible with the new 5.0 but they don't really say why. The reason is because they are _finally_ using standard amigados library and object formats. This means that you can now use a68k and blink (I've only actually tried a68k) with Manx. Yay! I think the reason they are downplaying it is because Lattice was already using the approved formats for everything and Manx probably thinks it makes them look bad. John Munsch