| |
Luke
Registered: Dec 2004
Posts: 19 |
8 or 16bit muls/divs
About multiply:
Bad one:
a*b=((a+b)/2)^2-(((a+b)/2-b))^2 with x*x matrix
It's near 30-40 cycles, but unstable with (a+b)bit0 bcoz ror after adc.
Some ppl using "nybble tables" $0n x $xy with $1000 size of tables and swap+add, but more than 50 cycles left.
And last bad is old asl bcc adc ror routine, but very slow
like 80+ cycles.
Now I trying to do any 16x16bit signed multiply, but it's really hard to make "short time" routine. Anyone got any idea?
About Divu/Divs
Classical lsr bcs sbc rol too slow.
But a/b= e^(lna-lnb) looks quite fast with e^x matrix, but
quite inaccurate.
Somebody got other "faster" idea for it? Particular 16/16bit routines.
|
|
... 29 posts hidden. Click here to view all posts....
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: I remember that, but after tests slower than classical asl bcc adc ror :) But I'll check it again.
edit. You are right, can be faster with tables. Damn, how to crunch that tables now , it's too much memory left :)
edit2. btw. Anyone got any fast arithmetical a=x*x method?
you can make a x^2 table by doing like this :
0,1,4,9,16,25,36
as you can see, the differences are
0,1,3,5,7,9,11,etc
so first number is 0, and then calc all numbers by nextnumber=previousnumber+1+2*positionoldnumber
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Just use drive code and the plain old binary mul/div loops suit perfectly. Works great for me. :) |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
ready.: Unfortunately, that's a multiply routine, not a divide. You're multiplying by a percentage or ratio, which is great if you already have the ratio, but doesn't avoid the division if you need to find it. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
White Flame: check it out better, it's a division.
Each lsr divides by 2, right? Many by 2 divisions provide 1/2, 1/4, 1/8,.... then sum toghether the terms you need to get the percentage you want of your original number. Don't you agree?
Besides in this way, there's no need for tables.
ciao,
Ready. |
| |
Luke
Registered: Dec 2004
Posts: 19 |
ready. - you are wrong :)
1) x = lda #$7f lsr lsr lsr lsr lsr lsr lsr sta $nn (nn)=$00
so for example 3x #$7f/ 128 = 0 ???!!!
Too many lost carry flags. It's inaccurate at all. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@ready: So... if a line is dx=34 and dy=78 and I wanna calculate the line slope dx/dy = 34/78, how do I do that using your algorithm? |
| |
ready.
Registered: Feb 2003
Posts: 441 |
Luke:
x = lda #$7f lsr lsr lsr lsr lsr lsr lsr sta $nn (nn)=$00
so for example 3x #$7f/ 128 = 0 ???!!!
is absolutely correct. #$7f=127 and 127/128=0.something. My routine deals only with integer. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
Luke:
x = lda #$7f lsr lsr lsr lsr lsr lsr lsr sta $nn (nn)=$00
so for example 3x #$7f/ 128 = 0 ???!!!
is absolutely correct. #$7f=127 and 127/128=0.something. My routine deals only with integer. |
| |
Luke
Registered: Dec 2004
Posts: 19 |
No :D 3x ($7f/128) = dec 2.97 not 0 :)
Show me that zoomer :))))))
edit: JackAsser: :DDDDDDD 34/78 = 0 too:D Did you know?:D |
| |
ready.
Registered: Feb 2003
Posts: 441 |
Luke: ok, you are right, but working with integers, it also depends on what operation you do first. If you do 3x#$7f=#$17d and then divide by 128 you get a more accurate result. The routine I put in my previous post was meant to be used for 8bit division. I just wanted to give the idea, not the detailed routine.
Doing division first causes you to loose significant digits.
For 16bit number, of course you have to use ror instead of lsr.
JackAsser: the same answer is valid for you too. #$34/#$78 is less then 1, so you should do something like #$134/#$78 to store some significant digits into memory as a result.
But so far I have used this division routine just with 8bit numbers and it works.
Ready. |
| Previous - 1 | 2 | 3 | 4 - Next |
