stowekeller@pro-carolina.cts.com (Stowe Keller) (11/20/88)
The question of C compilers for Apple ]['s periodically
surfaces, and I wanted to post my opinions - quite negative - of the
Manx Aztec C compiler, based on my evaluation of the product a year
ago. I uploaded this letter to Compuserve, and have received a couple
of thank-you's for warning people about the product. Others, though,
still manage to find it usable, although personally I have been rather
disappointed with the performance of programs that others have written
using this compiler. (I guess if you keep your expectations of a
product low enough, you'll never be disappointed 8-).
Stowe Keller
UUCP: [ cbosgd hplabs!hp-sdd sdcsvax
nosc]!crash!pnet01!pro-sol!stowekeller
UUCP: [ cbosgd hplabs!hp-sdd sdcsvax nosc]
!crash!pnet01!pro-carolina!stowekeller
ARPA: crash!pnet01!pro-sol!stowekeller@nosc.mil
ARPA: crash!pnet01!pro-carolina!stowekeller@nosc.mil
CIS: [71540,725] BIX: stowekeller GEnie: SKELLER
--------------------------------
To: Manx Software Systems
Box 55
Shrewsbury, N.J
07701
10/29/87
Dear sirs:
Please find enclosed one Aztec C65-c commercial C compiler for
Apple ][ ProDOS/DOS 3.3, RMA #1163. Upon evaluating the product, I am
sorry to say that I do not consider it usable as a serious software
development tool. I might consider keeping it for educational
purposes if it were only $50 - $75, but for $300 I expect alot more.
I have listed several of my complaints below.
As someone who has been programming Apples for eight years, and
has extensively programmed in 6502 assembly language, I have long been
looking for a powerful language for generating applications for the
//e and ][+. Having to develop as much as 11K of 6502 code is simply
too time-consuming to write and debug, and from what little I know of
C, it would appear to offer me a good solution for speeding
development time while yielding programs of reasonably good
performance. Also, I want software tools that do not force me into
frustrating command shells and file formats, but instead give me the
option of doing things my way, and will allow me to use my existing
utilities for exchanging and manipulating files.
The Manx C package fails to do this in several respects:
-I personally detest the UNIX command shell, although I respect
the fact that many people love it. I would prefer that the shell be
provided for those that want it, but that there be an easy way for the
user to invoke the Manx programs from any ProDOS command shell (in my
case, Living Legends Software Extended Command Processor). One
possibility would be to provide system file versions of the compiler,
assembler, etc, and when invoked, they would look for a text file
called COMMAND.LINE (or whatever), and if found, the program would
read the command line parameters from there. If not found, the
program would prompt the user for any additional information. This
way, if I desired, I could write utilities for the ProDOS Extended
Command Processor to translate its command line into the appropriate
COMMAND.LINE file mentioned above, and then invoke the desired Manx
program. This also would let me use command names with which I am
familiar, and not require me to write exec files to change the UNIX
commands into ECP-like names and syntax.
-The command shell crashes too easily. Just because it cannot
find a filename in the startup (PROFILE) program does not justify
crashing into the monitor; it should give an error message (preferably
human readable). It is very frustrating when a user first tries to
set up the system, and cannot get anywhere because the crucial
sequence of setting up the system environment variables is so
bug-ridden. Also, there does not appear to be any support for the
ProDOS QUIT command, which would enable me to exit gracefully to my
regular command shell.
-I realize that UNIX likes to use Ctrl-J's as end of line markers
in text files, but I don't, and none of my other software does. Since
I refuse to use an editor patterned after VI, I tried to use my other
editors to edit some of the supplied source files, and ran into a mess
when they were unable to process Ctrl-J's in place of Ctrl-M. I have
little desire to have to run such source files through a translation
program just to edit or otherwise process them. I am glad, though,
that the compiler accepts source files which use Ctrl-M's as line
terminators.
-In the shell, the DELETE key on my //e should behave like the
back-arrow. Also, it appears that control characters typed in from
the keyboard get echoed to the screen; for example, hitting ctrl-Q
gets echoed to my 80-column screen, putting it into 40-column mode,
which is not desirable.
-Graphics support is lousy. Although I can write additional
software drivers, I really don't have the time to do so. There should
at least be support for both hires pages, and support for Lo-res and
//e double hires would be nice additions.
-There is no technical info on the pseudo-code assembler. What if
I want to write my own pseudo-code assembly routines, or need to debug
the pseudo-code output of the compiler?
-The package would greatly benefit from a quick reference card for
the commands, utilities, etc. I know many software packages that cost
far less that provide quick reference cards.
-The assembler does not support 65802 opcodes, which is a great
shame. I use a 65802 on my //e system, and there are many features of
that chip that could boost the performance of compiled programs.
Providing a 65802 version of the compiler, assembler and runtime
routines would make the package far more attractive too me. Also, I
find it annoying that the assembler will not accept string literals as
data, thus making it extremely difficult to locate string constants in
the assembly listing (since each character gets compiled to its
numeric equivalent).
-There is no optimizer! This is a major drawback of the package,
especially in view of the slow-running code I have seen it generate.
I timed some simple floating point operations, and found Aztec C to be
significantly slower than Applesoft BASIC. This is pathetic!
Compiled code running SLOWER than a notoriously slow interpreted
language?
-Screen output is way too slow. Even when running with an
accelerator card, which gives my //e a three-fold speed increase, the
output of characters is visibly slow. I am aware that there is a
public domain source file to replace the screen drivers with faster
code, but I get tired of having to redesign the software packages I
buy to make them usable. Over the years, I have probably bought a
thousand dollars worth of software packages that were not quite what I
wanted, but I kept them in hopes of reworking them into usable,
bug-free tools. After hundreds of hours of time and frustration, I
usually gave up on them, and they now collect dust on the shelf. I do
not want to add another software package to that collection.
-As pointed out in the manual and on disk, there are known
software bugs, yet no compiler updates have been made for the past 15
months. This, in addition to the problems I have encountered, and the
stories I have heard the past few weeks from other Apple programmers
who tried Aztec C, demonstrates to me a lack of commitment by Manx to
support and maintain this software package. If the software were
still in beta-test, I would be willing to overlook some of these
problems, but I consider it unacceptable in what is supposedly a
mature "commercial quality C compiler". I cannot imagine how anyone
can write a worthwhile program with this compiler.
-For an upcoming MS-DOS project I am about to undertake, I had
planned on using the Manx 8086 C compiler, but in view of my
overwhelming negative experience with the Apple version, I have
decided against even considering it.
On the positive side, though, I would like to complement you
people on the manual. Overall, it is much better than many manuals I
have encountered for personal computers, in terms of providing and
presenting information. One excellent touch is the "Style" section; I
wish more manuals would offer advice like that for their programming
tools.
Thank you very much.
Stowe Keller
---------