Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!swrinde!ucsd!ucrmath!rhyde
From: rhyde@ucrmath.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: Computer capabilities
Message-ID: <10827@ucrmath.ucr.edu>
Date: 1 Jan 91 20:36:24 GMT
References: <325@generic.UUCP>
Organization: University of California, Riverside
Lines: 51

>>> Assembly language on the 65816 edges out the 8088 at almost half the clock
rate...

Of course, most 8088 system run at about twice the clock speed (or better)
of most 65c816 systems, so this advantage isn't as great as you would think.
(This btw, has to do with hardware, things like memory access times).

>> Logically both generate the same code for the same problem solution...

A lot of compiler vendors would like you to think this.  Alas, compilers
are, in general, brain dead.  They rarely make smart decisions concerning
code generation.  Like algorithm implementation in a HLL, there are thousands
of ways to accomplish something in assembly (machine) language.  The compiler
always picks the same way to do something.  An experienced assembly language
programmer can choose an efficient technique based on the current context.
I really laugh when someone tells me that there is not reason to use
assembly language because optimizing "C" compilers are so good.  They tell
me that their "C" compiler produces code which is only 25% slower and 50%
larger than a corresponding assembly language program.  I then turn around
and reimplement the program so it requires half the space and runs 5-10x
faster than the comparable "C" program.  While it is theoretically possible
to write a compiler that is as smart as a typical (not expert) assembly
language programmer, we're still a long ways off from this.

As for the architecture of the 65xxx vs. 8088 being good for compilers-
the 8088 has a BP register which makes it easy to access parameters and
local variables on the stack.  The 65c816 doesn't have (and desparately needs)
this.  A stack pointer which is 24 bits long would be useful too.  Easier
access to data on the stack (which is where HLLs pass parameters, store
temporaries, and allocate local variables)  would be useful.  Good, indexed
and indirect addressing modes on the stack would be useful as well.
SBF and DIVF (subtract from, divide from) instructions would also be useful.
A top of stack addressing mode, like the 68000 and 32000 have, would also be
incredibly useful to compiler writers.
Signed comparisons (branches) would be handy, for reasons you can imagine.
Long branches would be real useful (since the compiler always has to assume
that forward branches are out of range).
The ability to pop parameters off the stack when returning from a subroutine
would be useful.
Addressing modes to support various common HLL data structures (records,
arrays of pointers, handles, lists, sets, etc.) would be quite useful.  Most
machines only handle arrays and pointers reasonably well.  The 8088's four
component addressing scheme is a good example (although it doesn't go far
enough).  

RISC proponents argue that you can handle all of this in software.  You most
certainly can.  You can write a really good "C" compiler for a 6502.  But it's
so difficult to do that no one has.  Furthermore, the performance would be
terrible (the 6502 is *not* a RISC chip, with the advantages of a RISC).
.
*** Randy Hyde