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

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

[Jacob Lifshay]

On Sat, Mar 14, 2020, 18:01 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
wrote:

> Hello Jacob,
>         I’m running through the numbers and studying LibreSOC’s potential
> markets, and how we’d market the dual architecture.
> Just how feasible is the dual architecture we’re currently embarking on.
> Luke says its doable.
> What are your thoughts, and what are the challenges - just trying to get a
> comprehensive understanding.
>

It will be quite easy to do from the hardware side due to the relative
simplicity of user-mode RV64GC -- basically all we need is to do is
implement the instruction decoder and clean up the odds and ends that
result from the semantic differences.

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.

We can also build a bare-metal hypervisor-like program to emulate RV system
mode to allow easier testing (don't need to boot a whole Linux kernel) as
well as booting a whole RISC-V OS. I'd estimate that it would be less than
10kloc of code.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 3:17 AM Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> On Sat, Mar 14, 2020, 18:01 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
> wrote:
>
> > Hello Jacob,
> >         I’m running through the numbers and studying LibreSOC’s potential
> > markets, and how we’d market the dual architecture.
> > Just how feasible is the dual architecture we’re currently embarking on.
> > Luke says its doable.
> > What are your thoughts, and what are the challenges - just trying to get a
> > comprehensive understanding.
> >
>
> It will be quite easy to do from the hardware side due to the relative
> simplicity of user-mode RV64GC -- basically all we need is to do is
> implement the instruction decoder and clean up the odds and ends that
> result from the semantic differences.

pretty much.  the RV64GC decoder would map onto the exact same
internal operations (the ones that anton blanchard started), and we
would expand those as necessary.

however that's not the main problem

we actually have a serious "bootstrap" problem in terms of implementing POWER.

here's how it works with RISC-V:

* take spike, and add SimpleV (done - took 2-3 months appx)
* take riscv-isa-tests, and add SimpleV unit tests (done - took about 1 month)
* implement a core in hardware by taking an existing core and adding
in our engine.
* run the EXACT SAME BARE METAL UNIT TESTS.

hardware is bootstrapped.  it's done in an incremental fashion, *one*
unknown at a time.

now let's look at POWER.

1) where are the unit tests?
2) where is the simulator?
3) where is the port of softfloat-3 that supports POWER IEEE754 format?

and on top of this *NON-EXISTENT* (or barely adequate) code, we want
to add a vectorisation system, *and then implement it in hardware*?

that's a minimum of *five* extremely large unknowns.

we therefore have two potential approaches (which we may have to do in
parallel):

1) getting a power isa cycle-accurate simulator plus unit tests is
absolutely essential.

2) getting the core working by bootstrapping up in only *one* unknown
at a time, and that means RISC-V.

as (1) is a software-only effort, we can continue with (2) to keep
hardware-people busy and occupied.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Jacob Lifshay]

On Sat, Mar 14, 2020, 21:01 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> 3) where is the port of softfloat-3 that supports POWER IEEE754 format?
>

You can use simple-soft-float which is (modulo possible bugs) entirely
correct for Power except that it might propagate NaN payloads incorrectly
since NaN payload propagation is only partially implemented and that it
needs to have the additional 20-30 lines of trivial code added to record
the cause for generating a NaN (because Power has more than the standard
list of FP exception conditions).

To operate on the Power f32-in-f64 format all you need to do is convert all
inputs to f32 (check manual for exact operation), do the operation in f32
format, then convert back to f64 (conversion is lossless).

Additional benefits include: not needing compile-time flag changes to
switch between Power and RISC-V modes (everything is dynamically
adjustable).

The code is written on top of the algebraic numbers library I wrote (gives
us a type that behaves like an infinite-precision real number) and in a
straight-forward manner (no fancy math to make it faster), hopefully making
the internal algorithms easier to prove correct (assuming the algebraics
library gives the correct answer).

There are tested Python bindings.

I did test it against softfloat3 for RISC-V, all tests pass.

source:
https://salsa.debian.org/Kazan-team/simple-soft-float

autogenerated Rust docs:
https://docs.rs/simple-soft-float/0.1.0/simple_soft_float/

Jacob

>
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 7:59 AM Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> On Sat, Mar 14, 2020, 21:01 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
> wrote:
>
> > 3) where is the port of softfloat-3 that supports POWER IEEE754 format?
> >
>
> You can use simple-soft-float which is (modulo possible bugs) entirely
> correct for Power except that it might propagate NaN payloads incorrectly
> since NaN payload propagation is only partially implemented and that it
> needs to have the additional 20-30 lines of trivial code added to record
> the cause for generating a NaN (because Power has more than the standard
> list of FP exception conditions).

yes.  could you add that?  it's important.  if you need a POWERPC
64-bit system to log in to in order to check that they're correct (by
doing "real" FP on a "real" POWER9 system) i can ask around.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] pearpc simulator running

[Luke Kenneth Casson Leighton]

i've just managed to get pearpc running (clang, ./configure
--enable-cpu=generic), and it "boots" the Mandrake-9 PPC 32 (BE)
installation ISO perfectly well.

reading up, historically, it could not boot linux 2.6 kernels (only 2.4).

qemu:
https://wiki.qemu.org/Documentation/Platforms/POWER

that looks... relevant to running kvm, very much less relevant to a
cycle-accurate simulator *however*, we *may* be able to pick up tips
on how to implement an MMU (and a 64-bit UNIX TLB).

there's a set of buildroot configs for ppc 32-bit and 64-bit:
https://github.com/maximeh/buildroot/tree/master/board/qemu/

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Hendrik Boom]

On Sat, Mar 14, 2020 at 08:17:07PM -0700, Jacob Lifshay wrote:
> On Sat, Mar 14, 2020, 18:01 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
> wrote:
> 
> > Hello Jacob,
> >         I’m running through the numbers and studying LibreSOC’s potential
> > markets, and how we’d market the dual architecture.
> > Just how feasible is the dual architecture we’re currently embarking on.
> > Luke says its doable.
> > What are your thoughts, and what are the challenges - just trying to get a
> > comprehensive understanding.
> >
> 
> It will be quite easy to do from the hardware side due to the relative
> simplicity of user-mode RV64GC -- basically all we need is to do is
> implement the instruction decoder and clean up the odds and ends that
> result from the semantic differences.
> 
> 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 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.

Architecture switch would happen at system call and at process 
switch.

-- hendrik 
> 
> We can also build a bare-metal hypervisor-like program to emulate RV system
> mode to allow easier testing (don't need to boot a whole Linux kernel) as
> well as booting a whole RISC-V OS. I'd estimate that it would be less than
> 10kloc of code.
> 
> Jacob
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Jacob Lifshay]

On Sat, Mar 14, 2020, 22:10 Hendrik Boom <hendrik@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
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Immanuel, Yehowshua U]

> * take spike, and add SimpleV (done - took 2-3 months appx)
> * take riscv-isa-tests, and add SimpleV unit tests (done - took about 1 month)
> * implement a core in hardware by taking an existing core and adding
> in our engine.
> * run the EXACT SAME BARE METAL UNIT TESTS.
> 
> hardware is bootstrapped.  it's done in an incremental fashion, *one*
> unknown at a time.
> 
> now let's look at POWER.
> 
> 1) where are the unit tests?
> 2) where is the simulator?
> 3) where is the port of softfloat-3 that supports POWER IEEE754 format?

So what I’m hearing is that spike combined with risk-isa-tests has sped up the development process.

Now, we just need a way to map POWER onto Simple-V?
How does the decoded Michael is working on fit in?

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 7:19 AM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:

> > 1) where are the unit tests?
> > 2) where is the simulator?
> > 3) where is the port of softfloat-3 that supports POWER IEEE754 format?
>
> So what I’m hearing is that spike combined with risk-isa-tests has sped up the development process.

massively - and provided us with a way to test it, so that when it
comes to implementing it in hardware, the *hardware* can be verified
immediately.

bear in mind that the full hardware will run (in nmigen simulation
form) at *seconds* per cycle.  compiling with iverilog will be better
but nothing like an FPGA.

each level of additional complexity and time for compilation means yet
more delay in finishing... and not having unit tests actually means
*we can't declare it finished*.

> Now, we just need a way to map POWER onto Simple-V?

not quite.

1) first we need a suitable POWER simulator.  it needs to be 64-bit,
LE and BE capable, with a full MMU, and capable of running bare-metal
tests as well as a full GNU/Linux 64-bit OS (even if that's in-memory,
like spike)
2) we then need a full set of bare-metal unit tests
3) *then* we add SImple-V to POWER at the *specification* level
4) *then* we implement Simple-V in the POWER simulator
5) *then* we implement bare metal unit tests capable of running in the
POWER simulator
6) *then* we implement POWER in hardware
7) *then* we run the unit tests from step 2 under the hardware
8) *then* we add SimpleV to POWER in hardware
9) *then* we run the unit tests from step 5 under the hardware

it's a hell of a lot of work - a lot more than with RISC-V.  with
RISC-V the fact that spike and the unit tests exist *and work* is a
massive, massive head-start, where not only do we not have to do the
research to get that working, we can use it by examining even the
source code of the simulator to actually see what's going on [spike
actually implements RISC-V UNIX Platform TLBs, and throws full and
correct page-fault exceptions].


> How does the decoder Michael is working on fit in?

it's a decoder.  if you don't have it, you can't decode POWER
instructions.  it's an essential part.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Immanuel, Yehowshua U]

> massively - and provided us with a way to test it, so that when it
> comes to implementing it in hardware, the *hardware* can be verified
> immediately.

So it sounds like the only benefit of RISCV was the RISCV spike emulator which allowed us to test our SimpleV proposal.

I’m still not clear how keeping RISCV compatibility helps us?

It seems to me like excuses to keep RISCV around than an actual need to continue with it.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Immanuel, Yehowshua U]

> I’m still not clear how keeping RISCV compatibility helps us?
> It seems to me like excuses to keep RISCV around than an actual need to continue with it.

Unless we’re breaking down POWER instructions into RISCV operations internally - which DOES make sense to me.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Immanuel, Yehowshua U]

Although, even if we have POWER -> RISCV uOPS, we still don’t need RISCV64 compatibility.

Its just unnecessary from a customer standpoint and extra labor - I’m still not seeing the benefit.

For a MVP, we should do the minimum - which at this point, seems to be just POWER.

If its a matter of original NLNET proposals, its probably easier to request permission for changes in architectural promises than trying to deliver everything(I’m sure NLNET know that unforeseen obstacles can and will pop up)…

Yehowshua

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 6:21 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:
>
> > I’m still not clear how keeping RISCV compatibility helps us?
> > It seems to me like excuses to keep RISCV around than an actual need to continue with it.
>
> Unless we’re breaking down POWER instructions into RISCV operations internally - which DOES make sense to me.

no it doesn't, at all.  here's the ISA tables:
https://libre-riscv.org/openpower/isatables/

those are an *internal* format (each row).

mapping to that exact same internal format by creating a RISC-V
decoder is a matter of about... 3 to 4 days work.

converting RISC-V to POWER ISA by way of a *DIRECT* conversion is an
extremely complex task, one which would normally only be considered in
software.  look at how many lines of code there are in say qemu JIT
translation and it tells you what you need to know.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Immanuel, Yehowshua U]

> no it doesn't, at all.  here's the ISA tables:
> https://libre-riscv.org/openpower/isatables/

So RISCV is ONLY in software at this point - that is no RISCV on the actual hardware?

And I know I seem a little pushy - but I have to be able to justify RISCV support upfront.
To put it differently, if you can convince me of the value of retaining RISCV, then you can convince anyone.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Immanuel, Yehowshua U]

Or, is the internal format some sort of intermediate that both RISCV and POWER instructions map down to?

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 7:20 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:
>
> Or, is the internal format some sort of intermediate that both RISCV and POWER instructions map down to?

yeees.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 7:24 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Sun, Mar 15, 2020 at 7:20 PM Immanuel, Yehowshua U
> <yimmanuel3@gatech.edu> wrote:
> >
> > Or, is the internal format some sort of intermediate that both RISCV and POWER instructions map down to?
>
> yeees.

now you've got it.

and that internal format is trivial.  single-bit wires.

to do a 32-bit to 32-bit translator is a MASSIVE piece of silicon that
has to preserve every nuance of the instructions...

oh... err... and once it's translated to POWER, it has to go through
*another* translation process, to be decoded into the internal format?

errr no.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 7:17 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:

> > no it doesn't, at all.  here's the ISA tables:
> > https://libre-riscv.org/openpower/isatables/
>
> So RISCV is ONLY in software at this point - that is no RISCV on the actual hardware?

i've added this source code - wholesale - into the soc repo:
https://github.com/lambdaconcept/minerva

> And I know I seem a little pushy - but I have to be able to justify RISCV support upfront.
> To put it differently, if you can convince me of the value of retaining RISCV, then you can convince anyone.

i spent five months on adding SimpleV to spike.

*we do not have a working simulator for powerpc let alone have one
that has SV added to*

simple math.

estimated time to develop RISC-V SV hardware: about 4 man-months

estimate time to develop POWER SV hardware: at least ONE MAN-YEAR
because we DO NOT HAVE A SIMULATOR.

it's real simple.

if however we get USD $10m funding it's not an issue because we can
find a ton of people.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Immanuel, Yehowshua U]

OK.

So to sum up - we have limited funding currently, and we want to have something to show hopefully by October - progress on RISCV is already well underway.

Lets make this prominent on the website - that we’re currently doing Dual ISAs.

Once we do get a lot of more funding, I would eventually like to move to only supporting one architecture which seems to be POWER right now. I say this because I believe supporting DUAL ISA down the road will cause more headaches than its worth. Not that it isn’t possible, but its notably non-trivial and adds little value to most customers.

We can explain this to our backers - people can be flexible - especially over a cup of tea.

However for right now, the risk minimizing move (if I understand everything correctly) is to maintain the position of supporting both ISA with incremental additions of POWER.

Who knows, I could be wrong. Maybe people really would find a use for dual ISAs - but up front, to investor for example, and to me, it looks unnecessary.

What are your thoughts on this?

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Jacob Lifshay]

On Sun, Mar 15, 2020, 12:33 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
wrote:

> Who knows, I could be wrong. Maybe people really would find a use for dual
> ISAs - but up front, to investor for example, and to me, it looks
> unnecessary.


In my opinion, dual ISAs is a significant advantage that basically no one
else has, since it allows us to run both Power and RISC-V software at full
speed, it's also useful for on a test server where people need to test both
Power and RISC-V software (where QEMU isn't good enough).

Later (for Libre-SOC v2 or v3), it might be a good idea to add support for
x86 and x86_64 user-mode since the patents for the base ISA will have
expired by then. This would help give us an advantage since it would allow
us to run legacy software.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Immanuel, Yehowshua U]

> Later (for Libre-SOC v2 or v3), it might be a good idea to add support for
> x86 and x86_64 user-mode since the patents for the base ISA will have
> expired by then. This would help give us an advantage since it would allow
> us to run legacy software.

Isn’t x86 kinda big - like a 1000+ instructions? How would this impact our power target…

But other than that, I’m all for adding x86 support.

But yeah, the main thought in my head for sticking with a single ISA is power consumption.

Also, we should develop our codebase such that we can easily generate RTL that can target RISCV or POWER…

Like ``python3 builds.py —target RISCV64`` for example.

In other words, we should be able to parametrize by architecture:
or perhaps:

``python3 builds.py —target RISCV64+POWER``

This seems like a good feature and will probably encourage sustainable programming practices.


Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 7:53 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:

> But yeah, the main thought in my head for sticking with a single ISA is power consumption.

it's all at the translation (decoder), phase, yehowsua.   the choice
of ISA is a 33rd bit, and once decoded to that "internal" format,
it's... nothing.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Immanuel, Yehowshua U]

> x86 and x86_64 user-mode since the patents for the base ISA will have
> expired by then

Did you hear THAT intel?
Soto voice: Watch out

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 8:00 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:
>
> > x86 and x86_64 user-mode since the patents for the base ISA will have
> > expired by then
>
> Did you hear THAT intel?

haha :)

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Staf Verhaegen]

[-- Attachment #1.1: Type: text/plain, Size: 874 bytes --]

Immanuel, Yehowshua U schreef op zo 15-03-2020 om 19:52 [+0000]:
> > 
> > Later (for Libre-SOC v2 or v3), it might be a good idea to add support for
> > x86 and x86_64 user-mode since the patents for the base ISA will have
> > expired by then. This would help give us an advantage since it would allow
> > us to run legacy software.
> 
> 
> Isn’t x86 kinda big - like a 1000+ instructions? How would this impact our power target…
> 
> But other than that, I’m all for adding x86 support.

If you consider implementing x86 instruction set you also need to
consider the risk of patent lawsuits being filed at you...

Risc-V instruction set is specially designed to only use features which
are not patented or for which the patents have expired. I did not dive
in the open licensing terms but I assume that includes patent licenses.

greets,
Staf.


[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Jacob Lifshay]

On Sun, Mar 15, 2020, 15:04 Staf Verhaegen <staf@fibraservi.eu> wrote:

> Immanuel, Yehowshua U schreef op zo 15-03-2020 om 19:52 [+0000]:
> > >
> > > Later (for Libre-SOC v2 or v3), it might be a good idea to add support
> for
> > > x86 and x86_64 user-mode since the patents for the base ISA will have
> > > expired by then. This would help give us an advantage since it would
> allow
> > > us to run legacy software.
> >
> >
> > Isn’t x86 kinda big - like a 1000+ instructions? How would this impact
> our power target…
> >
> > But other than that, I’m all for adding x86 support.
>
> If you consider implementing x86 instruction set you also need to
> consider the risk of patent lawsuits being filed at you...
>

that's true, but if you only implement the parts where all the patents have
expired, then they'll have a hard time suing you for patent infringement.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Adam Van Ymeren]

On 2020-03-15 6:10 p.m., Jacob Lifshay wrote:
> On Sun, Mar 15, 2020, 15:04 Staf Verhaegen <staf@fibraservi.eu> wrote:
>
>> If you consider implementing x86 instruction set you also need to
>> consider the risk of patent lawsuits being filed at you...
>>
> that's true, but if you only implement the parts where all the patents have
> expired, then they'll have a hard time suing you for patent infringement.

Technically they'll have an easy time suing you.  Its easy to sue anyone
for anything.  They may have a hard time winning however.

>
> Jacob
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 10:23 PM Adam Van Ymeren <adam@vany.ca> wrote:

> Technically they'll have an easy time suing you.

so... how would that go?  what do you think the headline news would
be?  and what would the EFF, FSF and the SFLC's response be if we
asked them for help?  have a guess... :)

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Immanuel, Yehowshua U]

Haha, lets just wait until we’ve got some customers before pulling that stunt.
Also, literally, everybody including MS, Amazon, Apple, would be on our side.

Bad news for intel...

Sent from my iPad
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 7:44 PM Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> On Sun, Mar 15, 2020, 12:33 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
> wrote:
>
> > Who knows, I could be wrong. Maybe people really would find a use for dual
> > ISAs - but up front, to investor for example, and to me, it looks
> > unnecessary.
>
>
> In my opinion, dual ISAs is a significant advantage that basically no one
> else has, since it allows us to run both Power and RISC-V software at full
> speed, it's also useful for on a test server where people need to test both
> Power and RISC-V software (where QEMU isn't good enough).

from a commercial perspective, given that there doesn't exist any
mass-volume products that use RISC-V (just a lot of noise and a lot of
talk), it's not as attractive as it seems.

if however we assume that RISC-V *will* take off in mass-volume,
*then* it might become attractive.

however given that the RISC-V Foundation's reputation is now shot to
shit, and people know - loud and clear - that they are "Fake Open
Source", i highly doubt whether mass-commercial
*end-user-programmable* RISC-V systems will actually take off any time
in the next 8 to 12 years.

> Later (for Libre-SOC v2 or v3), it might be a good idea to add support for
> x86 and x86_64 user-mode since the patents for the base ISA will have
> expired by then. This would help give us an advantage since it would allow
> us to run legacy software.

now that *would* be good.

as we saw with the China ICT "Loongson G" architecture, even just the
base ISA having *partial* x86 hardware ISA support would give a
massive speed-boost of an emulated application.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Lauri Kasanen]

On Sun, 15 Mar 2020 12:43:45 -0700
Jacob Lifshay <programmerjake@gmail.com> wrote:

> Later (for Libre-SOC v2 or v3), it might be a good idea to add support for
> x86 and x86_64 user-mode since the patents for the base ISA will have
> expired by then. This would help give us an advantage since it would allow
> us to run legacy software.

486 and 586 patents had expired years ago, and we had Chinese 1 GHz
implementations of those (vortex86). Now they have 686 models, so I
take pentium pro patents are also up for use.

x86_64 should become free around 2022 by my estimation.

- Lauri

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Jacob Lifshay]

On Mon, Mar 16, 2020, 00:13 Lauri Kasanen <cand@gmx.com> wrote:

> On Sun, 15 Mar 2020 12:43:45 -0700
> Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> > Later (for Libre-SOC v2 or v3), it might be a good idea to add support
> for
> > x86 and x86_64 user-mode since the patents for the base ISA will have
> > expired by then. This would help give us an advantage since it would
> allow
> > us to run legacy software.
>
> 486 and 586 patents had expired years ago, and we had Chinese 1 GHz
> implementations of those (vortex86). Now they have 686 models, so I
> take pentium pro patents are also up for use.
>
> x86_64 should become free around 2022 by my estimation.
>

The amd64 spec was first published in august 2000 according to wikipedia,
so that may mean the base ISA patents expire in 2020.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Staf Verhaegen]

[-- Attachment #1.1: Type: text/plain, Size: 680 bytes --]

Lauri Kasanen schreef op ma 16-03-2020 om 09:14 [+0200]:
> On Sun, 15 Mar 2020 12:43:45 -0700Jacob Lifshay <programmerjake@gmail.com> wrote:
> > Later (for Libre-SOC v2 or v3), it might be a good idea to add support forx86 and x86_64 user-mode since the patents for the base ISA will haveexpired by then. This would help give us an advantage since it would allowus to run legacy software.
> 
> 486 and 586 patents had expired years ago, and we had Chinese 1 GHzimplementations of those (vortex86). Now they have 686 models, so Itake pentium pro patents are also up for use.

I think these were because Via had cross-patent license agreement with Intel.

greets,
Staf.


[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Lauri Kasanen]

On Mon, 16 Mar 2020 09:53:38 +0100
Staf Verhaegen <staf@fibraservi.eu> wrote:

> Lauri Kasanen schreef op ma 16-03-2020 om 09:14 [+0200]:
> > 486 and 586 patents had expired years ago, and we had Chinese 1 GHzimplementations of those (vortex86). Now they have 686 models, so Itake pentium pro patents are also up for use.
>
> I think these were because Via had cross-patent license agreement with Intel.

DMP is not related to VIA. Via's C and Nano lines happened much
earlier, with the licensing.

- Lauri

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

https://github.com/power-gem5
this boots a 64-bit BE linux kernel, plus a basic initramfs and has
telnet in to the console.
l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Staf Verhaegen]

[-- Attachment #1.1: Type: text/plain, Size: 680 bytes --]

Lauri Kasanen schreef op ma 16-03-2020 om 11:27 [+0200]:
> On Mon, 16 Mar 2020 09:53:38 +0100Staf Verhaegen <staf@fibraservi.eu> wrote:
> > Lauri Kasanen schreef op ma 16-03-2020 om 09:14 [+0200]:
> > > 486 and 586 patents had expired years ago, and we had Chinese 1 GHzimplementations of those (vortex86). Now they have 686 models, so Itake pentium pro patents are also up for use.
> > 
> > I think these were because Via had cross-patent license agreement with Intel.
> 
> DMP is not related to VIA. Via's C and Nano lines happened muchearlier, with the licensing.

I stand corrected; it was SiS which did the first Vortex86 and sold that line to DM&P.

Staf.




[-- Attachment #2: Type: text/plain, Size: 177 bytes --]

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 7:33 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:
>
> OK.
>
> So to sum up - we have limited funding currently, and we want to have
> something to show hopefully by October -

we're *going* to meet the tapeout deadline in October.  exactly what
with will be cut - in a draconian and clinical fashion - to *make*
that goal achievable.

> progress on RISCV is already well underway.

was.

*was* underway, until the RISC-V Foundation fucked us over, yes.


> Lets make this prominent on the website - that we’re currently doing Dual ISAs.
>
> Once we do get a lot of more funding, I would eventually like to move to only supporting one architecture which seems to be POWER right now. I say this because I believe supporting DUAL ISA down the road will cause more headaches than its worth.

well, once it's done it's done.

> Not that it isn’t possible, but its notably non-trivial and adds little value to most customers.

honestly i think you're right.  if we were doing ARM or x86 Dual ISA,
i'd say it had "real value".

> We can explain this to our backers - people can be flexible - especially over a cup of tea.
>
> However for right now, the risk minimizing move (if I understand everything correctly) is to maintain the position of supporting both ISA with incremental additions of POWER.

basically, so as not to be critically dependent on investment.

one of the biggest mistakes that any entrepreneurial team can make is
to make plans that ASSUME - as a critical dependency - the "existence
of VC funding".


> Who knows, I could be wrong. Maybe people really would find a use for dual ISAs - but up front, to investor for example, and to me, it looks unnecessary.

if an investor drop USD $10m onto the project, tomorrow, RISC-V goes.

if they *don't*, then we carry on with the plan that we have, and that
*most likely* means an incremental bootstrap process by way of RV32
(Minerva), RV64, RV64GC *and then* POWER *and then* SimpleV

why?

each of those is a *SMALL* incremental step.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Immanuel, Yehowshua U]

> i've added this source code - wholesale - into the soc repo:
> https://github.com/lambdaconcept/minerva

Note, I’ve spoken to Jean Francois Nguyen, the developer of Minerva.
He said that he can’t guarantee the pipeline dependencies are correctly implmented and
has done little to no formal verification on Minerva.

He said Minerva was just more of a proof of concept for nMigen.

So please keep that in mind.

@Luke, what did you want to use Minerva for?

On the other hand, VexRISCV is pretty well tested - although its in Chisel…
Maybe someone would care to translate it to nMigen.

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sun, Mar 15, 2020 at 6:20 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:
>
> > massively - and provided us with a way to test it, so that when it
> > comes to implementing it in hardware, the *hardware* can be verified
> > immediately.
>
> So it sounds like the only benefit of RISCV was the RISCV spike emulator which allowed us to test our SimpleV proposal.

it was much more than that: the formal testing, the emulation, the
bootloading, the buildroot - replicating all of these is almost a
YEAR's work.

we're doing silicon *in october*... with *no working powerpc software
simulator* let alone working hardware.

again, to emphasise: we *need* to do an "incremental approach".  not
having the pieces of the puzzle to be able to leapfrog from stone to
stone in small increments means that we are dead in the water until
those pieces are in place.


> I’m still not clear how keeping RISCV compatibility helps us?

we made a promise to our backers (including at least one sponsor who
is donating USD 500 a month).

> It seems to me like excuses to keep RISCV around than an actual need to continue with it.

on one hand we have financial backers on whom we depend.

on the other: if we bootstrap our way up the "ladder" by way of RISC-V
*FIRST*, we can "cross bootstrap" to POWER in SIDEWAYS small
increments.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [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@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

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev