[net.micro.apple] Re. Advice needed on Aztec C: DOS 3.3 code quality.

dudek@utcsrgv.UUCP (Gregory Dudek) (10/19/84)

   Well, I have some experience with Aztec c65 under DOS 3.3 &
certainly agree that the compiling is none too fast.  Having taken
a fairly close look at the code generated, my feeling is that,
on the whole, it's pretty good.  I feel that it has two serious
flaws, however.  For one, all arithmetic operations are performed
in 16 bits, even if the operands are characters.  This means the
the only way to get *really* fast code that does a lot of arithmetic
is to delete the unneeded extra operations BY HAND from the
assembly code.
   The other deficiency, although this may be intrinsic to the
6502 and not the fault of Manx, is that subroutine linkage taken
a whole pile of code, roughly 6-8 instructions per operand
passed, plus one subroutine call at either end of the call (caller
and callee) [I'm no certain what the called "system" routine does].
Again, it is, unfortunately, impossible to get the compiler to
gen. tighter code by using chars since it insists on putting 2 bytes
on the stack per operand, no matter what.
   By the way, using their I/O package also slows things down a LOT.
I was helping with some code that really needed fast character output
and found that writing special-purpose output routine for the screen
made an incredible difference.
   Despite these objections, I like the system & plan on buying one
for my own use at home -- a DOS 3.3 version too.
     Greg Dudek
-- 
   Gregory Dudek
   {cornell,decvax,ihnp4,linus,utzoo,uw-beaver}!utcsrgv!dudek

henry@utzoo.UUCP (Henry Spencer) (10/19/84)

> ... all arithmetic operations are performed
> in 16 bits, even if the operands are characters....
> ...
> ...[in function calls, the compiler] insists on putting 2 bytes
> on the stack per operand, no matter what.	...

Technically, it is impossible to change either of these characteristics
without violating the semantics of K&R C.  So the authors have a (not
trivial) excuse for doing it this way.  It would probably have been nice
if they'd provided an option to avoid this; some C compilers for micros
supply such an option.

The new draft ANSI C standard contains some careful wording to the effect
that compilers are entitled to do such optimization if the results are
certain to be identical to the unoptimized version.  This was arguably
true of the K&R definition too, but now it's explicit.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry