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

[Hendrik Boom]

On Sat, Mar 14, 2020 at 11:13:23PM -0700, Jacob Lifshay wrote:
> 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.

Whatever is done initially, it looks like openGL shaders will 
eventually run on the Power side, no matter which side the openGL 
program runs in. 

For RISC-V openGL programs, this looks rather like the present-day 
situation, where the graphics processor has its own machine code.

For Power openGL programs, this separation is unnecessary.

-- hendrik