nowlin@ihuxy.ATT.COM (Jerry Nowlin) (06/01/88)
I recently purchased Aztec C for the Atari ST from MANX Software Systems under a 30 day money back guarantee. Unfortunately, I sent it back. The following is part of a letter I sent to MANX Software Systems on May 29th. I left out the part about my good experiences with their CP/M and MS-DOS versions of Aztec C and the part about them shipping me an empty disk in the first place and the lack of speed with which they corrected that problem. This posting refers strictly to the technical problems I had with their Atari ST C compiler. I thought it might keep some people from making the same mistake I did. I waited almost two years for this product and I was very disappointed. =========================================================================== Problem 1. Yesterday I finally had time to take a look at Aztec C for the Atari ST. First I scanned the documentation again (remember I'd had it for three weeks already) and installed it on my hard disk. Then I used the example from section 3.3, page Tut.6 of the tutorial to compile a simple hello world program. Unfortunately when I tried "cc hello" all I got was a temporary file and no ".o" file. I read the compile section of the document in detail and could see no reason why I shouldn't have gotten a ".o" file but I eventually tried using the "-t" option to create a ".asm" file and then used the assembler to explicitly create a ".o" file. I was then able to use the linker to get an executable that worked, almost. Problem 2. I included a statement in my hello world that printed one line to standard error (stderr) in order to see how your buffering would effect the order of output and if redirection would be supported independently for the two standard output streams. Your manual talks about stderr in a couple of places. Section 2.1 of the library chapter mentions stderr as one of the three "preopened files" and in section 3.3 it is mentioned as the only stream to be unbuffered by default. I could not get the standard error output to show up anywhere. I had no problem with standard out when used implicitly with a simple printf() or explicitly with a fprintf(stdout,). Standard error is sadly missing. Problems 3. (the clincher) I then went on from a simple hello world program to a more complicated version of the standard UNIX where(1) command that I have working in Alcyon, Lattice, and Megamax. When I tried to compile it in Aztec I got two very disturbing undefined symbols from the linker. It couldn't find xbios() or gemdos(). I tried linking with all the libraries that came with the Aztec system but no luck. Then I checked the standard osbind.h header to see how they got around this problem and discovered that Aztec has decided that the library routine names that all the other C compilers have found acceptable weren't good enough. They had to use different ones. Since different osbind.h headers have been the source of several bugs in the past I have coded my programs with direct library calls to avoid problems between different versions of osbind.h. Now you come along and decide to make even the library routine names different. =========================================================================== Since it took me a total of about two hours to uncover this many problems I returned my copy of Aztec C and don't intend to bother with any MANX products from now on. Has anyone else purchased Aztec C for their ST yet? I'd be interested in different (opposing) opinions. Jerry Nowlin (...!ihnp4!ihuxy!nowlin)
michel@megamax.UUCP (Michel Rynderman) (06/01/88)
In article <2542@ihuxy.ATT.COM> nowlin@ihuxy.ATT.COM (Jerry Nowlin) writes: >>I recently purchased Aztec C for the Atari ST from MANX Software Systems >> >>Problem 1. >> >>world program. Unfortunately when I tried "cc hello" all I got was a >>temporary file and no ".o" file. cc probably stands for a compile and link utility. You needed to say "cc -c hello.c" to get a hello.o out of the compiler(just like UNIXtm) . I have seen their product on the Mac and that is how it acts. "cc hello.c" will compiler and link, removing the object file. >>Problem 2. >>I included a statement in my hello world that printed one line to standard >>error (stderr) in order to see how your buffering would effect the order of I don't think there is a STDERR on the ST, so I wouldn't expect it to work. It should probably just go to STDOUT. >>Problems 3. (the clincher) I don't know what's going on here. Michel@megamax -- Anyone who would like a reply to their mail sent to me needs to give a uucp path. The mailer on our system is weird. Either that or give me a tel. number and I'll give you a call. UUCP: pollux!megamax!michel PHONE: 214-987-4931
nowlin@ihuxy.ATT.COM (Jerry Nowlin) (06/02/88)
In article <1395@megamax.UUCP>, michel@megamax.UUCP (Michel Rynderman) writes: > In article <2542@ihuxy.ATT.COM> nowlin@ihuxy.ATT.COM (Jerry Nowlin) writes: > >>I recently purchased Aztec C for the Atari ST from MANX Software Systems > >> > >>Problem 1. > >> > >>world program. Unfortunately when I tried "cc hello" all I got was a > >>temporary file and no ".o" file. > > cc probably stands for a compile and link utility. You needed to say > "cc -c hello.c" to get a hello.o out of the compiler(just like UNIXtm) . > I have seen their product on the Mac and that is how it acts. > "cc hello.c" will compiler and link, removing the object file. I've been doing this long enough to have tried "-c". No soap. Even if "-c" worked, the Aztec tutorial should have had it documented correctly. I get real tired of documents with examples that have obviously never been tried by anyone. It reminds me of the joke: Q: How many tech writers does it take to screw in a light bulb? A: Just one, if there's a programmer around to explain it. PLEASE don't include examples in manuals without someone trying them! > >>Problem 2. > >>I included a statement in my hello world that printed one line to standard > >>error (stderr) in order to see how your buffering would effect the order of > > I don't think there is a STDERR on the ST, so I wouldn't expect it to work. > It should probably just go to STDOUT. The point is, if there is no stderr on the ST then they shouldn't have referred to it in their documentation at all other than to state that stderr wouldn't work. If there was stderr and it was the same as stdout their documentation should have stated that. Their document was a great example of misinformation when it came to stderr. By the way, I had to kludge stdio.h to work around a problem with stderr on either my first version of Megamax C or Lattice C or both. That's why I tried an example using stderr on Aztec C in the first place. Jerry Nowlin (...!ihnp4!ihuxy!nowlin)
rosenkra@Alliant.COM (Bill Rosenkranz) (06/04/88)
--- In article <2543@ihuxy.ATT.COM> nowlin@ihuxy.ATT.COM (Jerry Nowlin) writes: ->In article <1395@megamax.UUCP>, michel@megamax.UUCP (Michel Rynderman) writes ->> In article <2542@ihuxy.ATT.COM> nowlin@ihuxy.ATT.COM (Jerry Nowlin) writes: ->> >> ->> >>Problem 1. [discuss problems and rebutt response...] -> ->The point is, if there is no stderr on the ST then they shouldn't have ->referred to it in their documentation at all other than to state that ->stderr wouldn't work. If there was stderr and it was the same as stdout ->their documentation should have stated that. Their document was a great ->example of misinformation when it came to stderr. -> good points about bad docs. its a shame because i, too, have been waiting to see just how good this compiler would be. sounds like it needs some work yet. i guess i'll stick with good 'ol alcyon (maybe slow but it works...) if the problem is just cc, there are several cc programs (w/src) available (i wrote my own way back when) which could be converted. but it sounds like the libraries are brain damaged and that's just too much of a hassle to fix, even with say dlibs. i'm tired of hacking at system software just to get it to work the way it should (i.e. reasonably close to un*x). -bill
apratt@atari.UUCP (Allan Pratt) (06/04/88)
In article <2542@ihuxy.ATT.COM>, nowlin@ihuxy.ATT.COM (Jerry Nowlin) writes: > Problem 1. > > Unfortunately when I tried "cc hello" all I got was a > temporary file and no ".o" file. > > Problem 3. (the clincher) > > discovered that Aztec has > decided that the library routine names that all the other C compilers have > found acceptable weren't good enough. I had Problem 1, too, until I thought about what CC has to do. It has to Pexec the assembler. To do that it has to FIND the assembler. If you weren't running under Gulam, or if you didn't set your PATH correctly, it couldn't find the assembler and left you with the temp file. Took me about five minutes to establish that this was in fact the problem and correct for it (by editing gulam.g for the right directories). Problem 3 is in the same vein: any compiler product has to make the assumption that you are in its environment, including using the macros and libraries that came with it. If you don't, you can't blame the compiler for the results. Macros and libraries are tightly bound. If I try to use MWC-specific stuff under Megamax C, it won't work either. The osbind.h macro names are the same, of course: they're the Atari-published OS call names. One legitimate beef about Aztec C is that its CC isn't clever enough to start the linker, and the linker is too clever -- it includes the runtime startup code by magic. I would rather have less magic in the linker and more magic in CC. Also, CC should complain that it can't find the assembler, rather than failing silently. Finally, I would like to point out that Aztec C does more dhrystones per second than any other compiler for the ST that I tested: Compiler Mode NOREG REG MINIX CC 522 522 AZTEC C 3.6 32 bit large 772 830 AZTEC C 3.6 32 bit small 779 837 ALCYON 4.14 847 859 Megamax 2.0 874 919 MWC 2.0 996 1042 AZTEC C 3.6 16 bit large 1058 1128 Megamax 1.0 1063 1136 AZTEC C 3.6 16 bit small 1070 1142 These were all using the dhrystone source from Usenet (version 1.1, dated 01/31/87 from 01/06/86 from 12/01/84, by Reinhold P. Weicker, Rick Richardson, with results solicited by pcrat!rick). ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
egisin@watmath.waterloo.edu (Eric Gisin) (06/05/88)
In article <1068@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes: > Compiler Mode NOREG REG > > MINIX CC 522 522 > AZTEC C 3.6 32 bit large 772 830 > AZTEC C 3.6 32 bit small 779 837 > ALCYON 4.14 847 859 > Megamax 2.0 874 919 > MWC 2.0 996 1042 > AZTEC C 3.6 16 bit large 1058 1128 > Megamax 1.0 1063 1136 > AZTEC C 3.6 16 bit small 1070 1142 > > These were all using the dhrystone source from Usenet (version 1.1, > dated 01/31/87 from 01/06/86 from 12/01/84, by Reinhold P. Weicker, It looks like the MINIX ST people will get stuck with as poor a compiler as the PC people did. MJC 2.0 (Mark Johnson's shareware C compiler) does 950 Dhrystones (NOREG) with version 2 Dhrystone. Does anyone have a Dhrystone 2 figure for one of the above compilers so I can scale the MJC result to Dhrystone 1? I'd really like to see the Dhrystone results from GCC on an 8 Mhz 68000, does anyone have them?