Page 5 of 5
Does this seem eggregious to anyone besides me?
Posted: Thu Dec 02, 2021 5:02 pm
by ZeroByte
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.
Does this seem eggregious to anyone besides me?
Posted: Thu Dec 02, 2021 11:39 pm
by BruceMcF
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.
Does this seem eggregious to anyone besides me?
Posted: Fri Dec 03, 2021 1:21 am
by Scott Robison
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.
Does this seem eggregious to anyone besides me?
Posted: Fri Dec 03, 2021 5:29 am
by ZeroByte
@BruceMcFI'll have to try it out. Do you know offhand how many bytes it compiles down to?
Does this seem eggregious to anyone besides me?
Posted: Fri Dec 03, 2021 11:34 pm
by BruceMcF
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.