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.
> >
> > I
> 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
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
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
> > fil
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
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
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.
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 importa
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 th
> 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 c
-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 techni
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 su
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 (-
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#issuecommen
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.h
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 wr
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.co
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.
>
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
>
19 matches
Mail list logo
