You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At present there's a strong possibility that the compiler does not optimise fixed points defined with a zero-width fraction part due to the extra operations required for fractional fixed points.
Although I think it's unlikely that anyone would actually want to use a fixed point with a zero-width fraction part (because this would be more or less equivalent to an integer of the same size), I think it would be good to specialise this case at some point on the off chance that there is a genuine need for such types given that there's a clear way to optimise in this situation.
In particular, some of the possible optimisations are:
getInteger() can avoid shifting by simply returning this->value.
getFraction() can avoid shifting by simply returning 0.
Multiplication and division do not need to upscale and downscale.
roundFixed() and similar functions could simply return their argument.
At present there's a strong possibility that the compiler does not optimise fixed points defined with a zero-width fraction part due to the extra operations required for fractional fixed points.
Although I think it's unlikely that anyone would actually want to use a fixed point with a zero-width fraction part (because this would be more or less equivalent to an integer of the same size), I think it would be good to specialise this case at some point on the off chance that there is a genuine need for such types given that there's a clear way to optimise in this situation.
In particular, some of the possible optimisations are:
getInteger()
can avoid shifting by simply returningthis->value
.getFraction()
can avoid shifting by simply returning0
.roundFixed()
and similar functions could simply return their argument.The text was updated successfully, but these errors were encountered: