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.
