On Mon, Mar 4, 2024, at 12:45, Andre Przywara wrote:
On Mon, 04 Mar 2024 12:26:46 +0100 "Arnd Bergmann" arnd@arndb.de wrote:
On Mon, Mar 4, 2024, at 12:24, Andre Przywara wrote:
On Mon, 04 Mar 2024 12:11:36 +0100 "Arnd Bergmann" arnd@arndb.de wrote:
This used to be a 32-bit division. If the rate is never more than 4.2GHz, clock could be turned back into 'unsigned long' to avoid the expensive div_u64().
Wouldn't "div_u64(clock, 200)" solve this problem?
Yes, that's why I mentioned it as the worse of the two obvious solutions. ;-)
Argh, should have cleaned my glasses first ;-)
I guess I was put somehow put off by the word "expensive". While it's admittedly not trivial, I wonder if we care about the (hidden) complexity of that function? I mean it's neither core code nor something called frequently?
It's not critical if this is called infrequently, and as Maxime just replied, the 64-bit division is in fact required here. Since we are dividing by a constant value (200), there is a good chance that this will be get turned into fairly efficient multiply/shift code.
I don't think we have any clock exceeding 3GHz at the moment, but it sounds fishy to rely on that.
Right, it's just important to look at each case individually. The cost of 64-bit division is crazy if it gets called repeatedly, which is of course the entire reason we don't provide a __aeabi_uldivmod() function and require developers to think before adding div_u64().
Arnd