Re: Fwd: The End of an Era: Zilog Discontinues the Z80 Microprocessor
Hi Greg & Kenneth, As far as I'm aware the only C compilers around for the (e)Z80 are still ZDSII, SDCC, and LLVM patched for the TI 84+ calculator, all with drawbacks: ZDSII is C89, SDCC doesn't support the eZ80 in 24-bit mode, and the LLVM patch only produces binaries loadable on the calculator. I did have a further patch for LLVM to produce ELF objects, as GNU binutils fully supports the eZ80, but I haven't kept that up to date with changes to either llvm or the TI 84+ patches to llvm. (I still use an llvm 13.0.0 patched both for eZ80 for TI 84+, and further to produce ELF objects, myself). -- bje On Sat, May 4, 2024 at 5:23 AM Kenneth Pettit wrote: > Hi Greg, > > I don't actually use the Z80 so cannot recommend a toolchain for it. I > could ask on the Tiny Tapeout discord channel though. > > Ken > > On 5/3/24 7:45 AM, Gregory Nutt wrote: > > On 5/3/2024 8:31 AM, Kenneth Pettit wrote: > >> > >> There is an effort to make a Z80 replacement chip: > >> > >> https://app.tinytapeout.com/projects/668 > >> > >> This is just a start since there are limited I/O pins on Tiny > >> Tapeout, but I think the plan might be to eventually put it on an MPW > >> to have a fully functional Z80 replacement (maybe). > >> > >> In the meantime, Digikey and Mouser seems to have thousands in stock, > >> so get them while they are still available! :) > > > > Z80 is a lot of fun to play with. Unfortunately, there is no Z80 > > toolchain supported by NuttX so it is not usable. The 64KiB address > > may be a problem now too. The Z180 is also supported but currently > > has no toolchain (it used SDCC too). > > > > The main problem with SDCC is that cannot support passing unions or > > structures as parameters or as return values. POSIX depends on this. > > > > Almost all of the ZiLOG parts are no longer usable. None of those > > that depend solely on ZiLOGs ZDS II toolchain will build (z8, > > zNEO/z16). The ez80 also uses the ZDSII toolchain but there is > > alternative beta GCC support for the ez80. > > > > The main problems with ZSDS II is that it is C89 and very buggy. > > > > Ken, if we were to invest in revitalizing the parts what toolchain > > would you recommend? > > >
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: [VOTE] Apache NuttX 10.1.0 (incubating) RC1 release
+1 with caveat that I need to backport the compiler patch. Toolchain: clang version 13.0.0 (g...@github.com:jacobly0/llvm-project.git ff3f5b865edbac826fdd251f810da833dda775de) Target: ez80-none-unknown-elf Thread model: posix - LICENSE, NOTICE, README.md, DISCLAIMER-WIP present in both repositories. - Build for eZ80 using commit ID 9d4742af00 backported from master, plus patch for Z80 ELF support (PR to happen when tested adequately) - Build size is 253,610 text (down from 257,713 bytes for RC0), 197 bytes in data (unchanged from RC0) NuttShell (NSH) NuttX-10.1.0 nsh> free total used freelargest Umem: 253856 66272 187584 184736 -- bje On Tue, May 4, 2021 at 1:25 AM Alan Carvalho de Assis wrote: > Hi Everyone, please submit some information when you test it: > > - Used toolchain: i.e. last line of "gcc -v" is enough > - ELF nuttx size: i.e. "arm-none-eabi-size nuttx" > - Result of internal nsh free command. > > It will help us to track the size increase from a release to another. > > BR, > > Alan > > On 5/3/21, alin.jerpe...@sony.com wrote: > > Hello all, > > > > This is the latest tarball > > > > I am sorry for the confusion > > > > Thanks > > Alin > > > > > > -Original Message- > > From: Nathan Hartman > > Sent: den 3 maj 2021 17:14 > > To: dev@nuttx.apache.org > > Subject: Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC1 release > > > > On Mon, May 3, 2021 at 1:22 AM Alin Jerpelea wrote: > >> > >> Hello all, > >> Apache NuttX (Incubating) 10.1.0 RC1 has been staged under [1] and > >> it's time to vote on accepting it for release. If approved we will > >> seek final release approval from the IPMC. Voting will be open for 72hr. > >> > >> A minimum of 3 binding +1 votes and more binding +1 than binding -1 > >> are required to pass. > >> > >> The Apache requirements for approving a release can be found here [3] > >> "Before voting +1 [P]PMC members are required to download the signed > >> source code package, compile it as provided, and test the resulting > >> executable on their own platform, along with also verifying that the > >> package meets the requirements of the ASF policy on releases." > >> > >> A document to walk through some of this process has been published on > >> our project wiki and can be found here [4]. > >> > >> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM > >> items in [4]) [ ] -1 reject (explanation required) > >> > >> Thank you all, > >> Alin Jerpelea > >> > >> SCM Information: > >> Release tag: nuttx-10.1.0-RC1 > >> Hash for the release incubating-nuttx tag: > >> 3130ff691e386934eb276587a24d1efacf3bb30b > >> Hash for the release incubating-nuttx-apps tag: > >> 4348d91d1356335483089c3865282d80f13bedcd > >> > >> [1] > >> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/inc > >> ubator/nuttx/10.1.0-RC1/__;!!JmoZiZGBv3RvKRSx!u7bO_5TgIUsO429c5U2xXTz4 > >> HI0T2TqnSm836Wse15R0SGxhUdWk3viAcBF0cM9oFQ$ > >> [2]https://urldefense.com/v3/__https://raw.githubusercontent.com/apach > >> e/incubator-nuttx/nuttx-10.1.0-RC1/ReleaseNotes__;!!JmoZiZGBv3RvKRSx!u > >> 7bO_5TgIUsO429c5U2xXTz4HI0T2TqnSm836Wse15R0SGxhUdWk3viAcBELDkRTXA$ > >> [3] > >> https://urldefense.com/v3/__https://www.apache.org/dev/release.html*ap > >> proving-a-release__;Iw!!JmoZiZGBv3RvKRSx!u7bO_5TgIUsO429c5U2xXTz4HI0T2 > >> TqnSm836Wse15R0SGxhUdWk3viAcBGKE_xsSw$ > >> [4]https://urldefense.com/v3/__https://cwiki.apache.org/confluence/dis > >> play/NUTTX/Validating*a*staged*Release__;Kysr!!JmoZiZGBv3RvKRSx!u7bO_5 > >> TgIUsO429c5U2xXTz4HI0T2TqnSm836Wse15R0SGxhUdWk3viAcBE_QwknXQ$ > > > > > > Just to be sure I don't misunderstand, this is the latest release > candidate > > to be tested now? > > > > In the future, I recommend to increment the -RC numbers each time there > are > > new tarballs, to avoid any potential confusion. > > > > If this is indeed the latest RC, I'll try to test it today. > > > > Thanks for all your hard work!! > > > > Cheers, > > Nathan > > >
Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC0 release
Hi all, I don't think my test qualifies to give a +1 due to needing a patch for my unsupported toolchain, but otherwise it's successful. - LICENSE, NOTICE, README.md, DISCLAIMER-WIP present in both repositories. - Build for eZ80 requires a custom patch for a non-supported toolchain. Patch adds support for clang-ez80 and ELF format. - Executes successfully on hardware. - Build size is 257,713 bytes in text, 197 bytes in rodata - tuned config for 256KB flash. -- bje On Mon, Apr 19, 2021 at 12:06 AM Alin Jerpelea wrote: > Hello all, > Apache NuttX (Incubating) 10.1.0 RC0 has been staged under [1] and it's > time to vote on accepting it for release. If approved we will seek > final release approval from the IPMC. Voting will be open for 72hr. > > A minimum of 3 binding +1 votes and more binding +1 than binding -1 are > required to pass. > > The Apache requirements for approving a release can be found here [3] > "Before voting +1 [P]PMC members are required to download the signed > source code package, compile it as provided, and test the resulting > executable on their own platform, along with also verifying that the > package meets the requirements of the ASF policy on releases." > > A document to walk through some of this process has been published on > our project wiki and can be found here [4]. > > [ ] +1 accept (indicate what you validated - e.g. performed the non-RM > items in [4]) > [ ] -1 reject (explanation required) > > Thank you all, > Alin Jerpelea > > SCM Information: > Release tag: nuttx-10.1.0-RC0 > Hash for the release incubating-nuttx tag: > f380c919f04d5ee88e0a83f5632cc83af503664f > Hash for the release incubating-nuttx-apps tag: > 4348d91d1356335483089c3865282d80f13bedcd > > [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/10.1.0-RC0/ > [2] > https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-10.1.0-RC0/ReleaseNotes > [3] https://www.apache.org/dev/release.html#approving-a-release > [4] > https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release >
Re: avoiding pitfal of reuse of globals in FLAT mode?
On Thu, Mar 25, 2021 at 8:27 AM Byron Ellacott wrote: > Hi, > > Since the basic problem is that `getopt` doesn't have a per-task value it > can use, how would it keep track of which TLS key it's been allocated? > This question, at least, I understand the answer to having looked at the PR - the TLS key is shared across all threads (of course it would need to be) so can be stored in a single global. -- Byron
Re: avoiding pitfal of reuse of globals in FLAT mode?
Hi,
Since the basic problem is that `getopt` doesn't have a per-task value it
can use, how would it keep track of which TLS key it's been allocated?
Here's what I found in libc that would need task (thread) specific data:
- libs/libc/misc/lib_umask.c has g_mask
- libs/libc/libgen/lib_dirname.c and libs/libc/libgen/lib_basename each
have a g_retchar
- libs/libc/syslog/lib_setlogmask.c has g_syslog_mask (and a comment
describing this issue)
- libs/libc/pwd/* uses either g_passwd and g_passwd_buffer or g_pwd and
g_buf
- libs/libc/grp/* uses a similar pair for group data
- libs/libc/unistd/lib_getopt.c we know of, it has four words of global
data
- libs/libc/time/lib_localtime.c uses g_tm and may need per-task timezone
settings
- libs/libc/netdb/lib_netdb.c specifies h_errno as a global
- libs/libc/netdb/lib_gethostbyname2.c and lib_gethostbyaddr.c use
g_hostent and g_hostbuffer
- libs/libc/stdlib/lib_srand.c uses a variety of globals depending on
build options
- libs/libc/string/lib_strtok.c uses g_saveptr
Statically allocating a TLS key for each module would consume around 11
keys in each task. Dynamically allocated TLS keys cannot ever be released,
because these are globals handed over to user code with no indication when
they're no longer needed. It may be better to have an additional static
element in tls_info_s pointing to a heap-allocated structure containing the
libc globals. Functionally this is the same as a statically reserved TLS
key, but it's clearer what it's for.
--
Byron
On Thu, Mar 25, 2021 at 12:51 AM Gregory Nutt wrote:
> On 3/24/2021 8:38 AM, Matias N. wrote:
> > So, if I follow correctly, we could maybe have one TLS pointer pointing
> to a struct of pointers, one per each group of globals (one of this groups,
> would be the set of variables used by getopt()), like:
> >
> > struct task_globals_s
> > {
> >struct getopt_globals_s *getopt_globals;
> >/* ...others */
> > };
> >
> > Then getopt globals would only be allocated once for each task, and only
> when getopt() is called.
> >
> > Something like that?
>
> Yes, that is a possibility. But that is already implemented just as you
> describe as POSIX thread-specific data.
>
> The TLS data structure is defined in include/nuttx/tls.h as following.
> it is just an array of pointer size things and the errno variable.
>
> struct tls_info_s
> {
> #if CONFIG_TLS_NELEM > 0
>uintptr_t tl_elem[CONFIG_TLS_NELEM]; /* TLS elements */
> #endif
>int tl_errno;/* Per-thread error number */
> };
>
> This structure lies at the "bottom" of stack of every thread in user space.
>
> The standard pthread_getspecific() is then implemented as:
>
> FAR void *pthread_getspecific(pthread_key_t key)
> {
>return (FAR void *)tls_get_value((int)key);
> }
>
> Where
>
> uintptr_t tls_get_value(int tlsindex)
> {
>FAR struct tls_info_s *info;
>uintptr_t ret = 0;
>
>DEBUGASSERT(tlsindex >= 0 && tlsindex < CONFIG_TLS_NELEM);
>if (tlsindex >= 0 && tlsindex < CONFIG_TLS_NELEM)
> {
>/* Get the TLS info structure from the current threads stack */
>
>info = up_tls_info();
>DEBUGASSERT(info != NULL);
>
>/* Get the element value from the TLS info. */
>
>ret = info->tl_elem[tlsindex];
> }
>
>return ret;
> }
>
> The POSIX interface supports a pthread_key_create() to manage the indexing.
>
>
>
>
Re: avoiding pitfal of reuse of globals in FLAT mode?
On Wed, Mar 24, 2021 at 2:08 PM Xiang Xiao wrote: > On Wed, Mar 24, 2021 at 9:18 AM Matias N. wrote: > > > > > > > - devise a mechanism to mimic what would be done by OS in KERNEL mode > > (add > > > > > some custom handler to APIs internally using globals, such as getopt, > > that can be > > > > > called either manually by user or by the OS itself when the task is > > started?) > > > The custom handler isn't enough here, because the real problem is we need > the global variables per task/process. > As Greg suggests, we need something like TLS but per task/process not per > thread(e.g. task_getspecific/task_setspecific). > Once the mechanism is done, getopt can be converted to confirm the standard > trivally. > I was looking at this exact issue last week (see comment in https://github.com/apache/incubator-nuttx/pull/3054). The basis for this mechanism exists in the way errno is handled. Perhaps a structure defined for all libc globals added to TLS and a call from the task creation code to initialise it? > > > > > - other? > > The transparent/standard solution is switched to the ELF binary(note: it > doesn't depend on KERNEL mode), and then loses the XIP benefit(huge memory > penalty). But, it's doable to XIP again by combining ELF loader and ROMFS. > Switching to ELF doesn't necessarily help - I encountered the problem loading nsh as an ELF binary in a FLAT built. The globals optarg and optind aren't in libc.csv. They'll be picked up and included in symtab_apps, but those symbols will simply point to the (system) global variables, not a per-task variable. Byron
Re: Symbol tables, ELF binaries, and mksymtab
Hi all, Thanks for the feedback. I'm looking at option (2), modifying `libs/libc/symtab/symtab_find(ordered)?byname.c` to strip a leading underscore if a new Kconfig setting (SYMTAB_DECORATED in binfmt/Kconfig) is set. I considered modifying the ELF loader, but the kernel module system needs the same adjustment when making the same calls. The NXFLAT loader 'benefits' too, but I think toolchains that prefix underscores and toolchains that support the NXFLAT toolchain don't overlap. -- bje On Mon, Mar 15, 2021 at 12:40 AM Gregory Nutt wrote: > > Which I think is insufficient. Probably some of the support was removed? > > > No.. It is just that there was no support for loadable modules for those > older Cygwin toolchains. The underscore has not been used with Cygwin > since around 2015 so I think would be safe to just remove the > CONFIG_SIM_CYGWIN_DECORATED configuration. > > In your case, I think you have two options: > > 1) Write a tool to rename all of the symbols in the library to remove > the leading underscore (using objcopy --redefine-syms), or > > 2) Modify the elf loader[s] to conditionally prepend the '_' character > before looking up the symbol by name. > >
Symbol tables, ELF binaries, and mksymtab
Hi, I've been working on ELF binary loading for the eZ80. I'm compiling with CONFIG_SYSTEM_NSH=m to produce a stand-alone nsh binary. I'm finding the symbol tables (both the one generated in libs/libc with CONFIG_EXECFUNCS_SYSTEM_SYMTAB=y and the one generated in apps) to be wrong when it comes to C functions having a prepended underscore - the system symtab doesn't prepend an underscore, so all symbol lookups fail. The apps symtab does prepend an underscore to its "extern" definitions, so any use of that symbol table fails with undefined external references. Is this a configuration issue on my end? I've modified tools/mksymtab to (a) prepend an underscore to the symbol's name, and (b) prepend an "&" to the symbol's value. The latter change allows exporting global variables like optarg and optind - I've also added a number of missing symbols to syscall/syscall.csv and libs/libc/libc.csv. I can now boot a NuttX kernel with no shell and successfully execute nsh from SD card after my changes, but before I start making PRs I'd like to understand if the difficulties I've faced are a PEBKAC issue or something others encounter. (I'll also be contributing the Z80 elf loader, but it's not useful if you're using ZDS-II.) -- Byron
Re: z20x computer with Z80 microprocessor
My hardware is an eZ80F91 ASSP CPU at 50MHz (but I used a 50MHz oscillator, the PLL is unused) with SPI SD reader, Ethernet PHY, dual UARTs. Most of what I'm looking at would be applicable with the z20x with an eZ80 CPU, but relatively little would apply to the other CPUs you might use. Software wise, I've successfully built NuttX up to running NSH on it, mounting the SD card, with the RTC working. Here's the rough roadmap I have for NuttX building: - Check EMAC support works, up to DHCP and using ntpdate - Implement a syscall facility (via a RST, I think) - Write an ELF loader for the Z80 machine family (done except for relocations - but I can't fit a symbol table in Flash anyway) - Write a CP/M task, which also means supporting mixed memory mode - should only affect IRQ handling and task switching, I think There's still a number of integer size issues to work through first, I think. I am building with -Werror -Wconversion, which generates a huge number of errors. Most of them are harmless in practice, but ensuring I catch 24 bit issues means checking them all. An example is in sched/sched/sched_roundrobin.c: int decr; decr = MIN(tcb->timeslice, ticks); In this, tcb->timeslice is an int32_t, ticks is a uint32_t, and the MIN operation loses precision down to a 24-bit int. The round robin scheduler with default values should be fine with 24 or even 8 bits - I think you'd have to set ridiculous values to overflow anything. -- Byron On Sun, Feb 21, 2021 at 5:34 AM Brennan Ashton wrote: > I saw that Greg had started initial support for this retro computer a > year ago and I was curious if anyone else has experience with it. I > was considering doing a board run and building one for myself and > would be happy to build a few if there are people interested since I > will have to order multiple PCBs anyway. > > https://z20x.computer/ > > Greg, are you still doing anything on this? I know you have had > interest in the past with it. > > It looks like there has been some renewed interest in the Z80 with > Byron integrating the clang port. > > --Brennan >
Re: eZ80 arch/chip: anyone using it?
A fork of clang/llvm is being maintained at https://github.com/jacobly0/llvm-project. I further forked that to switch to targeting binutils (by just changing the emitted assembly syntax a little), which added Z80-family support last year some time. The llvm fork isn't perfect - it produces fairly inefficient and occasionally bizarre code, and has had a few errors in code generation that the fork maintainer has been fast to fix. I'm not sure how the Zilog tools manage debugging symbols but I would be very surprised if it's from ELF objects with DWARF attributes given the object files in the ZDS distribution appear to be a proprietary derivative of COFF. I'll go out on a limb and say it probably wouldn't work, at least not as far as debugging at the C level, but since the ZDI subsystem doesn't care what compiled the code you should be able to debug machine code with the ZPAK tools. I control the ZDI pins via my USB serial IC, but I've built no support for debug symbols yet. I haven't even tried a debug build. I modified the build process to add an option to switch toolchains but I've wound up needing to duplicate all the assembly files and slightly change their syntax. I can put up a merge request to see if my changes still allow the ZDS-II build to proceed, so I'll do that in the next few days. -- Byron On Fri, Feb 12, 2021 at 9:19 AM Gregory Nutt wrote: > I developed the ez80 and used it in several projects. I was working on > a port when the quarantine lock-down made it impossible to get parts > here in Costa Rica, at least temporarily. I have not gotten back to > working with those ez80 boards for a variety of reasons. > > I really like the ez80's.. lots of retro feel but faster updated so that > you are not stuck in a 16-bit address space. > > I think it is important to continue supporting the official ZiLOG ZDS-II > toolchains, however it would be great to have a clang/llvm alternative. > I was unaware of such a beast. Does it integrate with the ZiLOG tools > for debugger support? > > There are lots of problems with the ZDS-II tools, like C89 and sometimes > unpredictable compiler behavior. But, again, I think that the official > ZiLOG tools should be supported. Other than additional complexity, I > don't think that there is any reason that we could not support both with > the appropriate options in arch/arm/src/ez80/Toolchain.defs and lots of > changes to the build files. > > If you want to attempt such a thing, I could help out at least with some > backward compatibility testing. > > Greg > > On 2/11/2021 5:07 PM, Byron Ellacott wrote: > > Hi all, > > > > I'm wondering if there's anyone building NuttX for the eZ80. I've been > > working on a build of NuttX for a custom eZ80-based board with reasonable > > success so far, but I've made a pretty hefty change: I've switched from > the > > ZDS-II Windows-only toolchain to an unstable fork of clang/llvm targeting > > the eZ80. > > > > If there's little interest in the eZ80, I'll keep my changes on my fork > > rather than attempting to package up the toolchain. If there's no-one > > building with the ZDS-II, I don't think I can reasonably offer merge > > requests either, since I've no way to tell if the problems I've > encountered > > are due to my toolchain or not. > > > > Thanks, > >Byron > > >
eZ80 arch/chip: anyone using it?
Hi all, I'm wondering if there's anyone building NuttX for the eZ80. I've been working on a build of NuttX for a custom eZ80-based board with reasonable success so far, but I've made a pretty hefty change: I've switched from the ZDS-II Windows-only toolchain to an unstable fork of clang/llvm targeting the eZ80. If there's little interest in the eZ80, I'll keep my changes on my fork rather than attempting to package up the toolchain. If there's no-one building with the ZDS-II, I don't think I can reasonably offer merge requests either, since I've no way to tell if the problems I've encountered are due to my toolchain or not. Thanks, Byron
