Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!caip!cbmvax!higgin
From: higgin@cbmvax.cbm.UUCP (Paul Higginbottom)
Newsgroups: net.micro.amiga
Subject: Re: Aztec C, good, bad, HELP!
Message-ID: <242@cbmvax.cbmvax.cbm.UUCP>
Date: Wed, 14-May-86 14:33:23 EDT
Article-I.D.: cbmvax.242
Posted: Wed May 14 14:33:23 1986
Date-Received: Fri, 16-May-86 03:12:55 EDT
References: <276@bucsb.bu.edu.UUCP>
Reply-To: higgin@cbmvax.UUCP (Paul Higginbottom)
Organization: Commodore Technology, West Chester, PA
Lines: 116

In article <276@bucsb.bu.edu.UUCP> jdt@bucsb.bu.edu.UUCP (Dave Tenny) writes:
>
>In response to article 2564 "Question about Alink"
>>is it possible to link a "hello, world" to a less-than-10K executable ...
>
>I'd like to know that too.  I don't believe it's possible until Lattice
>V 99.6 gets out.  Don't get me wrong, I like the Lattice Amiga compiler,
>it's the size of the code that gets me down. 
>(I've been using my Lattice compiler for ~7 months)
>
>I took the (expensive) plunge and bought Aztec C V 3.20a this past weekend.
>Portability problems aside, I could *almost* be pleased with it.
>If you get your programs to compile & link, the code size is wonderful.
>
>The good points:
>  Aztec C is a fast compiler, no bones about it.

You didn't answer Dave Tenny's question, so I will.  It took me less than 1
minute(!!!) to write, compile, AND link hello.c and the executable is 4720
bytes.

>  LN (the linker) is fast *if* the 85k library is in ram.
>  The code produced is very small.

True - but that's a limitation in floppy access speed, NOT THE LINKER OR THE
COMPILER.

>
>The mediocre points:
>  The C compiler has it's share of bugs, nothing major,

WHAT DOESN'T?  Bitfields, and handling of bizarre (incorrect) syntax causes
the compiler prblems.

>  although I still have a problem compiling the latest version of
>  MicroEMACS 3.6, because the compiler generates an "internal" error
>  which the book says I shouldn't be receiving.  (Bind.C, any help out there?,
>  it fails in EPATH.H)
>

I ported a version (not sure what) of MicroEmacs source I had to the Amiga in
TWO HOURS!  I made changes to 3 files, I think, and hey, it worked!
With Lattice, this would have taken forever, without a real make, for one!

>  There is no tentative ansi draft support.. just vanilla C
>  with a vanilla runtime library.

Is this really causing you a problem?  The only problem we had is with
functions not being able to return structures when we were porting Hack.
So we changed the functions to return pointers to structs, and then did
an assignment which is does allow, upon return.  E.g:

	extern struct whatever *xyz();	/* was whatever xyz(); */
	struct whatever x;

	x = *xyz();	/* was x = xyz(); */

No big deal.

> 
>The BAD points:
>  Aztec uses non-standard object format.  Hence, the object library
>  manager I wrote for code as described in the technical reference
>  is USELESS with aztec.
>

BAD ONLY FOR YOU.

>  Because of the non standard object format, you are forced to use
>  the tools (LB - Aztec object librarian) supplied by Aztec to manipulate
>  the software.

'to manipulate the software' - huh?  At least there is a librarian!  I know
it has bugs, but I have been using it successfully for months now.  Most of
the bugs, I'm informed are due to a silly error in strncpy(), but, that will
be fixed in the next release (this is the FIRST release, after all!).

>
>  As it happens, the object librarian is THE PITS!!!
>  You'll never see a worse tool for a floppy disk system
>  (my ears still hurt from listening to the drives grind)
>

Again, the grinding is a limitation in floppy disks, not the librarian - for
it to do anything useful, a librarian will have to do a lot of file
manipulation.

>Unfortunately, the librarian is a very necessary tool for the type
>of development I do, because I split my source in the ONE-ROUTINE-PER-FILE
>fashion, and depend on the library manager to aid in the link.

You're the first person I've ever met who does this, ESPECIALLY on a floppy
system!  On a VAX, you might not pay much of a penalty.

>I feel that I've been penalized for buying
>the cheap (ahem, $300) developer version, because it does not have 
>the object ordering tool.  (Again, I am forced to use their tools because
>of the non-standard object format)

I agree with another person's reply - basically, if you're doing any serious
kind of development, you NEED the commercial version.  Also, the next release
will be able to link mixtures of their object, and what you call 'standard'
object files.

>  Aztec, I'm sorry.  But, I feel you owe me more for my $300,
>  and that I shouldn't be penalized for not buying the commercial version.

Again - you pay less, you get less - this is not a 'penalty', it's like buying
a car - if you don't get the sporty car, don't consider you've been penalized
because you can't get to 60 mph in under 10 seconds!

	Paul Higginbottom, extremely satisfied Aztec user.


Disclaimer: I do not work for Commodore, and am not associated with Manx
either.  My opinions are at least my own.