ELI5

[PythonLinks]

I am a little confused by this compiler and the ZPU. I thought the C language targeted register machines. And yet here it works with a stack machine. I also do not understand why the gcc version used is so old, while there appears to be a thriving ecosystem around the ZPU. I would expect someone to have done the upgrade. Is there a reason the version has not been updated?
Is there a reason why this would or would not work with the LLVM compiler? Is there a different C compiler which might be a better choice?

Somewhere there is some magic going on here, I am trying to figure out what is the key thing that makes this all work, and what are its limits.

Maybe I am not the only one who is curious. Thank You. Chris

[bert-lange]

Hello Chris!

Am 28.07.21 um 11:13 schrieb PythonLinks:

I am a little confused by this compiler and the ZPU. I thought the C language targeted register machines. And yet here it works with a stack machine.

The ZPU does trick a little, it uses three memory cells as register (search for 'memreg' in the startup code).

I also do not understand why the gcc version used is so old, while there appears to be a thriving ecosystem around the ZPU. I would expect someone to have done the upgrade. Is there a reason the version has not been updated?

Nobody with knowledge has found the time to update the ZPU enhancement of gcc. I'm an FPGA guy, and only a user of the compiler.

Is there a reason why this would or would not work with the LLVM compiler?

Just try it. I think it should be possible to combine llvm and ZPU.

Is there a different C compiler which might be a better choice?

I don't know.

Somewhere there is some magic going on here, I am trying to figure out what is the key thing that makes this all work, and what are its limits.

Maybe I am not the only one who is curious.

I'm also curious, but I also have a lot of interesting projects on my desk :-)

regards,

Bert

[oharboe]

Creating an LLVM backend for the ZPU is a lot like work... It would require a professional effort of a couple of months to do it. It's hard to see how it would be financed...

It's possible that a university student could do it for a masters project, but why do that instead of something more famous and mainstream like contribute to RISC-V?

What would be the motivation for using the ZPU instead of RISC-V these days?

[bert-lange]

Hello Øyvind,

Am 16.08.21 um 14:31 schrieb Øyvind Harboe:

What would be the motivation for using the ZPU instead of RISC-V these days?

It is still the smallest CPU with a C compiler that I know.

Not only in terms of LUTs and FFs, but also in space of memory needed for the program.

I can use the ZPU in a huge Stratix IV and also in a small MachXO2...

regards,

Bert

[oharboe]

Hello Øyvind, Am 16.08.21 um 14:31 schrieb Øyvind Harboe: What would be the motivation for using the ZPU instead of RISC-V these days? It is still the smallest CPU with a C compiler that I know. Not only in terms of LUTs and FFs, but also in space of memory needed for the program. I can use the ZPU in a huge Stratix IV and also in a small MachXO2... regards, Bert

Thanks! :-)

The biggest weakness in terms of size is code-size. If you want to avoid adding all the code to emulate instructions, then that requires a lot of flash/SRAM or you have to use a bigger version of the ZPU that implements all the instructions.

If there was an LLVM port, then LTO (link time optimization) could be used to eliminate a lot more code, making for a better minimal case 32 bit CPU.

[PythonLinks]

Sorry for the slow response. I was on vacation.

@bert-lange wrote:

The ZPU does trick a little, it uses three memory cells as register (search for 'memreg' in the startup code).

That explains a lot. And more importantly it gives me a pointer as to where I should read more.

@oharboe wrote:

What would be the motivation for using the ZPU instead of RISC-V these days?

Excellent question. For a single processor, I would prefer the RISC-V. But for multiple processors, the smaller ZPU design makes sense. In particular consider the case of hard real time control. Applications like the Parallax P2 target market. Or the XMOS (pre FFT) market. Where each external process can have a dedicated processor. That hugely simplifies software development. And speed of the individual processor is not that critical, compared to slow real world processes. There are a couple of things I do not like about the P2 design, with multiple ZPU's one could do much better. First on an FPGA and then hopefully as a dedicated chip.

Realistically it is a very long stretch, and yet I think it is very important to have a clear vision of the CPU I would like to be using, and that way as new many core processors are released, I have a yard stick by which to measure them.

So thank you all for your help. Next I have to read more about the architecture of the GNU compiler. I spend so much of my life reading.

[max1220]

Creating an LLVM backend for the ZPU is a lot like work... It would require a professional effort of a couple of months to do it. It's hard to see how it would be financed...

There already is a LLVM port: https://repo.or.cz/w/llvm/zpu.git I don't know in what shape it is, or what it would take to port to a newer LLVM version(last update 2010).

But I think porting to a newer version of GCC/LLVM could be done, I don't think either the GCC or the LLVM port require much additional "compiler work", as in complicated algorithms not implemented by LLVM or GCC generically already. It would mostly be updating to the newer semantics and "plumbing" the required parts together.

I thought the C language targeted register machines.

They are, but the compiler implementations need to be able to "allocate stack values" as well, if they "run out of registers". That is pretty common, but "always happens" for ZPU(Disclaimer: I'm not a compiler expert).