kurt@pyuxhh.UUCP (K A Gluck) (04/30/84)
I Posted the following request to the net: >------------------------------------------------------------------------ > SUBJECT: apple c net post > I am looking for information on C compilers for the apple ][e > I have heard of ?astek? c but have no information or > idea how good/bad it is. > > Please mail to me ihnp4!pyuxhh!kurt any info you have on c compilers > for the apple ][e and I will post the results to the net. >------------------------------------------------------------------------ Here are the replys. >------------------------------------------------------------------------ > Subject: Re: wanted info on apple c compilers (Aztec C) > > Byte devoted an issue to C last year, and reviewed and compared > many C compilers for many machines. Check it out. >------------------------------------------------------------------------ >------------------------------------------------------------------------ > Subject: Re: wanted info on apple c compilers > > So far as I know, Aztec (like the indians) C is the only reasonable > compiler available for the Apple. Get a copy of Byte for > more info (or an address at least). >------------------------------------------------------------------------ >------------------------------------------------------------------------ > Subject: Re: wanted info on apple c compilers > > The Manx Aztec C is a very ambitious C for the entire Apple > 6502 line. It includes subsets of sh, vi, diff, an archiver, > and four(!) possible run-time environments which can be mixed > to some extent, to wit: stand-alone native code, stand-alone > pseudo-machine code, native code to run under the shell, and > pseudo-machine code to run under the shell. Source to the > run-time libraries is included. It comes on 6 floppy surfaces. > > There is a catch of course. There has been a fair amount of > traffic in net.micro about the total lack of enthusiasm Manx > has for fixing numerous bugs. Their typical reply is, "I'm > sure you can patch that yourself if you just work through the > library code." No thanks! > > In short, when it works, it is the best environment I have seen > for Apple program development. When it doesn't work, tough. > > If you decide to go for it, and I would recommend that you do, > buy it from the Programmer Shop (see any InfoWorld). They are > good folks. > > Good luck, >------------------------------------------------------------------------ >------------------------------------------------------------------------ > Subject: Re: wanted info on apple c compilers > > Aztec C is great! It is full Unix (K & R) compatible. The CP/M version is > the one I prefer. >------------------------------------------------------------------------ >------------------------------------------------------------------------ > May I suggest the Aztec compiler for Apple ][e because it is completely > (99.995%) with Unix 7 systems. I write the majority of software I use > for Unix on Aztec C and then transmit the files up to the system. Most > of the source is included in the package, and cross compilers are > available so I can write something under Aztec CII (Z80 CPM) and run it > (after recompiling it ** without change in the source code ** ) on the > for Unix on Aztec C and then transmit the files up to the system. I > Apple, Apple + Prodos, CPM, PC DOS, and PDP11 systems. It does have one > major disadvantage. The compilation/link speed tends to be slow > (ramdisks would be of great help) and it does have a $250 price tag. >------------------------------------------------------------------------ >------------------------------------------------------------------------ > Subject: Re: wanted info on apple c compilers > I got AZTEC (from Manx) and *I LOVE IT!!* It's *very* compatible with the > K&R standard. It ain't the fastest compiler in the world, but, boy, does > it beat the *&$#$!! out of BASIC... >------------------------------------------------------------------------ >------------------------------------------------------------------------ > Subject: wanted info on apple c compilers > > Aztec C is also C-Manx, advertised regularly in BYTE. > > Excellent compatibility, Bit fields and enum types are NOT > supported, otherwise std. K&R C. > > Stdio had a few minor bugs, I think they've been fixed.. >------------------------------------------------------------------------ >------------------------------------------------------------------------ > I have Aztec C on my ][e. I've found some bugs in it, but nothing major. In > general I think it is a good system, though not particularly fast. If you really > want something to be efficient you'll have to use assembly language. They provide > one but it has no macros to speak of and isn't very well documented. Overall however, > I would say that I like the product. In particular it is nice because they provide > a UNIX-like shell and an editor that bears remarkable similarities to VI. > > (Re: communications devices. Ascii Express is quite good. Definitely worth it.) >------------------------------------------------------------------------ >------------------------------------------------------------------------ > Subject: Re: wanted info on apple c compilers > > The Aztec C compilers: the C65 (their 6502 version) appears to be quite > usable, and though they've managed to somehow partition the software so > that you're not forever swapping 5 1/4 diskettes, it's still clumsy unless > you have a multi-drive system (as I figure you do). It is provided with > a mini-Vi - style editor, and some unix-style commands, which certainly > help moving files around on the DOS3.3-compatible disks. I've also found > that it patches without a hitch to an SVA 8" controller driver, and THAT > certainly seems to make it a viable system. No bugs found yet, but then, > I really haven't been playing with it much. However, their CII, an 8080 > version, seems to be quite solid, though slow. > > One last note: the C65 is supplied with both a native code compiler and > an "interpretive" system, sorta like P-code, in order to permit the user > to conserve memory. They both seem to act alike, and for the few routines > that I've written where screen I/O is intensive (to an 80-column card), > there's little perceived degradation in speed. I'm sure I'll see some > when I have some computations to perform, though. >------------------------------------------------------------------------ To all of you who answered thanks for the help. -- Kurt Gluck SPL 1c273a Bell Communications Research Inc 6 Corporate Place Piscataway NJ, 08854 ihnp4!pyuxhh!kurt (201)-561-7100 x2023