Yep, I think this is the best compromise! Currently we are still able to run on 8-bit, the problem is that moving to time_t 64-bit we are paying a cost too high for small MCUs with less than 32KB Flash (and we don't know when the performance degrades for them).
I think a simpler alternative is to let NuttX to run with 32-bit time_t for users that want to use NuttX for some specific usage (like hobbyist application) but agree that they don't need to have a 100% POSIX Compliant solution. We know that NuttX is very useful even on small MCUs with time_t32-bit BR, Alan On Mon, May 4, 2026 at 10:42 AM Tomek CEDRO <[email protected]> wrote: > All Inviolables are equally important, but not always easy to > accomplish, like in this case. > > We are approaching the "end of times" as seen by 32-bit values. These > are/were also non-native to 8/16-bit platforms. > > The biggest problem here is do we want to allow non-posix smaller > timers? There were voices to allow 32-bit time in our last discussion > [2]. But this has disadvantages and risks too (i.e. limits, overflows, > non-atomic access). > > Looks like switching to POSIX 64-bit time as default, then working out > best common alternative solution optimized for smaller 8/16/32-bit > platforms is the way to go? > > [1] https://github.com/apache/nuttx/pull/18840 > [2] https://www.mail-archive.com/[email protected]/msg12060.html > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > On Mon, May 4, 2026 at 1:17 PM raiden00pl <[email protected]> wrote: > > > > " ## Strict POSIX compliance" is the first point in the INVIOLABLES.md, > > so I assume this is the main purpose of NuttX's existence. The main > > priority > > is POSIX, everything else is an addition - that's how I understand it. > > > > pon., 4 maj 2026 o 15:05 Gregory Nutt <[email protected]> napisał(a): > > > > > > > > > > > > > > ________________________________ > > > *Hobbyists are valued users of the OS including retro computing > hobbyists > > > and DIY “Maker” hobbyists.* > > > - > > > > > > *Supported toolchains: GCC, Clang, SDCC, ZiLOG ZDS-II (c89), IAR. > Others?* > > > I think we all agree that time_t 64-bit is very important and should > be the > > > default, but we cannot leave behind old MCUs and users because of it. > (that > > > is what "All Users Matter" means) > > > > > > But what if this is conflicts with > > > > > > ## Strict POSIX compliance > > > > > > Support for SDCC and ZDS where not removed, just broken irreparably. > > > Those compilers (and other small system compilers) will not support > POSIX > > > interface definitions. One problem is that you cannot pass structures > or > > > even enumeration values as parameters. There used to be special case > > > definitions (not so different from what we are talking about here) to > make > > > the OS interfaces non-POSIX so that these tools could build NuttX. The > > > change was very invasive and turned me into the believer in very strict > > > POSIX interface definitions. > > > > > > This case it was a painful trade-off. > > > > > > As a point of clarification... those changes were made PRIOR to the > > > INVIOLABLES.md. The starting point really should be sometime after > that. > > > From the standpoint of the INVIOLABLES.md, those architectures and > tools > > > were never supported. > > > > > > Otherwise we can change our motto to Linus Torvalds' phrase: "Doers > > > decide!" (probably he got it from "Parable of the Sower" book) > > > > > > So let me disagree with my colleague raiden00: "NuttX is for All > Users" and > > > "All Users Matter" :-) > > > > > > BR, > > > > > > Alan > > > > > > On Mon, May 4, 2026 at 9:07 AM Nathan Hartman < > [email protected]> > > > 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. > > > > > > > > > > > > > > > > > > >
