Re: Is it too hard to program for the Apple?

["Michael J. Mahon" <mjmahon@aol.com>]

John B. Matthews wrote:
> In article <WKGdnd-OD9HIOR7WnZ2dnUVZ_qKdnZ2d@giganews.com>,
>  "Michael J. Mahon" <mjmahon@aol.com> wrote:
>
>
> > D Finnigan wrote:
>
> [...]
>
> > > Slower even than Applesoft? That's not the impression that I got.
>
> [...]
>
> > Pascal compiled to p-code, or C compiled to runtime library calls,
> > runs perhaps twice as fast as compiled Applesoft, unless it does
> > a lot of floating-point arithmetic or graphics library calls, in
> > which case the speed is more comparable.
>
>
> While Apple's UCSD Pascal p-code system trades speed for space, Kyan 
> Pascal offers an interesting variation: it can either compile to runtime 
> library calls or compile to inline routines. Here's an example that 
> inlines the floating point libraries. Of course, the program is just an 
> interpreter itself!
>
> <http://home.roadrunner.com/~jbmatthews/a2/calc.html>
>
> I like being able to optimize critical sections of code in assembly, and 
> most development tools provide some way to do so. Applesoft has & and 
> USR() vectors; UCSD Pascal has a linker; Kyan has inline assembly; and 
> typical C compilers offer both.
>
> NadaNet is surely a premier example of mixing Applesoft and assembly:
>
> <http://home.comcast.net/~mjmahon/NadaNet.html>
>
> Here's an example using Kyan's inline approach to list volumes and tally 
> the ProDOS volume bitmap of each:
>
> <http://home.roadrunner.com/~jbmatthews/apple2.html#df>
>
> Here's an example using UCSD Pascal to link separate assembly routines:
>
> <http://home.roadrunner.com/~jbmatthews/a2/zap.html>

I'm also a big believer in using at least a couple of languages
or approaches in building applications--small and slow for things
where speed is not a consideration, larger and fast for the few
places where speed is of the essence.

However, an operating environment resident "kernel" is almost always
one of the places where maximum speed and compactness are justified.

All of NadaNet's speed-critical code *must* be in assembler to be
cycle-accurate.  It's & parser and protocols are not so speed-critical,
so while they are still implemented in assembly language, the form
is more "interpretive" to save space.  Getting it all in about 2KB
is worth the trouble, and it provides good support for both assembly
language apps and Applesoft apps.

There is a spectrum of "direct code" to "interpretive code", and there
is considerable advantage to being able to tune individual sections of
code to the appropriate spot on this spectrum depending on actual
execution profiles.  This approach was first formalized by Digitek, and
made their compilers something of a legend in their time.

-michael

NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon

"The wastebasket is our most important design
tool--and it's seriously underused."