*2. Isolate 64-bit arithmetic to a single helper module*
Instead of letting the compiler emit inline soft64 sequences
everywhere,
funnel all time_t arithmetic through a small set of out-of-line helpers
(
time_add, time_cmp, time_diff). The compiler can then share the same
code
rather than re-emitting it per call site. This trades a few call/return
instructions for eliminating duplicated soft64 code.
From a quick testing, this doesn't seem worth any effort - the compiler
(avr-gcc) already does this. It treats time_t as a generic 64bit value
and arithmetic operations call a builtin like __adddi3_s8. Similar for
comparisons.
It looks to me like the code size increase simply comes from the fact
that the compiler needs to shuffle more data around to have correct
bytes in correct registers when passing parameters to those builtins.
*4. Platform-specific time_t width via Kconfig*
Rather than a global forced 64-bit, NuttX could expose a
CONFIG_TIME64_BOUNDARY Kconfig that is automatically forced y on
platforms
where sizeof(long) >= 4 (ARM, RISC-V, ESP32) and defaults n on
AVR/MSP430,
with a prominently documented tradeoff warning. POSIX compliance
becomes
opt-in for platforms that can afford it. This is essentially what
CONFIG_SYSTEM_TIME64 was doing — the argument to NuttX maintainers
would
be: keep the escape hatch for 8-bit targets rather than making it
unconditional.
I believe the intention (or one of the intentions) behind the PR is to
remove ifdefs needed to support CONFIG_SYSTEM_TIME64 option. This
variant seems to be trading some ifdefs for other ifdefs.
*6. Audit the POSIX surface actually needed*
If the AVR target never uses clock_gettime, nanosleep, timer_create,
etc.,
those translation units should not be compiled in at all. A careful
menuconfig audit of CONFIG_CLOCK_* and CONFIG_TIMER_* options can carve
out
the dead weight without touching the ABI.
These are removed by the linker when not needed.
