Does this seem eggregious to anyone besides me?

ZeroByte · Post by **ZeroByte** » Thu Dec 02, 2021 5:02 pm

On 12/1/2021 at 7:14 PM, Scott Robison said:

My algorithm was fast!

Yeah - you're just over 1 scanline of raster time. Mine's 2.5, General is 18 scan lines.

BruceMcF · Post by **BruceMcF** » Thu Dec 02, 2021 11:39 pm

On 12/2/2021 at 12:02 PM, ZeroByte said:

Yeah - you're just over 1 scanline of raster time. Mine's 2.5, General is 18 scan lines.

I don't know if my last code above works correctly, but I think it's on the order of 130 clock cycles. Fully unrolled loops saves a lot of that, since even three byte shifts by two bits don't save a lot of space by looping.

Scott Robison · Post by **Scott Robison** » Fri Dec 03, 2021 1:21 am

On 12/2/2021 at 4:39 PM, BruceMcF said:

I don't know if my last code above works correctly, but I think it's on the order of 130 clock cycles. Fully unrolled loops saves a lot of that, since even three byte shifts by two bits don't save a lot of space by looping.

Could be. I didn't analyze the question of "how to efficiently divide by 60". I just tried to find the fastest way to code the original expression given. Not to say I found the fastest way, just that I had noticed all the bit shifts were 8 bits off another bit shift, so I was able to avoid most bit twiddling and just do repeated adds with the bytes aligned to different positions.

ZeroByte · Post by **ZeroByte** » Fri Dec 03, 2021 5:29 am

@BruceMcFI'll have to try it out. Do you know offhand how many bytes it compiles down to?

BruceMcF · Post by **BruceMcF** » Fri Dec 03, 2021 11:34 pm

On 12/3/2021 at 12:29 AM, ZeroByte said:

@BruceMcFI'll have to try it out. Do you know offhand how many bytes it compiles down to?

If I am counting the opcodes correctly, its around 75 bytes.

~~~~~~~~~~~~~~~~~~~~~

@Scott Robison

Quote

Could be. I didn't analyze the question of "how to efficiently divide by 60". I just tried to find the fastest way to code the original expression given. Not to say I found the fastest way, just that I had noticed all the bit shifts were 8 bits off another bit shift, so I was able to avoid most bit twiddling and just do repeated adds with the bytes aligned to different positions.

Yes, the difference is between finding an efficient way to find 0.016666... of something and an efficient way to find 0.01666259765625 of something.

For a dividend like 14,400, the difference seems like it would be smaller than the precision of a 16.8 answer.