jdt@bucsb.bu.edu.UUCP (Dave Tenny) (05/13/86)
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)
So...
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.
LN (the linker) is fast *if* the 85k library is in ram.
The code produced is very small.
The mediocre points:
The C compiler has it's share of bugs, nothing major,
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)
There is no tentative ansi draft support.. just vanilla C
with a vanilla runtime library.
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.
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.
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)
The object librarian has MANY bugs.
1.) Hangs when you forget the '.lib' extension of the library name.
2.) Complains about (and won't accept) code produced by the Aztec
compiler in certain instances. (The compiler and assembler
didn't indicate problems, and you can link the object loose,
only the librarian complains)
3.) I don't know if this is a librarian bug, or an AmigaDos COPY bug:
when you copy one of the LB libs to RAM:, then do a LB libname -T
(to list contents), LB complains about invalid headers. This is
even true about the C.LIB they provide.
4.) Other obscure behaviour I won't mention.
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.
LN (the linker) only makes one pass through libraries, and you must
have all the code in the library organized in the correct order of
external references if you want to link with one scan on the library.
Now, it's true that Aztec provides a tool for this, IF you buy the
commercial, $500 compiler. 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)
Another inconsistency,
They provide the ADUMP command for dumping AMIGA format object,
but not the utility for dumping their object (symbols, etc).
ADUMP is useless if you are using the Aztec products. And the other
utility is sold only with the commercial compiler. Does this make sense
to you?
Summary,
You may gather that I am less that thrilled with my new Aztec compiler.
Well, you're right. I believe it has a lot of potential, but
I haven't managed to port any of my C tools yet, because of the above
problems. In desparation I called my support number, (many more
if my nickels to the bit bucket) and didn't come out of the conversation
with any more than I went in with. (They were friendly, but
didn't have any ANSWERS).
If anybody has comments, suggestions, SOLUTIONS, corrections,
please reply. I would really like to get my TERMINAL program
to take advantage of the new compiler, and be half the size.
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.
No affiliations with anybody mentioned above,
Jeffrey D. Tennybreuel@h-sc1.UUCP (thomas breuel) (05/14/86)
|So... | |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. | LN (the linker) is fast *if* the 85k library is in ram. | The code produced is very small. | |The mediocre points: | The C compiler has it's share of bugs, nothing major, | 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) Manx is aware of the bugs. To compile MicroEMACS 3.6, you have to do two workarounds: you must use the +L option (MicroEMACS 3.6 has a bunch of type errors), and therefore you have to remove all expressions from '#if' statements, and in epath.h you have to move the '#if ... #endif' from inside the structure to the outside. | There is no tentative ansi draft support.. just vanilla C | with a vanilla runtime library. According to Manx technical support, this is forthcoming (in fact, they are on the ANSI draft committee, they say). The next release of the compiler will support returning of structures and might support argument type declarations in forward function declarations (or whatever ANSI calls it). |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. | |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 are swimming upstream, so to speak. I don't think that this development technique is too efficient (in terms of link time) with any system. |LN (the linker) only makes one pass through libraries, and you must |have all the code in the library organized in the correct order of |external references if you want to link with one scan on the library. |Now, it's true that Aztec provides a tool for this, IF you buy the |commercial, $500 compiler. 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) The price difference between commercial and developers version is $100, so you either paid $400 already, or you can get the commercial version for $400. I would strongly recommend you to get the commercial version. It has lots of useful goodies that make development much easier. $400 is a lot for a 'C' compiler, but, then, you get not only one of the best 'C' compilers in existence, but also: vi, make, as, grep, diff, a debugger, a librarian, a disassembler, and lots more. Lattice and Manx are comparable in price (but not in performance), by the way, when you add up the prices of all the Lattice programs and utilities ('C' compiler, assembler, decent text editor, and 'make' together also cost about $400). |Another inconsistency, |They provide the ADUMP command for dumping AMIGA format object, |but not the utility for dumping their object (symbols, etc). |ADUMP is useless if you are using the Aztec products. And the other |utility is sold only with the commercial compiler. Does this make sense |to you? Well, again, get the commercial version... | If anybody has comments, suggestions, SOLUTIONS, corrections, | please reply. I would really like to get my TERMINAL program | to take advantage of the new compiler, and be half the size. | | 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. I think spending the extra $100 for the commercial version is well worth it if you want to do serious development. The price of the system is admittedly sort of high, but you get probably one of the best 68k compilers in existence, and lots more. I only have the Aztec/Manx 'C' compiler (no Lattice), and I find that I can live very well with it. Most public domain stuff compiles very easily and doesn't require any changes. The compiler has a few bugs, but they are not very serious and will be fixed in the next release according to Manx. Thomas. PS: I have no connection with Manx other than that I am a satisfied customer. PPS: you can upgrade from any version to a higher version by paying the difference plus $10, if I recall correctly.
higgin@cbmvax.cbm.UUCP (Paul Higginbottom) (05/14/86)
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.
daveh@cbmvax.cbm.UUCP (Dave Haynie) (05/14/86)
In article <1100@h-sc1.UUCP> breuel@h-sc1.UUCP (thomas breuel) writes: >... I would strongly recommend you to get the commercial version. It has lots >of useful goodies that make development much easier. $400 is a lot for a 'C' >compiler, but, then, you get not only one of the best 'C' compilers in >existence, but also: vi, make, as, grep, diff, a debugger, a librarian, a >disassembler, and lots more. Lattice and Manx are comparable in price (but >not in performance), by the way, when you add up the prices of all the >Lattice programs and utilities ('C' compiler, assembler, decent text editor, >and 'make' together also cost about $400). Not to slight the Aztec compiler itself, but that DEAL that you mention doesn't sound like much of a deal. I use a version of MicroEmacs on my Amiga (and VAX) that blows away most mainframe versions of "vi", so I'd have little need for that; and Emacs is free. Same goes for grep and diff; there are many PD versions of each which outperform the originals, and will as likely outperform the Aztec versions. Even make is available in PD (though I think we both agree that the Lattice version of this, and of their text editor, are very overpriced). And the Aztec assembler is not a full powered assembler. That and the nonstandard object code produced have kept me away from Aztec. Having done multi-language programs on mainframes, I consider it essential to be able to link together anything you'd like no matter what its written in. Aztec might be the thing for standalnoe programming that requires a minumum of Assembly code, though I can't think of any reason I'd want to buy their editor. -- Dave Haynie {caip,inhp4,allegra,seismo}!cbmvax!daveh "There, beyond the bounds of your weak imagination Lie the noble towers of my city, bright and gold" -Genesis
breuel@h-sc1.UUCP (thomas breuel) (05/15/86)
||... I would strongly recommend you to get the commercial version. It has lots ||of useful goodies that make development much easier. $400 is a lot for a 'C' ||compiler, but, then, you get not only one of the best 'C' compilers in ||existence, but also: vi, make, as, grep, diff, a debugger, a librarian, a ||disassembler, and lots more. Lattice and Manx are comparable in price (but ||not in performance), by the way, when you add up the prices of all the ||Lattice programs and utilities ('C' compiler, assembler, decent text editor, ||and 'make' together also cost about $400). | |Not to slight the Aztec compiler itself, but that DEAL that you mention |doesn't sound like much of a deal. I use a version of MicroEmacs on my |Amiga (and VAX) that blows away most mainframe versions of "vi", so I'd |have little need for that; and Emacs is free. Same goes for grep and diff; I find this difficult to believe. Both 'vi' and 'z' have regular expression match, and substitution (in the next release), macros, named kill buffers, auto-indent. UN*X 'vi' in addition has a line oriented mode, can edit (almost) arbitrarily large files, has a LISP mode, ... If you claim that your version of MicroEMACS 'blows away most mainframe versions of vi' (I didn't know that 'vi' runs on many mainframes, I thought it runs mostly on PDP's and Vaxen), then either you haven't used 'vi' too much, or your version of MicroEMACS is sufficiently better than versions 3.6 or 30 posted recently. If the latter is the case, please let everyone know and post your version. |there are many PD versions of each which outperform the originals, and will |as likely outperform the Aztec versions. Even make is available in PD |(though I think we both agree that the Lattice version of this, and of their |text editor, are very overpriced). Again, since I have the Manx system and also have many of the PD programs you mention, I feel that I can at least have an opinion about this... The Manx 'make' utility is the closest to UN*X make (and the most powerful microcomputer 'make') I have seen. Sure there are PD versions of 'grep' around, but not of ctags, which is something the 'z' editor supports and which is what you often want to use instead of 'grep' anyhow (because it is so much faster). |And the Aztec assembler is not a full |powered assembler. That and the nonstandard object code produced have What *is* a full powered assembler then? Manx 'as' has macros and conditionals. That is about as much as you get in most micro computer assemblers. |kept me away from Aztec. Having done multi-language programs on mainframes, |I consider it essential to be able to link together anything you'd like |no matter what its written in. Aztec might be the thing for standalnoe |programming that requires a minumum of Assembly code, though I can't think |of any reason I'd want to buy their editor. Again, what else do you need but a 'C' compiler and a good assembler? That's precisely what Manx gives you, for the same price for which you get the Lattice system. However, the Manx compiler is faster and produces better code. Now, I'm not saying that I don't consider $400 for a 'C' development system to be a lot of money. I am just saying that the prices for the Lattice system and the Manx system are comparable. And, btw, you don't have to pay the extra $100 for the text editor or the 'make' utility if you don't want them. I would just strongly recommend that you do, since I find that they 'blow away any microcomputer version'. (Except for pcvi, which is identical to UN*X 'vi' and therefore, naturally (:-) better than 'z'). Thomas. PS: again, my only connection to Manx is that I'm a satisfied customer.
mykes@3comvax.UUCP (Mike Schwartz) (05/15/86)
Cutting down Aztec C is a joke. How many programs do you see in a store that even compare with it? Let's see, there's only Lattice (C compilers). No comparison. I use Aztec C practically as much as I use my Amiga, so I figure a couple hundred ($400 or whatever) is worth it. I am thrilled with version 3.20 of the compiler, and can't say enough about it. Sure it has a few bugs, but the Amiga has some too. But look at what they both are: Amiga=best computer available for < $2000 by far; Aztec 'C' = best compiler for Amiga by far (at any price, native to the Amiga). If you don't want to pay for the best, then go ahead and settle for less. Face the facts, we are in on the ground floor of a new machine, just as people were at one time for the IBM PC. Sure there are greps and all the other unix trash (my own terminology) in the public domain, but as a professional developer, I would rather not spend my time porting these non-trivial, file system oriented programs. Paying an extra $100 saves me time worth much more than $100. Why cry about it. The $400 package also includes the SOURCE to the ENTIRE library, which is somewhat disappointing to see 1000 source files, of which 750 are all 3 line assembler routines. However, the flexability of being able to build custom run-time libraries is well worth it. As an aside, it really is a shame to compile thousands of little files to make up a library, especially on floppy disk based computers. You spend more time loading the compiler and assembler from disk than you do compiling. It is much more time efficient to balance the number and size of different source files to take advantage of the fact that once the compiler has been loaded, it may as well do a few more milliseconds of work. You don't want to recompile everything all the time, either, so there must be some middle ground that is reasonable (there always is).
dougl@ism780c.UUCP (05/15/86)
In article <1100@h-sc1.UUCP> breuel@h-sc1.UUCP (thomas breuel) writes: ... Lots and Lots of stuff ... >According to Manx technical support, this is forthcoming (in fact, >they are on the ANSI draft committee, they say). ... More stuff ... I just checked my X3J11/86-017 (Feb 14,1986 C ansi draft) Yes both People from Manx and from Lattice are on the committee. Thats: Thomas Fenwick of Manx Software Systems Inc. and Steve Hersee of Lattice Inc. for those interested parties. Doug Leavitt { sdcrdcf, ima!ism780 } !ism780c!dougl
dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (05/16/86)
Bad for me too.... I do wish you all would back your like-dislike wars with examples...... -Matt
mwm@ucbopal.berkeley.edu (Mike (I'll be mellow when I'm dead) Meyer) (05/17/86)
In article <242@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom) writes: >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! It only took me a couple of hours to port v.30 to the Amiga, using the Lattice C compiler. The PD makes got the job done (though I did have to add lotsa rules). Changing that Emacs (new bindings, much better mouse support) wasn't hard either. I almost bought the Manx compiler at the WCCF prices. However, given 1) the cost; 2) the lack of ANSI features; 3) Ecosoft and others moving into the market, I decided that I'd wait until there was a better selection of compilers to choose from. Lattice + PD make/cc/MicroGNUmacs is more than adequate. Final comment, on the Emacs/vi wars (sorry, Matt): MicroEmacs missing regular expresions is relatively minor. GNU has them, and I never use them. Incremental search, once you get used to it, is better. Tags would be nice, though. <mike
hr@uicsl.UUCP (05/17/86)
RE: "...|Having done multi-language programs on mainframes, |I consider it essential to be able to link together anything you'd like |no matter what its written in." "Again, what else do you need but a 'C' compiler and a good assembler?" In my case, a good FORTRAN compiler. My wife needs LISP and Pascal. If we could get our hands on one, we'd want SNOBOL too. While we can stand the interpreters not communicating with anything else, I'll give preference to language implementations that don't lock me into one language or company. ---- harold ravlin {ihnp4,pur-ee}!uiucdcs!uicsl!hr
drew@orsvax1.UUCP (Drew Lucy) (05/19/86)
> Cutting down Aztec C is a joke. How many programs do you see in a store that > even compare with it? Let's see, there's only Lattice (C compilers). No > comparison. I use Aztec C practically as much as I use my Amiga, so I figure > a couple hundred ($400 or whatever) is worth it. > > I am thrilled with version 3.20 of the compiler, and can't say enough about > it. Sure it has a few bugs, but the Amiga has some too. But look at what they > both are: Amiga=best computer available for < $2000 by far; Aztec 'C' = best > compiler for Amiga by far (at any price, native to the Amiga). > > If you don't want to pay for the best, then go ahead and settle for less. Face > the facts, we are in on the ground floor of a new machine, just as people were > at one time for the IBM PC. > { > Sure there are greps and all the other unix trash (my own terminology) in > the public domain, but as a professional developer, I would rather not spend > my time porting these non-trivial, file system oriented programs. Paying > an extra $100 saves me time worth much more than $100. Why cry about it. > > The $400 package also includes the SOURCE to the ENTIRE library, which is > somewhat disappointing to see 1000 source files, of which 750 are all 3 > line assembler routines. However, the flexability of being able to build > custom run-time libraries is well worth it. > > As an aside, it really is a shame to compile thousands of little files to > make up a library, especially on floppy disk based computers. You spend > more time loading the compiler and assembler from disk than you do > compiling. It is much more time efficient to balance the number and size > of different source files to take advantage of the fact that once the > compiler has been loaded, it may as well do a few more milliseconds of work. > You don't want to recompile everything all the time, either, so there must > be some middle ground that is reasonable (there always is). *** REPLACE THIS LINE WITH YOUR MESSAGE ***
drew@orsvax1.UUCP (Drew Lucy) (05/19/86)
Sorry about the previous posting. I'm a devoted Emacs user struggling with vi. I too am a satisfied Aztec C user. It does have some weak points though. The one that is bugging me this week is that the grep utility provided will only search files in the current directory. Give Manx's grep a pathname for an argument and it responds as if it didn't find any matches in the file. All the nifty wildcarding and options are nice but, I'll stick to PD greps until Manx can search any file from anywhere in the file hierarchy. Drew
daveh@cbmvax.UUCP (05/20/86)
In article <1101@h-sc1.UUCP> breuel@h-sc1.UUCP (thomas breuel) writes: >I find this difficult to believe. Both 'vi' and 'z' have regular expression >match, and substitution (in the next release), macros, named kill buffers, >auto-indent. UN*X 'vi' in addition has a line oriented mode, can edit >(almost) arbitrarily large files, has a LISP mode, ... Well, the ME versions I've been using, 3.6 and Andy Finkel's version, have Macros, any number of named buffers, multiple screen windows within the limits of the display device, and auto-indent. No RE matching, true. And 3.6 has text and C modes; LISP mode is not very complicated if you want to add it. And if your talking about UN*X versions, GNU (also free) actually executes LISP itself. Also, isn't the "line-oriented mode" of the UN*X systems actually a thing called EX, the extended editor that calls VI as its screen-oriented submode? > >If you claim that your version of MicroEMACS 'blows away most mainframe >versions of vi' (I didn't know that 'vi' runs on many mainframes, I thought >it runs mostly on PDP's and Vaxen) > Well, UN*X runs on the Cray-2. Is that close enough to a mainframe? I've used VI for two years while working at Bell Labs. Its so cumbersome as compared to EMACS, I rarely used the advanced features in VI because of this. True, some do use them (large system VIs I speak of), but I've found 3.6 to give me more speed/productivity then any UN*X VI I've ever used. >Again, what else do you need but a 'C' compiler and a good assembler? >That's precisely what Manx gives you, for the same price for which >you get the Lattice system. However, the Manx compiler is faster >and produces better code. Well, I'd at least like the option to be able to link in code written in any other language, maybe Modula2, BCPL, etc. No problem on a VAX, so it shouldn't be on an Amiga, right? The Manx Compiler runs a bit fasetr and produces faster code. The size of the code is Lattice's stupidity in organizing their libraries; the Lattice code itself is small. -- Dave Haynie {caip,inhp4,allegra,seismo}!cbmvax!daveh "There, beyond the bounds of your weak imagination Lie the noble towers of my city, bright and gold" -Genesis