Re: Change time_t to signed type

Hi Takashi, > > ideally, we should use int64_t for all targets unconditionally, IMO. > however, in practice, 64-bit integers don't seem available for some of > our targets. (ez80, z8, z16) > maybe someone can add 64-bit integer support to their toolchains. but > i suppose we don't want to wait for

Re: Change time_t to signed type

Hi, On Wed, Nov 6, 2024 at 7:13 AM Tomek CEDRO wrote: > > Nathan you mentioned the 8-bit and 16-bit platforms to use 32-bit > unsigned. That would imply "virtual" type not natively supported by > platform. Do you know what is the penalty for using such types? Is it > safe? Does it work on all co

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.

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.co

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 repositor

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

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 havi

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

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 > > >

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

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 t

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 w

Re: eZ80 arch/chip: anyone using it?

ny 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 > &

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 targe