On 12/10/20 2:47 PM, Peter Maydell wrote: >> With the shift, you're discarding the high 32 bits of the result. You'll >> lose >> those same bits if you shift one of the inputs left by 32, and use only the >> high part of the result, e.g. >> >> mulu(&discard, &ret, clk->period, ticks << 32); >> return ret; >> >> Which on some hosts, e.g. aarch64, only requires umulh and not two multiply >> instructions. > > We can't do this if we want to allow a full 64-bit 'ticks' input, right?
Correct. > So I think my plan for v2 of this series is just to add in the > saturation-to-INT64_MAX logic. Sounds good. r~
