[libre-riscv-dev] LibreSOC - RISCV and POWER dual architecture feasibility

[Jacob Lifshay]

On Sat, Mar 14, 2020, 22:10 Hendrik Boom <hendrik at topoi.pooq.com> wrote:

> On Sat, Mar 14, 2020 at 08:17:07PM -0700, Jacob Lifshay wrote:
> > The software side will be a little harder but still relatively easy, we
> > need to implement support for translating Linux system calls from the
> > RISC-V interface to the internal calls, as well as implementing the
> > syscalls for switching modes between ISAs -- that's like 80% of the work
> on
> > the Linux Kernel side. For userspace, we can have just executing RISC-V
> ELF
> > executables as a MVP, later, we can implement the stuff in the dynamic
> > linker to handle having both Power and RV code loaded in the same process
> > -- I'm thinking we should use a system similar to Wine and Darling (like
> > Wine but macOS on Linux) where they have two dynamic linkers in the same
> > process. Will have to figure that out.
>
> Is the multiarch feature of Linux of any use here?


I don't think so, since it would allow switching between ppc64le and
ppc32le (or some other 32-bit variant of Power).

  I think it
> allows a choice of architecture for each *process*.  So we'd
> just have to have two sets of libraries.  We wouldn't have to link
> any code that contains both architectures.
>

We can do that just fine, however, since all our custom extensions are only
in the Power side, RISC-V programs wouldn't be able to use the custom
extensions so that means Vulkan (and our other user-space drivers) would be
very slow or not run at all.

Therefore, we should build ISA to ISA interfaces to allow a RISC-V function
to call and be called by a Power function -- my current plan is to have the
program make a syscall to switch between ISAs.

maybe have syscalls something like:

// Power side
void call_riscv_from_power(void (*riscv_function)(void *), void *arg);

// RISC-V side
void call_power_from_riscv(void (*power_function)(void *), void *arg);

We would still have to worry about the differences between RISC-V and Power
ABIs such as memory layouts and handling stack unwinding and backtraces.

The current plan is for Kernel-mode to be entirely Power and it can switch
to RV when switching to user mode as well as any interrupt, exception, or
syscall will switch to Power mode and run the appropriate Kernel code.

Jacob