Re: Porting mes to RISC-V 64 bit

[W. J. van der Laan]

> Hello!

Hey!

> > Over the weekend I have been working on porting mes to RISC-V. I am
> > aiming for RV32IM and RV64IM e.g. `riscv32-unknown-linux-elf` and
> > `risc64-unknown-linux-elf`. But 64-bit is my primary aim at the moment
> > because it is a more common architecture for Linux RISC-V.
>
> That's beautiful. Just a heads-up: Please note that Mes currently does
> not fully support any 64bit platform yet. For x86_64-linux it passes
> most of the test set, however, we haven't built a functional tinycc yet
> with MesCC.

I've noticed this. I would have liked to focus on 32-bit first but one problem 
is that RV64 hardware generally doesn't run RV32 code, unlike for x86 both 
32-bit and 64-bit are 'primary' platforms without a backward compatibility 
relationship. And the only immediately usable development environment I have is 
RV64: a SiFive Unleashed board.

RV32 is great for FPGAs though. Last year I did some experimentation with an 
open hardware FPGA board (ULX3S) which has an FPGA capable of running four 
Linux-capable RV32 softcores. The bitstream can be compiled with the 
yosys+nextpnr FOSS toolchain. This is really neat for bootstrapping hardware 
and software in tandem long-term, however somewhat slow and with little memory 
available so less comfortable for development.

So I'm not really sure. If supporting 64-bit is really too much of an obstacle 
I consider shifting my focus. But also, going from RV64 to RV32 when RV64 is 
fully supported will be relatively straightforward but everything is more 
manageable than trying to do both at the same time. Conceptually they are very 
similar but lots of little context details (like the Linux syscall API) are 
different enough.

> > I got as far as having `mes-gcc` run on my SiFive Unleashed board, as
> > well as having the scaffold and mes tests pass for gcc (except
> > for 70-extern and 80-setjmp which seem really impractical to handle
> > for gcc). `mescc` also gets to the help message but I haven't adapted
> > it in any way for the architecture yet.
>
> OK, no harm in taking small steps ;-)

Yeah :) Bootstrapping is clearly a project that needs a long breath.

> > I expect that the biggest challenge in getting mescc to generate
> > RISC-V binaries is the assumption that there is a persistent flags
> > register (arch:a?->r and such). RISC-V instead has instructions that
> > compare a register against another register or zero and branch / set a
> > value directly. So some refactoring outside the architecture-specific
> > module will be needed.
>
> Okay. Stumbling on x86-specific choices was bound to happen at some
> time. Let's look at simple examples/tests and see what can be done.

Right, I will try that, have to start with really minimal C programs anyway. 
I'll start by creating the platform-specific structures, right now it fails with

assert fail: TYPE (x) == TSTRUCT

while trying to compile anything, probably because of a missing result in 
arch-get-info.

> Yes, for Mes please do. I took a look at your branch, please note that
> Mes uses GNU ChangeLog like commit messages. You can look at previous
> commits for inspiration.
> https://www.gnu.org/software/mes/manual/html_node/Submitting-Patches.html#Submitting-Patches

Ok, will do.

> If you're an Emacs user, using Magit is a great help there. Please ask
> if you need any help.
>
> We may want to keep your work on a "wip-riscv" branch for a while to
> mature and see that the x86 bootstrap does not break. Also, I'm working
> to integrate the full-source bootstrap work (the wip-m2 branch). That's
> quite an operation, we may want to integrate your work first if it's
> ready sooner but we probably don't want to mix those efforts.

I tend to agree though it might also make sense to selectively upstream some 
things that can already be upstreamed. If the codebases start to diverge too 
much it will be harder to integrate them later.
I have tried to be careful not to break other architectures.

> Thanks a lot for doing this work!

It's both nasty and beautiful in a sense, but anyhow, it needs to be done.

Greetings,
W.