Schrijver
| rest in a division
|
ARTRAG msx master Berichten: 1587 | Geplaatst: 15 Oktober 2006, 16:36   |
What is the best way to compute in ASM the rest of a division
between two 8bit unsigned chars?
Note: I am not interested in the division itself, only in the rest.
this code works but...
; In A rest of E / C
xor a
ld b,8
2:
rl e
rla
sub c
jr nc,1f
add a,c
1:
djnz 2b
I am sure it can be reduced to one simgle faster loop. |
|
ro msx guru Berichten: 2307 | Geplaatst: 15 Oktober 2006, 16:48   |
we're talking assembly here. can hardly be any "signed" stuff.. (well, you COULD make routines for that) basically it's just 8 bits of data. nothing fancy about it. that having said.....
If your routine does the job, why are ye not satisfied (yet)?
But I'd go for : A rest of A/B
(it's quicker rotating/subbing the Accu then the E reg or any other)
something like
loop: sub b
jr c, loop
add a,b
ret
(or something, can't really remember flags etc)
|
|
ARTRAG msx master Berichten: 1587 | Geplaatst: 15 Oktober 2006, 17:17   |
i see, what if a = b ?
your loop gives b, but the rest is zero...
|
|
ARTRAG msx master Berichten: 1587 | Geplaatst: 15 Oktober 2006, 17:59   |
About the routine i posted, it needs 8 iteractions, quite a lot compared to yours.
unfortunately your routine looks buggy...
|
|
wolf_
 msx legend Berichten: 4629 | Geplaatst: 15 Oktober 2006, 18:09   |
The asm-n00b comes in: shouldn't JR be a JP? Iirc a JP is faster orso (at the cost of some size in mem), which would be nice for these runs..  |
|
ARTRAG msx master Berichten: 1587 | Geplaatst: 15 Oktober 2006, 18:18   |
yes, but the problem now is the flag condition.
IMHO something is wrong in ro's proposal,
if a=B the rest is not computed correctly
|
|
ro msx guru Berichten: 2307 | Geplaatst: 15 Oktober 2006, 18:58   |
JP is faster than JR on some conditions. JR is 2 bytes, JP is 3 bytes.
Also the jr c,loop should be jr nc,loop or jr nz,loop (ofcourse, shame)
Can't remember flags when crossing zero..
about the A=B, my guess the Carry indeed has to be checked
(sorry, haven't actually been coding Z80 for years.. but it's something like this for sure. I'd look it up, but I'm lazy)
|
|
Prodatron msx master Berichten: 1088 | Geplaatst: 16 Oktober 2006, 00:01   |
JR is as fast as JP, if the condition is true, and
JR is faster than JP, if the condition is false.
...at least on the CPC, where the timing is a little bit more simple than on the MSX  |
|
ARTRAG msx master Berichten: 1587 | Geplaatst: 16 Oktober 2006, 00:27   |
Let's speak of the algorithm. JP or JR is a matter of 1-2 Mcycles
Now the problem is:
how can be implemented ro's proposal in
order to deal also with the a=b condition?
what about this routine?
; In A rest of A / C
loop:
sub c
jp m,end
jp loop
end:
add a,c
|
|
dvik msx master Berichten: 1302 | Geplaatst: 16 Oktober 2006, 00:52   |
This one works (same as ro's but with the nc condition on the jump):
; In A rest of A / B
loop:
sub b
jp nc,loop
add b
ret
if a=b, then you get two turns in the loop which gives a = -b, then you add b at the end so you'll get a = 0 which is expected.
This algorithm is pretty good unless you have some edge conditions where A is big and B is very small. If you think that you have the latter case alot you should try to find a better algorithm that is quicker in those contditions. |
|
ro msx guru Berichten: 2307 | Geplaatst: 16 Oktober 2006, 08:19   |
Quote:
| This one works (same as ro's but with the nc condition on the jump):
; In A rest of A / B
loop:
sub b
jp nc,loop
add b
ret
if a=b, then you get two turns in the loop which gives a = -b, then you add b at the end so you'll get a = 0 which is expected.
This algorithm is pretty good unless you have some edge conditions where A is big and B is very small. If you think that you have the latter case alot you should try to find a better algorithm that is quicker in those contditions.
|
What I said in my earlier post "replace the "jr c" for "jr nc" . . my mistake.
IIRC when sub a,b crosses zero (making the value "negative" ) the Carry flag is set. |
|
ARTRAG msx master Berichten: 1587 | Geplaatst: 16 Oktober 2006, 10:44   |
Thanks, i'll try dvick code, in my case A and
B should be always very close
@dvick
my first post is a 8bit/8bit division that works always in 8 steps, but in my situation
successive subtractions should be better, as I should get the result in 2-3 cycles
|
|
|
|
|