Share a clever design trick in Zephyr: (just sharing and will not affect current conclusions.)
Zephyr retains 32-bit support for timeout precision. References: https://github.com/zephyrproject-rtos/zephyr/blob/main/kernel/Kconfig#L745-L754 https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/sys/clock.h#L45-L49 The benefits of this subtle design are as follows: 1. Embedded hardware is natively 32-bit On 32-bit MCUs such as Cortex-M, 64-bit arithmetic requires multiple instruction cycles, resulting in lower performance and larger stack memory footprint. By contrast, 32-bit uint32_t operations are single-cycle and deliver optimal efficiency. Moreover, 32-bit tick range is sufficient for most embedded scenarios. 2. Sufficient time coverage for common tick frequencies - 100 Hz tick (10 ms per tick): A 32-bit counter can span up to 49.7 days. - 1 kHz tick (1 ms per tick): Also covers up to 49.7 days. - 10 kHz tick (100 μs per tick): Covers up to 4.97 days. Most embedded sleep and timeout requirements never exceed these time limits. 3. 64-bit is implemented as an optional extension When CONFIG_TIMEOUT_64BIT is enabled, k_ticks_t becomes int64_t, allowing kernel APIs to support much longer timeouts. Nevertheless, z_tick_sleep still preserves the 32-bit logic internally for legacy code compatibility; the 64-bit processing path is implemented in other code branches. >From the perspective of the kernel time subsystem, if we adopt similar optimizations specifically for 32-bit CPUs, it will also bring performance improvements to our own kernel time subsystem. BRs, Alan C. Assis <[email protected]> 于2026年5月6日周三 21:38写道： > Thank you Xiang, > > I will submit a fix removing it, I think a simple sed command will fix it. > > BR, > > Alan > > On Wed, May 6, 2026 at 10:28 AM Xiang Xiao <[email protected]> > wrote: > > > Linux do the similar thing: > > > > > https://github.com/torvalds/linux/commit/24e4a8c3e8868874835b0f1ad6dd417341e99822#diff-97463f7cbd63070d218d2557262b21231956345f6a005557296657c1f913c788R27-R41 > > but it was removed in 2014. > > > > On Wed, May 6, 2026 at 6:47 PM raiden00pl <[email protected]> wrote: > > > > > > It may be possible to combine variants 2 and 4. Have time_t always be > > > 64bit, add the helpers you suggested (time_add, time_diff etc.) > > > > > > This is what I meant when writing somewhere earlier in this thread. > > > > > > time_t remains 64-bit so the API is OK, any optimization hidden behind > > > Kconfig is done in the logic working with time_t, so no 64-bit math is > > > used. > > > This way everyone would be happy, but the question is how much of it > > > can be done without messing around with the code too much. > > > > > > śr., 6 maj 2026 o 12:27 <[email protected]> napisał(a): > > > > > > > > Exactly, I think only option 2 and 3 makes sense, but since you > > already > > > > > confirmed that option 2 is not worth... > > > > > > > > It may be possible to combine variants 2 and 4. Have time_t always be > > > > 64bit, add the helpers you suggested (time_add, time_diff etc.) > > > > > > > > Then, if chosen by a Kconfig option, the helpers could switch to > > > > alternate versions which would type-cast the operands to smaller size > > > > (say 32bit). The compiler takes care of the rest. The option > obviously > > > > needs sufficiently visible warning about implications of selecting it > > > > (which implies it needs to be off by default so the user actually > reads > > > > the warning.) > > > > > > > > Advantages: > > > > - time_t is 64bit > > > > - if some operation involving time is missed and not converted to use > > > > the helpers, things will still work correctly > > > > > > > > Disadvantages: > > > > - casting the type of the operands may suppress warnings and hide > bugs > > > > - fairly intrusive change > > > > > > > > Unless I am missing something, this could work - not sure if > something > > > > like this can be merged without support from 32bit world though. > > > > > > > > > >
