Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!ucsd!ucrmath!rhyde
From: rhyde@ucrmath.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: Computer capabilities
Message-ID: <10872@ucrmath.ucr.edu>
Date: 4 Jan 91 06:23:43 GMT
References: <325@generic.UUCP> <10827@ucrmath.ucr.edu> <1991Jan2.060637.7936@nntp-server.caltech.edu>
Organization: University of California, Riverside
Lines: 38

>> The real issue is development time vs.  code qualities...

That's why there's very little software available for the GS, people don't
want to use assembly language anymore and assembly is the only practical
language for reasonable software on the GS.  Sure,  you can use C or Pascal
for simple tasks, but for complex tasks HLLs are *way* too slow on the '816.

As for code development time, did you say you're using ORCA/C? :-)
Of course, if you compare ORCA/C against ORCA (the assembler) perhaps you
don't get a skewed view.  I promise you though, I can get a product working
twice as fast with Brian Fitzgerald's Lisa/816 than I can with ORCA/C.
Orca/C is, shall we say, glacial.  I tried porting FLEX & BISON to the GS
using ORCA/C.  I gave up.  It was too slow (ORCA/C) and the version I had
(whatever their second release was) had way too many bugs.  The standard
library was very wimpy.  I dunno if they've fixed these problems in a later
release.  I just went back to my '386 mumbling about rotten tools.  I hate
blasting Bytework's products, they're the best we've got and we all really
need to support them, but geeze....

>> ORCA/C uses the direct page register (as a base pointer)..
Sure, so do the other languages available.  This has two major disadvantages:
(1) Your stack frames are limited to 256 bytes, max (no big arrays!)
(2) You can't use direct page values as "register" variables.  Since the frames
    are rarely page aligned, accessing such variables costs an extra cycle on
    each access.  As for the extra addressing modes, if a frame pointer were
    available, presumably it would support all of these as well.  See my
    article on the 65820 for more details.

>> [instruction sequence] isn't THAT bad.
 This is 10 cycles above and beyond the cost of a return.  Not to mention
six extra bytes (for *each* call).
For "C" you  have no choice but to do this.  For Pascal, whose procedures and
functions have a fixed number of parameters) the subroutine can pop the
parameters rather than the caller.  Given how universities are pushing
"modular" code these days, and the amount of people writing *tiny* subroutines
in this world, you'd probably be surprised how much this little addition
would help.
*** Randy Hyde