<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Tue, 05 Feb 2013 19:12:54 +0100
From   : j+bbcmicro@... (J. E. Klasek)
Subject: 6502 coding request

On Tue, Feb 05, 2013 at 04:40:37PM +0000, J.G.Harston wrote:
> J. E. Klasek wrote:
> >Congratulations! My first tryout was multiplying by 5/3, times 5 is 
> >easy and
> >1/3 is multiply with 0.01010101010 with a two digits periodic ...
> 
> At some point I'll also need 100ths->60ths, which is *0.6, which a 
> quick bit of scribbling turns out to be 0.1001100110011etc, so I should 
> be able to combine both bits of code into one routine with an entry 
> recurring multipland(sp?).

The shift-and-add pattern differs a lot. I think this "optimization" in
space results in far more disadvantage in time.

> 
> >>LSR wksp+5:ROR wksp+4:ROR wksp+3  :\ add=add/2
> >  CLC                               :\ clean add
> >>LDA wksp+0:ADC wksp+3:STA wksp+0  :\ num=num+add
> 
> I found that by omitting the CLC I got more accurate results due to bit 
> 0 falling out of the rotate and getting added on. 

Yes, this some sort of rounding operation. For a correct rounding only after
the last shift a set carry (>= 0.5) should be added. Rounding on each
addition may lead to a difference larger than 1 sometimes.

> I ran a test from 
> &000000 to &444444 and got exact multiples of 100 about 98% of the time, 
> and off by -1 or +1 occasionally,  off by -2 about once in 100,000. I'll 
> stick the code in mdfs.net/Info/Comp/6502/ProgTips at some point. It's 
> good enough for timing where 15.00s or 15.01s make little difference, 
> and most timing is TIME>something, so if testing eg TIME-T%>1500 then 
> juddering from 1500 to 1502 is still going to succeed.

Right, I'm with you. 
I hope some of the stated optimizations find their way into ProgTips :)


Johann
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>