Move to C99 for common code
Hello team, Recently I mr. @Xiang Xiao 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 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 "", "", "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
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.karashche...@gmail.com> wrote: > Hello team, > > Recently I mr. @Xiang Xiao 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 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 "", "", > "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
On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < petro.karashche...@gmail.com> wrote: > Hello team, > > Recently I mr. @Xiang Xiao 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 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 "", "", > "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
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 wrote: > > > On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < > petro.karashche...@gmail.com> wrote: > >> Hello team, >> >> Recently I mr. @Xiang Xiao 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 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 "", "", >> "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
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.karashche...@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 wrote: > >> >> >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < >> petro.karashche...@gmail.com> wrote: >> >>> Hello team, >>> >>> Recently I mr. @Xiang Xiao 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 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 "", "", >>> "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
On Sat, Jan 8, 2022 at 1:15 PM Petro Karashchenko < petro.karashche...@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 wrote: > > > > > > > On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < > > petro.karashche...@gmail.com> wrote: > > > >> Hello team, > >> > >> Recently I mr. @Xiang Xiao 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 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 "", "", > >> "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
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.karashche...@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.karashche...@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 > wrote: > > > >> > >> > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < > >> petro.karashche...@gmail.com> wrote: > >> > >>> Hello team, > >>> > >>> Recently I mr. @Xiang Xiao 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 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 "", > "", > >>> "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
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 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.karashche...@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.karashche...@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 > > wrote: > > > > > >> > > >> > > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < > > >> petro.karashche...@gmail.com> wrote: > > >> > > >>> Hello team, > > >>> > > >>> Recently I mr. @Xiang Xiao 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 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 "", > > "", > > >>> "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
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.karashche...@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 wrote: > > > > > > > On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < > > petro.karashche...@gmail.com> wrote: > > > >> Hello team, > >> > >> Recently I mr. @Xiang Xiao 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 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 "", "", > >> "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
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 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 > 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.karashche...@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.karashche...@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 >> > wrote: >> > > >> > >> >> > >> >> > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < >> > >> petro.karashche...@gmail.com> wrote: >> > >> >> > >>> Hello team, >> > >>> >> > >>> Recently I mr. @Xiang Xiao 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 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 "", >> > "", >> > >>> "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
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, 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 > 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.karashche...@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.karashche...@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 > > > wrote: > > > > > > > >> > > > >> > > > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < > > > >> petro.karashche...@gmail.com> wrote: > > > >> > > > >>> Hello team, > > > >>> > > > >>> Recently I mr. @Xiang Xiao 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 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 "", > > > "", > > > >>> "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
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
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 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, 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 >> 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.karashche...@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.karashche...@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 >> > > wrote: >> > > > >> > > >> >> > > >> >> > > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < >> > > >> petro.karashche...@gmail.com> wrote: >> > > >> >> > > >>> Hello team, >> > > >>> >> > > >>> Recently I mr. @Xiang Xiao 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 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 "", >> > > "", >> > > >>> "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
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 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
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, 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 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, 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 > >> 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.karashche...@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.karashche...@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 < > xiaoxiang781...@gmail.com> > >> > > wrote: > >> > > > > >> > > >> > >> > > >> > >> > > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < > >> > > >> petro.karashche...@gmail.com> wrote: > >> > > >> > >> > > >>> Hello team, > >> > > >>> > >> > > >>> Recently I mr. @Xiang Xiao 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 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 "", > >> > > "", > >> > > >>> "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 al
Re: Move to C99 for common code
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 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 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
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 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 > 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 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
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 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.karashche...@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 > wrote: > > > > > > > > > > > On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < > > > petro.karashche...@gmail.com> wrote: > > > > > >> Hello team, > > >> > > >> Recently I mr. @Xiang Xiao 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 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 "", > "", > > >> "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
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 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, > 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 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, 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 > > > >> 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.karashche...@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.karashche...@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 < > > xiaoxiang781...@gmail.com> > > >> > > wrote: > > >> > > > > > >> > > >> > > >> > > >> > > >> > > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < > > >> > > >> petro.karashche...@gmail.com> wrote: > > >> > > >> > > >> > > >>> Hello team, > > >> > > >>> > > >> > > >>> Recently I mr. @Xiang Xiao 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 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 "", > > >> > > "", > > >> > > >>> "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 > > >> > > >>
Re: Move to C99 for common code
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.karashche...@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 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, > > 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 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, 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 < > xiaoxiang781...@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.karashche...@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.karashche...@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 < > > > xiaoxiang781...@gmail.com> > > > >> > > wrote: > > > >> > > > > > > >> > > >> > > > >> > > >> > > > >> > > >> On Sat, Jan 8, 2022 at 6:29 AM Petro Karashchenko < > > > >> > > >> petro.karashche...@gmail.com> wrote: > > > >> > > >> > > > >> > > >>> Hello team, > > > >> > > >>> > > > >> > > >>> Recently I mr. @Xiang Xiao 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 pointed out that "for the > > > common > > > >> > code > > >
Re: Move to C99 for common code
> Also consider SH1 > And M16C
Re: Move to C99 for common code
On Sat, Jan 8, 2022 at 11:34 AM Alan Carvalho de Assis 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
On 1/9/22, Nathan Hartman wrote: > On Sat, Jan 8, 2022 at 11:34 AM Alan Carvalho de Assis > 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
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 wrote: > On 1/9/22, Nathan Hartman wrote: > > On Sat, Jan 8, 2022 at 11:34 AM Alan Carvalho de Assis < > acas...@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
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
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 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 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 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
> > 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
On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt 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
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 пише: > On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt 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
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.karashche...@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 > пише: > > > On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt > 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
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 : H END : H LOADED: H (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 00 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 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.karashche...@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 >> пише: >> >> > On Mon, Jan 10, 2022 at 9:15 AM Gregory Nutt >> 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 >> > bui
RE: Move to C99 for common code
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
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 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. >