Re: Re: Reevaluate the C89 Requirement
On Wed, Aug 31, 2022 at 11:06 AM Gregory Nutt wrote: > > > There used to be one defining inline to be nothing for ZDS-II . It would > > > only be necessary to restore it for ZDS-II. This does not fix the > > function > > > duplication of static inline functions in header files, however. > > > > Is the duplication really a problem, though? > > > > After all, the whole point of a static inline function is to insert > > the code directly at the call sites, which implies duplication and > > larger code footprint. Ostensibly static inline should only be used > > for "very small" functions. > > > > It can be and was in the past. It depends not only on the size of the > static inline function but also on how many are in a header file and how > many times the header file is included. There are 15 in ctype.h. I suppose this is made much worse when the compiler does not automatically remove unused functions. There may be a way to workaround this. The idea is to put the static inline function in a header, but wrap it with some preprocessor logic so that when the compiler does not support static inline, it would read an extern declaration rather than the entire function. Then, in only one source file, the header is included immediately after defining some IMPLEMENTATION symbol. So only in that one source file, the compiler reads the entire function. The header may be included from many files, but only one file will define IMPLEMENTATION (or any desired name) before the include. > I removed most of the others a couple of years ago (replacing them with > macros)still , but we grew more since that PR. But I think that the > situation is not so bad now. > > Another problem (for SDCC only) is this: > https://acassis.wordpress.com/2022/01/14/testing-nuttx-rtos-on-z80-simulator/ Ah yes the passing struct as value problem. I think standard C89 is supposed to support that, so this is a limitation in SDCC rather than a problem on our end? Nathan
Re: Re: Reevaluate the C89 Requirement
> There used to be one defining inline to be nothing for ZDS-II . It would > > only be necessary to restore it for ZDS-II. This does not fix the > function > > duplication of static inline functions in header files, however. > > Is the duplication really a problem, though? > > After all, the whole point of a static inline function is to insert > the code directly at the call sites, which implies duplication and > larger code footprint. Ostensibly static inline should only be used > for "very small" functions. > It can be and was in the past. It depends not only on the size of the static inline function but also on how many are in a header file and how many times the header file is included. There are 15 in ctype.h. I removed most of the others a couple of years ago (replacing them with macros)still , but we grew more since that PR. But I think that the situation is not so bad now. Another problem (for SDCC only) is this: https://acassis.wordpress.com/2022/01/14/testing-nuttx-rtos-on-z80-simulator/
Re: Re: Reevaluate the C89 Requirement
On Tue, Aug 30, 2022 at 10:45 AM Gregory Nutt wrote: > z8, ez80, and ZNEO using the ZiLOG ZDS-II compiler. I don't know the > current outstanding issues with that compiler. The Z80 parts currently use > SDCC but could also use one of several other open source compilers > such as Z88dk > which I know nothing about. I know nothing about Z88DK either, except that it is at https://github.com/z88dk/z88dk and appears to be an active project. It seems worth looking into. This article (from 2016) explains some of the compiler options: https://feilipu.me/2016/09/16/z80-c-code-development-with-eclipse-and-z88dk/ Personally I am a fan of supporting as many compilers as possible. Every compiler reads the code a little bit differently and can notice and warn about different things. The more compilers you can build and run your code with, the better the chances that you catch and fix the common mistakes. If we become a project that only builds on GCC and/or clang, then I think we will miss out on a lot of valuable diagnostics. Cheers, Nathan
Re: Re: Reevaluate the C89 Requirement
On Tue, Aug 30, 2022 at 4:16 PM Gregory Nutt wrote: > > > compiler.h has changed a lot. Does it still support compilers without > > > inline support? It appears not. I used to define inline to be nothing > > for > > > ZDS-II which worked okay except for static inline functions in header > > files > > > which would be replicated. > > > > > > > If this is acceptable, I could create a new macro in compiler.h for it. > > > > There used to be one defining inline to be nothing for ZDS-II . It would > only be necessary to restore it for ZDS-II. This does not fix the function > duplication of static inline functions in header files, however. Is the duplication really a problem, though? After all, the whole point of a static inline function is to insert the code directly at the call sites, which implies duplication and larger code footprint. Ostensibly static inline should only be used for "very small" functions. Cheers, Nathan
Re: Re: Reevaluate the C89 Requirement
Since SDCC supports Zilog chipset very well, why not switch from ZDS-II to > SDCC? > SDCC supports z80 and z180 but none of the other ZiLOG chipsets. ez80 has an unverified GCC port but ZDS-II is the only compiler option for the remaining parts. See http://sdcc.sourceforge.net/ > > compiler.h has changed a lot. Does it still support compilers without > > inline support? It appears not. I used to define inline to be nothing > for > > ZDS-II which worked okay except for static inline functions in header > files > > which would be replicated. > > > > If this is acceptable, I could create a new macro in compiler.h for it. > There used to be one defining inline to be nothing for ZDS-II . It would only be necessary to restore it for ZDS-II. This does not fix the function duplication of static inline functions in header files, however.
Re: Reevaluate the C89 Requirement
On Tue, Aug 30, 2022 at 5:30 PM Sebastien Lorquet wrote: > Hi, > > That would be -1 for me too. > > Reason 1 from Nathan could change my vote. > > But reason 2 would be a shame. We have one of the few a RTOS that > support CPUs outside ARM. > > > TBH, there is no solid technical reason to change this rule. Most of the > things mentioned in this comment are syntactic sugar that can be > supported with macros. > > It isn't always possible, here is an examples: https://github.com/apache/incubator-nuttx/pull/6926/files#diff-c8b3d3e48a21d03758b14794aaba6c9d818e349a2ce2bdc873f529daf5746abfR315-R328 Functions which return some value are hard to convert to macro in no trivial case. But inlining of simple and frequently used functions is a very important method to improve the performance. > Sebastien > > Le 30/08/2022 à 03:18, Nathan Hartman a écrit : > > On Mon, Aug 29, 2022 at 7:54 PM Alan Rosenthal > > > wrote: > > > >> Hi! > >> > >> What needs to be done to open the discussion to consider changing the > >> rules? > >> > >> Also please see a very detailed comment on the github issue here by > >> @robertlipe: > >> > https://github.com/apache/incubator-nuttx/issues/6896#issuecomment-1227971503 > >> > > > > Basically what Greg said: motivate someone of the PPMC to call a vote. > > > > Just FYI, based on what Byron points out with regard to the Zilog > families > > needing C89 (and possibly other archs that weren't mentioned), I would > > probably vote -1 unless either: > > > > 1) there is a toolchain, which is complete (not "experimental") that > > supports these platforms, or: > > > > 2) someone can convince me that no one cares about these architectures > > anymore, such as if it's shown that NuttX already contains significant > > breakage on these platforms that prevents them from working anyway, no > one > > has complained, and it has gone unfixed for several years > > > > If 1 or 2 (or both) I'm okay with it. But if changing the rules will > leave > > users in the dust, then I'm not okay with it. > > > > Just my thoughts... I'll be glad to hear the thoughts of others. > > > > Cheers, > > Nathan > > >
Re: Re: Reevaluate the C89 Requirement
On Wed, Aug 31, 2022 at 3:39 AM Gregory Nutt wrote: > Yes. 2.95 > > > > > Classic Z80 is probably not viable due to the 64Kb address limitation > but > > > is still relevant for Z80 derived parts with MMUs such as Z180 and the > ZX > > > Spectrum Next or with wider address buses such as the eZ80. z8 was > never > > > well tested. But eZ80 and ZNEO have been important platforms to > support > > > and are/were needed by a few still active products. > > > > > > z8, ez80, and ZNEO using the ZiLOG ZDS-II compiler. I don't know the > > > current outstanding issues with that compiler. The Z80 parts currently > > use > > > SDCC but could also use one of several other open source compilers > > > such as Z88dk > > > which I know nothing about. > > > > > > > > From http://sdcc.sourceforge.net/doc/sdccman.pdf, inline is supported. > > > > But ZDS-II does not support inline. > > Since SDCC supports Zilog chipset very well, why not switch from ZDS-II to SDCC? > compiler.h has changed a lot. Does it still support compilers without > inline support? It appears not. I used to define inline to be nothing for > ZDS-II which worked okay except for static inline functions in header files > which would be replicated. > If this is acceptable, I could create a new macro in compiler.h for it.
Re: Re: Reevaluate the C89 Requirement
Yes. 2.95 > > Classic Z80 is probably not viable due to the 64Kb address limitation but > > is still relevant for Z80 derived parts with MMUs such as Z180 and the ZX > > Spectrum Next or with wider address buses such as the eZ80. z8 was never > > well tested. But eZ80 and ZNEO have been important platforms to support > > and are/were needed by a few still active products. > > > > z8, ez80, and ZNEO using the ZiLOG ZDS-II compiler. I don't know the > > current outstanding issues with that compiler. The Z80 parts currently > use > > SDCC but could also use one of several other open source compilers > > such as Z88dk > > which I know nothing about. > > > > > From http://sdcc.sourceforge.net/doc/sdccman.pdf, inline is supported. > > But ZDS-II does not support inline. compiler.h has changed a lot. Does it still support compilers without inline support? It appears not. I used to define inline to be nothing for ZDS-II which worked okay except for static inline functions in header files which would be replicated.
Re: Re: Reevaluate the C89 Requirement
On Tue, Aug 30, 2022 at 10:43 PM Gregory Nutt wrote: > > Just FYI, based on what Byron points out with regard to the Zilog > families needing C89 (and possibly other archs that weren't mentioned), I > would probably vote -1 unless... > > There have been several other cases over the years where there were ports > to classic architectures no longer supported by contemporary GCC. I recall > a project a few years back that needed to use GCC 2.9.3 because that was > the only toolchain available. > > I can't find GCC 2.9.3 online document, the closing one is 2.95( https://gcc.gnu.org/releases.html): which support inline: https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC92 > The SH1 architecture is still in the source tree and I believe that support > for SH1 is only available in GCC 3.3.6 which is c89. > > GCC 3.3.6 support inline and designated initialization: https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Inline.html#Inline https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Designated-Inits.html#Designated-Inits > > 2) someone can convince me that no one cares about these > architectures > > anymore, such as if it's shown that NuttX already contains > significant > > breakage on these platforms that prevents them from working anyway, > no one > > has complained, and it has gone unfixed for several years > > If someone takes an arch seriously, he should enable the automation ci build for that arch at least. Otherwise, nobody can promise his change will never break the seldom used arch. > Classic Z80 is probably not viable due to the 64Kb address limitation but > is still relevant for Z80 derived parts with MMUs such as Z180 and the ZX > Spectrum Next or with wider address buses such as the eZ80. z8 was never > well tested. But eZ80 and ZNEO have been important platforms to support > and are/were needed by a few still active products. > > z8, ez80, and ZNEO using the ZiLOG ZDS-II compiler. I don't know the > current outstanding issues with that compiler. The Z80 parts currently use > SDCC but could also use one of several other open source compilers > such as Z88dk > which I know nothing about. > > >From http://sdcc.sourceforge.net/doc/sdccman.pdf, inline is supported. > Breakage in less commonly used ports is just a fact of life. Our policy in > the past (eg., Windows native build) was not to remove support just because > of breakage. Breakage can always be fixed, removed architectures cannot. > >From my experience, the most common breakage is inline and designated initialization. From the above summary, we can relax the inline keyword at least.
Re: Re: Reevaluate the C89 Requirement
> Just FYI, based on what Byron points out with regard to the Zilog families needing C89 (and possibly other archs that weren't mentioned), I would probably vote -1 unless... There have been several other cases over the years where there were ports to classic architectures no longer supported by contemporary GCC. I recall a project a few years back that needed to use GCC 2.9.3 because that was the only toolchain available. The SH1 architecture is still in the source tree and I believe that support for SH1 is only available in GCC 3.3.6 which is c89. > 2) someone can convince me that no one cares about these architectures > anymore, such as if it's shown that NuttX already contains significant > breakage on these platforms that prevents them from working anyway, no one > has complained, and it has gone unfixed for several years Classic Z80 is probably not viable due to the 64Kb address limitation but is still relevant for Z80 derived parts with MMUs such as Z180 and the ZX Spectrum Next or with wider address buses such as the eZ80. z8 was never well tested. But eZ80 and ZNEO have been important platforms to support and are/were needed by a few still active products. z8, ez80, and ZNEO using the ZiLOG ZDS-II compiler. I don't know the current outstanding issues with that compiler. The Z80 parts currently use SDCC but could also use one of several other open source compilers such as Z88dk which I know nothing about. Breakage in less commonly used ports is just a fact of life. Our policy in the past (eg., Windows native build) was not to remove support just because of breakage. Breakage can always be fixed, removed architectures cannot.
Re: Reevaluate the C89 Requirement
-1 for the same reasons On Tue, 30 Aug 2022, 11:30 Sebastien Lorquet, wrote: > Hi, > > That would be -1 for me too. > > Reason 1 from Nathan could change my vote. > > But reason 2 would be a shame. We have one of the few a RTOS that > support CPUs outside ARM. > > > TBH, there is no solid technical reason to change this rule. Most of the > things mentioned in this comment are syntactic sugar that can be > supported with macros. > > > Sebastien > > Le 30/08/2022 à 03:18, Nathan Hartman a écrit : > > On Mon, Aug 29, 2022 at 7:54 PM Alan Rosenthal > > > wrote: > > > >> Hi! > >> > >> What needs to be done to open the discussion to consider changing the > >> rules? > >> > >> Also please see a very detailed comment on the github issue here by > >> @robertlipe: > >> > https://github.com/apache/incubator-nuttx/issues/6896#issuecomment-1227971503 > >> > > > > Basically what Greg said: motivate someone of the PPMC to call a vote. > > > > Just FYI, based on what Byron points out with regard to the Zilog > families > > needing C89 (and possibly other archs that weren't mentioned), I would > > probably vote -1 unless either: > > > > 1) there is a toolchain, which is complete (not "experimental") that > > supports these platforms, or: > > > > 2) someone can convince me that no one cares about these architectures > > anymore, such as if it's shown that NuttX already contains significant > > breakage on these platforms that prevents them from working anyway, no > one > > has complained, and it has gone unfixed for several years > > > > If 1 or 2 (or both) I'm okay with it. But if changing the rules will > leave > > users in the dust, then I'm not okay with it. > > > > Just my thoughts... I'll be glad to hear the thoughts of others. > > > > Cheers, > > Nathan > > >
Re: Reevaluate the C89 Requirement
Hi, That would be -1 for me too. Reason 1 from Nathan could change my vote. But reason 2 would be a shame. We have one of the few a RTOS that support CPUs outside ARM. TBH, there is no solid technical reason to change this rule. Most of the things mentioned in this comment are syntactic sugar that can be supported with macros. Sebastien Le 30/08/2022 à 03:18, Nathan Hartman a écrit : On Mon, Aug 29, 2022 at 7:54 PM Alan Rosenthal wrote: Hi! What needs to be done to open the discussion to consider changing the rules? Also please see a very detailed comment on the github issue here by @robertlipe: https://github.com/apache/incubator-nuttx/issues/6896#issuecomment-1227971503 Basically what Greg said: motivate someone of the PPMC to call a vote. Just FYI, based on what Byron points out with regard to the Zilog families needing C89 (and possibly other archs that weren't mentioned), I would probably vote -1 unless either: 1) there is a toolchain, which is complete (not "experimental") that supports these platforms, or: 2) someone can convince me that no one cares about these architectures anymore, such as if it's shown that NuttX already contains significant breakage on these platforms that prevents them from working anyway, no one has complained, and it has gone unfixed for several years If 1 or 2 (or both) I'm okay with it. But if changing the rules will leave users in the dust, then I'm not okay with it. Just my thoughts... I'll be glad to hear the thoughts of others. Cheers, Nathan
Re: Re: Reevaluate the C89 Requirement
On Tue, Aug 30, 2022 at 3:18 AM Nathan Hartman wrote: > Just my thoughts... I'll be glad to hear the thoughts of others. I can understand both sides.. and that this is quite a large architectural change that would impact both compatibility and workload.. maybe a clear list of pros (+1) and cons (-1) would make this situation more clear and accountable with the numbers behind? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Re: Reevaluate the C89 Requirement
On Mon, Aug 29, 2022 at 7:54 PM Alan Rosenthal wrote: > Hi! > > What needs to be done to open the discussion to consider changing the > rules? > > Also please see a very detailed comment on the github issue here by > @robertlipe: > https://github.com/apache/incubator-nuttx/issues/6896#issuecomment-1227971503 > Basically what Greg said: motivate someone of the PPMC to call a vote. Just FYI, based on what Byron points out with regard to the Zilog families needing C89 (and possibly other archs that weren't mentioned), I would probably vote -1 unless either: 1) there is a toolchain, which is complete (not "experimental") that supports these platforms, or: 2) someone can convince me that no one cares about these architectures anymore, such as if it's shown that NuttX already contains significant breakage on these platforms that prevents them from working anyway, no one has complained, and it has gone unfixed for several years If 1 or 2 (or both) I'm okay with it. But if changing the rules will leave users in the dust, then I'm not okay with it. Just my thoughts... I'll be glad to hear the thoughts of others. Cheers, Nathan
Re: Re: Reevaluate the C89 Requirement
You would probably need to motivate a member of the PPMC to host a vote. No one person should make a decision like this. A vote confirms the will of the majority of the PPMC. For the case of code modifications, there are special voting rules that apply: https://www.apache.org/foundation/voting.html On Mon, Aug 29, 2022 at 5:55 PM Alan Rosenthal wrote: > Hi! > > What needs to be done to open the discussion to consider changing the > rules? > > Also please see a very detailed comment on the github issue here by > @robertlipe: > https://github.com/apache/incubator-nuttx/issues/6896#issuecomment-1227971503 > > Thanks, > > Alan > > On 2022/08/25 07:07:43 Byron Ellacott wrote: > > Hi, > > > > On Wed, Aug 24, 2022 at 11:58 PM Xiang Xiao > > wrote: > > > > > On Wed, Aug 24, 2022 at 11:38 AM Nathan Hartman > > > wrote: > > > > > > > On Tue, Aug 23, 2022 at 8:33 PM Alan Rosenthal < > alan.rosent...@gmail.com > > > > > > > > wrote: > > > > > > > > > Hello NuttXers, > > > > > > > > > > I recently posted an issue to the NuttX Github page: > > > > > https://github.com/apache/incubator-nuttx/issues/6896 > > > > > > > > > > I'll summarize my thoughts here. > > > > > > > > > > Currently NuttX has a C89 requirement. However, there is code in > the > > > > > codebase today that is not C89 compliant. Rather than reworking > > > > > existing code to be C89, we should reevaluate the C89 requirement. > > > > > > > > > > C99 and C11 have added a lot of language features, and by updating > the > > > C > > > > > standard to a newer version, we will add more tools to the NuttX > > > toolbox. > > > > > > > > > > > > > > > > Hello Alan, > > > > > > > > Thanks for sharing your thoughts. > > > > > > > > I believe one of the big reasons for C89 compliance in the codebase > is > > > > because NuttX supports a wide range of microcontroller chips, not all > of > > > > which have a C99 or newer toolchain available. > > > > > > > > > > > Here is the arch supported by NuttX: > > > C99 > > > arm Y > > > arm64 Y > > > avr Y > > > ceva Y > > > hc > > > mips Y > > > misoc > > > or1k Y > > > renesas Y > > > risc-v Y > > > sim Y > > > sparc Y > > > x86 Y > > > x86_64 Y > > > xtensa Y > > > z16 > > > z80 > > > I don't know which compiler is used for hc, misoc, z16 and z80, but > other > > > arches support C99 very well. > > > So, the question is whether the C99 requirement will impact these four > > > arches. > > > > > > > All of the Zilog family CPUs (z8, z16, z80, z180, ez80) use the ZDS-II > > development software released by Zilog by default. The C compiler in > ZDS-II > > is C89 and a C99 requirement will stop the successful build of the z16 > and > > z80 (z80, z180, ez80 cpu) arches. > > > > Some time ago I contributed the necessary changes for the eZ80 target to > > build using an experimental release of clang with Z80 and eZ80 support, > but > > it's not been sufficient priority for me to either contribute the > automated > > tests to have it continue to build, nor to even keep reasonably up to > date > > with NuttX changes, so I can't say for sure that it still builds > correctly. > > If it does build, then the eZ80 CPU in the z80 arch would at least still > be > > usable for those willing to use an experimental clang port. > > > > -- > > bje > > >
RE: Re: Reevaluate the C89 Requirement
Hi! What needs to be done to open the discussion to consider changing the rules? Also please see a very detailed comment on the github issue here by @robertlipe: https://github.com/apache/incubator-nuttx/issues/6896#issuecomment-1227971503 Thanks, Alan On 2022/08/25 07:07:43 Byron Ellacott wrote: > Hi, > > On Wed, Aug 24, 2022 at 11:58 PM Xiang Xiao > wrote: > > > On Wed, Aug 24, 2022 at 11:38 AM Nathan Hartman > > wrote: > > > > > On Tue, Aug 23, 2022 at 8:33 PM Alan Rosenthal < alan.rosent...@gmail.com > > > > > > wrote: > > > > > > > Hello NuttXers, > > > > > > > > I recently posted an issue to the NuttX Github page: > > > > https://github.com/apache/incubator-nuttx/issues/6896 > > > > > > > > I'll summarize my thoughts here. > > > > > > > > Currently NuttX has a C89 requirement. However, there is code in the > > > > codebase today that is not C89 compliant. Rather than reworking > > > > existing code to be C89, we should reevaluate the C89 requirement. > > > > > > > > C99 and C11 have added a lot of language features, and by updating the > > C > > > > standard to a newer version, we will add more tools to the NuttX > > toolbox. > > > > > > > > > > > > Hello Alan, > > > > > > Thanks for sharing your thoughts. > > > > > > I believe one of the big reasons for C89 compliance in the codebase is > > > because NuttX supports a wide range of microcontroller chips, not all of > > > which have a C99 or newer toolchain available. > > > > > > > > Here is the arch supported by NuttX: > > C99 > > arm Y > > arm64 Y > > avr Y > > ceva Y > > hc > > mips Y > > misoc > > or1k Y > > renesas Y > > risc-v Y > > sim Y > > sparc Y > > x86 Y > > x86_64 Y > > xtensa Y > > z16 > > z80 > > I don't know which compiler is used for hc, misoc, z16 and z80, but other > > arches support C99 very well. > > So, the question is whether the C99 requirement will impact these four > > arches. > > > > All of the Zilog family CPUs (z8, z16, z80, z180, ez80) use the ZDS-II > development software released by Zilog by default. The C compiler in ZDS-II > is C89 and a C99 requirement will stop the successful build of the z16 and > z80 (z80, z180, ez80 cpu) arches. > > Some time ago I contributed the necessary changes for the eZ80 target to > build using an experimental release of clang with Z80 and eZ80 support, but > it's not been sufficient priority for me to either contribute the automated > tests to have it continue to build, nor to even keep reasonably up to date > with NuttX changes, so I can't say for sure that it still builds correctly. > If it does build, then the eZ80 CPU in the z80 arch would at least still be > usable for those willing to use an experimental clang port. > > -- > bje >
Re: Reevaluate the C89 Requirement
Hi, On Wed, Aug 24, 2022 at 11:58 PM Xiang Xiao wrote: > On Wed, Aug 24, 2022 at 11:38 AM Nathan Hartman > wrote: > > > On Tue, Aug 23, 2022 at 8:33 PM Alan Rosenthal > > > wrote: > > > > > Hello NuttXers, > > > > > > I recently posted an issue to the NuttX Github page: > > > https://github.com/apache/incubator-nuttx/issues/6896 > > > > > > I'll summarize my thoughts here. > > > > > > Currently NuttX has a C89 requirement. However, there is code in the > > > codebase today that is not C89 compliant. Rather than reworking > > > existing code to be C89, we should reevaluate the C89 requirement. > > > > > > C99 and C11 have added a lot of language features, and by updating the > C > > > standard to a newer version, we will add more tools to the NuttX > toolbox. > > > > > > > > Hello Alan, > > > > Thanks for sharing your thoughts. > > > > I believe one of the big reasons for C89 compliance in the codebase is > > because NuttX supports a wide range of microcontroller chips, not all of > > which have a C99 or newer toolchain available. > > > > > Here is the arch supported by NuttX: > C99 > arm Y > arm64 Y > avr Y > ceva Y > hc > mips Y > misoc > or1k Y > renesas Y > risc-v Y > sim Y > sparc Y > x86 Y > x86_64 Y > xtensa Y > z16 > z80 > I don't know which compiler is used for hc, misoc, z16 and z80, but other > arches support C99 very well. > So, the question is whether the C99 requirement will impact these four > arches. > All of the Zilog family CPUs (z8, z16, z80, z180, ez80) use the ZDS-II development software released by Zilog by default. The C compiler in ZDS-II is C89 and a C99 requirement will stop the successful build of the z16 and z80 (z80, z180, ez80 cpu) arches. Some time ago I contributed the necessary changes for the eZ80 target to build using an experimental release of clang with Z80 and eZ80 support, but it's not been sufficient priority for me to either contribute the automated tests to have it continue to build, nor to even keep reasonably up to date with NuttX changes, so I can't say for sure that it still builds correctly. If it does build, then the eZ80 CPU in the z80 arch would at least still be usable for those willing to use an experimental clang port. -- bje
Re: Reevaluate the C89 Requirement
On Wed, Aug 24, 2022 at 11:38 AM Nathan Hartman wrote: > On Tue, Aug 23, 2022 at 8:33 PM Alan Rosenthal > wrote: > > > Hello NuttXers, > > > > I recently posted an issue to the NuttX Github page: > > https://github.com/apache/incubator-nuttx/issues/6896 > > > > I'll summarize my thoughts here. > > > > Currently NuttX has a C89 requirement. However, there is code in the > > codebase today that is not C89 compliant. Rather than reworking > > existing code to be C89, we should reevaluate the C89 requirement. > > > > C99 and C11 have added a lot of language features, and by updating the C > > standard to a newer version, we will add more tools to the NuttX toolbox. > > > > Hello Alan, > > Thanks for sharing your thoughts. > > I believe one of the big reasons for C89 compliance in the codebase is > because NuttX supports a wide range of microcontroller chips, not all of > which have a C99 or newer toolchain available. > > Here is the arch supported by NuttX: C99 arm Y arm64 Y avr Y ceva Y hc mips Y misoc or1k Y renesas Y risc-v Y sim Y sparc Y x86 Y x86_64 Y xtensa Y z16 z80 I don't know which compiler is used for hc, misoc, z16 and z80, but other arches support C99 very well. So, the question is whether the C99 requirement will impact these four arches. I think that we have been getting away with non-C89 compliance in arch- or > board-specific code in places where it is known that the toolchain(s) used > with that arch/board do support the newer standard. > > Yes, there are places in the code where non-C89 code is being used but > shouldn't be. I just recently fixed a couple of such cases, such as PR-6853 > [1]. > > We could find violations of C89 automatically by adding the -std=c89 switch > when building all shared (non-arch-, non-board-specific files) with GCC > (and probably clang). (We might need a few additional command line > switches.) > > But we found that some C99 features(e.g. inline) are very important to generate efficient code in the recent optimization work. So it's better to relax the rule to exclude some well supported C99 features. > Or we could discuss and consider changing the rules. I would be okay with > that only if we don't have to abandon users who depend on C89 conformance > or give up support for archs/boards that depend on it because of their > available toolchains. > > [1] https://github.com/apache/incubator-nuttx/pull/6853. > > Cheers, > Nathan >
Re: Reevaluate the C89 Requirement
On Tue, Aug 23, 2022 at 8:33 PM Alan Rosenthal wrote: > Hello NuttXers, > > I recently posted an issue to the NuttX Github page: > https://github.com/apache/incubator-nuttx/issues/6896 > > I'll summarize my thoughts here. > > Currently NuttX has a C89 requirement. However, there is code in the > codebase today that is not C89 compliant. Rather than reworking > existing code to be C89, we should reevaluate the C89 requirement. > > C99 and C11 have added a lot of language features, and by updating the C > standard to a newer version, we will add more tools to the NuttX toolbox. Hello Alan, Thanks for sharing your thoughts. I believe one of the big reasons for C89 compliance in the codebase is because NuttX supports a wide range of microcontroller chips, not all of which have a C99 or newer toolchain available. I think that we have been getting away with non-C89 compliance in arch- or board-specific code in places where it is known that the toolchain(s) used with that arch/board do support the newer standard. Yes, there are places in the code where non-C89 code is being used but shouldn't be. I just recently fixed a couple of such cases, such as PR-6853 [1]. We could find violations of C89 automatically by adding the -std=c89 switch when building all shared (non-arch-, non-board-specific files) with GCC (and probably clang). (We might need a few additional command line switches.) Or we could discuss and consider changing the rules. I would be okay with that only if we don't have to abandon users who depend on C89 conformance or give up support for archs/boards that depend on it because of their available toolchains. [1] https://github.com/apache/incubator-nuttx/pull/6853. Cheers, Nathan
Reevaluate the C89 Requirement
Hello NuttXers, I recently posted an issue to the NuttX Github page: https://github.com/apache/incubator-nuttx/issues/6896 I'll summarize my thoughts here. Currently NuttX has a C89 requirement. However, there is code in the codebase today that is not C89 compliant. Rather than reworking existing code to be C89, we should reevaluate the C89 requirement. C99 and C11 have added a lot of language features, and by updating the C standard to a newer version, we will add more tools to the NuttX toolbox. Thanks, Alan
