Proposal: std.Target: Add more architecture tags.
#20835
Conversation
| @@ -979,26 +979,38 @@ pub const Cpu = struct { | |||
| }; | |||
|
|
|||
| pub const Arch = enum { | |||
| alpha, | |||
There was a problem hiding this comment.
Alpha technically allows big endian implementations. To my knowledge, no such implementation has ever existed, and no software that supports Alpha supports it in a big endian configuration. So no alphaeb here.
| msp430, | ||
| or1k, |
There was a problem hiding this comment.
OpenRISC does specify a 64-bit architecture, but no core designs exist for that yet, and no software supports it. In practice, OpenRISC is basically considered a 32-bit architecture, so not adding a 64-bit variant here yet.
| thumb, | ||
| thumbeb, | ||
| x86, | ||
| x86_64, | ||
| xcore, | ||
| xtensa, | ||
| xtensaeb, |
There was a problem hiding this comment.
Xtensa supports both little and big endian. QEMU supports both, as does GCC.
alexrp
force-pushed
the
target-add-arches
branch
from
2d51a28 to
e5ad877
Compare
|
Approved. Some notes:
|
Makes sense. And FWIW, I was being fairly conservative here. If we wanted to be a tad more liberal with the selection, I think
Hmmmmm. Mixed feelings right as I'm reading this. Mostly concern about the UX. But let me think/sleep on it and get back to you with some coherent thoughts. |
@andrewrk ok, did some thinking (sorry if this ended up a bit ramble-y): I think there's a world where you can separate bitness and endianness from the architecture tag, but I don't think CPU features are the way. If you went that route, you'd need two separate feature flags to indicate "this CPU is capable of 64-bit code" and "we're actually compiling code to be 64-bit". It just seems a bit wrong on a conceptual level. I view CPU features as being strictly capabilities, and the choice of endianness and bitness as almost being similar to the choice of ABI, if that makes sense. (For SPARC v9, being capable of true bi-endianness, it quite literally is 'just' a choice of ABI. But that's an exceptional case.) So if we wanted to reduce the amount of But this is where the user-friendliness concern I alluded to earlier comes in: Endianness and bitness are much more important than CPU model, features, ABI, and even libc in many cases, when specifying a target triple. Assuming for a second that #20690 is accepted in its current form, we can infer a sensible ABI for probably 95% of all Zig usage that'll ever happen. We also already have mostly reasonable baselines for CPU models/features, and our default choice of libc is probably also good for most users. But if I want to target, say, Here I would suggest that e.g. for endianness, the combination "some are mandatory ( There's also the familiarity aspect to consider. People are used to the So, if we were to go this route, I would strongly suggest that we try to maintain status quo syntax, even if the underlying modeling of the information is more structured. That is: The parsing works by first chopping off endianness and bitness suffixes if present (in that order), and then matching against the
For this scheme to work, In this new world order, pub const Target = struct {
arch: Arch,
cpu: Cpu,
os: Os,
libc: LibC,
abi: Abi,
ofmt: ObjectFormat,
// I think there's enough info here to warrant separating it from Cpu, if possible.
pub const Arch = struct {
tag: Tag,
bits: Bits,
endian: Endian,
pub const Tag = enum {
arm,
mips,
powerpc,
riscv,
sparc,
x86,
...
};
pub const Bits = enum {
@"32",
@"64",
};
pub const Endian = enum {
big,
little,
};
};
pub const Cpu = struct {
model: Model,
features: Feature.Set,
pub const Feature = struct { ... };
pub const Model = struct { ... };
};
pub const Os = struct {
tag: Tag,
version_range: VersionRange,
pub const Tag = enum { ... };
};
pub const LibC = struct {
tag: Tag,
dynamic_linker: DynamicLinker,
version_range: VersionRange,
pub const Tag = enum { ... };
pub const DynamicLinker = struct { ... };
};
pub const Abi = struct {
variant: Variant,
options: Options,
// Analogous to Model and Features in Cpu.
pub const Variant = struct { ... };
pub const Options = struct { ... };
};
pub const ObjectFormat = enum { ... };
}; |
|
@andrewrk I plan to re-do this as a proper PR shortly since #21020 and #21037 are the only remaining cleanups I planned to do in preparation. Just wanted to check if you had a chance to consider my comment above? (Even though I considered it in the context of #20690, it could be done independently of that.) |
|
(In any case, closing this since there's no reason to have it pollute the PR queue right now.) |
This is sort of a mini-proposal in PR form; CI is expected to fail. If we like this direction, I'll turn this into a complete patch.
Introduction
I'm starting this from the premise that we want
std.Targetto be usable more broadly than just in the Zig compiler itself. I could imagine it being useful in other compilers, assemblers, emulators, etc. I certainly would like to base my own compiler project's target information on it. If this premise is wrong, then of course the rest of this doesn't matter. 🙂I've surveyed about 40-50 different architectures (depending on how you count) as part of this. This PR contains the selection of architectures that I think are worth proactively adding to
std.Targetbased on some objective and subjective criteria.The objective criteria:
(Note: I don't consider deprecated ports to count here. For example,
ia64andnios2have GCC backends, but they're slated for removal. Also, the Linux and glibc/musl points don't count for microcontrollers.)If all of these are false, then the architecture is hopelessly dead and thus excluded. If only one or two of these are true, it requires an individual (potentially subjective) evaluation. If three to five are true, it's clearly alive.
Survey Results
Clearly Alive
These are included without further evaluation.
alpha: GCC, Linux, glibc, QEMUarc64: GCC, Linux, glibc, QEMUarcis ARCv2). This is a new-ish architecture; support is in the process of being upstreamed.hppa: GCC, Linux, glibc, QEMUia64which HP abandonedhppafor...kvx: GCC, LLVM, Linux, musl, QEMUmicroblaze: GCC, Linux, glibc, musl, QEMUor1k: GCC, Linux, glibc, musl, QEMUsh: GCC, Linux, glibc, musl, QEMUHopelessly Dead
These are excluded without further evaluation due to fulfilling none of the objective criteria.
avr32biinc500ia64lm8m88kns32ks360s370tilevaxz8ez8z8kz80kz80ez80z180z280z380zneoIndividual Evaluation
bfin: GCCc6x: GCCcris: GCC, QEMUepiphany: GCCfr30: GCCfrv: GCCft32: GCCh8300: GCCiq2000: GCClm32: GCCm32c: GCCm32r: GCCmcore: GCCmn10300: GCCmoxie: GCCnds32: GCCnios2: Linux, glibcpdp11: GCCpru: GCCrl78: GCCrx: GCC, QEMUs390: GCC, glibcs390x. Once removed, I expect glibc to follow, and eventually GCC.tricore: QEMUv850: GCCvisium: GCCxstormy16: GCC