Xiang and Raiden,
Can we use this option (CONFIG_POSIX_PSE51_SUBSET) for now to avoid
removing the time_t 32-bit?
BTW, I used the AI help (Claude) to find the option to optimize the code
size, I think option 2 could work (because currently the compiler is
replicating the lib to 64-bit math division/multiplication everytime time_t
operations are used) and option 3 too:
Why the bloat happens
On AVR (8-bit, no hardware 64-bit ops), every 64-bit arithmetic operation
on time_t gets emitted as a multi-instruction software sequence — addition,
comparison, load/store — all expanded by the compiler into 4–8× more
instructions than the 32-bit equivalent. The 2KB is mostly this
soft-arithmetic overhead accumulating across all the time-related syscall
paths.
Optimization strategies
*1. Weak-link / linker garbage collection*
Ensure all time subsystem functions are in separate translation units
with -ffunction-sections
-fdata-sections and --gc-sections. Any path not reachable from your
application gets dead-stripped. This is likely already done in NuttX but
worth auditing — a single stray reference can pull in an entire 64-bit math
chain.
*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.
*3. Split representation internally*
Keep the public API time_t as 64-bit (POSIX compliant) but store the
internal tick counter as 32-bit + epoch-offset:
/* Internal: 32-bit ticks + a 32-bit epoch extension */
static uint32_t g_tick_low;
static uint32_t g_tick_epoch; /* incremented on overflow */
/* Only promote to 64-bit at the POSIX boundary */
time_t clock_systime_ticks(void) {
return ((time_t)g_tick_epoch << 32) | g_tick_low;
}
The 64-bit promotion then happens only at the API boundary, keeping the hot
interrupt path 32-bit and minimising soft64 instruction spread.
*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.
*5. LTO (Link-Time Optimization)*
-flto lets the compiler see across translation unit boundaries and
inline/fold redundant 64-bit sequences that separate compilation hides. On
AVR with avr-gcc this can be meaningful — but test carefully since LTO on
AVR has historically had edge-case bugs.
*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.
Thoughts?
BR,
Alan
On Mon, May 4, 2026 at 3:50 PM Alan C. Assis <[email protected]> wrote:
> raiden00, that could be an option, although I think it is a drastic option
> :-)
>
> Remember that even PSE51/52 requires time() and time_t, but doesn't
> require time_t equal to 64-bit (because it is based on IEEE Std
> 1003.13-2003).
>
> Maybe it can change in the future, but currently time_t is not required to
> be 64-bit for PSE51/52.
>
> So we could have CONFIG_POSIX_SUBSET_PSE51 or _PSE52 and allow
> CONFIG_SYSTEM_TIME64 be disabled.
>
> BR,
>
> Alan
>
>
>
> On Mon, May 4, 2026 at 12:40 PM raiden00pl <[email protected]> wrote:
>
>> The standard says that time_t "is an integer type of at least 64 bits."
>> So for small systems, maybe we need to think from the other side - how
>> to optimize memory usage for systems that don't care about time, but
>> without touching the definition of time_t. I understand that there are
>> applications that don't care about absolute time, or even - don't care
>> about
>> time at all. I have built several such applications myself.
>>
>> Perhaps the solution is to disable time handling at all (not sure if
>> possible)
>> or optimize the time calculations. I thought about it once, but I had to
>> move
>> on to other topics before I came up with something useful :)
>>
>> pon., 4 maj 2026 o 17:31 Matteo Golin <[email protected]>
>> napisał(a):
>>
>> > What I will say as a bit of an aside is that a few things have mentioned
>> > here in regards to optimizations that can be made to fit in a smaller
>> > footprint. If we're worried about slowly overfilling small MCUs, we can
>> > start another milestone for size-based optimizations we can make to
>> > counteract these necessary changes.
>> >
>> > Matteo
>> >
>> > On Mon, May 4, 2026, 5:27 PM Tomek CEDRO <[email protected]> wrote:
>> >
>> > > +1 :-) Standard is standard, as a project we need to adhere, if a
>> > > developer wants to do something else it's up to them, but project
>> > > needs to stay standard compliant by default :-)
>> > >
>> > > --
>> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>> > >
>> > > On Mon, May 4, 2026 at 3:18 PM raiden00pl <[email protected]>
>> wrote:
>> > > >
>> > > > > The thing is - in my opinion - that interpretation of "strict
>> POSIX
>> > > > > compliance" is application-dependent.
>> > > >
>> > > > I don't think so, standardization doesn't work that way. In fact,
>> it is
>> > > the
>> > > > opposite:
>> > > > the standard is the main set of requirements on which all the rest
>> is
>> > > built.
>> > > > If a standard states that X must be Y, then you meet the standard
>> if X
>> > > is Y.
>> > > > If X is not Y, then you don't meet the standard. The application is
>> not
>> > > > subject
>> > > > to the POSIX standard, the subject of the POSIX standard is the OS
>> > > > interface.
>> > > > So it doesn't matter if your application uses 32 bit time or not,
>> > time_t
>> > > > has to be
>> > > > 64 bit to be compliant with the standard.
>> > > >
>> > > > pon., 4 maj 2026 o 16:57 Michal Lenc <[email protected]>
>> > napisał(a):
>> > > >
>> > > > > But that's not caused by Xiang's merge request, the support is
>> > already
>> > > > > broken from what I understood from Greg's messages, right?
>> > > > >
>> > > > > To be fair, I am not 100 % convinced if we should go into too much
>> > > > > trouble to support these archaic platforms. On one hand it's cool
>> to
>> > > > > have those, because not many platforms support them, on the other
>> it
>> > > can
>> > > > > be a real pain from the maintenance and codebase clearance point
>> of
>> > > view.
>> > > > >
>> > > > > Having a portable layer that would provide the interface for 8/16
>> bit
>> > > > > platforms could be a solution if we find someone willing to
>> maintain
>> > > it,
>> > > > > but I think it should be solely for those platforms and not used
>> from
>> > > > > 32/64 bit microcontrollers because of code simplicity. Because
>> this
>> > > > > isn't just time related, but I suppose there are incompatible
>> issues
>> > > > > with other POSIX interfaces as well.
>> > > > >
>> > > > > Michal
>> > > > >
>> > > > > On 5/4/26 16:23, Tomek CEDRO wrote:
>> > > > > > This still does not solve issues on 8 and 16 bit platforms (i.e.
>> > > > > > non-atomic access, overflows). The problem may be just less
>> > visible /
>> > > > > > painful. I think we need "default" and "portable" implementation
>> > that
>> > > > > > would both provide POSIX compliant time functionality (int64_t)?
>> > > > > >
>> > > > > > --
>> > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>> > > > > >
>> > > > > > On Mon, May 4, 2026 at 2:19 PM Michal Lenc <
>> [email protected]>
>> > > wrote:
>> > > > > >>> I like the idea of 64-bit time_t being the default with a way
>> to
>> > > > > reduce it
>> > > > > >>> when appropriate for a particular use case. The Kconfig
>> > > "---help---"
>> > > > > text
>> > > > > >>> could warn that less than 64-bit is non-POSIX and the
>> > consequences
>> > > of
>> > > > > using
>> > > > > >>> less than 64 bits, and let the developer decide. By default
>> we'll
>> > > be
>> > > > > >>> 64-bits and complying with POSIX on this issue.
>> > > > > >> I think this is the ideal "common ground". Let's make 64 bit
>> time
>> > > > > >> default and replace the CONFIG_SYSTEM_TIME64
>> > > > > >> option with CONFIG_SYSTEM_TIME32 one that would still use 32
>> bit
>> > > time
>> > > > > >> for use cases where this is required. This way we will keep
>> POSIX
>> > > > > >> compatibility and also leave open door for older platforms with
>> > less
>> > > > > >> flash/RAM.
>> > > > > >>
>> > > > > >> Michal
>> > > > > >>
>> > > > > >> On 5/4/26 14:03, Nathan Hartman wrote:
>> > > > > >>> One of the nicest things about NuttX is that you can use it
>> with
>> > > any
>> > > > > >>> microcontroller. That's the biggest selling point for me:
>> instead
>> > > of
>> > > > > using
>> > > > > >>> a different set of vendor libraries for each microcontroller,
>> you
>> > > can
>> > > > > >>> standardize on NuttX and your code becomes portable across
>> > > > > microcontrollers
>> > > > > >>> regardless of vendor.
>> > > > > >>>
>> > > > > >>> If we start leaving microcontrollers behind, first it will be
>> > 8-bit
>> > > > > >>> microcontrollers, then likely it will be 16-bit, eventually
>> we'll
>> > > be a
>> > > > > >>> large and heavy OS that only works on powerful, expensive
>> chips.
>> > > > > >>>
>> > > > > >>> I like the idea of 64-bit time_t being the default with a way
>> to
>> > > > > reduce it
>> > > > > >>> when appropriate for a particular use case. The Kconfig
>> > > "---help---"
>> > > > > text
>> > > > > >>> could warn that less than 64-bit is non-POSIX and the
>> > consequences
>> > > of
>> > > > > using
>> > > > > >>> less than 64 bits, and let the developer decide. By default
>> we'll
>> > > be
>> > > > > >>> 64-bits and complying with POSIX on this issue.
>> > > > > >>>
>> > > > > >>> My 2¢...
>> > > > > >>>
>> > > > > >>> Nathan
>> > > > > >>>
>> > > > > >>> On Mon, May 4, 2026 at 7:43 AM Alan C. Assis <
>> [email protected]>
>> > > > > wrote:
>> > > > > >>>
>> > > > > >>>> I wasn't aware that libfaketime was facing an issue with the
>> > > time_t
>> > > > > moving
>> > > > > >>>> to 64-bit ?
>> > > > > >>>>
>> > > > > >>>> https://github.com/wolfcw/libfaketime/issues/418
>> > > > > >>>>
>> > > > > >>>> I think in our case we don't have any issue (I hope), other
>> than
>> > > the
>> > > > > code
>> > > > > >>>> increasing and a worse performance on 8/16/32-bit MCUs.
>> > > > > >>>>
>> > > > > >>>> BR,
>> > > > > >>>>
>> > > > > >>>> Alan
>> > > > > >>>>
>> > > > > >>>> On Sun, May 3, 2026 at 4:22 PM Gregory Nutt <
>> > [email protected]>
>> > > > > wrote:
>> > > > > >>>>
>> > > > > >>>>> There are some compilers that do not support uin64_t
>> natively.
>> > > For
>> > > > > >>>> those,
>> > > > > >>>>> library support would be needed.
>> > > > > >>>>>
>> > > > > >>>>> If an implementation requires multiple accesses to
>> read/write
>> > > uint64,
>> > > > > >>>> then
>> > > > > >>>>> the accesses would be non-atomic. At a bare minimum, the
>> > locked
>> > > > > section
>> > > > > >>>>> would be required (which would not prevent concurrent
>> accesses
>> > > from
>> > > > > >>>>> interrupt handlers).
>> > > > > >>>>>
>> > > > > >>>>> I support the POSIX first prioritization. I removed a lot
>> of
>> > > support
>> > > > > >>>>> needed by some of these architectures in the past for
>> similar
>> > > > > reasons.
>> > > > > >>>>> That broke certain compilers and a lot of implementations
>> > (which
>> > > are
>> > > > > >>>> still
>> > > > > >>>>> broken). We should probably do the same, but with full
>> > > awareness of
>> > > > > >>>>> functionality well will use or things that are very broken.
>> > > > > >>>>>
>> > > > > >>>>> I have suggested removing support for the 8 bit
>> architectures
>> > > and for
>> > > > > >>>>> compilers like the ZDS and SDCC compilers. Carrying
>> > > architectures
>> > > > > with
>> > > > > >>>>> this level of breakage is misleading.
>> > > > > >>>>>
>> > > > > >>>>> ________________________________
>> > > > > >>>>> From: [email protected] <[email protected]>
>> > > > > >>>>> Sent: Sunday, May 3, 2026 9:42 AM
>> > > > > >>>>> To: [email protected] <[email protected]>
>> > > > > >>>>> Subject: Re: [DISCUSS] Removal of CONFIG_SYSTEM_TIME64 and
>> make
>> > > > > time_t
>> > > > > >>>>> 64-bit by default
>> > > > > >>>>>
>> > > > > >>>>> Hello,
>> > > > > >>>>>
>> > > > > >>>>> I tried for AVR128DA28 - tools/configure.sh -l breadxavr:nsh
>> > > > > >>>>>
>> > > > > >>>>> Default setting (CONFIG_SYSTEM_TIME64 not set):
>> > > > > >>>>>
>> > > > > >>>>> Register: nsh
>> > > > > >>>>> Register: sh
>> > > > > >>>>> LD: nuttx
>> > > > > >>>>> Memory region Used Size Region Size %age Used
>> > > > > >>>>> flash: 50457 B 128 KB 38.50%
>> > > > > >>>>> sram: 636 B 16 KB 3.88%
>> > > > > >>>>> eeprom: 0 B 512 B 0.00%
>> > > > > >>>>> rodata: 592 B 4 KB 14.45%
>> > > > > >>>>> CP: nuttx.hex
>> > > > > >>>>> CP: nuttx.asm
>> > > > > >>>>>
>> > > > > >>>>> With CONFIG_SYSTEM_TIME64 set:
>> > > > > >>>>>
>> > > > > >>>>> Register: nsh
>> > > > > >>>>> Register: sh
>> > > > > >>>>> LD: nuttx
>> > > > > >>>>> Memory region Used Size Region Size %age Used
>> > > > > >>>>> flash: 52307 B 128 KB 39.91%
>> > > > > >>>>> sram: 668 B 16 KB 4.08%
>> > > > > >>>>> eeprom: 0 B 512 B 0.00%
>> > > > > >>>>> rodata: 592 B 4 KB 14.45%
>> > > > > >>>>> CP: nuttx.hex
>> > > > > >>>>> CP: nuttx.asm
>> > > > > >>>>>
>> > > > > >>>>> 2kB seems quite noticeable for a chip with 128kB flash.
>> Runtime
>> > > costs
>> > > > > >>>>> are somewhat hard to assess, the time_t type is used in
>> > internal
>> > > > > >>>>> timekeeping but the code was developed with tickless mode of
>> > > > > operation
>> > > > > >>>>> in mind so the timekeeping functions should not run that
>> often
>> > > unless
>> > > > > >>>>> the system gets busy with processing lots of timed events.
>> > > > > >>>>>
>> > > > > >>>>> As for the benefits - the real question is how many devices
>> > > (designed
>> > > > > >>>>> with a chip like this one) need to know real time and
>> therefore
>> > > > > handle
>> > > > > >>>>> year 2038. (None of my use cases need that.)
>> > > > > >>>>>
>> > > > > >>>>> So for small systems, having the option to configure NuttX
>> so
>> > > time_t
>> > > > > is
>> > > > > >>>>> 32 bit wide would certainly be beneficial. Making the
>> > > SYSTEM_TIME64
>> > > > > >>>>> option default to DEFAULT_SMALL would be nice but it's not
>> > > > > POSIX-correct
>> > > > > >>>>> so I don't think that's gonna fly.
>> > > > > >>>>>
>> > > > >
>> > > > >
>> > >
>> >
>>
>
