bug-mes
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]