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
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
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
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
>
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
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
>
> 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
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
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
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.
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
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
> Also consider SH1
>
And M16C
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
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
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
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
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
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
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
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
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
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
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.
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
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
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.
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,
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
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
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).
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
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
33 matches
Mail list logo
