date:20241105




On 11/5/2024 3:43 AM, Takashi Yamamoto wrote:

i guess it's possible to implement it similarly to what we do for errno.

eg.
#  define environ (*get_environ_ptr_ptr())

although it still isn't quite posix compatible, it might be good
enough for many applications.
d18be28c82a2a6d82115c8af19d/shell/ash.c#L10574


There would be a complexity in this:  The environ is shared by all 
threads in a task group.  Hence, the environ lies in the protected, 
kernel task group structure.  That structure  is not accessible to user 
code in PROTECTED or KERNEL build modes.


So in order to do what you want, you would need to (1) redesign how 
common data is stored so that the environ is accessible from user space 
or (2) marshal the environ to other accessible memory when it is 
requested.  Neither are simple and the latter would have synchronization 
issues.


I think there is an open issue about the POSIX compatibility of the 
environment.

Re: POSIX environ variable

2024-11-05 Thread Ville Juven

For direct user level access, one option is to move tg_envp to TLS / 
task_info_s. This way the user could access the memory without boring a hole 
into the kernel.

In KERNEL mode this issue is very simple; every process has its own instance of 
environ** anyway so there is no need to use TLS or anything.

However, in FLAT mode having a per-process instance of environ** is going to be 
more difficult. You could -in theory- make a reference to the TLS area and use 
it like that. This reference would have to be updated on every context switch. 
Whether or not this is even possible to implement in a multicore (SMP) system 
is beyond me, the reference would need to be duplicated on every CPU and the 
user would need to be able to query which CPU it is running on.

You could combine Takashi's idea with TLS to achieve a "good enough" solution.

-Ville

From: Gregory Nutt 
Sent: Tuesday, November 5, 2024 2:39 PM
To: dev@nuttx.apache.org 
Subject: Re: POSIX environ variable

On 11/5/2024 3:43 AM, Takashi Yamamoto wrote:
> i guess it's possible to implement it similarly to what we do for errno.
>
> eg.
> #  define environ (*get_environ_ptr_ptr())
>
> although it still isn't quite posix compatible, it might be good
> enough for many applications.
> d18be28c82a2a6d82115c8af19d/shell/ash.c#L10574

There would be a complexity in this:  The environ is shared by all
threads in a task group.  Hence, the environ lies in the protected,
kernel task group structure.  That structure  is not accessible to user
code in PROTECTED or KERNEL build modes.

So in order to do what you want, you would need to (1) redesign how
common data is stored so that the environ is accessible from user space
or (2) marshal the environ to other accessible memory when it is
requested.  Neither are simple and the latter would have synchronization
issues.

I think there is an open issue about the POSIX compatibility of the
environment.

Re: POSIX environ variable


On 11/5/2024 6:57 AM, Ville Juven wrote:

For direct user level access, one option is to move tg_envp to TLS / 
task_info_s. This way the user could access the memory without boring a hole 
into the kernel.


The same environ is used by all threads in a task group/process. If one 
thread changes the environment, it effects all threads in group/process


It could be possible to put the environment in the TLS of the main 
thread and other could the access indirectly through their TLS references.



In KERNEL mode this issue is very simple; every process has its own instance of 
environ** anyway so there is no need to use TLS or anything.
Yep.  Lots of things are simpler in true kernel mode.  Just like the 
designers of Unix intended!  NuttX is more complex and requires some 
trade-offs.

However, in FLAT mode having a per-process instance of environ** is going to be 
more difficult. You could -in theory- make a reference to the TLS area and use 
it like that. This reference would have to be updated on every context switch. 
Whether or not this is even possible to implement in a multicore (SMP) system 
is beyond me, the reference would need to be duplicated on every CPU and the 
user would need to be able to query which CPU it is running on.
I think this is already done for a few group common things.  But I don't 
remember.  I haven't been that active for awhile (I got too old!  74 in 
three days).

Re: Change time_t to signed type

2024-11-05 Thread michal . lyszczek

On 2024-11-05 08:13:19, Simon Filgis wrote:
> Seems like a dump question, but why time needs to be signed?
It doesn't. But you may want to go backwards to show date before 1970. This is
usually implemented by using negative time.

-- 
.-.---.--.-.
| Michal Lyszczek | Embedded C, Linux |   Company Address|  .-. opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|  supporter |
| https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\  & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/) programer |
`--^--^--^-'


signature.asc
Description: PGP signature

Re: Change time_t to signed type

2024-11-05 Thread Simon Filgis

Thanks. So there are use cases for negative numbers of time. Interesting.


--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 


On Tue, Nov 5, 2024 at 11:03 AM  wrote:

> On 2024-11-05 08:13:19, Simon Filgis wrote:
> > Seems like a dump question, but why time needs to be signed?
> It doesn't. But you may want to go backwards to show date before 1970.
> This is
> usually implemented by using negative time.
>
> --
>
> .-.---.--.-.
> | Michal Lyszczek | Embedded C, Linux |   Company Address|  .-.
> opensource |
> | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|
> supporter |
> | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\
> & |
> | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/)
> programer |
>
> `--^--^--^-'
>

Re: POSIX environ variable

2024-11-05 Thread Ville Juven

>I think this is already done for a few group common things.

This is what task_info_s in TLS does, it is the "process common information" 
field. So putting env there would work for the whole process.

The name "TLS" here is a bit confusing, obviously the env data is shared by the 
process and all its threads.


-Ville

From: Gregory Nutt 
Sent: Tuesday, November 5, 2024 3:35 PM
To: dev@nuttx.apache.org 
Subject: Re: POSIX environ variable

On 11/5/2024 6:57 AM, Ville Juven wrote:
> For direct user level access, one option is to move tg_envp to TLS / 
> task_info_s. This way the user could access the memory without boring a hole 
> into the kernel.

The same environ is used by all threads in a task group/process. If one
thread changes the environment, it effects all threads in group/process

It could be possible to put the environment in the TLS of the main
thread and other could the access indirectly through their TLS references.

> In KERNEL mode this issue is very simple; every process has its own instance 
> of environ** anyway so there is no need to use TLS or anything.
Yep.  Lots of things are simpler in true kernel mode.  Just like the
designers of Unix intended!  NuttX is more complex and requires some
trade-offs.
> However, in FLAT mode having a per-process instance of environ** is going to 
> be more difficult. You could -in theory- make a reference to the TLS area and 
> use it like that. This reference would have to be updated on every context 
> switch. Whether or not this is even possible to implement in a multicore 
> (SMP) system is beyond me, the reference would need to be duplicated on every 
> CPU and the user would need to be able to query which CPU it is running on.
I think this is already done for a few group common things.  But I don't
remember.  I haven't been that active for awhile (I got too old!  74 in
three days).

Sound Open Firmware - Liam Girdwood, Intel

https://www.youtube.com/watch?v=vwDoEumA1Mo

NuttX mentioned :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: Change time_t to signed type

2024-11-05 Thread Alin Jerpelea

I think that we should focus on fixing the 2038 issue and maintain
compatibility with the existing code.
We should not postpone the fix until later or break the compatibility for
our users

Best regards
Alin

On Tue, Nov 5, 2024 at 8:08 AM Guiding Li  wrote:

> Hi Greg,
>
> Rather than reducing the size of time_t and joining the systems with the
> year 2038 problem, I think that a better solution is to solve the problem
> permanently.
> ---
> Agree with your last part, we should find a better way to ‘ put things
> right once and for all ’, and not use the unsigned int to *postpone the
> occurrence of things*
>
> So, Someone thinks time_t will overflow when set int32_t, should think
> his code should open TIME64 or handle the overflow himself.
>
>
> Gregory Nutt  于2024年11月5日周二 05:24写道：
>
>> You are right, there is no requirement by any standard that time_t be
>> signed.  Lots of discussion on Wikipedia:
>> https://en.wikipedia.org/wiki/Unix_time
>>
>> The only motivation for making time_t signed is for compatibility with
>> GLIBC.  For example, some very old Unix systems permit negative time values
>> for times before the epoch.  The penalty for this compatibility with a
>> non-standard different is a loss of range and the year 2038 problem.
>>
>> This is the year 2038 problem:
>> https://en.wikipedia.org/wiki/Year_2038_problem
>>
>> Any product released after this change will fail in the field in 2038.
>> That could be an issue for a few systems with very long lives.  Most OSs
>> have already fixed the year 2038 problem... but in different ways.  See the
>> Year_2038_Problem for solutions that are fielded now (one fix, ironically,
>> is to make time_t unsigned).
>>
>> Rather than reducing the size of time_t and joining the systems with the
>> year 2038 problem, I think that a better solution is to solve the problem
>> permanently.
>>
>>
>> On 11/4/2024 2:50 PM, b...@the-wanderers.org wrote:
>>
>> Hi Guiding,
>>
>> Both your reference and the Open Group specification documents both only
>> state that POSIX requires time_t to be an integer type, not a signed
>> integer.
>>
>> The Open Group Base Specifications Issue 8
>> 
>> pubs.opengroup.org 
>> [image: favicon.ico] 
>> 
>>
>> GNU libc additionally mandates a signed integer but notes this is a GNU
>> extension and not a POSIX requirement.
>>
>> The 2024 edition of POSIX has introduced a requirement for time_t to be
>> 64 bits. As has already been noted this is itself a substantial change.
>>
>>   Byron
>>
>> On 4 Nov 2024, at 11:33 PM, Guiding Li 
>>  wrote:
>>
>> Hi all:
>>
>> We decide change 'time_t' from unsigned type to signed type in PR:
>> https://github.com/apache/nuttx/pull/14460
>>
>> Because when compile some POSIX library, there always be a warning on
>> comparison
>> between time_t and zero.
>>
>> For example:
>>
>> The following code will generate warnings:
>> auto now = time(nullptr);
>> auto last_active_time = GetEventService(self->ctx_)->getActiveTime(); if
>> (last_active_time + 60 * 1000 / 1000 <= now) {
>>
>> src/ams/../controller/controller_timer.h: In lambda function:
>> src/ams/../controller/controller_timer.h:117:57: warning: comparison of
>> integer expressions of different signedness: 'long long int' and 'long
>> long
>> unsigned int' [-Wsign-compare]
>> 117 | if (last_active_time + 60 * 1000 / 1000 <= now) {
>>
>>
>> And we can find an reference on the official website:
>>
>> https://www.gnu.org/software/libc/manual/html_node/Time-Types.html
>>
>> On POSIX-conformant systems, time_t is an integer type.
>>
>>
>> The comparation of the merits and shortcomings:
>>
>> Advantage:
>> For the most POSIX applications they assume the time_t as signed and do
>> compare with 0.
>> The code will become more compatible after this modification.
>>
>> Disadvantage:
>> None.
>>
>>
>> If there is any question about this, please let me know.
>> Thanks,
>> Guiding
>>
>>

POSIX environ variable

2024-11-05 Thread Marco Casaroli

Hello,

I am sorry if this was already discussed before. I could not find
concrete information in the documentation or the mailing list history.

According to POSIX specifications [1]:

> The array is pointed to by the external variable environ, which is defined as:
>
> extern char **environ;

But in NuttX, it is defined differently [2], when
CONFIG_DISABLE_ENVIRON is not set, like:

> #  define environ get_environ_ptr()

Which calls a function [3] and gets its result. This gives problems if
the apps try to do things like:

> environ = ...;

Which is, in fact, fairly common [4, 5, 6].

So I have two questions:

1. What is the cleanest way to work around the environment update
these apps are trying to do? What are the changes I should make to the
app code so that it can correctly handle setting the environment?

2. Is there any way we can update NuttX to actually define environ
like POSIX specifies, so that we can handle these apps without
modifications?

Thank you very much.

BR

// Marco Casaroli

[1] 
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap08.html
[2] 
https://github.com/apache/nuttx/blob/0fad2ee73f5431cbe34cc02253909f290938cd12/include/stdlib.h#L70
[3] 
https://github.com/apache/nuttx/blob/0fad2ee73f5431cbe34cc02253909f290938cd12/sched/environ/env_getenvironptr.c#L57
[4] 
https://github.com/landley/toybox/blob/c47184b389d5bf97135afbf55aa4a41bc29812eb/lib/env.c#L29
[5] 
https://github.com/landley/toybox/blob/c47184b389d5bf97135afbf55aa4a41bc29812eb/toys/pending/sh.c#L1379
[6] 
https://github.com/mirror/busybox/blob/371fe9f71d445d18be28c82a2a6d82115c8af19d/shell/ash.c#L10574

Re: POSIX environ variable

i guess it's possible to implement it similarly to what we do for errno.

eg.
#  define environ (*get_environ_ptr_ptr())

although it still isn't quite posix compatible, it might be good
enough for many applications.

whatever approach we take, it probably requires some extra validations
in the kernel. (ie. untrust the pointer as it might be user-given
now.)

On Tue, Nov 5, 2024 at 5:22 PM Marco Casaroli
 wrote:
>
> Hello,
>
> I am sorry if this was already discussed before. I could not find
> concrete information in the documentation or the mailing list history.
>
> According to POSIX specifications [1]:
>
> > The array is pointed to by the external variable environ, which is defined 
> > as:
> >
> > extern char **environ;
>
> But in NuttX, it is defined differently [2], when
> CONFIG_DISABLE_ENVIRON is not set, like:
>
> > #  define environ get_environ_ptr()
>
> Which calls a function [3] and gets its result. This gives problems if
> the apps try to do things like:
>
> > environ = ...;
>
> Which is, in fact, fairly common [4, 5, 6].
>
> So I have two questions:
>
> 1. What is the cleanest way to work around the environment update
> these apps are trying to do? What are the changes I should make to the
> app code so that it can correctly handle setting the environment?
>
> 2. Is there any way we can update NuttX to actually define environ
> like POSIX specifies, so that we can handle these apps without
> modifications?
>
> Thank you very much.
>
> BR
>
> // Marco Casaroli
>
> [1] 
> https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap08.html
> [2] 
> https://github.com/apache/nuttx/blob/0fad2ee73f5431cbe34cc02253909f290938cd12/include/stdlib.h#L70
> [3] 
> https://github.com/apache/nuttx/blob/0fad2ee73f5431cbe34cc02253909f290938cd12/sched/environ/env_getenvironptr.c#L57
> [4] 
> https://github.com/landley/toybox/blob/c47184b389d5bf97135afbf55aa4a41bc29812eb/lib/env.c#L29
> [5] 
> https://github.com/landley/toybox/blob/c47184b389d5bf97135afbf55aa4a41bc29812eb/toys/pending/sh.c#L1379
> [6] 
> https://github.com/mirror/busybox/blob/371fe9f71d445d18be28c82a2a6d82115c8af19d/shell/ash.c#L10574

Re: Change time_t to signed type

2024-11-05 Thread Sebastien Lorquet

Hi,

the problem you demonstrate exists in the code below, but it's a coding
bug. it's missing the signed cast to compare wrapping variables.

It is well known that to compare counters that can rollover/wrap, the
subtraction to check if the timer has elapsed *must* be using signed
arithmetic.

The usual case is hardware timers, which are most always considered
unsigned. This is not just a Nuttx problem.

https://stackoverflow.com/questions/3095623/how-to-deal-with-a-wrapping-counter-in-embedded-c

This cast is required, at least as an explicit acknowledge that the
wrapping behaviour has been taken into consideration. I add comments
every time I have to do this now. Of course I have been bitten by this
bug too, in a bare metal PIC18 project IIRC.

So, forcing counters to be signed just to avoid a well known embedded
development pitfall makes little sense to me.

The ability to use negative timestamps (even if probably not really
useful but you never know) is a much more valid reason.

I still do not advise changing the signedness of time_t, the reason is
to prevent unpredictability in projects *we are not even aware of*

But doing so on the 64-bit version of time_t is less critical because it
avoids the y2038 problem.

Anyway, changing the signedness of such an important variable should
have to be explicitly acknowledged by developers.

Maybe with a mechanism similar to debian updates that displays a text
with important warnings from updated packages. That could be triggered
by make.

Or maybe a kconfig option, something like that now must be checked
before code compiles again:

#ifndef CONFIG_DEVELOPER_ACKNOWLEDGED_TIME_SIGNEDNESS_CHANGE
#error "Signedness of 64-bit time_t has changed, you may need to fix
your code to take this change into account. Please do so, then select
option CONFIG_DEVELOPER_ACKNOWLEDGED_TIME_SIGNEDNESS_CHANGE in kconfig
(indicate where to find it) to acknowledge this fact."

#endif

We should make sure that every developer will be aware of it. Releases
notes are not enough.

Thank you everyone for discussing these issues.

Sebastien

On 11/5/24 19:50, Xiang Xiao wrote:

Here is a simple example demonstrate that why the signed/unsigned is very
important for time_t:
one function records a timestamp:
time_t t1 = time(NULL);

another function records a second timestamp:
time_t t2 = time(NULL);

and check which one is early by:
if (t2 - t1 < 0)
{
printf("t2 is early than t1\n");
}

But If time_t is an unsigned integer, the comparison can never become true:
https://devblogs.microsoft.com/oldnewthing/20140122-00/?p=2013
Since most POSIX OS map time_t to a signed type, the above code(appears in
many code bases) works very well until they meet NuttX.
Actually, we hit the problem before which takes our engineer to debug this
problem and find the root cause by several days.
That's why I prefer to follow other OS practice if the spec is ambiguous
like time_t.
If 32bit signed time_t is unacceptable due to the 2038 problem, at least
64bit time_t should change to the signed integer.
Otherwise, you will take time to debug the above problem soon or later.

On Tue, Nov 5, 2024 at 6:05 PM Simon Filgis
wrote:

Thanks. So there are use cases for negative numbers of time. Interesting.

--
Hard- and Softwaredevelopment Consultant

Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015

On Tue, Nov 5, 2024 at 11:03 AM wrote:

On 2024-11-05 08:13:19, Simon Filgis wrote:

Seems like a dump question, but why time needs to be signed?

It doesn't. But you may want to go backwards to show date before 1970.
This is
usually implemented by using negative time.

.-.---.--.-.

`--^--^--^-'

Re: Change time_t to signed type

Yet another (probably silly) idea: how about giving choice if 32
and/or 64 bit time is signed or unsigned in the kconfig and the
summary warning at the end of build? This way developers could select
what they want to use?

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: Change time_t to signed type

2024-11-05 Thread Xiang Xiao

Here is a simple example demonstrate that why the signed/unsigned is very
important for time_t:
one function records a timestamp:
time_t t1 = time(NULL);

another function records a second timestamp:
time_t t2 = time(NULL);

and check which one is early by:
if (t2 - t1 < 0)
  {
printf("t2 is early than t1\n");
  }

But If time_t is an unsigned integer, the comparison can never become true:
https://devblogs.microsoft.com/oldnewthing/20140122-00/?p=2013
Since most POSIX OS map time_t to a signed type, the above code(appears in
many code bases) works very well until they meet NuttX.
Actually, we hit the problem before which takes our engineer to debug this
problem and find the root cause by several days.
That's why I prefer to follow other OS practice if the spec is ambiguous
like time_t.
If 32bit signed time_t is unacceptable due to the 2038 problem, at least
64bit time_t should change to the signed integer.
Otherwise, you will take time to debug the above problem soon or later.

On Tue, Nov 5, 2024 at 6:05 PM Simon Filgis 
wrote:

> Thanks. So there are use cases for negative numbers of time. Interesting.
>
>
> --
> Hard- and Softwaredevelopment Consultant
>
> Geschäftsführung: Simon Filgis
> USt-IdNr.: DE305343278
> ISO9001:2015 
>
>
> On Tue, Nov 5, 2024 at 11:03 AM  wrote:
>
> > On 2024-11-05 08:13:19, Simon Filgis wrote:
> > > Seems like a dump question, but why time needs to be signed?
> > It doesn't. But you may want to go backwards to show date before 1970.
> > This is
> > usually implemented by using negative time.
> >
> > --
> >
> >
> .-.---.--.-.
> > | Michal Lyszczek | Embedded C, Linux |   Company Address|  .-.
> > opensource |
> > | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|
> > supporter |
> > | https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\
> > & |
> > | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/)
> > programer |
> >
> >
> `--^--^--^-'
> >
>

Re: Change time_t to signed type

2024-11-05 Thread Nathan Hartman

On Tue, Nov 5, 2024 at 3:07 PM Tomek CEDRO  wrote:
>
> Yet another (probably silly) idea: how about giving choice if 32
> and/or 64 bit time is signed or unsigned in the kconfig and the
> summary warning at the end of build? This way developers could select
> what they want to use?

This could give developers complete control, if they want something
different than what we decide. But, which would be default? On 32-bit
and 64-bit archs, I suggest to use the 64 bit signed type as default.
On 8-bit and 16-bit archs, I suggest to use 32-bit unsigned as
default. Developers who want something different can choose whichever
combo they want.

The ---help--- text for 32-bit signed should contain a WARNING: Your
product will have a year 2038 problem if you choose this option!

Also, I think we had a Kconfig in the past to choose the epoch. Is
this still possible? Perhaps developers who never expect to deal with
dates before the product release (e.g., 2024) could set the epoch to
01-01-2024 and use a 32-bit type? Various functions in the OS might
have to be updated to accommodate such a Kconfig.

Cheers,
Nathan

Re: Change time_t to signed type

On Tue, Nov 5, 2024 at 9:46 PM Nathan Hartman  wrote:
>
> On Tue, Nov 5, 2024 at 3:07 PM Tomek CEDRO  wrote:
> >
> > Yet another (probably silly) idea: how about giving choice if 32
> > and/or 64 bit time is signed or unsigned in the kconfig and the
> > summary warning at the end of build? This way developers could select
> > what they want to use?
>
> This could give developers complete control, if they want something
> different than what we decide. But, which would be default? On 32-bit
> and 64-bit archs, I suggest to use the 64 bit signed type as default.
> On 8-bit and 16-bit archs, I suggest to use 32-bit unsigned as
> default. Developers who want something different can choose whichever
> combo they want.
>
> The ---help--- text for 32-bit signed should contain a WARNING: Your
> product will have a year 2038 problem if you choose this option!
>
> Also, I think we had a Kconfig in the past to choose the epoch. Is
> this still possible? Perhaps developers who never expect to deal with
> dates before the product release (e.g., 2024) could set the epoch to
> 01-01-2024 and use a 32-bit type? Various functions in the OS might
> have to be updated to accommodate such a Kconfig.

Okay so summing up all the problems and solutions this may be common
denominator:
1. Kconfig selectable `uint32_t time_t` as default on <= 32-bit
targets, can be changed to `int32_t time_t`.
2. Kconfig selectable `int64_t time_t` as default on 64-bit targets,
can be changed to `uint64_t time_t`.
3. Casting to (int) on time comparison + patching code / upstreams.

There is an inconsistency, but there is a choice.

Nathan you mentioned the 8-bit and 16-bit platforms to use 32-bit
unsigned. That would imply "virtual" type not natively supported by
platform. Do you know what is the penalty for using such types? Is it
safe? Does it work on all compilers? Is it slow? if no, then maybe we
could also use int64_t on 32-bit platforms? :-P

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: Change time_t to signed type

> I don't think, personally, that any of this is reason enough to worry about
> it. Using an int64_t for time_t is IMO a perfectly reasonable default for
> 32-bit and up targets. and possibly for all targets. Offering a kconfig
> option to support 32-bit (signed or unsigned) time_t offers an easy
> work-around should anyone find that the couple of percent increase in code
> size and execution time causes their project to fail - or if anyone is in
> the unfortunate situation where they depend on code that's made assumptions
> about size or signedness.

ideally, we should use int64_t for all targets unconditionally, IMO.
however, in practice, 64-bit integers don't seem available for some of
our targets. (ez80, z8, z16)
maybe someone can add 64-bit integer support to their toolchains. but
i suppose we don't want to wait for it to happen.

Re: Change time_t to signed type



On 11/5/2024 8:35 PM, Byron Ellacott wrote:

Hi Takashi,


ideally, we should use int64_t for all targets unconditionally, IMO.
however, in practice, 64-bit integers don't seem available for some of
our targets. (ez80, z8, z16)
maybe someone can add 64-bit integer support to their toolchains. but
i suppose we don't want to wait for it to happen.


No, you wouldn't want to wait for that, it's highly unlikely that ZDS-II
will ever get a substantial update and the community compiler options
all have their own issues and limitations. Much as I'd love to say that the
unofficial (e)Z80 clang target solves all problems, it's a few major
versions behind llvm now and my ELF patch for it is likewise not current -
it'd be a bit of effort for someone to actually use this option.


ZDS-II is no longer an option anyway.  Changes in function prototypes 
and definitions of data types has made ZDS-II unusable (and that is 
really probably OK).  Recent eZ80 builds have used an experimental 
version of GCC.


zNEO (z16) and z8 are no long supportable without ZDS-II.  Other z80s 
don't work with common small compilers like SDCC anymore.

Re: Change time_t to signed type

2024-11-05 Thread Byron Ellacott

Hi,

On Wed, Nov 6, 2024 at 7:13 AM Tomek CEDRO  wrote:

>
> Nathan you mentioned the 8-bit and 16-bit platforms to use 32-bit
> unsigned. That would imply "virtual" type not natively supported by
> platform. Do you know what is the penalty for using such types? Is it
> safe? Does it work on all compilers? Is it slow? if no, then maybe we
> could also use int64_t on 32-bit platforms? :-P
>

It's safe, widely supported by compilers, and "slow" in that multiple
instructions will be used to support the operation instead of just one, and
multiple registers will carry the value instead of just one.

There's a penalty for it, but it's not really straightforward. Considering
a Cortex-M0 based processor, arithmetic operations on 64-bit values will
usually just be two or three instructions instead of one (eg, UMULL+MLA for
a 64-bit multiply for one operand 32-bit or less, or UMULL+MLA+MLA for two
64-bit operands). The real penalty kicks in for function arguments, though.
The common ARM calling convention reserves only four 32-bit registers for
function arguments, so passing three 32-bit arguments is entirely in
registers but passing three 64-bit arguments will put two 32-bit words on
the stack. Similarly, only registers r0-r3 and r12 can be used freely while
r4-r11 must have their values preserved. A function doing almost anything
with a 64-bit value is likely to use more than five registers and will need
to push and pop values.

You can see the difference in compiled output for a 32-bit function doing a
* b + c and a 64-bit function doing the same here:
https://godbolt.org/z/8bKj6an4z

As it happens the ARMv7 instruction set is designed to handle 64-bit values
with a minimum of fuss. For giggles try changing the compiler used by
godbolt to AVR GCC, where 64-bit multiplication is implemented as a libcall
and the ABI requires that 18 or so registers get preserved by the callee if
their contents can't be guaranteed to be non-volatile.

I don't think, personally, that any of this is reason enough to worry about
it. Using an int64_t for time_t is IMO a perfectly reasonable default for
32-bit and up targets. and possibly for all targets. Offering a kconfig
option to support 32-bit (signed or unsigned) time_t offers an easy
work-around should anyone find that the couple of percent increase in code
size and execution time causes their project to fail - or if anyone is in
the unfortunate situation where they depend on code that's made assumptions
about size or signedness.

-- 
Byron

Re: Change time_t to signed type

2024-11-05 Thread Xiang Xiao

Yes, I prefer 64bit time_t to map to int64_t unconditionally, since 64bit
time_t is seldom selected by NuttX supported boards now, and no 2038
problem.
For 32bit time_t, we can add a Kconfig to let the user select
signed/unsigned and default to unsigned for compatibility reasons.

On Wed, Nov 6, 2024 at 9:40 AM Takashi Yamamoto
 wrote:

> > I don't think, personally, that any of this is reason enough to worry
> about
> > it. Using an int64_t for time_t is IMO a perfectly reasonable default for
> > 32-bit and up targets. and possibly for all targets. Offering a kconfig
> > option to support 32-bit (signed or unsigned) time_t offers an easy
> > work-around should anyone find that the couple of percent increase in
> code
> > size and execution time causes their project to fail - or if anyone is in
> > the unfortunate situation where they depend on code that's made
> assumptions
> > about size or signedness.
>
> ideally, we should use int64_t for all targets unconditionally, IMO.
> however, in practice, 64-bit integers don't seem available for some of
> our targets. (ez80, z8, z16)
> maybe someone can add 64-bit integer support to their toolchains. but
> i suppose we don't want to wait for it to happen.
>

Re: Change time_t to signed type

Is it possible to create just a simple Kconfig list of choices like this?

int64_t time_t <-- default
int32_t time_t
uint32_t time_t

This should cover most use cases and give developer a choice on
smaller / older platforms right?

There will be no inconsistencies autodetections variants (whatever
hidden actions) nor dependencies on target platforms / toolchains just
a manual conscious simple choice by the developer in one single place
:-)

I guess there is no sense to add 16-bit types to the list?

And we will have one single place to add int128_t when RV128 shows up :-)

Would that meet everyone needs and expectations? Plus maybe some
visible initial configuration message what type is used :-)

Tomek




On Wed, Nov 6, 2024 at 3:18 AM Xiang Xiao  wrote:
>
> Yes, I prefer 64bit time_t to map to int64_t unconditionally, since 64bit
> time_t is seldom selected by NuttX supported boards now, and no 2038
> problem.
> For 32bit time_t, we can add a Kconfig to let the user select
> signed/unsigned and default to unsigned for compatibility reasons.
>
> On Wed, Nov 6, 2024 at 9:40 AM Takashi Yamamoto
>  wrote:
>
> > > I don't think, personally, that any of this is reason enough to worry
> > about
> > > it. Using an int64_t for time_t is IMO a perfectly reasonable default for
> > > 32-bit and up targets. and possibly for all targets. Offering a kconfig
> > > option to support 32-bit (signed or unsigned) time_t offers an easy
> > > work-around should anyone find that the couple of percent increase in
> > code
> > > size and execution time causes their project to fail - or if anyone is in
> > > the unfortunate situation where they depend on code that's made
> > assumptions
> > > about size or signedness.
> >
> > ideally, we should use int64_t for all targets unconditionally, IMO.
> > however, in practice, 64-bit integers don't seem available for some of
> > our targets. (ez80, z8, z16)
> > maybe someone can add 64-bit integer support to their toolchains. but
> > i suppose we don't want to wait for it to happen.
> >



-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: Change time_t to signed type

2024-11-05 Thread Byron Ellacott

Hi Takashi,

>
> ideally, we should use int64_t for all targets unconditionally, IMO.
> however, in practice, 64-bit integers don't seem available for some of
> our targets. (ez80, z8, z16)
> maybe someone can add 64-bit integer support to their toolchains. but
> i suppose we don't want to wait for it to happen.
>

No, you wouldn't want to wait for that, it's highly unlikely that ZDS-II
will ever get a substantial update and the community compiler options
all have their own issues and limitations. Much as I'd love to say that the
unofficial (e)Z80 clang target solves all problems, it's a few major
versions behind llvm now and my ELF patch for it is likewise not current -
it'd be a bit of effort for someone to actually use this option.

-- 
bje

Re: Change time_t to signed type

On Wed, Nov 6, 2024 at 11:47 AM Gregory Nutt  wrote:
>
>
> On 11/5/2024 8:35 PM, Byron Ellacott wrote:
> > Hi Takashi,
> >
> >> ideally, we should use int64_t for all targets unconditionally, IMO.
> >> however, in practice, 64-bit integers don't seem available for some of
> >> our targets. (ez80, z8, z16)
> >> maybe someone can add 64-bit integer support to their toolchains. but
> >> i suppose we don't want to wait for it to happen.
> >>
> > No, you wouldn't want to wait for that, it's highly unlikely that ZDS-II
> > will ever get a substantial update and the community compiler options
> > all have their own issues and limitations. Much as I'd love to say that the
> > unofficial (e)Z80 clang target solves all problems, it's a few major
> > versions behind llvm now and my ELF patch for it is likewise not current -
> > it'd be a bit of effort for someone to actually use this option.
>
> ZDS-II is no longer an option anyway.  Changes in function prototypes
> and definitions of data types has made ZDS-II unusable (and that is
> really probably OK).  Recent eZ80 builds have used an experimental
> version of GCC.

does that GCC have int64_t?

> zNEO (z16) and z8 are no long supportable without ZDS-II.  Other z80s
> don't work with common small compilers like SDCC anymore.

i guess people who care these targets should express what they want
wrt this time_t discussion.
eg.
* drop 32-bit time_t and leave these targets broken
* keep uint32_t time_t as a user-visible option
* make it depend on CONFIG_HAVE_LONG_LONG or such
* something else?

Re: Change time_t to signed type




On 11/5/2024 9:18 PM, Takashi Yamamoto wrote:

does that GCC have int64_t?

Yes, according to include/nuttx/compiler.h.



zNEO (z16) and z8 are no long supportable without ZDS-II.  Other z80s
don't work with common small compilers like SDCC anymore.

i guess people who care these targets should express what they want
wrt this time_t discussion.
eg.
* drop 32-bit time_t and leave these targets broken
* keep uint32_t time_t as a user-visible option
* make it depend on CONFIG_HAVE_LONG_LONG or such
* something else?


There is no usable toolchain for these CPUs.

Re: Change time_t to signed type