Best RETARGETABLE C compiler for FPGA CPU projects?

[gnuarm]

People seem enthralled by C.  I'm not such a big fan.  I much prefer to work in forth.  But then, I'm not trying to port C code. 

A forth oriented CPU is very easy to make in an fpga.  They can be small and if you know how to design in an HDL, they can be very fast.  Your forth CPU can be programmed in forth to "interpret" x86 opcodes as an intermediate language.  Then you can still program it in C.

what does x86 opcodes have to do  with c? x86 didn't even exist when c came about

Existing compilers will compile C code for an x86 processor.  Your forth target can emulate an x86 and run the compiled C code.   I believe the C compilers still support the early x86 processors, like the 8086, 80286, etc.  So, you don't need to worry with the full, modern instruction set. 

Meanwhile, your forth target will run forth to provide an interactive scripting language.

Yes you could do that, but there is no reason to think that x86 is the best ISA to use for this purpose. Almost anything else (at least 16 or 32 bit) I can think of would be better.

x86 is just about as annoying to parse / decode in software as it is in hardware. Perhaps even worse, it is EXTREMELY annoying and slow to emulate condition codes on a machine with different condition codes or even different rules for setting them (or none at all). In a JITting emulator that can give a 2:1 slowdown, but in an interpretive one (assuming trivial instruction code, which x86 doesn't have) it can be 5:1 or worse compared to emulating an ISA without condition codes.

You seem to be swimming against the flow.  If you can't figure out how to deal with this issue, then you should not be working on the problem. 

On the contrary, I have academically published (and frequently cited) work in this area (high performance RISC-V emulation on x86), have commits in QEMU and Spike (Golden Reference RISC-V emulator), and have worked on JITs for Javascript, C# and others.

Then, why are you making a simple problem difficult?

[laugensalm]

People seem enthralled by C.  I'm not such a big fan.  I much prefer to work in forth.  But then, I'm not trying to port C code. 

A forth oriented CPU is very easy to make in an fpga.  They can be small and if you know how to design in an HDL, they can be very fast.  Your forth CPU can be programmed in forth to "interpret" x86 opcodes as an intermediate language.  Then you can still program it in C.

what does x86 opcodes have to do  with c? x86 didn't even exist when c came about

Existing compilers will compile C code for an x86 processor.  Your forth target can emulate an x86 and run the compiled C code.   I believe the C compilers still support the early x86 processors, like the 8086, 80286, etc.  So, you don't need to worry with the full, modern instruction set. 

Meanwhile, your forth target will run forth to provide an interactive scripting language.

That might be possible in theory, but is complete nonsense from an engineering perspective.
I'm well aware of the Forth niche, and I've seen funky things indeed, like UDP stacks written in Forth running on a enhanced J1. But emulating a register architecture on a stack machine introduces a massive overhead, not just from emulation side,  let aside a horribly designed x86 legacy.

It is actually easier to get a new core designed and verified according to a regression test of an existing compiler suite than the other way, designing a compiler backend, *if* full coverage is required. Else, LLVM can give you quick results as well, question is, whether  the C frontend then still makes sense compared to Python code generation.

C is good for porting stuff and is understood by almost all. That's just that.

I just realized how old this thread was, and that I already posted on DOOM on the ZPU (still a very nice stack machine, being actively used). At the end of the day, the engineering question specific to a CPU SoC is: Will it still fit on my FPGA and can I program it with a standard gcc?

To give an example about hard limits: I need to run a bare metal 'OS' with RPC functionality (UDP/IP) in 32kB RAM. RV32c (compressed ISA) is getting close, ZPU can do, i.e. provides the optimum relation of gate count and code density and obviously beats x86-opcodes in the latter discipline.
Would I really even consider inserting an emulation layer?

[mikerj]

Then, why are you making a simple problem difficult?

He isn't, simply pointing out how complex your "simple" solution would be in practice.

[gnuarm]

Then, why are you making a simple problem difficult?

He isn't, simply pointing out how complex your "simple" solution would be in practice.

Sure, you can make anything difficult, if you really want to. 

[langwadt]

Then, why are you making a simple problem difficult?

He isn't, simply pointing out how complex your "simple" solution would be in practice.

Sure, you can make anything difficult, if you really want to.

and you can say anything it simple and easy if you haven't done it

[Berni]

Then, why are you making a simple problem difficult?

He isn't, simply pointing out how complex your "simple" solution would be in practice.

Sure, you can make anything difficult, if you really want to.

Go ahead and try to write a x86 emulator in forth and see how 'simple' it really is (especially if you want to support a fairly modern variant of x86)

The simple solution is to take a existing simple ISA (like a 6502) that has existing compilers for it and just implement that. These old ISAs are already designed to be simple to use while getting a reasonable amount of performance out of a small number of transistors. You could still add your own custom extensions to a popular instruction set.

[SiliconWizard]

Q: Can you suggest a retargetable C compiler?
A: C is obsolete, use Micropython.
 

[abeyer]

A: C is obsolete, use Micropython.

...just so long as you already have a working c toolchain to build micropython 

[EEexpert]

Tiny C compiler would be a good choice.
A competent C developer can add new CPU arch to it in a couple of weeks if it's his first arch, next one may need just a couple of days. Very good knowledge of the instruction set for the target arch is required.

[Canis Dirus Leidy]

A forth oriented CPU is very easy to make in an fpga.  They can be small and if you know how to design in an HDL, they can be very fast.  Your forth CPU can be programmed in forth to "interpret" x86 opcodes as an intermediate language.  Then you can still program it in C.

Why bother with emulation at all, instead of taking a ready-made core like ao486/s80x86/MCL86? If, of course, the task is to get a working x86-compatible SoC.

[gnuarm]

A forth oriented CPU is very easy to make in an fpga.  They can be small and if you know how to design in an HDL, they can be very fast.  Your forth CPU can be programmed in forth to "interpret" x86 opcodes as an intermediate language.  Then you can still program it in C.

Why bother with emulation at all, instead of taking a ready-made core like ao486/s80x86/MCL86? If, of course, the task is to get a working x86-compatible SoC.

How large is such a CPU in an fpga? 

[langwadt]

A forth oriented CPU is very easy to make in an fpga.  They can be small and if you know how to design in an HDL, they can be very fast.  Your forth CPU can be programmed in forth to "interpret" x86 opcodes as an intermediate language.  Then you can still program it in C.

Why bother with emulation at all, instead of taking a ready-made core like ao486/s80x86/MCL86? If, of course, the task is to get a working x86-compatible SoC.

How large is such a CPU in an fpga?

more like why would anyone even consider an x86 in an fpga?

[gnuarm]

A forth oriented CPU is very easy to make in an fpga.  They can be small and if you know how to design in an HDL, they can be very fast.  Your forth CPU can be programmed in forth to "interpret" x86 opcodes as an intermediate language.  Then you can still program it in C.

Why bother with emulation at all, instead of taking a ready-made core like ao486/s80x86/MCL86? If, of course, the task is to get a working x86-compatible SoC.

How large is such a CPU in an fpga?

more like why would anyone even consider an x86 in an fpga?

Because it will run the code from his C compiler. 

[brucehoult]

A forth oriented CPU is very easy to make in an fpga.  They can be small and if you know how to design in an HDL, they can be very fast.  Your forth CPU can be programmed in forth to "interpret" x86 opcodes as an intermediate language.  Then you can still program it in C.

Why bother with emulation at all, instead of taking a ready-made core like ao486/s80x86/MCL86? If, of course, the task is to get a working x86-compatible SoC.

How large is such a CPU in an fpga?

more like why would anyone even consider an x86 in an fpga?

Because it will run the code from his C compiler.

A partial list of ISAs that C code can be compiled to from GCC and/or LLVM:

aarch64, amd64, arc, arm32, avr, csky, hexagon, hppa, ix86, ia64, loongarch, m68k, microblaze, mips, msp430, nds32, or1k, ppc32, ppc64, riscv32, riscv64, s390, sparc, sparc64, sparcv9, thumb, xcore, xtensa.

All those compilers (and usually emulators too) are just an "apt install" away on Debian-based systems (or equiv on Fedora, Arch etc).

Most of them would be a better choice than x86, but in particular early arm32, riscv32, or msp430 if 16 bit is good enough.

[gnuarm]

A forth oriented CPU is very easy to make in an fpga.  They can be small and if you know how to design in an HDL, they can be very fast.  Your forth CPU can be programmed in forth to "interpret" x86 opcodes as an intermediate language.  Then you can still program it in C.

Why bother with emulation at all, instead of taking a ready-made core like ao486/s80x86/MCL86? If, of course, the task is to get a working x86-compatible SoC.

How large is such a CPU in an fpga?

more like why would anyone even consider an x86 in an fpga?

Because it will run the code from his C compiler.

A partial list of ISAs that C code can be compiled to from GCC and/or LLVM:

aarch64, amd64, arc, arm32, avr, csky, hexagon, hppa, ix86, ia64, loongarch, m68k, microblaze, mips, msp430, nds32, or1k, ppc32, ppc64, riscv32, riscv64, s390, sparc, sparc64, sparcv9, thumb, xcore, xtensa.

Which of these are small enough to fit in the fpga?

All those compilers (and usually emulators too) are just an "apt install" away on Debian-based systems (or equiv on Fedora, Arch etc).

Most of them would be a better choice than x86, but in particular early arm32, riscv32, or msp430 if 16 bit is good enough.

Maybe someone will read this and give it the attention it deserves.

[brucehoult]

A partial list of ISAs that C code can be compiled to from GCC and/or LLVM:

aarch64, amd64, arc, arm32, avr, csky, hexagon, hppa, ix86, ia64, loongarch, m68k, microblaze, mips, msp430, nds32, or1k, ppc32, ppc64, riscv32, riscv64, s390, sparc, sparc64, sparcv9, thumb, xcore, xtensa.

Which of these are small enough to fit in the fpga?

Depends how big the FPGA is.

There is an RISC-V RV32I core that fits in 198 LUTs and 164 FF on an iCE40, or 125 LUTs and 164 FF on an Artix-7.

I think the smallest and cheapest popular iCE40 boards have 3000 or 5000 LUTs, so there's plenty of room left for other things. e.g. the popular iCEBreaker has 5K LUTs and this site says it fits 10 such RV32I cores, plus a simple network joining them. https://corescore.store/  An Lattice iCEstick with 384 LUTs fits 2 of these cores.

Larger FPGAs can fit 10,000 SeRV cores.

[Berni]

That SERV is a neat little CPU softcore there.

Does look like it would be a useful CPU for some simple control tasks in FPGAs. The size usually matters more than the speed, and this thing is packed impressively tiny. Didn't think id see CPUs with internal 1bit data paths in the modern day, but it makes perfect sense here.

[brucehoult]

That SERV is a neat little CPU softcore there.

Does look like it would be a useful CPU for some simple control tasks in FPGAs. The size usually matters more than the speed, and this thing is packed impressively tiny. Didn't think id see CPUs with internal 1bit data paths in the modern day, but it makes perfect sense here.

Yes. It has very few gate delays so the clock can be near the FPGA's maximum (maybe 400 MHz on Artix-7?) which means even with 32 cycles for most instructions (64 for shifts and branches) it probably averages around 10 (32 bit!) MIPS at that clock speed.

There is also now "QERV" which widens the data path to 4 bits and gives 3x speedup, while adding only 15% in LUTs.

SeRV runs valid RV32I code, but doesn't try to do anything sensible with unimplemented opcodes -- just whatever happens happens. The same as 6502 and z80 and others of that era...

[laugensalm]

That SERV is a neat little CPU softcore there.

Does look like it would be a useful CPU for some simple control tasks in FPGAs. The size usually matters more than the speed, and this thing is packed impressively tiny. Didn't think id see CPUs with internal 1bit data paths in the modern day, but it makes perfect sense here.

The problem with RISC-V is its suboptimal code density, and not to forget the register file which eats up at least one block ram primitive. With the 'c' (compressed instructions) extension, you get better density, but that doesn't perform well on an FPGA. I'd see the SERV rather as one of many serial CPU experiments (people have been doing this with MIPS more than 10 years ago).

msp430 (I've used neo430) and ZPU are among those with best code density versus minimal LUT usage while having GCC support. Without GCC requirements, you can go even lower with funky 9 bit opcodes (this being rather FPGA specific) or code windowing (where an address line is actually part of the opcode...), or you take the mentioned Forth path through some really minimal stack machines.

[coppice]

The problem with RISC-V is its suboptimal code density, and not to forget the register file which eats up at least one block ram primitive. With the 'c' (compressed instructions) extension, you get better density, but that doesn't perform well on an FPGA. I'd see the SERV rather as one of many serial CPU experiments (people have been doing this with MIPS more than 10 years ago).

I think people get too hung up on code density. I've spent years around people experimenting with code density, and getting excited about small increases. When you point out how little real world code for ARMs uses THUMB instructions they sulk.

[ataradov]

In FPGAs and soft cores code density matters. If you are using soft cores for basic control tasks, then you are likely running out of BRAMs, and those are usually not great to waste.

[langwadt]

In FPGAs and soft cores code density matters. If you are using soft cores for basic control tasks, then you are likely running out of BRAMs, and those are usually not great to waste.

yeh, that's the problem with softcores,  if you look at an MCU die almost all of it is memory, and an FPGA is a very expensive way to buy memory

[langwadt]

The problem with RISC-V is its suboptimal code density, and not to forget the register file which eats up at least one block ram primitive. With the 'c' (compressed instructions) extension, you get better density, but that doesn't perform well on an FPGA. I'd see the SERV rather as one of many serial CPU experiments (people have been doing this with MIPS more than 10 years ago).

I think people get too hung up on code density. I've spent years around people experimenting with code density, and getting excited about small increases. When you point out how little real world code for ARMs uses THUMB instructions they sulk.

depends on what ARM, cortex-m is only thumb(-2)

with slow memory like the flash usually is on an MCU it can also help with speed

[asmi]

In FPGAs and soft cores code density matters. If you are using soft cores for basic control tasks, then you are likely running out of BRAMs, and those are usually not great to waste.

Just about all FPGAs load their bitstream from QSPI flash, and almost always there is a leftover space which can be used to store application code. The only "cost" here is a small component to access QSPI flash, and since the only thing it requires is readonly access, it can be very simple as all it needs to do is issue a read command with start address where application is stored, copy it to some external memory, and transfer control to it. AMD/Xilinx even provides an out-of-box solution for this in form of SREC bootloader. And in rare case when FPGA doesn't have any external memory, you can run the code straight from  QSPI via XIP.

[bson]

On any of the Unix (BSD) releases for the PDP-11.  BSD 2.11 is my favorite of those that run on the PiDP-11 simply because I understand Unix (a bit) but I know nothing about the other DEC OSes.  They might be learnable but they are not compelling - to me.

There's not much compelling reason to learn the DEC OSes, other than from a system design perspective.  Of them, RSX-11M/M+ is by far the most interesting; it's an asynchronous real-time executive without threading, but with (never shipped with) SMP support.  The second most interesting is RSTS/E with its runtime system (RTS) model, which is basically an OS emulation layer, with emulators for other DEC OSes (and a few other specialized things; when I was in high school we created a LISP RTS for RSTS/E). The RTSes handled things like command parsing and syscall translation to native RSTS/E.  It was a pretty nice timesharing system actually (for the day) that came with a native BASIC RTS.  You could do things like develop software targeting dedicated RSX-11M (or S) systems without things like virtual memory (on the target), on the timeshare system, then often just link it for the target and run it there.  (Linking was required without an MMU to actually relocate the program for the target system.)  The linker, the RSX task builder (TKB) was much more than just a linker.

Of course completely obsolete today.  It was practical and quite excellent for the days though, and I think worth studying for anyone interested in system design.  (Much of RSX also came with source code that was compiled for a specific system during the install process - and later to change system options.)

By comparison I personally (just me) think BSD is a big shrug... it's just an old, very primitive Unix.