You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Petro Karashchenko <pe...@gmail.com> on 2022/01/07 22:28:49 UTC
Move to C99 for common code
Hello team,
Recently I mr. @Xiang Xiao <xi...@gmail.com> had a discussion in
one of the PR's related to C89 code compliance. Particularly related to
initializing a structure by field names (designated initializers). Mr. @Xiang
Xiao <xi...@gmail.com> pointed out that "for the common code it
is better to avoid C99 only features".
I examined the current NuttX code and see that currently common code is far
away from C89 already and things like "<stdbool.h>", "<inttypes.h>",
"snprintf", "designated initializers", "__VA_ARGS__" (variadic macro) are
deeply embedded into the code.
I would like to come up with the suggestion to make C99 as a prerequisite
for the compiler that is used to build NuttX code.
Best regards,
Petro
Re: Move to C99 for common code
Posted by Xiang Xiao <xi...@gmail.com>.
On Sat, Jan 8, 2022 at 1:15 PM Petro Karashchenko <
petro.karashchenko@gmail.com> wrote:
> Hi,
>
> What about inline functions? Those are also a part on C99.
>
>
Change to normal function or macro.
> Are those old architectures checked by the CI?
Not all, arm/mips/risc-v/sim/x86/x86_64/xensa/renesas is enabled in CI,
avr/ceva/hc/misoc/or1k/z16/z80 not:
https://github.com/apache/incubator-nuttx/tree/master/tools/ci/testlist/all.dat
> I mean do we have a proof
> that those are still compilable with the latest release?
>
> Best regards,
> Petro
>
> On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <xi...@gmail.com> wrote:
>
> >
> >
> > On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
> > petro.karashchenko@gmail.com> wrote:
> >
> >> Hello team,
> >>
> >> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a discussion
> >> in one of the PR's related to C89 code compliance. Particularly related
> to
> >> initializing a structure by field names (designated initializers). Mr.
> @Xiang
> >> Xiao <xi...@gmail.com> pointed out that "for the common code
> >> it is better to avoid C99 only features".
> >> I examined the current NuttX code and see that currently common code is
> >> far away from C89 already and things like "<stdbool.h>", "<inttypes.h>",
> >> "snprintf", "designated initializers", "__VA_ARGS__" (variadic macro)
> are
> >> deeply embedded into the code.
> >>
> >>
> > We need separate the features that come from the compiler and the
> standard
> > library. Since the libc is provided by NuttX self:
> >
> > 1. The header files(e.g.stdbool.h, intttyes.h) and function(e.g.
> > snprintf) can be used in common code since NuttX can provide the
> > implementation for all arch even the arch use a very old compiler
> > 2. The preprocessor (e.g. __VA_ARGS__) or language( designated
> > initializers) feature need to avoid or incorporate into the
> conditional
> > macro
> >
> > .
> >
> >> I would like to come up with the suggestion to make C99 as a
> prerequisite
> >> for the compiler that is used to build NuttX code.
> >>
> >
> > As Greg said, if compilers used on all arch supported by NuttX support
> > C99, there is no reason to limit us to C89. The compiler status is a
> > keypoint.
> >
> >
> >>
> >> Best regards,
> >> Petro
> >>
> >>
>
Re: Move to C99 for common code
Posted by Petro Karashchenko <pe...@gmail.com>.
When talking about inline I'm referring to "static inline" functions like
in
https://github.com/apache/incubator-nuttx/blob/c55085c0d8864c9401de97872ab3463d474f262c/include/nuttx/mutex.h
and not to "inline_function" define from compiler.h.
At least I do not find "#define inline" (to empty) in compiler.h
Best regards,
Petro
On Sat, Jan 8, 2022, 2:55 PM Gregory Nutt <sp...@gmail.com> wrote:
> Inline is not an issue. There is a file at include/nuttx/compiler.h that
> handles superficial differences between tools. If the compiler does not
> support inline, it is simply undefined.
>
> I have built ez80 using the ZiLOG tools fairly recently, but none of the
> others. It worked fine.
>
> On Fri, Jan 7, 2022 at 11:15 PM Petro Karashchenko <
> petro.karashchenko@gmail.com> wrote:
>
> > Hi,
> >
> > What about inline functions? Those are also a part on C99.
> >
> > Are those old architectures checked by the CI? I mean do we have a proof
> > that those are still compilable with the latest release?
> >
> > Best regards,
> > Petro
> >
> > On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <xi...@gmail.com>
> wrote:
> >
> > >
> > >
> > > On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
> > > petro.karashchenko@gmail.com> wrote:
> > >
> > >> Hello team,
> > >>
> > >> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a
> discussion
> > >> in one of the PR's related to C89 code compliance. Particularly
> related
> > to
> > >> initializing a structure by field names (designated initializers). Mr.
> > @Xiang
> > >> Xiao <xi...@gmail.com> pointed out that "for the common
> code
> > >> it is better to avoid C99 only features".
> > >> I examined the current NuttX code and see that currently common code
> is
> > >> far away from C89 already and things like "<stdbool.h>",
> "<inttypes.h>",
> > >> "snprintf", "designated initializers", "__VA_ARGS__" (variadic macro)
> > are
> > >> deeply embedded into the code.
> > >>
> > >>
> > > We need separate the features that come from the compiler and the
> > standard
> > > library. Since the libc is provided by NuttX self:
> > >
> > > 1. The header files(e.g.stdbool.h, intttyes.h) and function(e.g.
> > > snprintf) can be used in common code since NuttX can provide the
> > > implementation for all arch even the arch use a very old compiler
> > > 2. The preprocessor (e.g. __VA_ARGS__) or language( designated
> > > initializers) feature need to avoid or incorporate into the
> > conditional
> > > macro
> > >
> > > .
> > >
> > >> I would like to come up with the suggestion to make C99 as a
> > prerequisite
> > >> for the compiler that is used to build NuttX code.
> > >>
> > >
> > > As Greg said, if compilers used on all arch supported by NuttX support
> > > C99, there is no reason to limit us to C89. The compiler status is a
> > > keypoint.
> > >
> > >
> > >>
> > >> Best regards,
> > >> Petro
> > >>
> > >>
> >
>
Re: Move to C99 for common code
Posted by Gregory Nutt <sp...@gmail.com>.
Inline is not an issue. There is a file at include/nuttx/compiler.h that
handles superficial differences between tools. If the compiler does not
support inline, it is simply undefined.
I have built ez80 using the ZiLOG tools fairly recently, but none of the
others. It worked fine.
On Fri, Jan 7, 2022 at 11:15 PM Petro Karashchenko <
petro.karashchenko@gmail.com> wrote:
> Hi,
>
> What about inline functions? Those are also a part on C99.
>
> Are those old architectures checked by the CI? I mean do we have a proof
> that those are still compilable with the latest release?
>
> Best regards,
> Petro
>
> On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <xi...@gmail.com> wrote:
>
> >
> >
> > On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
> > petro.karashchenko@gmail.com> wrote:
> >
> >> Hello team,
> >>
> >> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a discussion
> >> in one of the PR's related to C89 code compliance. Particularly related
> to
> >> initializing a structure by field names (designated initializers). Mr.
> @Xiang
> >> Xiao <xi...@gmail.com> pointed out that "for the common code
> >> it is better to avoid C99 only features".
> >> I examined the current NuttX code and see that currently common code is
> >> far away from C89 already and things like "<stdbool.h>", "<inttypes.h>",
> >> "snprintf", "designated initializers", "__VA_ARGS__" (variadic macro)
> are
> >> deeply embedded into the code.
> >>
> >>
> > We need separate the features that come from the compiler and the
> standard
> > library. Since the libc is provided by NuttX self:
> >
> > 1. The header files(e.g.stdbool.h, intttyes.h) and function(e.g.
> > snprintf) can be used in common code since NuttX can provide the
> > implementation for all arch even the arch use a very old compiler
> > 2. The preprocessor (e.g. __VA_ARGS__) or language( designated
> > initializers) feature need to avoid or incorporate into the
> conditional
> > macro
> >
> > .
> >
> >> I would like to come up with the suggestion to make C99 as a
> prerequisite
> >> for the compiler that is used to build NuttX code.
> >>
> >
> > As Greg said, if compilers used on all arch supported by NuttX support
> > C99, there is no reason to limit us to C89. The compiler status is a
> > keypoint.
> >
> >
> >>
> >> Best regards,
> >> Petro
> >>
> >>
>
Re: Move to C99 for common code
Posted by Gregory Nutt <sp...@gmail.com>.
I think that eliminating some older architectures would be a good thing.
There should be some criteria for selecting those:
- The should be minimal ports with no extensive development,
- They should not be popular or have been popular.
- They should not have extensive board support
- They should have no value to the retro-computing community.
There are several that meet these criteria: sh1, m16c, z8.
Re: Move to C99 for common code
Posted by Petro Karashchenko <pe...@gmail.com>.
In general yes, but my main point was that I saw designated initializer
list heavily used in drivers code that is intended to be common. Also there
are some C99 features like inline functions in common code.
So we need to make an effort and clean-up common code to get back C89
compatibility.
Best regards,
Petro
On Sun, Jan 9, 2022, 1:41 PM Alan Carvalho de Assis <ac...@gmail.com>
wrote:
> On 1/9/22, Nathan Hartman <ha...@gmail.com> wrote:
> > On Sat, Jan 8, 2022 at 11:34 AM Alan Carvalho de Assis <
> acassis@gmail.com>
> > wrote:
> >
> >> I agree! There are few places where designated initializer list are used
> >> in
> >> the common code (in arch/ and boards/ they can be used without further
> >> concern), so it can be fixed at no time.
> >>
> >> In the other hand this flexibility is the root causes for confusion,
> >> mainly
> >> for new contributors. It does appear orthogonal that part of the code
> are
> >> using C99/C11 and part are using C89.
> >
> >
> >
> > Architecture-specific code can use whatever that architecture's compiler
> > supports and in some cases might even have to use special features or
> > syntax.
> >
> > The question is only about common code.
> >
> > Common code that must work on all architectures is what has to be C89.
>
> That is what I said, but the point is: if NuttX mix C99/C11 in some
> places in the source code tree and in other places it only accepts C89
> it creates confusion for people.
>
> All this discussion started when our colleague saw a designated
> initializer list commit coming in a PR and thought it was forbidden,
> but in fact it was legal because it was to arch/ directory.
>
> Following a single standard could avoid this kind of confusion, but
> unfortunately we cannot move to C99 or newer until we have compilers
> for old arch supported by NuttX. Also forcing C89 to arch/ and board/
> will require a huge effort to adapt those source code. So we have a
> dilemma/catch 22.
>
> BR,
>
> Alan
>
Re: Move to C99 for common code
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
On 1/9/22, Nathan Hartman <ha...@gmail.com> wrote:
> On Sat, Jan 8, 2022 at 11:34 AM Alan Carvalho de Assis <ac...@gmail.com>
> wrote:
>
>> I agree! There are few places where designated initializer list are used
>> in
>> the common code (in arch/ and boards/ they can be used without further
>> concern), so it can be fixed at no time.
>>
>> In the other hand this flexibility is the root causes for confusion,
>> mainly
>> for new contributors. It does appear orthogonal that part of the code are
>> using C99/C11 and part are using C89.
>
>
>
> Architecture-specific code can use whatever that architecture's compiler
> supports and in some cases might even have to use special features or
> syntax.
>
> The question is only about common code.
>
> Common code that must work on all architectures is what has to be C89.
That is what I said, but the point is: if NuttX mix C99/C11 in some
places in the source code tree and in other places it only accepts C89
it creates confusion for people.
All this discussion started when our colleague saw a designated
initializer list commit coming in a PR and thought it was forbidden,
but in fact it was legal because it was to arch/ directory.
Following a single standard could avoid this kind of confusion, but
unfortunately we cannot move to C99 or newer until we have compilers
for old arch supported by NuttX. Also forcing C89 to arch/ and board/
will require a huge effort to adapt those source code. So we have a
dilemma/catch 22.
BR,
Alan
Re: Move to C99 for common code
Posted by Nathan Hartman <ha...@gmail.com>.
On Sat, Jan 8, 2022 at 11:34 AM Alan Carvalho de Assis <ac...@gmail.com>
wrote:
> I agree! There are few places where designated initializer list are used in
> the common code (in arch/ and boards/ they can be used without further
> concern), so it can be fixed at no time.
>
> In the other hand this flexibility is the root causes for confusion, mainly
> for new contributors. It does appear orthogonal that part of the code are
> using C99/C11 and part are using C89.
Architecture-specific code can use whatever that architecture's compiler
supports and in some cases might even have to use special features or
syntax.
The question is only about common code.
Common code that must work on all architectures is what has to be C89.
Nathan
Re: Move to C99 for common code
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
I agree! There are few places where designated initializer list are used in
the common code (in arch/ and boards/ they can be used without further
concern), so it can be fixed at no time.
In the other hand this flexibility is the root causes for confusion, mainly
for new contributors. It does appear orthogonal that part of the code are
using C99/C11 and part are using C89.
BR,
Alan
On Saturday, January 8, 2022, Petro Karashchenko <
petro.karashchenko@gmail.com> wrote:
> I do not think that code duplication is a good idea. I'd better search
> common code for designated initializer list and rework it (remove) to get
> back C89 style.
>
> Best regards,
> Petro
>
> On Sat, Jan 8, 2022, 3:54 PM Alin Jerpelea <je...@gmail.com> wrote:
>
> > that code duplication is the way I was thinking if we want to be able to
> > use both compilers and keep all platforms
> > Best Regards
> > Alin
> >
> > On Sat, 8 Jan 2022, 14:42 Alan Carvalho de Assis, <ac...@gmail.com>
> > wrote:
> >
> > > Hi Alin,
> > >
> > > using a menu option in this case will not work because the point is
> > > not passing a std c99 flag to the compiler, but using some C99
> > > features in the source code to simplify it.
> > >
> > > For example: the designated initializer list:
> > >
> > > struct test_s test =
> > > {
> > > .second = 2,
> > > .first = 1
> > > };
> > >
> > > It is not supported by C89 and adding an entry in the menuconfig will
> > > require duplication in the source code to support both standards (C89
> > > and C99).
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On 1/8/22, Alin Jerpelea <je...@gmail.com> wrote:
> > > > In my opinion we should try to keep all platforms and avoid breaking
> > them
> > > > by adopting new standards
> > > >
> > > > An option would be to add the C99 as a menu option while keeping the
> > > > current compilers compatibility
> > > >
> > > > Best Regards
> > > > Alin
> > > >
> > > >
> > > > On Sat, 8 Jan 2022, 13:53 Gregory Nutt, <sp...@gmail.com> wrote:
> > > >
> > > >> z80 holds all 8-bit ZiLOG architectures. That means
> > > >>
> > > >> z80 using the SDCC compiler
> > > >> z180 using the SDCC compiler
> > > >> ez80 which normally uses the ZiLOG compiler, but there is an
> > > experimental
> > > >> version of GCC for the ez80
> > > >>
> > > >> z16 uses only ZiLOG compiler
> > > >>
> > > >> Also consider SH1
> > > >>
> > > >> This will also require changes to INVIOLABLES.md and the coding
> > > standard.
> > > >> I would also recommend a formal vote to assure that you are
> following
> > > the
> > > >> will of the user base and not a personal agenda. There used to be a
> > > >> small
> > > >> but important group of retro computer folk using NuttX; this
> > eliminates
> > > >> support for them. There is language in the INVIOLABLES that is there
> > > >> specifically to protect them from actions like this.
> > > >>
> > > >> I have not heard of anyone using these architectures recently. I
> > would
> > > >> say
> > > >> that only ez80 is active with active development boards. There are
> > > >> occasional developments with z180-like hardware.
> > > >>
> > > >> On Fri, Jan 7, 2022 at 11:40 PM Xiang Xiao <
> xiaoxiang781216@gmail.com
> > >
> > > >> wrote:
> > > >>
> > > >> > Ceva we just added this week also supports C99, so we just need to
> > > >> > check
> > > >> > avr, misoc, or1k, z16 and z80.
> > > >> >
> > > >> > On Sat, Jan 8, 2022 at 1:35 PM Petro Karashchenko <
> > > >> > petro.karashchenko@gmail.com> wrote:
> > > >> >
> > > >> > > In addition I just checked latest GCC with HC12 support is 3.0.4
> > > >> version.
> > > >> > > It have C99 integrated. Will check with AVR32, but will probably
> > > need
> > > >> > some
> > > >> > > help with others.
> > > >> > >
> > > >> > > Best regards,
> > > >> > > Petro
> > > >> > >
> > > >> > > On Sat, Jan 8, 2022, 7:15 AM Petro Karashchenko <
> > > >> > > petro.karashchenko@gmail.com> wrote:
> > > >> > >
> > > >> > > > Hi,
> > > >> > > >
> > > >> > > > What about inline functions? Those are also a part on C99.
> > > >> > > >
> > > >> > > > Are those old architectures checked by the CI? I mean do we
> > have a
> > > >> > proof
> > > >> > > > that those are still compilable with the latest release?
> > > >> > > >
> > > >> > > > Best regards,
> > > >> > > > Petro
> > > >> > > >
> > > >> > > > On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <
> > > xiaoxiang781216@gmail.com>
> > > >> > > wrote:
> > > >> > > >
> > > >> > > >>
> > > >> > > >>
> > > >> > > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
> > > >> > > >> petro.karashchenko@gmail.com> wrote:
> > > >> > > >>
> > > >> > > >>> Hello team,
> > > >> > > >>>
> > > >> > > >>> Recently I mr. @Xiang Xiao <xi...@gmail.com> had
> a
> > > >> > > discussion
> > > >> > > >>> in one of the PR's related to C89 code compliance.
> > Particularly
> > > >> > > related to
> > > >> > > >>> initializing a structure by field names (designated
> > > >> > > >>> initializers).
> > > >> > Mr.
> > > >> > > @Xiang
> > > >> > > >>> Xiao <xi...@gmail.com> pointed out that "for the
> > > common
> > > >> > code
> > > >> > > >>> it is better to avoid C99 only features".
> > > >> > > >>> I examined the current NuttX code and see that currently
> > common
> > > >> code
> > > >> > is
> > > >> > > >>> far away from C89 already and things like "<stdbool.h>",
> > > >> > > "<inttypes.h>",
> > > >> > > >>> "snprintf", "designated initializers", "__VA_ARGS__"
> (variadic
> > > >> macro)
> > > >> > > are
> > > >> > > >>> deeply embedded into the code.
> > > >> > > >>>
> > > >> > > >>>
> > > >> > > >> We need separate the features that come from the compiler and
> > the
> > > >> > > >> standard library. Since the libc is provided by NuttX self:
> > > >> > > >>
> > > >> > > >> 1. The header files(e.g.stdbool.h, intttyes.h) and
> > > >> > > >> function(e.g.
> > > >> > > >> snprintf) can be used in common code since NuttX can
> provide
> > > >> > > >> the
> > > >> > > >> implementation for all arch even the arch use a very old
> > > >> > > >> compiler
> > > >> > > >> 2. The preprocessor (e.g. __VA_ARGS__) or language(
> > > designated
> > > >> > > >> initializers) feature need to avoid or incorporate into
> the
> > > >> > > conditional
> > > >> > > >> macro
> > > >> > > >>
> > > >> > > >> .
> > > >> > > >>
> > > >> > > >>> I would like to come up with the suggestion to make C99 as a
> > > >> > > >>> prerequisite for the compiler that is used to build NuttX
> > code.
> > > >> > > >>>
> > > >> > > >>
> > > >> > > >> As Greg said, if compilers used on all arch supported by
> NuttX
> > > >> support
> > > >> > > >> C99, there is no reason to limit us to C89. The compiler
> status
> > > is
> > > >> > > >> a
> > > >> > > >> keypoint.
> > > >> > > >>
> > > >> > > >>
> > > >> > > >>>
> > > >> > > >>> Best regards,
> > > >> > > >>> Petro
> > > >> > > >>>
> > > >> > > >>>
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: Move to C99 for common code
Posted by Petro Karashchenko <pe...@gmail.com>.
I do not think that code duplication is a good idea. I'd better search
common code for designated initializer list and rework it (remove) to get
back C89 style.
Best regards,
Petro
On Sat, Jan 8, 2022, 3:54 PM Alin Jerpelea <je...@gmail.com> wrote:
> that code duplication is the way I was thinking if we want to be able to
> use both compilers and keep all platforms
> Best Regards
> Alin
>
> On Sat, 8 Jan 2022, 14:42 Alan Carvalho de Assis, <ac...@gmail.com>
> wrote:
>
> > Hi Alin,
> >
> > using a menu option in this case will not work because the point is
> > not passing a std c99 flag to the compiler, but using some C99
> > features in the source code to simplify it.
> >
> > For example: the designated initializer list:
> >
> > struct test_s test =
> > {
> > .second = 2,
> > .first = 1
> > };
> >
> > It is not supported by C89 and adding an entry in the menuconfig will
> > require duplication in the source code to support both standards (C89
> > and C99).
> >
> > BR,
> >
> > Alan
> >
> > On 1/8/22, Alin Jerpelea <je...@gmail.com> wrote:
> > > In my opinion we should try to keep all platforms and avoid breaking
> them
> > > by adopting new standards
> > >
> > > An option would be to add the C99 as a menu option while keeping the
> > > current compilers compatibility
> > >
> > > Best Regards
> > > Alin
> > >
> > >
> > > On Sat, 8 Jan 2022, 13:53 Gregory Nutt, <sp...@gmail.com> wrote:
> > >
> > >> z80 holds all 8-bit ZiLOG architectures. That means
> > >>
> > >> z80 using the SDCC compiler
> > >> z180 using the SDCC compiler
> > >> ez80 which normally uses the ZiLOG compiler, but there is an
> > experimental
> > >> version of GCC for the ez80
> > >>
> > >> z16 uses only ZiLOG compiler
> > >>
> > >> Also consider SH1
> > >>
> > >> This will also require changes to INVIOLABLES.md and the coding
> > standard.
> > >> I would also recommend a formal vote to assure that you are following
> > the
> > >> will of the user base and not a personal agenda. There used to be a
> > >> small
> > >> but important group of retro computer folk using NuttX; this
> eliminates
> > >> support for them. There is language in the INVIOLABLES that is there
> > >> specifically to protect them from actions like this.
> > >>
> > >> I have not heard of anyone using these architectures recently. I
> would
> > >> say
> > >> that only ez80 is active with active development boards. There are
> > >> occasional developments with z180-like hardware.
> > >>
> > >> On Fri, Jan 7, 2022 at 11:40 PM Xiang Xiao <xiaoxiang781216@gmail.com
> >
> > >> wrote:
> > >>
> > >> > Ceva we just added this week also supports C99, so we just need to
> > >> > check
> > >> > avr, misoc, or1k, z16 and z80.
> > >> >
> > >> > On Sat, Jan 8, 2022 at 1:35 PM Petro Karashchenko <
> > >> > petro.karashchenko@gmail.com> wrote:
> > >> >
> > >> > > In addition I just checked latest GCC with HC12 support is 3.0.4
> > >> version.
> > >> > > It have C99 integrated. Will check with AVR32, but will probably
> > need
> > >> > some
> > >> > > help with others.
> > >> > >
> > >> > > Best regards,
> > >> > > Petro
> > >> > >
> > >> > > On Sat, Jan 8, 2022, 7:15 AM Petro Karashchenko <
> > >> > > petro.karashchenko@gmail.com> wrote:
> > >> > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > What about inline functions? Those are also a part on C99.
> > >> > > >
> > >> > > > Are those old architectures checked by the CI? I mean do we
> have a
> > >> > proof
> > >> > > > that those are still compilable with the latest release?
> > >> > > >
> > >> > > > Best regards,
> > >> > > > Petro
> > >> > > >
> > >> > > > On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <
> > xiaoxiang781216@gmail.com>
> > >> > > wrote:
> > >> > > >
> > >> > > >>
> > >> > > >>
> > >> > > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
> > >> > > >> petro.karashchenko@gmail.com> wrote:
> > >> > > >>
> > >> > > >>> Hello team,
> > >> > > >>>
> > >> > > >>> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a
> > >> > > discussion
> > >> > > >>> in one of the PR's related to C89 code compliance.
> Particularly
> > >> > > related to
> > >> > > >>> initializing a structure by field names (designated
> > >> > > >>> initializers).
> > >> > Mr.
> > >> > > @Xiang
> > >> > > >>> Xiao <xi...@gmail.com> pointed out that "for the
> > common
> > >> > code
> > >> > > >>> it is better to avoid C99 only features".
> > >> > > >>> I examined the current NuttX code and see that currently
> common
> > >> code
> > >> > is
> > >> > > >>> far away from C89 already and things like "<stdbool.h>",
> > >> > > "<inttypes.h>",
> > >> > > >>> "snprintf", "designated initializers", "__VA_ARGS__" (variadic
> > >> macro)
> > >> > > are
> > >> > > >>> deeply embedded into the code.
> > >> > > >>>
> > >> > > >>>
> > >> > > >> We need separate the features that come from the compiler and
> the
> > >> > > >> standard library. Since the libc is provided by NuttX self:
> > >> > > >>
> > >> > > >> 1. The header files(e.g.stdbool.h, intttyes.h) and
> > >> > > >> function(e.g.
> > >> > > >> snprintf) can be used in common code since NuttX can provide
> > >> > > >> the
> > >> > > >> implementation for all arch even the arch use a very old
> > >> > > >> compiler
> > >> > > >> 2. The preprocessor (e.g. __VA_ARGS__) or language(
> > designated
> > >> > > >> initializers) feature need to avoid or incorporate into the
> > >> > > conditional
> > >> > > >> macro
> > >> > > >>
> > >> > > >> .
> > >> > > >>
> > >> > > >>> I would like to come up with the suggestion to make C99 as a
> > >> > > >>> prerequisite for the compiler that is used to build NuttX
> code.
> > >> > > >>>
> > >> > > >>
> > >> > > >> As Greg said, if compilers used on all arch supported by NuttX
> > >> support
> > >> > > >> C99, there is no reason to limit us to C89. The compiler status
> > is
> > >> > > >> a
> > >> > > >> keypoint.
> > >> > > >>
> > >> > > >>
> > >> > > >>>
> > >> > > >>> Best regards,
> > >> > > >>> Petro
> > >> > > >>>
> > >> > > >>>
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: Move to C99 for common code
Posted by Alin Jerpelea <je...@gmail.com>.
that code duplication is the way I was thinking if we want to be able to
use both compilers and keep all platforms
Best Regards
Alin
On Sat, 8 Jan 2022, 14:42 Alan Carvalho de Assis, <ac...@gmail.com> wrote:
> Hi Alin,
>
> using a menu option in this case will not work because the point is
> not passing a std c99 flag to the compiler, but using some C99
> features in the source code to simplify it.
>
> For example: the designated initializer list:
>
> struct test_s test =
> {
> .second = 2,
> .first = 1
> };
>
> It is not supported by C89 and adding an entry in the menuconfig will
> require duplication in the source code to support both standards (C89
> and C99).
>
> BR,
>
> Alan
>
> On 1/8/22, Alin Jerpelea <je...@gmail.com> wrote:
> > In my opinion we should try to keep all platforms and avoid breaking them
> > by adopting new standards
> >
> > An option would be to add the C99 as a menu option while keeping the
> > current compilers compatibility
> >
> > Best Regards
> > Alin
> >
> >
> > On Sat, 8 Jan 2022, 13:53 Gregory Nutt, <sp...@gmail.com> wrote:
> >
> >> z80 holds all 8-bit ZiLOG architectures. That means
> >>
> >> z80 using the SDCC compiler
> >> z180 using the SDCC compiler
> >> ez80 which normally uses the ZiLOG compiler, but there is an
> experimental
> >> version of GCC for the ez80
> >>
> >> z16 uses only ZiLOG compiler
> >>
> >> Also consider SH1
> >>
> >> This will also require changes to INVIOLABLES.md and the coding
> standard.
> >> I would also recommend a formal vote to assure that you are following
> the
> >> will of the user base and not a personal agenda. There used to be a
> >> small
> >> but important group of retro computer folk using NuttX; this eliminates
> >> support for them. There is language in the INVIOLABLES that is there
> >> specifically to protect them from actions like this.
> >>
> >> I have not heard of anyone using these architectures recently. I would
> >> say
> >> that only ez80 is active with active development boards. There are
> >> occasional developments with z180-like hardware.
> >>
> >> On Fri, Jan 7, 2022 at 11:40 PM Xiang Xiao <xi...@gmail.com>
> >> wrote:
> >>
> >> > Ceva we just added this week also supports C99, so we just need to
> >> > check
> >> > avr, misoc, or1k, z16 and z80.
> >> >
> >> > On Sat, Jan 8, 2022 at 1:35 PM Petro Karashchenko <
> >> > petro.karashchenko@gmail.com> wrote:
> >> >
> >> > > In addition I just checked latest GCC with HC12 support is 3.0.4
> >> version.
> >> > > It have C99 integrated. Will check with AVR32, but will probably
> need
> >> > some
> >> > > help with others.
> >> > >
> >> > > Best regards,
> >> > > Petro
> >> > >
> >> > > On Sat, Jan 8, 2022, 7:15 AM Petro Karashchenko <
> >> > > petro.karashchenko@gmail.com> wrote:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > What about inline functions? Those are also a part on C99.
> >> > > >
> >> > > > Are those old architectures checked by the CI? I mean do we have a
> >> > proof
> >> > > > that those are still compilable with the latest release?
> >> > > >
> >> > > > Best regards,
> >> > > > Petro
> >> > > >
> >> > > > On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <
> xiaoxiang781216@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > >>
> >> > > >>
> >> > > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
> >> > > >> petro.karashchenko@gmail.com> wrote:
> >> > > >>
> >> > > >>> Hello team,
> >> > > >>>
> >> > > >>> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a
> >> > > discussion
> >> > > >>> in one of the PR's related to C89 code compliance. Particularly
> >> > > related to
> >> > > >>> initializing a structure by field names (designated
> >> > > >>> initializers).
> >> > Mr.
> >> > > @Xiang
> >> > > >>> Xiao <xi...@gmail.com> pointed out that "for the
> common
> >> > code
> >> > > >>> it is better to avoid C99 only features".
> >> > > >>> I examined the current NuttX code and see that currently common
> >> code
> >> > is
> >> > > >>> far away from C89 already and things like "<stdbool.h>",
> >> > > "<inttypes.h>",
> >> > > >>> "snprintf", "designated initializers", "__VA_ARGS__" (variadic
> >> macro)
> >> > > are
> >> > > >>> deeply embedded into the code.
> >> > > >>>
> >> > > >>>
> >> > > >> We need separate the features that come from the compiler and the
> >> > > >> standard library. Since the libc is provided by NuttX self:
> >> > > >>
> >> > > >> 1. The header files(e.g.stdbool.h, intttyes.h) and
> >> > > >> function(e.g.
> >> > > >> snprintf) can be used in common code since NuttX can provide
> >> > > >> the
> >> > > >> implementation for all arch even the arch use a very old
> >> > > >> compiler
> >> > > >> 2. The preprocessor (e.g. __VA_ARGS__) or language(
> designated
> >> > > >> initializers) feature need to avoid or incorporate into the
> >> > > conditional
> >> > > >> macro
> >> > > >>
> >> > > >> .
> >> > > >>
> >> > > >>> I would like to come up with the suggestion to make C99 as a
> >> > > >>> prerequisite for the compiler that is used to build NuttX code.
> >> > > >>>
> >> > > >>
> >> > > >> As Greg said, if compilers used on all arch supported by NuttX
> >> support
> >> > > >> C99, there is no reason to limit us to C89. The compiler status
> is
> >> > > >> a
> >> > > >> keypoint.
> >> > > >>
> >> > > >>
> >> > > >>>
> >> > > >>> Best regards,
> >> > > >>> Petro
> >> > > >>>
> >> > > >>>
> >> > >
> >> >
> >>
> >
>
Re: Move to C99 for common code
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Alin,
using a menu option in this case will not work because the point is
not passing a std c99 flag to the compiler, but using some C99
features in the source code to simplify it.
For example: the designated initializer list:
struct test_s test =
{
.second = 2,
.first = 1
};
It is not supported by C89 and adding an entry in the menuconfig will
require duplication in the source code to support both standards (C89
and C99).
BR,
Alan
On 1/8/22, Alin Jerpelea <je...@gmail.com> wrote:
> In my opinion we should try to keep all platforms and avoid breaking them
> by adopting new standards
>
> An option would be to add the C99 as a menu option while keeping the
> current compilers compatibility
>
> Best Regards
> Alin
>
>
> On Sat, 8 Jan 2022, 13:53 Gregory Nutt, <sp...@gmail.com> wrote:
>
>> z80 holds all 8-bit ZiLOG architectures. That means
>>
>> z80 using the SDCC compiler
>> z180 using the SDCC compiler
>> ez80 which normally uses the ZiLOG compiler, but there is an experimental
>> version of GCC for the ez80
>>
>> z16 uses only ZiLOG compiler
>>
>> Also consider SH1
>>
>> This will also require changes to INVIOLABLES.md and the coding standard.
>> I would also recommend a formal vote to assure that you are following the
>> will of the user base and not a personal agenda. There used to be a
>> small
>> but important group of retro computer folk using NuttX; this eliminates
>> support for them. There is language in the INVIOLABLES that is there
>> specifically to protect them from actions like this.
>>
>> I have not heard of anyone using these architectures recently. I would
>> say
>> that only ez80 is active with active development boards. There are
>> occasional developments with z180-like hardware.
>>
>> On Fri, Jan 7, 2022 at 11:40 PM Xiang Xiao <xi...@gmail.com>
>> wrote:
>>
>> > Ceva we just added this week also supports C99, so we just need to
>> > check
>> > avr, misoc, or1k, z16 and z80.
>> >
>> > On Sat, Jan 8, 2022 at 1:35 PM Petro Karashchenko <
>> > petro.karashchenko@gmail.com> wrote:
>> >
>> > > In addition I just checked latest GCC with HC12 support is 3.0.4
>> version.
>> > > It have C99 integrated. Will check with AVR32, but will probably need
>> > some
>> > > help with others.
>> > >
>> > > Best regards,
>> > > Petro
>> > >
>> > > On Sat, Jan 8, 2022, 7:15 AM Petro Karashchenko <
>> > > petro.karashchenko@gmail.com> wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > What about inline functions? Those are also a part on C99.
>> > > >
>> > > > Are those old architectures checked by the CI? I mean do we have a
>> > proof
>> > > > that those are still compilable with the latest release?
>> > > >
>> > > > Best regards,
>> > > > Petro
>> > > >
>> > > > On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <xi...@gmail.com>
>> > > wrote:
>> > > >
>> > > >>
>> > > >>
>> > > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
>> > > >> petro.karashchenko@gmail.com> wrote:
>> > > >>
>> > > >>> Hello team,
>> > > >>>
>> > > >>> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a
>> > > discussion
>> > > >>> in one of the PR's related to C89 code compliance. Particularly
>> > > related to
>> > > >>> initializing a structure by field names (designated
>> > > >>> initializers).
>> > Mr.
>> > > @Xiang
>> > > >>> Xiao <xi...@gmail.com> pointed out that "for the common
>> > code
>> > > >>> it is better to avoid C99 only features".
>> > > >>> I examined the current NuttX code and see that currently common
>> code
>> > is
>> > > >>> far away from C89 already and things like "<stdbool.h>",
>> > > "<inttypes.h>",
>> > > >>> "snprintf", "designated initializers", "__VA_ARGS__" (variadic
>> macro)
>> > > are
>> > > >>> deeply embedded into the code.
>> > > >>>
>> > > >>>
>> > > >> We need separate the features that come from the compiler and the
>> > > >> standard library. Since the libc is provided by NuttX self:
>> > > >>
>> > > >> 1. The header files(e.g.stdbool.h, intttyes.h) and
>> > > >> function(e.g.
>> > > >> snprintf) can be used in common code since NuttX can provide
>> > > >> the
>> > > >> implementation for all arch even the arch use a very old
>> > > >> compiler
>> > > >> 2. The preprocessor (e.g. __VA_ARGS__) or language( designated
>> > > >> initializers) feature need to avoid or incorporate into the
>> > > conditional
>> > > >> macro
>> > > >>
>> > > >> .
>> > > >>
>> > > >>> I would like to come up with the suggestion to make C99 as a
>> > > >>> prerequisite for the compiler that is used to build NuttX code.
>> > > >>>
>> > > >>
>> > > >> As Greg said, if compilers used on all arch supported by NuttX
>> support
>> > > >> C99, there is no reason to limit us to C89. The compiler status is
>> > > >> a
>> > > >> keypoint.
>> > > >>
>> > > >>
>> > > >>>
>> > > >>> Best regards,
>> > > >>> Petro
>> > > >>>
>> > > >>>
>> > >
>> >
>>
>
Re: Move to C99 for common code
Posted by Alin Jerpelea <je...@gmail.com>.
In my opinion we should try to keep all platforms and avoid breaking them
by adopting new standards
An option would be to add the C99 as a menu option while keeping the
current compilers compatibility
Best Regards
Alin
On Sat, 8 Jan 2022, 13:53 Gregory Nutt, <sp...@gmail.com> wrote:
> z80 holds all 8-bit ZiLOG architectures. That means
>
> z80 using the SDCC compiler
> z180 using the SDCC compiler
> ez80 which normally uses the ZiLOG compiler, but there is an experimental
> version of GCC for the ez80
>
> z16 uses only ZiLOG compiler
>
> Also consider SH1
>
> This will also require changes to INVIOLABLES.md and the coding standard.
> I would also recommend a formal vote to assure that you are following the
> will of the user base and not a personal agenda. There used to be a small
> but important group of retro computer folk using NuttX; this eliminates
> support for them. There is language in the INVIOLABLES that is there
> specifically to protect them from actions like this.
>
> I have not heard of anyone using these architectures recently. I would say
> that only ez80 is active with active development boards. There are
> occasional developments with z180-like hardware.
>
> On Fri, Jan 7, 2022 at 11:40 PM Xiang Xiao <xi...@gmail.com>
> wrote:
>
> > Ceva we just added this week also supports C99, so we just need to check
> > avr, misoc, or1k, z16 and z80.
> >
> > On Sat, Jan 8, 2022 at 1:35 PM Petro Karashchenko <
> > petro.karashchenko@gmail.com> wrote:
> >
> > > In addition I just checked latest GCC with HC12 support is 3.0.4
> version.
> > > It have C99 integrated. Will check with AVR32, but will probably need
> > some
> > > help with others.
> > >
> > > Best regards,
> > > Petro
> > >
> > > On Sat, Jan 8, 2022, 7:15 AM Petro Karashchenko <
> > > petro.karashchenko@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > What about inline functions? Those are also a part on C99.
> > > >
> > > > Are those old architectures checked by the CI? I mean do we have a
> > proof
> > > > that those are still compilable with the latest release?
> > > >
> > > > Best regards,
> > > > Petro
> > > >
> > > > On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <xi...@gmail.com>
> > > wrote:
> > > >
> > > >>
> > > >>
> > > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
> > > >> petro.karashchenko@gmail.com> wrote:
> > > >>
> > > >>> Hello team,
> > > >>>
> > > >>> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a
> > > discussion
> > > >>> in one of the PR's related to C89 code compliance. Particularly
> > > related to
> > > >>> initializing a structure by field names (designated initializers).
> > Mr.
> > > @Xiang
> > > >>> Xiao <xi...@gmail.com> pointed out that "for the common
> > code
> > > >>> it is better to avoid C99 only features".
> > > >>> I examined the current NuttX code and see that currently common
> code
> > is
> > > >>> far away from C89 already and things like "<stdbool.h>",
> > > "<inttypes.h>",
> > > >>> "snprintf", "designated initializers", "__VA_ARGS__" (variadic
> macro)
> > > are
> > > >>> deeply embedded into the code.
> > > >>>
> > > >>>
> > > >> We need separate the features that come from the compiler and the
> > > >> standard library. Since the libc is provided by NuttX self:
> > > >>
> > > >> 1. The header files(e.g.stdbool.h, intttyes.h) and function(e.g.
> > > >> snprintf) can be used in common code since NuttX can provide the
> > > >> implementation for all arch even the arch use a very old compiler
> > > >> 2. The preprocessor (e.g. __VA_ARGS__) or language( designated
> > > >> initializers) feature need to avoid or incorporate into the
> > > conditional
> > > >> macro
> > > >>
> > > >> .
> > > >>
> > > >>> I would like to come up with the suggestion to make C99 as a
> > > >>> prerequisite for the compiler that is used to build NuttX code.
> > > >>>
> > > >>
> > > >> As Greg said, if compilers used on all arch supported by NuttX
> support
> > > >> C99, there is no reason to limit us to C89. The compiler status is a
> > > >> keypoint.
> > > >>
> > > >>
> > > >>>
> > > >>> Best regards,
> > > >>> Petro
> > > >>>
> > > >>>
> > >
> >
>
Re: Move to C99 for common code
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
I got a response from Philipp Klaus Krause, maintainer of SDCC:
"I guess there was a misunderstanding. SDCC can now assign struct and
union, but it still can't pass and return them.
I think passing and returning struct and union will be supported in
4.3.0 (some SDCC developers want to look into implementing it this
summer)."
So, probably after version 4.3 we could use SDCC to compile NuttX again.
BR,
Alan
On 1/15/22, Gregory Nutt <sp...@gmail.com> wrote:
> I suppose that if someone really wants to use z80, they would need to hunt
> down a better compiler.
>
>
> When we removed those SDCC hacks from the code, we were under the belief
> that SDCC had corrected that problem. But obviously not.
>
>
> I would not recommend restoring them. They are too invasive and force
> breakage of the POSIX interface.
>
>
> z80 itself, I suspect is not important because I doubt it is usable because
> of the 64Kb address space. But other z80 family members and derivatives
> could be used because they support an MMU.
>
RE: Move to C99 for common code
Posted by Gregory Nutt <sp...@gmail.com>.
I suppose that if someone really wants to use z80, they would need to hunt
down a better compiler.
When we removed those SDCC hacks from the code, we were under the belief
that SDCC had corrected that problem. But obviously not.
I would not recommend restoring them. They are too invasive and force
breakage of the POSIX interface.
z80 itself, I suspect is not important because I doubt it is usable because
of the 64Kb address space. But other z80 family members and derivatives
could be used because they support an MMU.
Re: Move to C99 for common code
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Just to let you know, I tested the Z80 and it was broken:
https://acassis.wordpress.com/2022/01/14/testing-nuttx-rtos-on-z80-simulator/
As Mr. Greg commented in this post, the guilt was this commit:
https://github.com/apache/incubator-nuttx/commit/67ec3d7926d871c515fb1a55a11da8630fe53649
If I go back to commit 554d56b8752119ade4411cde9dbc1dfc5fdb8ac0 (and
move apps repository to a commit around this date) the compilation
works:
$ ./tools/configure.sh z80sim:nsh
$ make menuconfig (maybe you need to remove some apps/ new directories
left behind)
$ make
Complete build log is here:
https://pastebin.com/raw/JMfXif3H
I tried to use the z80sim Release 1.37, Copyright (C) 1987-2021 by Udo
Munk, but it doesn't appear to run:
$ z80sim -z -x nuttx.hex
####### ##### ### ##### ### # #
# # # # # # # # ## ##
# # # # # # # # # # #
# ##### # # ##### ##### # # # #
# # # # # # # # #
# # # # # # # # # #
####### ##### ### ##### ### # #
Release 1.37, Copyright (C) 1987-2021 by Udo Munk
CPU speed is unlimited, CPU executes undocumented instructions
Loader statistics for file nuttx.hex:
START : 0000H
END : FFFFH
LOADED: 0000H (0)
Op-code trap at 6edd: ed 19
PC A SZHPNC I IFF BC DE HL A'F' B'C' D'E' H'L' IX IY SP
6edf 6e 000000 00 11 e5dd 77de 6edd 7808 4f5e 2e17 c99e 0821 95d6 873b
>>>
Maybe this hex file need to be converted to .bin before executing, the
README.txt say nothing about the z80sim used (seems to exist more than
1 z80sim around) and don't say how to run it.
BR,
Alan
On 1/10/22, Xiang Xiao <xi...@gmail.com> wrote:
> Even no people complain about the inline usage, but it's always good to
> isolate the inline keyword in compiler.h like others.
>
> On Tue, Jan 11, 2022 at 4:37 AM Petro Karashchenko <
> petro.karashchenko@gmail.com> wrote:
>
>> Following the discussion related to the "inline" keyword usage in common
>> code. I have done draft changes in
>> https://github.com/apache/incubator-nuttx/pull/5201 with an approach that
>> possibly can be used to get rid of "inline" in common code.
>> But I'm not even sure if this is needed to anyone, since there are no
>> reports about compilation issues for any of the supported platforms. This
>> means that the platforms are either not used (projects not updated to the
>> latest NuttX release) or all used compilers support "inline" (and maybe
>> C99).
>> I would appreciate it if people can give feedback should I continue
>> changing 7000 other places, or just drop this activity.
>>
>> Best regards,
>> Petro
>>
>> пн, 10 січ. 2022 р. о 17:17 Nathan Hartman <ha...@gmail.com>
>> пише:
>>
>> > On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt <sp...@gmail.com>
>> wrote:
>> > >
>> > > >
>> > > > Speaking of the Z80, would it be possible to run NuttX in a Grant
>> > Searle
>> > > > / RC2014 platform with a 8k ROM /56k RAM split, or would any
>> > > > attempt
>> > > > require banked memory?
>> > > >
>> > >
>> > > I don't know if it is possible or not. I don't know if NuttX is
>> > > viable
>> > on
>> > > any CPU limited to a 64Kb address space. In their day, those 8-bit
>> CPUs
>> > > were programmed in highly tuned assembly language. it is hard to
>> imagine
>> > > running an OS that is almost as big as the addressable memory and
>> > > being
>> > > able to do anything meaningful. NuttX may have outgrown these
>> platforms.
>> > >
>> > > I think that z80 architecture support is still important because
>> > > there
>> > are
>> > > so many derivatives from z80, like that FPGA in the ZX Spectrum Next
>> > > (
>> > > https://en.wikipedia.org/wiki/ZX_Spectrum_Next). That FPGA runs the
>> z80
>> > > with a extended address space using an MMU similar to the z180 but
>> > > with
>> > > smaller pages. Other derivatives like the z300 and the ez80 just
>> > support a
>> > > wider address space. I have done a couple of ezo ports recently
>> > > (like
>> > > http://z20x.computer/).
>> > >
>> > > I appreciate this discussion about protecting the NuttX supported
>> > platforms.
>> >
>> > I think non-arch-specific code should stick with C89 and we should not
>> > be too eager to remove architectures that have these needs.
>> >
>> > It's not too hard to tell people that non-arch-specific code needs to
>> > be
>> > C89.
>> >
>> > We can catch it more easily in precheck by passing the C89 flag to the
>> > compiler.
>> >
>> > Only in the case where an architecture is incomplete, unmaintained,
>> > and NuttX isn't really viable for it anymore, should we consider
>> > removing it.
>> >
>> > We should have a rule that removing an arch should require a process
>> > that makes it highly likely that we'd hear from any users who consider
>> > that arch important.
>> >
>> > For example, get the word out for some period of time and solicit
>> > feedback. If no feedback, then mark the arch deprecated, produce
>> > build-time warnings, require users to activate some kind of
>> > CONFIG_DEPRECATED_ARCH to use it. In other words, do things to get
>> > their attention. And then, have a mandatory waiting period to allow
>> > enough time to either attract maintainers or be able to declare the
>> > arch dead with a clear conscience.
>> >
>> > > > So many RTOS are just for arm.
>> >
>> > The whole point why I adopted NuttX is because of being able to move
>> > my applications from one arch to another.
>> >
>> > > Originally, NuttX was focused on the hobbyist, DIYer, and
>> retro-computing
>> > > enthusiast. But nowadays, it is dominated by businesses with business
>> > value
>> > > systems that are sometimes not compatible with the needs or interests
>> of
>> > > hobbyists. That is why there is such a long discussion in the
>> > > INVIOLABLE.md under "All Users Matter." That was essentially the
>> > contract
>> > > I made when I agreed to give the OS to the community. But it is
>> > > going
>> to
>> > > take some strong leadership to keep those values since the OS is
>> > controlled
>> > > completely by businesses now and businesses tend to think only of
>> > > their
>> > own
>> > > needs.
>> >
>> > We need more hobbyist/DIYer committers and PMC.
>> >
>> > We need a short and professional presentation, targeted specifically
>> > to business users, that clearly explains why it is in their best
>> > interests to play nice with the community.
>> >
>> > Cheers,
>> > Nathan
>> >
>>
>
Re: Move to C99 for common code
Posted by Xiang Xiao <xi...@gmail.com>.
Even no people complain about the inline usage, but it's always good to
isolate the inline keyword in compiler.h like others.
On Tue, Jan 11, 2022 at 4:37 AM Petro Karashchenko <
petro.karashchenko@gmail.com> wrote:
> Following the discussion related to the "inline" keyword usage in common
> code. I have done draft changes in
> https://github.com/apache/incubator-nuttx/pull/5201 with an approach that
> possibly can be used to get rid of "inline" in common code.
> But I'm not even sure if this is needed to anyone, since there are no
> reports about compilation issues for any of the supported platforms. This
> means that the platforms are either not used (projects not updated to the
> latest NuttX release) or all used compilers support "inline" (and maybe
> C99).
> I would appreciate it if people can give feedback should I continue
> changing 7000 other places, or just drop this activity.
>
> Best regards,
> Petro
>
> пн, 10 січ. 2022 р. о 17:17 Nathan Hartman <ha...@gmail.com>
> пише:
>
> > On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt <sp...@gmail.com>
> wrote:
> > >
> > > >
> > > > Speaking of the Z80, would it be possible to run NuttX in a Grant
> > Searle
> > > > / RC2014 platform with a 8k ROM /56k RAM split, or would any attempt
> > > > require banked memory?
> > > >
> > >
> > > I don't know if it is possible or not. I don't know if NuttX is viable
> > on
> > > any CPU limited to a 64Kb address space. In their day, those 8-bit
> CPUs
> > > were programmed in highly tuned assembly language. it is hard to
> imagine
> > > running an OS that is almost as big as the addressable memory and being
> > > able to do anything meaningful. NuttX may have outgrown these
> platforms.
> > >
> > > I think that z80 architecture support is still important because there
> > are
> > > so many derivatives from z80, like that FPGA in the ZX Spectrum Next (
> > > https://en.wikipedia.org/wiki/ZX_Spectrum_Next). That FPGA runs the
> z80
> > > with a extended address space using an MMU similar to the z180 but with
> > > smaller pages. Other derivatives like the z300 and the ez80 just
> > support a
> > > wider address space. I have done a couple of ezo ports recently (like
> > > http://z20x.computer/).
> > >
> > > I appreciate this discussion about protecting the NuttX supported
> > platforms.
> >
> > I think non-arch-specific code should stick with C89 and we should not
> > be too eager to remove architectures that have these needs.
> >
> > It's not too hard to tell people that non-arch-specific code needs to be
> > C89.
> >
> > We can catch it more easily in precheck by passing the C89 flag to the
> > compiler.
> >
> > Only in the case where an architecture is incomplete, unmaintained,
> > and NuttX isn't really viable for it anymore, should we consider
> > removing it.
> >
> > We should have a rule that removing an arch should require a process
> > that makes it highly likely that we'd hear from any users who consider
> > that arch important.
> >
> > For example, get the word out for some period of time and solicit
> > feedback. If no feedback, then mark the arch deprecated, produce
> > build-time warnings, require users to activate some kind of
> > CONFIG_DEPRECATED_ARCH to use it. In other words, do things to get
> > their attention. And then, have a mandatory waiting period to allow
> > enough time to either attract maintainers or be able to declare the
> > arch dead with a clear conscience.
> >
> > > > So many RTOS are just for arm.
> >
> > The whole point why I adopted NuttX is because of being able to move
> > my applications from one arch to another.
> >
> > > Originally, NuttX was focused on the hobbyist, DIYer, and
> retro-computing
> > > enthusiast. But nowadays, it is dominated by businesses with business
> > value
> > > systems that are sometimes not compatible with the needs or interests
> of
> > > hobbyists. That is why there is such a long discussion in the
> > > INVIOLABLE.md under "All Users Matter." That was essentially the
> > contract
> > > I made when I agreed to give the OS to the community. But it is going
> to
> > > take some strong leadership to keep those values since the OS is
> > controlled
> > > completely by businesses now and businesses tend to think only of their
> > own
> > > needs.
> >
> > We need more hobbyist/DIYer committers and PMC.
> >
> > We need a short and professional presentation, targeted specifically
> > to business users, that clearly explains why it is in their best
> > interests to play nice with the community.
> >
> > Cheers,
> > Nathan
> >
>
Re: Move to C99 for common code
Posted by Petro Karashchenko <pe...@gmail.com>.
Following the discussion related to the "inline" keyword usage in common
code. I have done draft changes in
https://github.com/apache/incubator-nuttx/pull/5201 with an approach that
possibly can be used to get rid of "inline" in common code.
But I'm not even sure if this is needed to anyone, since there are no
reports about compilation issues for any of the supported platforms. This
means that the platforms are either not used (projects not updated to the
latest NuttX release) or all used compilers support "inline" (and maybe
C99).
I would appreciate it if people can give feedback should I continue
changing 7000 other places, or just drop this activity.
Best regards,
Petro
пн, 10 січ. 2022 р. о 17:17 Nathan Hartman <ha...@gmail.com> пише:
> On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt <sp...@gmail.com> wrote:
> >
> > >
> > > Speaking of the Z80, would it be possible to run NuttX in a Grant
> Searle
> > > / RC2014 platform with a 8k ROM /56k RAM split, or would any attempt
> > > require banked memory?
> > >
> >
> > I don't know if it is possible or not. I don't know if NuttX is viable
> on
> > any CPU limited to a 64Kb address space. In their day, those 8-bit CPUs
> > were programmed in highly tuned assembly language. it is hard to imagine
> > running an OS that is almost as big as the addressable memory and being
> > able to do anything meaningful. NuttX may have outgrown these platforms.
> >
> > I think that z80 architecture support is still important because there
> are
> > so many derivatives from z80, like that FPGA in the ZX Spectrum Next (
> > https://en.wikipedia.org/wiki/ZX_Spectrum_Next). That FPGA runs the z80
> > with a extended address space using an MMU similar to the z180 but with
> > smaller pages. Other derivatives like the z300 and the ez80 just
> support a
> > wider address space. I have done a couple of ezo ports recently (like
> > http://z20x.computer/).
> >
> > I appreciate this discussion about protecting the NuttX supported
> platforms.
>
> I think non-arch-specific code should stick with C89 and we should not
> be too eager to remove architectures that have these needs.
>
> It's not too hard to tell people that non-arch-specific code needs to be
> C89.
>
> We can catch it more easily in precheck by passing the C89 flag to the
> compiler.
>
> Only in the case where an architecture is incomplete, unmaintained,
> and NuttX isn't really viable for it anymore, should we consider
> removing it.
>
> We should have a rule that removing an arch should require a process
> that makes it highly likely that we'd hear from any users who consider
> that arch important.
>
> For example, get the word out for some period of time and solicit
> feedback. If no feedback, then mark the arch deprecated, produce
> build-time warnings, require users to activate some kind of
> CONFIG_DEPRECATED_ARCH to use it. In other words, do things to get
> their attention. And then, have a mandatory waiting period to allow
> enough time to either attract maintainers or be able to declare the
> arch dead with a clear conscience.
>
> > > So many RTOS are just for arm.
>
> The whole point why I adopted NuttX is because of being able to move
> my applications from one arch to another.
>
> > Originally, NuttX was focused on the hobbyist, DIYer, and retro-computing
> > enthusiast. But nowadays, it is dominated by businesses with business
> value
> > systems that are sometimes not compatible with the needs or interests of
> > hobbyists. That is why there is such a long discussion in the
> > INVIOLABLE.md under "All Users Matter." That was essentially the
> contract
> > I made when I agreed to give the OS to the community. But it is going to
> > take some strong leadership to keep those values since the OS is
> controlled
> > completely by businesses now and businesses tend to think only of their
> own
> > needs.
>
> We need more hobbyist/DIYer committers and PMC.
>
> We need a short and professional presentation, targeted specifically
> to business users, that clearly explains why it is in their best
> interests to play nice with the community.
>
> Cheers,
> Nathan
>
Re: Move to C99 for common code
Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt <sp...@gmail.com> wrote:
>
> >
> > Speaking of the Z80, would it be possible to run NuttX in a Grant Searle
> > / RC2014 platform with a 8k ROM /56k RAM split, or would any attempt
> > require banked memory?
> >
>
> I don't know if it is possible or not. I don't know if NuttX is viable on
> any CPU limited to a 64Kb address space. In their day, those 8-bit CPUs
> were programmed in highly tuned assembly language. it is hard to imagine
> running an OS that is almost as big as the addressable memory and being
> able to do anything meaningful. NuttX may have outgrown these platforms.
>
> I think that z80 architecture support is still important because there are
> so many derivatives from z80, like that FPGA in the ZX Spectrum Next (
> https://en.wikipedia.org/wiki/ZX_Spectrum_Next). That FPGA runs the z80
> with a extended address space using an MMU similar to the z180 but with
> smaller pages. Other derivatives like the z300 and the ez80 just support a
> wider address space. I have done a couple of ezo ports recently (like
> http://z20x.computer/).
>
> I appreciate this discussion about protecting the NuttX supported platforms.
I think non-arch-specific code should stick with C89 and we should not
be too eager to remove architectures that have these needs.
It's not too hard to tell people that non-arch-specific code needs to be C89.
We can catch it more easily in precheck by passing the C89 flag to the compiler.
Only in the case where an architecture is incomplete, unmaintained,
and NuttX isn't really viable for it anymore, should we consider
removing it.
We should have a rule that removing an arch should require a process
that makes it highly likely that we'd hear from any users who consider
that arch important.
For example, get the word out for some period of time and solicit
feedback. If no feedback, then mark the arch deprecated, produce
build-time warnings, require users to activate some kind of
CONFIG_DEPRECATED_ARCH to use it. In other words, do things to get
their attention. And then, have a mandatory waiting period to allow
enough time to either attract maintainers or be able to declare the
arch dead with a clear conscience.
> > So many RTOS are just for arm.
The whole point why I adopted NuttX is because of being able to move
my applications from one arch to another.
> Originally, NuttX was focused on the hobbyist, DIYer, and retro-computing
> enthusiast. But nowadays, it is dominated by businesses with business value
> systems that are sometimes not compatible with the needs or interests of
> hobbyists. That is why there is such a long discussion in the
> INVIOLABLE.md under "All Users Matter." That was essentially the contract
> I made when I agreed to give the OS to the community. But it is going to
> take some strong leadership to keep those values since the OS is controlled
> completely by businesses now and businesses tend to think only of their own
> needs.
We need more hobbyist/DIYer committers and PMC.
We need a short and professional presentation, targeted specifically
to business users, that clearly explains why it is in their best
interests to play nice with the community.
Cheers,
Nathan
Re: Move to C99 for common code
Posted by Gregory Nutt <sp...@gmail.com>.
>
> Speaking of the Z80, would it be possible to run NuttX in a Grant Searle
> / RC2014 platform with a 8k ROM /56k RAM split, or would any attempt
> require banked memory?
>
I don't know if it is possible or not. I don't know if NuttX is viable on
any CPU limited to a 64Kb address space. In their day, those 8-bit CPUs
were programmed in highly tuned assembly language. it is hard to imagine
running an OS that is almost as big as the addressable memory and being
able to do anything meaningful. NuttX may have outgrown these platforms.
I think that z80 architecture support is still important because there are
so many derivatives from z80, like that FPGA in the ZX Spectrum Next (
https://en.wikipedia.org/wiki/ZX_Spectrum_Next). That FPGA runs the z80
with a extended address space using an MMU similar to the z180 but with
smaller pages. Other derivatives like the z300 and the ez80 just support a
wider address space. I have done a couple of ezo ports recently (like
http://z20x.computer/).
I appreciate this discussion about protecting the NuttX supported platforms.
>
> So many RTOS are just for arm.
>
Originally, NuttX was focused on the hobbyist, DIYer, and retro-computing
enthusiast. But nowadays, it is dominated by businesses with business value
systems that are sometimes not compatible with the needs or interests of
hobbyists. That is why there is such a long discussion in the
INVIOLABLE.md under "All Users Matter." That was essentially the contract
I made when I agreed to give the OS to the community. But it is going to
take some strong leadership to keep those values since the OS is controlled
completely by businesses now and businesses tend to think only of their own
needs.
Re: Move to C99 for common code
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hi,
SDCC recently added a 6502 port, based on their HC08 port. I think it
has a chance to be better than cc65 or any gcc arsenal.
Yes, the 6502 8-bit hardware stack is very limited, but by paying the
price of a less efficient code, a software stack is possible.
Of course, such a port would probably be EXTREMELY limited and possiby
just a proof of concept, but a fun one for sure.
Speaking of the Z80, would it be possible to run NuttX in a Grant Searle
/ RC2014 platform with a 8k ROM /56k RAM split, or would any attempt
require banked memory?
I appreciate this discussion about protecting the NuttX supported platforms.
So many RTOS are just for arm.
Sebastien
Le 08/01/2022 à 15:46, Alan Carvalho de Assis a écrit :
> Yes, now I remember the reason to it has been removed.
>
> BTW, I think 6502 will face same issue because the stack point is only
> 8-bits (it will be limited to 256 bytes), correct?
>
> On 1/8/22, Gregory Nutt <sp...@gmail.com> wrote:
>> Support for the 8051 was removed for other reasons... that family has a
>> very small hardware stack that had to be saved and restored on each context
>> switch. That provided bigtime compatibility issues with other
>> architectures. That combined with the facts that (1) I never could get the
>> 8051 running reliably without stack overflows, and (2) the 8051 was not
>> really a viable platform for NuttX because it was so limited in other ways.
>>
>> That is ancient history from 2014. I used to carefully document why any
>> feature was removed from the OS and kept that here:
>> https://bitbucket.org/patacongo/obsoleted/src/60ec01456d8b09f5b813a5fd8865cdbd5a0ccc20/ChangeLog#lines-4
>>
>> On Sat, Jan 8, 2022 at 7:45 AM Alan Carvalho de Assis <ac...@gmail.com>
>> wrote:
>>
>>> Hi Tomasz,
>>>
>>> Currently NuttX doesn't support 6502 and even the support to 8051 was
>>> removed some years ago.
>>>
>>> BTW, I think it could be possible to support C99 for 6502 if you use gcc:
>>> https://github.com/itszor/gcc-6502-bits
>>>
>>> BR,
>>>
>>> Alan
>>>
>>> On 1/8/22, Tomasz CEDRO <to...@cedro.info> wrote:
>>>> On Sat, Jan 8, 2022 at 1:53 PM Gregory Nutt wrote:
>>>>> z80 holds all 8-bit ZiLOG architectures. That means
>>>>>
>>>>> z80 using the SDCC compiler
>>>>> z180 using the SDCC compiler
>>>>> ez80 which normally uses the ZiLOG compiler, but there is an
>>> experimental
>>>>> version of GCC for the ez80
>>>>>
>>>>> z16 uses only ZiLOG compiler
>>>>>
>>>>> Also consider SH1
>>>>>
>>>>> This will also require changes to INVIOLABLES.md and the coding
>>> standard.
>>>>> I would also recommend a formal vote to assure that you are following
>>> the
>>>>> will of the user base and not a personal agenda. There used to be a
>>>>> small
>>>>> but important group of retro computer folk using NuttX; this
>>>>> eliminates
>>>>> support for them. There is language in the INVIOLABLES that is there
>>>>> specifically to protect them from actions like this.
>>>>>
>>>>> I have not heard of anyone using these architectures recently. I
>>>>> would
>>>>> say
>>>>> that only ez80 is active with active development boards. There are
>>>>> occasional developments with z180-like hardware.
>>>> One day I would love to run NuttX on 6502.. it would be nice if C99
>>>> wont make it impossible (why should it?).. but my knowledge is too
>>>> small so I will look how the thread goes :-)
>>>>
>>>> --
>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>>>>
Re: Move to C99 for common code
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Yes, now I remember the reason to it has been removed.
BTW, I think 6502 will face same issue because the stack point is only
8-bits (it will be limited to 256 bytes), correct?
On 1/8/22, Gregory Nutt <sp...@gmail.com> wrote:
> Support for the 8051 was removed for other reasons... that family has a
> very small hardware stack that had to be saved and restored on each context
> switch. That provided bigtime compatibility issues with other
> architectures. That combined with the facts that (1) I never could get the
> 8051 running reliably without stack overflows, and (2) the 8051 was not
> really a viable platform for NuttX because it was so limited in other ways.
>
> That is ancient history from 2014. I used to carefully document why any
> feature was removed from the OS and kept that here:
> https://bitbucket.org/patacongo/obsoleted/src/60ec01456d8b09f5b813a5fd8865cdbd5a0ccc20/ChangeLog#lines-4
>
> On Sat, Jan 8, 2022 at 7:45 AM Alan Carvalho de Assis <ac...@gmail.com>
> wrote:
>
>> Hi Tomasz,
>>
>> Currently NuttX doesn't support 6502 and even the support to 8051 was
>> removed some years ago.
>>
>> BTW, I think it could be possible to support C99 for 6502 if you use gcc:
>> https://github.com/itszor/gcc-6502-bits
>>
>> BR,
>>
>> Alan
>>
>> On 1/8/22, Tomasz CEDRO <to...@cedro.info> wrote:
>> > On Sat, Jan 8, 2022 at 1:53 PM Gregory Nutt wrote:
>> >> z80 holds all 8-bit ZiLOG architectures. That means
>> >>
>> >> z80 using the SDCC compiler
>> >> z180 using the SDCC compiler
>> >> ez80 which normally uses the ZiLOG compiler, but there is an
>> experimental
>> >> version of GCC for the ez80
>> >>
>> >> z16 uses only ZiLOG compiler
>> >>
>> >> Also consider SH1
>> >>
>> >> This will also require changes to INVIOLABLES.md and the coding
>> standard.
>> >> I would also recommend a formal vote to assure that you are following
>> the
>> >> will of the user base and not a personal agenda. There used to be a
>> >> small
>> >> but important group of retro computer folk using NuttX; this
>> >> eliminates
>> >> support for them. There is language in the INVIOLABLES that is there
>> >> specifically to protect them from actions like this.
>> >>
>> >> I have not heard of anyone using these architectures recently. I
>> >> would
>> >> say
>> >> that only ez80 is active with active development boards. There are
>> >> occasional developments with z180-like hardware.
>> >
>> > One day I would love to run NuttX on 6502.. it would be nice if C99
>> > wont make it impossible (why should it?).. but my knowledge is too
>> > small so I will look how the thread goes :-)
>> >
>> > --
>> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>> >
>>
>
Re: Move to C99 for common code
Posted by Gregory Nutt <sp...@gmail.com>.
Support for the 8051 was removed for other reasons... that family has a
very small hardware stack that had to be saved and restored on each context
switch. That provided bigtime compatibility issues with other
architectures. That combined with the facts that (1) I never could get the
8051 running reliably without stack overflows, and (2) the 8051 was not
really a viable platform for NuttX because it was so limited in other ways.
That is ancient history from 2014. I used to carefully document why any
feature was removed from the OS and kept that here:
https://bitbucket.org/patacongo/obsoleted/src/60ec01456d8b09f5b813a5fd8865cdbd5a0ccc20/ChangeLog#lines-4
On Sat, Jan 8, 2022 at 7:45 AM Alan Carvalho de Assis <ac...@gmail.com>
wrote:
> Hi Tomasz,
>
> Currently NuttX doesn't support 6502 and even the support to 8051 was
> removed some years ago.
>
> BTW, I think it could be possible to support C99 for 6502 if you use gcc:
> https://github.com/itszor/gcc-6502-bits
>
> BR,
>
> Alan
>
> On 1/8/22, Tomasz CEDRO <to...@cedro.info> wrote:
> > On Sat, Jan 8, 2022 at 1:53 PM Gregory Nutt wrote:
> >> z80 holds all 8-bit ZiLOG architectures. That means
> >>
> >> z80 using the SDCC compiler
> >> z180 using the SDCC compiler
> >> ez80 which normally uses the ZiLOG compiler, but there is an
> experimental
> >> version of GCC for the ez80
> >>
> >> z16 uses only ZiLOG compiler
> >>
> >> Also consider SH1
> >>
> >> This will also require changes to INVIOLABLES.md and the coding
> standard.
> >> I would also recommend a formal vote to assure that you are following
> the
> >> will of the user base and not a personal agenda. There used to be a
> >> small
> >> but important group of retro computer folk using NuttX; this eliminates
> >> support for them. There is language in the INVIOLABLES that is there
> >> specifically to protect them from actions like this.
> >>
> >> I have not heard of anyone using these architectures recently. I would
> >> say
> >> that only ez80 is active with active development boards. There are
> >> occasional developments with z180-like hardware.
> >
> > One day I would love to run NuttX on 6502.. it would be nice if C99
> > wont make it impossible (why should it?).. but my knowledge is too
> > small so I will look how the thread goes :-)
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >
>
Re: Move to C99 for common code
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Tomasz,
Currently NuttX doesn't support 6502 and even the support to 8051 was
removed some years ago.
BTW, I think it could be possible to support C99 for 6502 if you use gcc:
https://github.com/itszor/gcc-6502-bits
BR,
Alan
On 1/8/22, Tomasz CEDRO <to...@cedro.info> wrote:
> On Sat, Jan 8, 2022 at 1:53 PM Gregory Nutt wrote:
>> z80 holds all 8-bit ZiLOG architectures. That means
>>
>> z80 using the SDCC compiler
>> z180 using the SDCC compiler
>> ez80 which normally uses the ZiLOG compiler, but there is an experimental
>> version of GCC for the ez80
>>
>> z16 uses only ZiLOG compiler
>>
>> Also consider SH1
>>
>> This will also require changes to INVIOLABLES.md and the coding standard.
>> I would also recommend a formal vote to assure that you are following the
>> will of the user base and not a personal agenda. There used to be a
>> small
>> but important group of retro computer folk using NuttX; this eliminates
>> support for them. There is language in the INVIOLABLES that is there
>> specifically to protect them from actions like this.
>>
>> I have not heard of anyone using these architectures recently. I would
>> say
>> that only ez80 is active with active development boards. There are
>> occasional developments with z180-like hardware.
>
> One day I would love to run NuttX on 6502.. it would be nice if C99
> wont make it impossible (why should it?).. but my knowledge is too
> small so I will look how the thread goes :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
Re: Move to C99 for common code
Posted by Tomasz CEDRO <to...@cedro.info>.
On Sat, Jan 8, 2022 at 1:53 PM Gregory Nutt wrote:
> z80 holds all 8-bit ZiLOG architectures. That means
>
> z80 using the SDCC compiler
> z180 using the SDCC compiler
> ez80 which normally uses the ZiLOG compiler, but there is an experimental
> version of GCC for the ez80
>
> z16 uses only ZiLOG compiler
>
> Also consider SH1
>
> This will also require changes to INVIOLABLES.md and the coding standard.
> I would also recommend a formal vote to assure that you are following the
> will of the user base and not a personal agenda. There used to be a small
> but important group of retro computer folk using NuttX; this eliminates
> support for them. There is language in the INVIOLABLES that is there
> specifically to protect them from actions like this.
>
> I have not heard of anyone using these architectures recently. I would say
> that only ez80 is active with active development boards. There are
> occasional developments with z180-like hardware.
One day I would love to run NuttX on 6502.. it would be nice if C99
wont make it impossible (why should it?).. but my knowledge is too
small so I will look how the thread goes :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Move to C99 for common code
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
According to SDCC page they have support to C99 and C11 see:
http://sdcc.sourceforge.net
Not sure if it applies to all MCU/CPU supported by the project.
But I agree we cannot move to C99 if it means removing support to some
architectures, we need to find a way to keep NuttX supporting them.
BR,
Alan
On 1/8/22, Gregory Nutt <sp...@gmail.com> wrote:
> z80 holds all 8-bit ZiLOG architectures. That means
>
> z80 using the SDCC compiler
> z180 using the SDCC compiler
> ez80 which normally uses the ZiLOG compiler, but there is an experimental
> version of GCC for the ez80
>
> z16 uses only ZiLOG compiler
>
> Also consider SH1
>
> This will also require changes to INVIOLABLES.md and the coding standard.
> I would also recommend a formal vote to assure that you are following the
> will of the user base and not a personal agenda. There used to be a small
> but important group of retro computer folk using NuttX; this eliminates
> support for them. There is language in the INVIOLABLES that is there
> specifically to protect them from actions like this.
>
> I have not heard of anyone using these architectures recently. I would say
> that only ez80 is active with active development boards. There are
> occasional developments with z180-like hardware.
>
> On Fri, Jan 7, 2022 at 11:40 PM Xiang Xiao <xi...@gmail.com>
> wrote:
>
>> Ceva we just added this week also supports C99, so we just need to check
>> avr, misoc, or1k, z16 and z80.
>>
>> On Sat, Jan 8, 2022 at 1:35 PM Petro Karashchenko <
>> petro.karashchenko@gmail.com> wrote:
>>
>> > In addition I just checked latest GCC with HC12 support is 3.0.4
>> > version.
>> > It have C99 integrated. Will check with AVR32, but will probably need
>> some
>> > help with others.
>> >
>> > Best regards,
>> > Petro
>> >
>> > On Sat, Jan 8, 2022, 7:15 AM Petro Karashchenko <
>> > petro.karashchenko@gmail.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > What about inline functions? Those are also a part on C99.
>> > >
>> > > Are those old architectures checked by the CI? I mean do we have a
>> proof
>> > > that those are still compilable with the latest release?
>> > >
>> > > Best regards,
>> > > Petro
>> > >
>> > > On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <xi...@gmail.com>
>> > wrote:
>> > >
>> > >>
>> > >>
>> > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
>> > >> petro.karashchenko@gmail.com> wrote:
>> > >>
>> > >>> Hello team,
>> > >>>
>> > >>> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a
>> > discussion
>> > >>> in one of the PR's related to C89 code compliance. Particularly
>> > related to
>> > >>> initializing a structure by field names (designated initializers).
>> Mr.
>> > @Xiang
>> > >>> Xiao <xi...@gmail.com> pointed out that "for the common
>> code
>> > >>> it is better to avoid C99 only features".
>> > >>> I examined the current NuttX code and see that currently common
>> > >>> code
>> is
>> > >>> far away from C89 already and things like "<stdbool.h>",
>> > "<inttypes.h>",
>> > >>> "snprintf", "designated initializers", "__VA_ARGS__" (variadic
>> > >>> macro)
>> > are
>> > >>> deeply embedded into the code.
>> > >>>
>> > >>>
>> > >> We need separate the features that come from the compiler and the
>> > >> standard library. Since the libc is provided by NuttX self:
>> > >>
>> > >> 1. The header files(e.g.stdbool.h, intttyes.h) and function(e.g.
>> > >> snprintf) can be used in common code since NuttX can provide the
>> > >> implementation for all arch even the arch use a very old compiler
>> > >> 2. The preprocessor (e.g. __VA_ARGS__) or language( designated
>> > >> initializers) feature need to avoid or incorporate into the
>> > conditional
>> > >> macro
>> > >>
>> > >> .
>> > >>
>> > >>> I would like to come up with the suggestion to make C99 as a
>> > >>> prerequisite for the compiler that is used to build NuttX code.
>> > >>>
>> > >>
>> > >> As Greg said, if compilers used on all arch supported by NuttX
>> > >> support
>> > >> C99, there is no reason to limit us to C89. The compiler status is a
>> > >> keypoint.
>> > >>
>> > >>
>> > >>>
>> > >>> Best regards,
>> > >>> Petro
>> > >>>
>> > >>>
>> >
>>
>
Re: Move to C99 for common code
Posted by Gregory Nutt <sp...@gmail.com>.
> Also consider SH1
>
And M16C
Re: Move to C99 for common code
Posted by Gregory Nutt <sp...@gmail.com>.
z80 holds all 8-bit ZiLOG architectures. That means
z80 using the SDCC compiler
z180 using the SDCC compiler
ez80 which normally uses the ZiLOG compiler, but there is an experimental
version of GCC for the ez80
z16 uses only ZiLOG compiler
Also consider SH1
This will also require changes to INVIOLABLES.md and the coding standard.
I would also recommend a formal vote to assure that you are following the
will of the user base and not a personal agenda. There used to be a small
but important group of retro computer folk using NuttX; this eliminates
support for them. There is language in the INVIOLABLES that is there
specifically to protect them from actions like this.
I have not heard of anyone using these architectures recently. I would say
that only ez80 is active with active development boards. There are
occasional developments with z180-like hardware.
On Fri, Jan 7, 2022 at 11:40 PM Xiang Xiao <xi...@gmail.com>
wrote:
> Ceva we just added this week also supports C99, so we just need to check
> avr, misoc, or1k, z16 and z80.
>
> On Sat, Jan 8, 2022 at 1:35 PM Petro Karashchenko <
> petro.karashchenko@gmail.com> wrote:
>
> > In addition I just checked latest GCC with HC12 support is 3.0.4 version.
> > It have C99 integrated. Will check with AVR32, but will probably need
> some
> > help with others.
> >
> > Best regards,
> > Petro
> >
> > On Sat, Jan 8, 2022, 7:15 AM Petro Karashchenko <
> > petro.karashchenko@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > What about inline functions? Those are also a part on C99.
> > >
> > > Are those old architectures checked by the CI? I mean do we have a
> proof
> > > that those are still compilable with the latest release?
> > >
> > > Best regards,
> > > Petro
> > >
> > > On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <xi...@gmail.com>
> > wrote:
> > >
> > >>
> > >>
> > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
> > >> petro.karashchenko@gmail.com> wrote:
> > >>
> > >>> Hello team,
> > >>>
> > >>> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a
> > discussion
> > >>> in one of the PR's related to C89 code compliance. Particularly
> > related to
> > >>> initializing a structure by field names (designated initializers).
> Mr.
> > @Xiang
> > >>> Xiao <xi...@gmail.com> pointed out that "for the common
> code
> > >>> it is better to avoid C99 only features".
> > >>> I examined the current NuttX code and see that currently common code
> is
> > >>> far away from C89 already and things like "<stdbool.h>",
> > "<inttypes.h>",
> > >>> "snprintf", "designated initializers", "__VA_ARGS__" (variadic macro)
> > are
> > >>> deeply embedded into the code.
> > >>>
> > >>>
> > >> We need separate the features that come from the compiler and the
> > >> standard library. Since the libc is provided by NuttX self:
> > >>
> > >> 1. The header files(e.g.stdbool.h, intttyes.h) and function(e.g.
> > >> snprintf) can be used in common code since NuttX can provide the
> > >> implementation for all arch even the arch use a very old compiler
> > >> 2. The preprocessor (e.g. __VA_ARGS__) or language( designated
> > >> initializers) feature need to avoid or incorporate into the
> > conditional
> > >> macro
> > >>
> > >> .
> > >>
> > >>> I would like to come up with the suggestion to make C99 as a
> > >>> prerequisite for the compiler that is used to build NuttX code.
> > >>>
> > >>
> > >> As Greg said, if compilers used on all arch supported by NuttX support
> > >> C99, there is no reason to limit us to C89. The compiler status is a
> > >> keypoint.
> > >>
> > >>
> > >>>
> > >>> Best regards,
> > >>> Petro
> > >>>
> > >>>
> >
>
Re: Move to C99 for common code
Posted by Xiang Xiao <xi...@gmail.com>.
Ceva we just added this week also supports C99, so we just need to check
avr, misoc, or1k, z16 and z80.
On Sat, Jan 8, 2022 at 1:35 PM Petro Karashchenko <
petro.karashchenko@gmail.com> wrote:
> In addition I just checked latest GCC with HC12 support is 3.0.4 version.
> It have C99 integrated. Will check with AVR32, but will probably need some
> help with others.
>
> Best regards,
> Petro
>
> On Sat, Jan 8, 2022, 7:15 AM Petro Karashchenko <
> petro.karashchenko@gmail.com> wrote:
>
> > Hi,
> >
> > What about inline functions? Those are also a part on C99.
> >
> > Are those old architectures checked by the CI? I mean do we have a proof
> > that those are still compilable with the latest release?
> >
> > Best regards,
> > Petro
> >
> > On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <xi...@gmail.com>
> wrote:
> >
> >>
> >>
> >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
> >> petro.karashchenko@gmail.com> wrote:
> >>
> >>> Hello team,
> >>>
> >>> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a
> discussion
> >>> in one of the PR's related to C89 code compliance. Particularly
> related to
> >>> initializing a structure by field names (designated initializers). Mr.
> @Xiang
> >>> Xiao <xi...@gmail.com> pointed out that "for the common code
> >>> it is better to avoid C99 only features".
> >>> I examined the current NuttX code and see that currently common code is
> >>> far away from C89 already and things like "<stdbool.h>",
> "<inttypes.h>",
> >>> "snprintf", "designated initializers", "__VA_ARGS__" (variadic macro)
> are
> >>> deeply embedded into the code.
> >>>
> >>>
> >> We need separate the features that come from the compiler and the
> >> standard library. Since the libc is provided by NuttX self:
> >>
> >> 1. The header files(e.g.stdbool.h, intttyes.h) and function(e.g.
> >> snprintf) can be used in common code since NuttX can provide the
> >> implementation for all arch even the arch use a very old compiler
> >> 2. The preprocessor (e.g. __VA_ARGS__) or language( designated
> >> initializers) feature need to avoid or incorporate into the
> conditional
> >> macro
> >>
> >> .
> >>
> >>> I would like to come up with the suggestion to make C99 as a
> >>> prerequisite for the compiler that is used to build NuttX code.
> >>>
> >>
> >> As Greg said, if compilers used on all arch supported by NuttX support
> >> C99, there is no reason to limit us to C89. The compiler status is a
> >> keypoint.
> >>
> >>
> >>>
> >>> Best regards,
> >>> Petro
> >>>
> >>>
>
Re: Move to C99 for common code
Posted by Petro Karashchenko <pe...@gmail.com>.
In addition I just checked latest GCC with HC12 support is 3.0.4 version.
It have C99 integrated. Will check with AVR32, but will probably need some
help with others.
Best regards,
Petro
On Sat, Jan 8, 2022, 7:15 AM Petro Karashchenko <
petro.karashchenko@gmail.com> wrote:
> Hi,
>
> What about inline functions? Those are also a part on C99.
>
> Are those old architectures checked by the CI? I mean do we have a proof
> that those are still compilable with the latest release?
>
> Best regards,
> Petro
>
> On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <xi...@gmail.com> wrote:
>
>>
>>
>> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
>> petro.karashchenko@gmail.com> wrote:
>>
>>> Hello team,
>>>
>>> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a discussion
>>> in one of the PR's related to C89 code compliance. Particularly related to
>>> initializing a structure by field names (designated initializers). Mr. @Xiang
>>> Xiao <xi...@gmail.com> pointed out that "for the common code
>>> it is better to avoid C99 only features".
>>> I examined the current NuttX code and see that currently common code is
>>> far away from C89 already and things like "<stdbool.h>", "<inttypes.h>",
>>> "snprintf", "designated initializers", "__VA_ARGS__" (variadic macro) are
>>> deeply embedded into the code.
>>>
>>>
>> We need separate the features that come from the compiler and the
>> standard library. Since the libc is provided by NuttX self:
>>
>> 1. The header files(e.g.stdbool.h, intttyes.h) and function(e.g.
>> snprintf) can be used in common code since NuttX can provide the
>> implementation for all arch even the arch use a very old compiler
>> 2. The preprocessor (e.g. __VA_ARGS__) or language( designated
>> initializers) feature need to avoid or incorporate into the conditional
>> macro
>>
>> .
>>
>>> I would like to come up with the suggestion to make C99 as a
>>> prerequisite for the compiler that is used to build NuttX code.
>>>
>>
>> As Greg said, if compilers used on all arch supported by NuttX support
>> C99, there is no reason to limit us to C89. The compiler status is a
>> keypoint.
>>
>>
>>>
>>> Best regards,
>>> Petro
>>>
>>>
Re: Move to C99 for common code
Posted by Petro Karashchenko <pe...@gmail.com>.
Hi,
What about inline functions? Those are also a part on C99.
Are those old architectures checked by the CI? I mean do we have a proof
that those are still compilable with the latest release?
Best regards,
Petro
On Sat, Jan 8, 2022, 6:37 AM Xiang Xiao <xi...@gmail.com> wrote:
>
>
> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
> petro.karashchenko@gmail.com> wrote:
>
>> Hello team,
>>
>> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a discussion
>> in one of the PR's related to C89 code compliance. Particularly related to
>> initializing a structure by field names (designated initializers). Mr. @Xiang
>> Xiao <xi...@gmail.com> pointed out that "for the common code
>> it is better to avoid C99 only features".
>> I examined the current NuttX code and see that currently common code is
>> far away from C89 already and things like "<stdbool.h>", "<inttypes.h>",
>> "snprintf", "designated initializers", "__VA_ARGS__" (variadic macro) are
>> deeply embedded into the code.
>>
>>
> We need separate the features that come from the compiler and the standard
> library. Since the libc is provided by NuttX self:
>
> 1. The header files(e.g.stdbool.h, intttyes.h) and function(e.g.
> snprintf) can be used in common code since NuttX can provide the
> implementation for all arch even the arch use a very old compiler
> 2. The preprocessor (e.g. __VA_ARGS__) or language( designated
> initializers) feature need to avoid or incorporate into the conditional
> macro
>
> .
>
>> I would like to come up with the suggestion to make C99 as a prerequisite
>> for the compiler that is used to build NuttX code.
>>
>
> As Greg said, if compilers used on all arch supported by NuttX support
> C99, there is no reason to limit us to C89. The compiler status is a
> keypoint.
>
>
>>
>> Best regards,
>> Petro
>>
>>
Re: Move to C99 for common code
Posted by Xiang Xiao <xi...@gmail.com>.
On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko <
petro.karashchenko@gmail.com> wrote:
> Hello team,
>
> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a discussion
> in one of the PR's related to C89 code compliance. Particularly related to
> initializing a structure by field names (designated initializers). Mr. @Xiang
> Xiao <xi...@gmail.com> pointed out that "for the common code it
> is better to avoid C99 only features".
> I examined the current NuttX code and see that currently common code is
> far away from C89 already and things like "<stdbool.h>", "<inttypes.h>",
> "snprintf", "designated initializers", "__VA_ARGS__" (variadic macro) are
> deeply embedded into the code.
>
>
We need separate the features that come from the compiler and the standard
library. Since the libc is provided by NuttX self:
1. The header files(e.g.stdbool.h, intttyes.h) and function(e.g.
snprintf) can be used in common code since NuttX can provide the
implementation for all arch even the arch use a very old compiler
2. The preprocessor (e.g. __VA_ARGS__) or language( designated
initializers) feature need to avoid or incorporate into the conditional
macro
.
> I would like to come up with the suggestion to make C99 as a prerequisite
> for the compiler that is used to build NuttX code.
>
As Greg said, if compilers used on all arch supported by NuttX support C99,
there is no reason to limit us to C89. The compiler status is a keypoint.
>
> Best regards,
> Petro
>
>
Re: Move to C99 for common code
Posted by Gregory Nutt <sp...@gmail.com>.
The only issue is that there are several architectures that only have c89
compilers available for them. Moving to C11 for the common code is
equivalent to saying that we will no longer support those architectures.
If we agree that we no longer need to support those architectures and that
it will not be an issue in the future, then there is no reason not to adopt
C11.
I forget all of the architectures that have no C11 compilers available.
This would apply to architectures that do not use GCC or mainstream tools
(like the ZiLOG 8- and 16-bit architectures) and also to old architectures
that use GCC but are not supported by the most recent versions of GCC.
like HCS12, AVR32, and others.
So discontinuing support for these architectures is really the crux of this
discussion. This is a decision that should not be taken lightly and I
would recommend that we have a formal discussion with the community and a
vote by the PPMC before we discontinue support for any architectures.
All users matter.
On Fri, Jan 7, 2022 at 4:29 PM Petro Karashchenko <
petro.karashchenko@gmail.com> wrote:
> Hello team,
>
> Recently I mr. @Xiang Xiao <xi...@gmail.com> had a discussion in
> one of the PR's related to C89 code compliance. Particularly related to
> initializing a structure by field names (designated initializers). Mr.
> @Xiang
> Xiao <xi...@gmail.com> pointed out that "for the common code it
> is better to avoid C99 only features".
> I examined the current NuttX code and see that currently common code is far
> away from C89 already and things like "<stdbool.h>", "<inttypes.h>",
> "snprintf", "designated initializers", "__VA_ARGS__" (variadic macro) are
> deeply embedded into the code.
>
> I would like to come up with the suggestion to make C99 as a prerequisite
> for the compiler that is used to build NuttX code.
>
> Best regards,
> Petro
>