Adds new cpu architectures propeller1 and propeller2.

[ikskuh]

These cpu architectures allow targeting the Parallax Propeller 1 and Propeller 2, which are both very special microcontrollers with 512 registers and 8 cpu cores.

Resolves #21559

[ikskuh]

I tested it with the following code:

const std = @import("std");

/// Write long in D[31:0] to hub address {#}S/PTRx.
/// Prior SETQ/SETQ2 invokes cog/LUT block transfer.
inline fn wrlong(dst: u32, value: u32 ) void {
    asm volatile(
        "wrlong"
        :
        : [dst] "r" (dst),
          [val] "r" (value)
    );
}

extern fn check() bool;

export fn _start() void {
    while(check()) {
        wrlong(0x100, 1234);
    }
}

compiled both with

../stage3/bin/zig build-exe -target propeller1-freestanding -ofmt=c demo.zig 
../stage3/bin/zig build-exe -target propeller2-freestanding -ofmt=c demo.zig 

both commands work and seem to emit reasonable C code, so i guess we're good to go with experimentation now :)

[alexrp]

https://github.com/parallaxinc/propgcc/blob/b280e7a77103d479e82cc687711de6a45579ad70/binutils/include/elf/common.h#L408-L409

This needs to be added to std.elf.EM.

[ikskuh]

I'm also adding a P2/PROPELLER2 target taken from here:
https://github.com/ne75/llvm-project/blob/ee801ce165dc3a968ea78d7f793c713a91aabe97/llvm/include/llvm/BinaryFormat/ELF.h#L322C3-L322C15

[ikskuh]

Okay, this should be resolved now.

[alexrp]

Hmm... it's a little unfortunate that the LLVM port deviates in a few ways from the precedent established by the binutils/GCC ports much earlier.

The choice of EM_P2 = 300 is particularly problematic; ports that haven't been assigned an ELF machine type "officially" are supposed to use a larger number picked at random, like the ones here, to prevent conflicts.

Further, the binutils port in the propgcc repo differentiates P1 and P2 by some bits in ELF's e_flags field, not by e_machine.

The LLD port also uses elf32p2 as the linker emulation name instead of the established elf32-propeller.

Frankly, I think the binutils port is in the right here, and the LLVM port is doing things differently for no good reason that I can tell. So I think we should omit EM_P2 and just return EM_PROPELLER for both cases, and ideally also engage with the maintainer of the LLVM port and see if they'd be willing to change this to conform to the binutils port.

[alexrp]

If you haven't already, I recommend running

• zig run tools/generate_c_size_and_align_checks.zig -- propeller-freestanding-none | propeller-elf-gcc -fsyntax-only -x c -
• zig run tools/generate_c_size_and_align_checks.zig -- propeller2-freestanding-none | propeller-elf-gcc -mp2 -fsyntax-only -x c -

to ensure that we actually have the correct C type size/alignment values in std.Target.

[ikskuh]

If you haven't already, I recommend running

• zig run tools/generate_c_size_and_align_checks.zig -- propeller-freestanding-none | propeller-elf-gcc -fsyntax-only -x c -
• zig run tools/generate_c_size_and_align_checks.zig -- propeller2-freestanding-none | propeller-elf-gcc -mp2 -fsyntax-only -x c -

to ensure that we actually have the correct C type size/alignment values in std.Target.

Should i run this against the propeller-elf-gcc or the llvm build? there are several C compilers that may disagree with each other

I can try fetching as much of them as possible and do the runs for each of those

[alexrp]

Should i run this against the propeller-elf-gcc or the llvm build? there are several C compilers that may disagree with each other

I would hope that they agree on these values as otherwise they're ABI-incompatible, which should be a bug. That said, I'd be more inclined to consider the GCC port authoritative given that it's under the Parallax organization.

[ikskuh]

That said, I'd be more inclined to consider the GCC port authoritative given that it's under the Parallax organization.

That is kind of a bold assumption 🤣 Afaik, only propeller1 has an official gcc port while P2 hasn't.

The available compilers for P1 are (hard to find). Afaik there's at least the Parallax GCC and another random C compiler.

For P2 they actually have a tooling list

[alexrp]

That is kind of a bold assumption 🤣 Afaik, only propeller1 has an official gcc port while P2 hasn't.

Hmm, are you sure? Their GCC port has an -mp2 switch which is supposed to generate Propeller 2 code. 🤔

See e.g.:

• https://github.com/parallaxinc/propgcc/blob/b280e7a77103d479e82cc687711de6a45579ad70/gcc/gcc/config/propeller/propeller.opt#L74-L76
• https://github.com/parallaxinc/propgcc/blob/b280e7a77103d479e82cc687711de6a45579ad70/gcc/gcc/config/propeller/propeller.md#L28-L32

[alexrp]

If you feel like it, it would be nice to also add these constants to std.elf:

• https://github.com/parallaxinc/propgcc/blob/b280e7a77103d479e82cc687711de6a45579ad70/binutils/include/elf/propeller.h#L33-L54
• https://github.com/parallaxinc/propgcc/blob/b280e7a77103d479e82cc687711de6a45579ad70/binutils/include/elf/propeller.h#L77-L79

But that's just a nice-to-have and not essential for merging this.

[alexrp]

I've thought about this a bit more and I think I'd prefer representing P2 as a CPU feature. My reasoning is that we actually have precedent for this already; for example, MIPS r6 made many backwards-incompatible changes (e.g. reallocated encodings, removed instructions), yet we don't represent that as a distinct Arch tag. I believe PowerPC has also historically removed features, but I can't remember the exact details there.

But let's just get this merged with this approach for now and I'll do a follow-up PR showing what I have in mind.

[ikskuh]

I've thought about this a bit more and I think I'd prefer representing P2 as a CPU feature. My reasoning is that we actually have precedent for this already; for example, MIPS r6 made many backwards-incompatible changes (e.g. reallocated encodings, removed instructions), yet we don't represent that as a distinct Arch tag. I believe PowerPC has also historically removed features, but I can't remember the exact details there.

This would mean we have no generic cpu then, but only propeller1 and propeller2? They are neither binary compatible nor instruction compatible, it's more like arm vs. aarch64 than arm vs. thumb

This would also mean you can't check on arch but always have to check on the actual CPU in your code as well, so if you ever need to do something for p1 and p2, it would look like this:

switch(builtin.cpu.arch) {
  .propeller => switch(builtin.cpu) {
    &std.Target.propeller.cpus.propeller1 => { ... },
    &std.Target.propeller.cpus.propeller1 => { ... },
  },
  ...
}

I wonder why they made them a CPU/Feature in the gcc port. Probably due to convenience as otherwise you have to use prop1-none-eabi-gcc and prop2-none-eabi-gcc instead of prop-none-eabi-gcc

[alexrp]

This would mean we have no generic cpu then, but only propeller1 and propeller2? They are neither binary compatible nor instruction compatible, it's more like arm vs. aarch64 than arm vs. thumb

Yes; this is no different from the MIPS situation. The "generic" CPU would be arbitrarily defined to be propeller1, just as mips32/mips64 (r1) are arbitrarily defined to be the generic CPUs for MIPS.

This would also mean you can't check on arch but always have to check on the actual CPU

You would check the feature flag that the CPU would imply; specifically, propeller2 would imply p2. That currently looks like std.Target.propeller.featureSetHas(target.cpu.features, .p2) which is indeed too verbose, but I have some ideas for making this API more ergonomic that I plan to get to soon. I think something like target.cpu.features.has(.propeller, .p2) should be possible with some light comptime magic.

I wonder why they made them a CPU/Feature in the gcc port.

From what I saw in GCC and binutils, there's still a decent amount of overlap in instruction encodings, and they don't use wholly separate en/decoding tables or anything. In this way, I don't think the arm vs aarch64 comparison quite works because A64 really is an entirely new instruction set from A32.

[ikskuh]

Let's wait until we have all toolchains tested if they agree on the C type sizes

[andrewrk]

I think one heuristic to determine whether it should be a CPU feature vs a different arch is whether you would want two different self-hosted backend implementations, or whether you would rather have one that checks the CPU feature. If they would share a lot of implementation code, that is a hint that the same CPU arch would make sense.

Another heurisic would be @sizeOf(usize). This is the only reason x86 and x86_64 are not the same CPU arch for example even though 64bit is a CPU feature that can be enabled for x86 (which doesn't make any sense given this way of doing things), and you would definitely use the same backend logic for both.

[ikskuh]

I think one heuristic to determine whether it should be a CPU feature vs a different arch is whether you would want two different self-hosted backend implementations, or whether you would rather have one that checks the CPU feature. If they would share a lot of implementation code, that is a hint that the same CPU arch would make sense.

That's a pretty good heuristic and i think i have to take a deep-dive into codegen for that 😁

They both have basically the same idea behind the instruction encoding and style, but the semantics of basically all except the most basic instructions are different.

It starts with RDLONG which can only read Hub memory on P1 and reads continuous memory on P2.

@sizeOf(usize) would be 32 bit with 23 bit padding for 2 of the 3 address spaces so it's kinda hard to say.

But now i'm super tempted to create a self-hosted backend for the two processors... 🤔

Next steps for me is still getting all the compilers up and running, which sadly takes a lot of time :(

[ikskuh]

@alexrp i guess we have to do our refines in a later MR 😆

[andrewrk]

Sorry, it looks like I jumped the gun. Well, at least nobody will create conflicts with what you have so far, right? :)

[ikskuh]

Sorry, it looks like I jumped the gun. Well, at least nobody will create conflicts with what you have so far, right? :)

Guess so! I think it's better to have it merged as-is right now as i now don't have to distribute my fork to the sole user right now 😆

Alex and me will figure the details out and make it right and nice soon