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

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

D Finnigan wrote:
> Michael Black wrote:
>
> > On Mon, 22 Feb 2010, D Finnigan wrote:
> >
> >
> > > Thanks to everyone's responses, I've decided to slow down, man up, and
> > > learn
> > > to program in C for the Apple IIe, and also hopefully learn more assembly
> > > as
> > > well.
> >
> > Assembly is pretty fast, C is really slow.
>
>
> Slower even than Applesoft? That's not the impression that I got.

Speaking only about run time, Applesoft is about the slowest of the
bunch--I usually estimate about 300 statements per second on an
unaccelerated Apple for simple statements without trancendental
functions.  ;-)

Compiled Applesoft (any of several compilers) really means compiled
into direct calls to runtime "execute" routines, and generally runs
about 5x faster than fully interpreted Applesoft (YMMV).

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.

C compiled to machine code is several times faster than code that
calls runtime routines for everything, but is larger as a result.
And again, if it does a lot of meaty calls, then those routines will
determine the runtime.

Assembly language is easily a few hundred times faster than Applesoft,
and usually 2x-3x faster than compiled code, since the assembly language
programmer allocates machine registers "perfectly" for speed and uses
"ideal" machine-oriented data structures, not a few "standard" types
provided by a programming language. (Of course, if all the time is
spent in libraries, those libraries will determine the speed.)

Any production OS intended to run on a (small fraction of a) 64KB
machine can and should be written in assembly language, for compactness
as much as speed and versatility.  16KB of 6502 code is less than 5-6k
lines of code, and therefore well within the range of easily managed
assembly programs--assuming reasonable factoring, macros, etc.

Most system code has no use for floating-point, and, barring a GUI,
no use for graphics subroutines.  The most time-consuming calls it
is likely to make involve block moves or table searches, so making
those fast and/or infrequent is a big win.  The most frequent operation
is likely to be procedure call, so adopting a flexible hierarchy of
calling methods is of great importance for both space and speed.
(This is another area where compiled languages seldom provide enough
versatility to, for example, pass parameters in registers or toggles.)

-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."