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. > > >
