C, asm, FSTs, and who has his nose up whose butt :)

[sbehrens@bigfoot.com (Sönke Behrens)]

nathan@visi.com (Nathan Mates) wrote:

>In article <69bvdk$cpu$1@opal.southwind.net>,
>Randy Shackelford <shack@onyx.southwind.net> wrote:
>>Dave Althoff (dalloff@freenet.columbus.oh.us) wrote:
>>: Without arguing that GNO is or isn't a Linux lookalike (quite frankly, I
>>: don't care...)...please tell me that I am not seeing a rejection of the
>>: longstanding tradition of hand-coding Assembler for the Apple ][ series! 
>>: Personally, I think the hand-written code is what sets the ][ apart. 
>>: Sure, compiled high-level code is a lot easier to write, and it is a lot
>>: more portable, it also tends to be bigger and slower thanks to the
>>: included libraries...

I think a mixture is best. There are things that should be in asm, and
there are things that are easier maintained in C.

Let me use a few examples, i.e. code I have written or ported:

- occ is 100% C. There is no need to use asm here, it would just slow
  down maintenance. No computing-intensive code present.
- udl is 100% C. This could benefit from ASM in a few crucial
  routines, but I haven't gotten round to it.
- ndp is part C, part asm. The asm parts are routines that were
  originally C, and were converted to asm after profiling.
- lhalpha is part C, part asm. All the actual work is done by
  asm routines, the user interface is pure C.

I guess what I am saying is: Reinventing the wheel in asm is nice.
It's even fun. But it is also a slow process. I highly respect people
who can write something like DreamGraphics in 100% pure Merlin asm,
but that doesn't mean it's the _only_ way to write software or get
performance.

Consider the 10/90, or some say 20/80 rule: 10% (20%) of the code
account for 90% (80%) of your runtime. Exactly _which_ parts eat up
your runtime is often very surprising and is revealed only by a
profile.

The first step is to optimize your algorithms and data structures ...
I have gotten speedups of factor 10 (easily) with this. When you are
satisfied that you have the optimal algorithm and the optimal data
structure, and your code is _still_ too slow, then recode those 10% in
asm for another speedup. Which won't be anywhere near times 10,
though. Times 2 if you are lucky. Which is very desirable as well,
agreed.

>>it's the only way to get any speed at all. You don't have linux on Apple IIs
>>because there isn't enough horsepower to run so much compiled code.

Actually there are other reasons for not having Linux. Linux makes so
many assumptions about the architecture (32-bit ints, lots of
registers, lots of stack space, etc) that it would be a _major_ hassle
to try and port it. GNO/ME is here, a lot of work has gone into it and
is going into it, it does not "take over" and keep you from running
GS/OS apps ... so it is only logical to continue in that direction and
use a less "bloated" environment.

As for raw horsepower ... well what the heck, eh. Of course an Apple
IIgs ain't a Pentium-II or K6-300. If you need power, use your second
computer. That's what it's for :)

>   It's much easier to accept that Apple never had a good design for
>the FST API, then all of these *WRONG* reasons propagated by you. But,
>since you've got your nose so brown from kissing Apple's ass in
>public, you sure don't seem to care about your appearing the freak in
>public.
>
>   Back to the original point of this thread: Apple royally messed up
>the API of the GS/OS FSTs. And that's *NOT* the fault of the 65xx
>series, that's not the fault of the language things were written
>in. That fault is purely on the programmers at Apple. And yes, I'm
>saying they could have done it better, but they shaved too many
>corners. If they're gonna be insulted by such a statement, I'd rather

Now, I disagree with Nathan's language (hello Nate! :), but I agree
with his factual points. The FST API has been cobbled together, it is
not a clean design. I remember a quote from an Apple engineer along
the lines of "Hell, we had the source to everything. If we needed
something, we just wrote it". That is hacker culture pure, not
software design or software engineering. It's the way MS still writes
code (yuck).

Apple did a damn fine job with GS/OS. But I maintain they didn't do a
_great_ job. A _great_ job would have meant better documentation, more
encapsulation, and cleaner, extendable APIs. It's doable, even on a
2.8MHz machine.

Sönke
-- 
ORCA/C buglist and other stuff at: http://www.arrowweb.com/sbehrens/