Re: Apple and the Holy War

[pausch@saafNOSPAM.se (Paul Schlyter)]

In article <CrNQ4.618$Jf.1855@newsfeed.slurp.net>,
Forrest <bctimes@hotmail.com> wrote:
 
> Somewhere, pausch@saafNOSPAM.se (Paul Schlyter) wrote:
> 
>> The Applesoft FP package wasn't that bad -- it compared favourably with
>> 8080 code running at twice the clock speed -- and then Applesoft yielded
>> 9-10 digits of precision while the 8080 code yielded only 7 digits of
>> precision.
> 
> It was still a rush job and not optimized.
 
How do you know that?  Did you find a significantly faster 6502 FP
package somewhere else?
 
> It would be interesting to see whether any speed enhancements were made
> to the FP code between Applesoft I and II, or indeed any changes at all.
 
I don't think so.  Many years ago I compared the FP code in Applesoft II
to the corresponding FP code in PET-Basic and C64-Basic -- as far as I
could see, they were identical.
 
> (Goodness knows the Applesoft II garbage collection and string handling
> routines still had vast room for improvement, as the later efforts of
> Randy Wigginton and Alan Bird demonstrate.  Something like a hundred-fold
> speed improvement...)
 
True, but those improvements also required singificantly more memory.
However you've now switched subjects: just because the string
handling and garbage collection was inefficient doesn't imply that
the FP routines were equally inefficient!  Or did you find 6502 FP
routines elsewhere which offered a 100-fold, or even a 10-fold or a
mere 3-fold improvement, while giving you the same precision,
compared to those in Applesoft?
 
>> You suggest that I should have written that program in assembler.  If
>> I had followed your edvice, that program would not have been completed.
> 
> You wrote that you never completed the Applesoft version and guessed at its 
> speed.
 
Yes.  I did some benchmarks of pieces of some of the more FP
intensive code though (such as computing the Moon's position at any
instant), so my guess wasn't completely out of the blue.
 
If you do your floating-point by your own assembly language subroutines,
there are a few ways to speed up your code though:
 
1. Use reduced precision.  It's pointless to do all computations
using 9-10 decimal digits of precision, if you're going to round the
final result to 2-3 digits anyway.  Don't use more precision that
you need.
 
2. Use fixed point instead of floating point.  Works fine if your
numbers cover only a fairly small range.
 
3. Use table-lookup whenever feasible.  Computations of e.g.
trigonometric function at low precision can be greatly speeded up
by using table lookup and perhaps linear interpolation between
two table values.
 
As an experiment, I once implemented a ruotine to compute the Sun's
position to maximum precision (this is a trigonometric series
containing some 100 terms, most of them of very small magnitude) in
Z80 assembly language.  That routine yielded the same final precision
as a conventional implementation on an XT with an 8087 FPU -- but the
Z80 implementation was faster!
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40,  S-114 38 Stockholm,  SWEDEN
e-mail:  pausch at saaf dot se   or    paul.schlyter at ausys dot se
WWW:     http://hotel04.ausys.se/pausch    http://welcome.to/pausch