Optimizing DIV

[Darrel Taylor]

What, are you going to make me do it?

I will have exact numbers, good or bad.
Do you want to be the first to know ... (a.k.a. you do it)

Or do you give me a free Jab? Without a glove.
<br>

[Darrel Taylor]

Results are in ....

I'm taping up my hand.

Anything you want to change?
<br>

[skimask]

Arg! I fell asleep in my chair thinking about it.
I'm tellin' ya... I wrote a complement of 32bit math routines for my 6809E back in the day on my CoCo2. There's probably one friggin thing I'm forgetting. And no I haven't google'd anything because I don't want to.
I'll remember it eventually... Make that jab to the back of the head. Maybe that shot will knock it forward.

[skimask]

Ok, getting somewhere now...
Had a thought earlier of adding a few extra loops to knock down the '32bit only' divide into sections dealing with only 32, 24, 16 and 8 bit divides.
It's working well in the short tests, sometimes knocking cycle counts down by more than 3/4, usually by about 1/2.
Fairly sure I fixed the 0/0 bug also...that could've been a bit more obvious...but I don't see how.

[Darrel Taylor]

<img align=left border=1 hspace=10 vspace=10 src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2857" />
<!-- -->It appears that along with some new errors, ...
you've added an average of 3 instruction cycles to the PBP DIV time.

According to the theory, the most optimization would be gained when using small numbers. So 8-bit/8-bit should see the greatest effect.<hr>

--Testing 8/8, Skip 0/0 this time--
Test- A=1-255, B=0-255
No ERRORs:
SkiMIN=762 SkiMAX=1018
PBPMIN=759 PBPMAX=1015


This is the latest test program ... SkiDiv5.pbp

These are the results at different OPT levels ...
SKI_DIV_OPT_1
SKI_DIV_OPT_2
SKI_DIV_OPT_3
SKI_DIV_OPT_0

This test program uses the Timing methods described in Post #2.

[skimask]

It appears that along with some new errors, ...

Hmmm... That code I posted last night at 22:17 worked good for me, as far as errors go. 0/0 was the only one I got and I found the source of that one. But not much for savings.

you've added an average of 3 instruction cycles to the PBP DIV time.
According to the theory, the most optimization would be gained when using small numbers. So 8-bit/8-bit should see the greatest effect.

That's what I'm getting also now that I've got a 'method' working.

[Darrel Taylor]

It's working well in the short tests, sometimes knocking cycle counts down by more than 3/4, usually by about 1/2.

Keep in mind that the previous test program was only looking for the accuracy of the results, not the timing.

It used 2 divides, 1 for the quotient and another for the remainder.

        PBPQ = AL / BL                   ; do same in PBP
        PBPR = AL // BL

When it looked like you were getting 1/2 the cycle count. It's because PBP had to do it twice.

The new test program is geared towards Timing.
PBP only has to do it once now.
<br>

[skimask]

It used 2 divides, 1 for the quotient and another for the remainder.

Ya, I noticed that last night after everything was running TWICE as fast.
I knew it was too good to be true.
I'm cooking on some numbers right now based on loop sizes of 9, 99, and 999 (step 1)...and so on...
After those get done cooking, I'm going to expand those number out to 32 bit with larger steps and let it cook again. Like you annotated, could take months!