Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!claris!jazzman
From: jazzman@claris.com (Sydney R. Polk)
Newsgroups: comp.sys.apple
Subject: Re: Computer languages on the various Apple Corp computers
Message-ID: <10206@claris.com>
Date: 23 May 89 22:31:58 GMT
References: <2821@puff.cs.wisc.edu>
Organization: Claris Corporation, Santa Clara CA
Lines: 68

From article <2821@puff.cs.wisc.edu>, by blochowi@cat28.CS.WISC.EDU (Jason Blochowiak):
> In article <8905211959.AA07195@crash.cts.com> pnet01!pro-nsfmat!pro-europa!nelson@nosc.mil writes:
>> [...]
>>The reason for this is simple - high-level languages are terribly impractical
>>on the 6502 based //. They are fairly tough to make run on the 65816.
> 	I agree with the bit about doing high-level languages on the 6502, but
> not about the 65816 - it has support for stackframes, large data sets, and
> pretty much everything else necessary for high-level languages. Sure, the
> 65816 doesn't have ops that are as powerful as, say, the 68000, but, gee, isn't
> that what RISC is all about?
The main problems I see with the 65816 are as follows:

-  You say it has support for stack frames.  However, the stack is small
(64K) and can only be put in special memory (bank 0) which is taken up
by tool memory and firmware.  Furthermore, the only way I know of to 
have stack frames is the way we do it, with the D register pointing at
the start of your local space.  This means losing a cycle per access,
as D will not usually be page-aligned, and it means a 256 byte limit on
your local space.

- It is very hard to write a compiler with 1 and two thirds registers (X
and Y are both one-third).  It is incredibly difficult to write an
efficient compiler with only one general purpose register.

- The chip is missing some addressing modes which make doing somethings
very difficult.  For instance, the only addressing mode on jsl is 
long.  This means you have to write self-modifying code to do a long
jump table.

- The chip only works with 16 bit quantities at a time most of the time.
You have to put the processor status into 8-bit mode to do character
and string processing.

- If you plan on having more than 64K of data space, it is very difficult
to decide whether an address should be stored short (16 bits, in same
bank) or long (24 bits).  You can't have all short, because you can
only address 64K with short addressing.  But doing everything long addressing
really slows the compiled code down a bunch.

- A RISC chip usually has an incredible number of registers, say 256, and
as such, is perfect for compilers.  This chip has one, so is not
really a RISC chip.

- A chip that has no hardware multiply is not going to do arithmetic very
fast, much less floating point.

- Enforcing an absolute limit of 64K per code segment is not very friendly,
and will break an awful lot of programs on other platforms.

We have had some experience with the APW and MPW C compilers on this machine,
and after all of the problems we've had, we still prefer assembly.  This
is in addition to the fact that the compiled code runs two to three times
as slow as the assembly.  I'm sorry, but with this machine's clock speed,
we cannot afford to waste the time.  The code also compiles about 50% larger.
We also don't have the disk space.

AppleWorks GS is big as it is.  We have optimized a hell of a lot of
assembly code.  I honestly believe that it is not possible to do a project
as large as AWGS on a compiler on the 65816, it is just to difficult to
write a reasonable compiler.

And yes, I have written a small compiler before.

-- 
Syd Polk           | Wherever you go, there you are.
jazzman@claris.com | Let the music be your light.
GO 'STROS!         | These opinions are mine.  Any resemblence to other
GO RICE!           |  opinions, real or fictitious, is purely coincidence.