toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/05/91)
rhyde@ucrmath.ucr.edu (randy hyde) writes: >Those M & X bits are a big source of trouble in complex programs. Sure they are, if you don't structure your code. 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. Todd Whitesel toddpw @ tybalt.caltech.edu
rhyde@ucrmath.ucr.edu (randy hyde) (01/07/91)
>>>>>
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 Hydetoddpw@nntp-server.caltech.edu (Todd P. Whitesel) (01/07/91)
rhyde@ucrmath.ucr.edu (randy hyde) writes: > The way to get the '816 to scream (so it outperforms programs on the Mac >and PC) is to pull out all the stops and count cycles. Can't argue with that statement. What I will argue with is the way people refuse to do just that because they think they have to write the whole thing in assembly or not at all. The way I write now is to use Orca/C as much as possible, and to throw in appropriate asm{} statements whenever speed is required. I've gotten damn good results so far; we'll see if it keeps working when I get to the goodly sized projects coming up. >tricky code on the '816 is probably 2-4 times more complex due to those M & X Again, I think you're trying too hard. In many cases you don't gain anything by trying to use 8 bit registers, and when you do, it is not that hard to keep the sizing straight. >If you want to see the kind of code I'm talking about, study the Apple II >monitor sometime. I did. Fervently. Its days are over as far as the 65816 and most software is concerned so get used to it. Don't waste time trying to optimize the whole damn program, figure out what needs to be optimized and spend your time on that. I know where you're coming from, Randy. I wrote a replacement quit code for Prodos 8 that does more than any other selector (except 80 column support -- I originally wrote it to run on my ][+) and in the same 3 pages. The code is actually 770 bytes long, but the last two are MLI return parameters and I don't need to initialize them. But after talking to some Microsoft interviewers last year, I began to rrealise that supercompact or balls-to-the-wall fast code is far less practical in the real world than most of us assembly jocks would like to think. So until the next major species of micro comes out (and I hope I can get on the design team of that), I'll stick to practical programming on today's fluffy architectures. Todd Whitesel toddpw @ tybalt.caltech.edu