Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!usc!sdd.hp.com!ucsd!ucrmath!rhyde
From: rhyde@ucrmath.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: Chill, Randy
Message-ID: <10915@ucrmath.ucr.edu>
Date: 6 Jan 91 17:03:37 GMT
References: <1991Jan5.014646.26135@ux1.cso.uiuc.edu> <10904@ucrmath.ucr.edu> <1991Jan5.095921.17870@nntp-server.caltech.edu>
Organization: University of California, Riverside
Lines: 32

>>>>>
Randy, you've been railing on the '816 for architectural features that don't
tolerate sloppy coding of large projects ever since you started to post here.

What's so damn hard about modularizing your assembly code into subroutines
whose register sizes are easy to manage? Avoiding mode problems on entry and
exit is as easy as PHP/PLP.
<<<<<

Alas, my perspective is based on my experiences as a software manager and
as an instructor.  There are lots of people claiming you can write
well-written structured code in "C" and assembly.  In reality, even those
who yell the most rarely live up to their own claims.  I prefer a clean
architecture like the 32000 which eliminates many of the kludges found
in other processors.  It lets me write assembly code without those
problems.

Furthermore, if you write well-structured, modular, easy to read code on
the '816 (yes, it can be done) you lose on the performance end.  People
who write assembly language code like this are the ones who generally 
claim that coding in "C" isn't so bad.  The way to get the '816 to
scream (so it outperforms programs on the Mac and PC) is to pull ou;t all
the stops and count cycles.  I've written a lot of code this way and I
wouldn't wish the task of reading it on to anyone around here.  It was
bad enough on the 65c02, but writing tricky code on the '816 is probably
2-4 times more complex due to those M & X bits.  When you write optimal
code, you rarely use subroutines, much less those PHP/PLP instructions.
If you want to see the kind of code I'm talking about, study the Apple II
monitor sometime.  Woz's code still stands out today as a shining example
of some incredible coding (not easy to read or understand, but extremely
compact and well thought out).  
*** Randy Hyde