Best RETARGETABLE C compiler for FPGA CPU projects?

[Berry Straw]

Something like this maybe?

https://x.com/BrunoLevy01/status/1795102632438038768

[trossin]

I’m not sure if this was said but instead of creating your own instruction set, reinvent the wheel and design your own implementation of a vintage processor. This way a C compiler will already exist. You can make it fun by amping up the implementation by adding multi-level caching, out of order execution and branch prediction logic. A killer 68000 would be fun as it at least has a large address space compared to a 6502.

Years ago I created a cycle and speed accurate hardware emulator of a 1970s vintage 1802 processor using a PIC microprocessor all in assembler. That was a fun project. I also wrote a toy C compiler for it which I’ll admit was painful.

[brucehoult]

I’m not sure if this was said but instead of creating your own instruction set, reinvent the wheel and design your own implementation of a vintage processor. This way a C compiler will already exist.

Absolutely the path of least resistance. But vintage processors are often not well supported by modern compilers -- or just are very difficult to support. It's easier to implement RISC-V RV32I than 6502. Or Arm, for that matter, but you can publish your RISC-V CPU without getting sued.

[bson]

You could grab an older version of gcc and add a machine description (.md) and other bits and pieces needed for your target.  You'd also need a version of binutils and do the same for gas since older gcc's generate assembly that needs to be assembled.  But presumably you want an assembler anyway.  You also need to add support to libbfd and few other libraries.  The most elementary .md for gcc is pretty straightforward (I added several in the 90s when I worked on those versions of gcc on the GNU Project at FSF, just for testing purposes, using completely invented architectures, for example with only subtraction, complement, and increment, but no addition so it would be forced to exercise my changes), and then you can address obvious shortcomings as they crop up and bother you.  This is assuming you're inventing a GPR-based architecture with linear memory; anything else and C is not going to be a good option.

[DiTBho]

A couple of man-weeks to design and implement a CPU in an FPGA but from what I see, man-years to retarget the compiler.

myC has been 8 years in the making, there is no optimization layer yet and the machine layer only includes MIPS32 and MIPS5++ (prototype).

I personally spent some time on myC too to do some personal development and research and see what could be done to improve C.

Not much, I tried and... honestly, I tried so many ideas in the last 8 years, almost all of them miserably failed, except the latest approach that is giving me satisfaction, but not so much if we consider the generated code.

I think it's basically a matter of trade-offs, but finding the right balance in a C compiler, written from scratch and mutated, or simply cloned and retargeted, always requires experience and a lot of time and dedication.

Does it make sense? It depends, but if the goal is to run Doom, then I think it's better to take a risc-v core, a { binutils, gcc, gdb, musl } toolchain, and digest them as is.

[DiTBho]

That was a fun project. I also wrote a toy C compiler for it which I’ll admit was painful.

This remembers me when I tried to add M56000 to gcc-v2.95

It's an old Motorola DSP.
There are no C compilers for it.
563xx has a few, 56000 has none.

[DiTBho]

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. 

GameDuino-v1. Basically a Forth-CPU on a Spartan3-250.
(v2 is completely different)