Continuation of #25680, squished into one commit for now
feat: init eZ80 arch via CBE #30622
clevor/zig:ez80 into master
Thanks for the patch.
I've never messed with ez80 or z80 before, so I may be mistaken here, but I've done my best to review this in the interest of getting it landed.
Everywhere that #if defined(zig_ez80) appears in zig.h, it looks wrong to me. I also challenged the decision to use "ez80" as the arch rather than "z80". Other than that, I think this looks ready to land.
@ -1312,6 +1326,7 @@ pub const Cpu = struct {
bpfeb,
bpfel,
csky,
ez80,
It looks like this should be z80, maybe with a target CPU feature of "e", although if that is only changing the clock frequency it's unclear that there is a meaningful difference between ez80 and z80 from a compiler's perspective.
@andrewrk wrote in #30622 (comment):
It looks like this should be z80, maybe with a target CPU feature of "e", although if that is only changing the clock frequency it's unclear that there is a meaningful difference between ez80 and z80 from a compiler's perspective.
While it's quite similar, it's actually got some architectural improvements (simple pipeline, new instructions...) and famously has a full 24-bit address mode ("ADL") and indeed can be clocked faster.
@ -80,2 +80,4 @@
#define zig_x86_16
#define zig_x86
#elif defined (__ez80)
#define zig_ez80
what is the purpose of defining zig_ez80?
@ -582,6 +587,16 @@ typedef signed long long int16_t;
#define INT16_MAX ( INT16_C(0x7FFF))
#define UINT16_MAX ( INT16_C(0xFFFF))
#if defined(zig_ez80)
It looks wrong to check the OS rather than checking the min and max like all the rest of the surrounding macros.
@ -707,6 +737,12 @@ const Index = enum(u32) {
zig_f128,
zig_c_longdouble,
//ez80stdint.h
these are unrelated to ez80. they are defined in stdint.h just like the others
The width of an eZ80 register pair, at least in ADL mode, is 24 bits, and the CE toolchain's fork of jacobly's fork also supports 48-bit integers implemented as 2 24-bit register pairs.
FWIW, I have some comments to add to the discussion here, but won't have time until I'm back home on the 3rd.
0f5bdf7f96
257cbfbb7c
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.This proposal is planned.
The web application for interactive documentation and generation of its assets.
The C backend outputs C source code.
The LLVM backend outputs an LLVM bitcode module.
The self-hosted backends produce machine code directly.
Zig's included binary utilities: zig ar, zig dlltool, zig lib, zig ranlib, zig objcopy, and zig rc.
Implementing this issue could cause existing code to no longer compile or have different behavior.
The Zig build system - zig build, std.Build, the build runner, and package management.
An issue related to debug information (e.g. DWARF) produced by the Zig compiler.
An issue with documentation, e.g. the language reference or standard library doc comments.
This issue points out an error message that is unhelpful and should be improved.
Tokenization, parsing, AstGen, ZonGen, Sema, Legalize, and Liveness.
An issue related to Zig's integrated fuzz testing.
Reuse of internal compiler state for faster compilation.
This issue relates to Zig's libc implementation and/or vendored libcs.
This issue relates to Zig's compiler-rt library.
This issue relates to Zig's vendored libc++ and/or libc++abi.
This issue relates to Zig's standard library.
This issue relates to Zig's vendored libtsan.
This issue relates to Zig's ubsan-rt library.
This issue relates to Zig's vendored libunwind.
Zig's integrated object file and incremental linker.
The compiler reports success but produces semantically incorrect code.
This issue suggests modifications. If it also has the "accepted" label then it is planned.
This issue or pull request should be mentioned in the release notes.
This issue is related to testing the compiler, standard library, or other parts of Zig.
This issue tracks the support tier for a target.
Zig as a drop-in C-family compiler.
The Zig source code formatter.
https://ziglang.org/news/announcing-donor-bounties
Observed behavior contradicts documented or intended behavior.
This issue is limited in scope and/or knowledge of project internals.
An issue with a third-party project that uses this project.
Solving this issue will likely involve adding new logic or components to the codebase.
An issue related to project infrastructure, e.g. continuous integration.
A task to improve performance and/or resource usage.
No questions on the issue tracker; use a community space instead.
A bug that did not occur in a previous version.
An issue with a third-party project that this project uses.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?