[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Porting mes to RISC-V 64 bit
From: |
Jan Nieuwenhuizen |
Subject: |
Re: Porting mes to RISC-V 64 bit |
Date: |
Tue, 06 Apr 2021 19:19:51 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
W. J. van der Laan writes:
Hi,
>> 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.
Okay. Yes, I merely wanted to give you a heads-up. I would really like
64bits to work; it just may that we be missing something lateron in the
bootstrap. Let's see when we get there.
> 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, that's most likely.
>> 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.
Sure, let's try to avoid doing unwise things :-)
>> Thanks a lot for doing this work!
>
> It's both nasty and beautiful in a sense, but anyhow, it needs to be
> done.
Yes! Thanks,
Janneke
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | AvatarĀ® http://AvatarAcademy.com