[libre-riscv-dev] power pc

Jacob Lifshay programmerjake at gmail.com
Tue Oct 29 22:58:30 GMT 2019


On Tue, Oct 29, 2019, 15:42 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Wednesday, October 30, 2019, Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > On Tue, Oct 29, 2019, 14:08 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > wrote:
> >
> > > On Tue, Oct 29, 2019 at 8:16 PM Michael Pham <
> pham.michael.98 at gmail.com>
> > > wrote:
> > >
> > > > Does this mean that all these use cases will suffer from less
> > > > efficiency if you do decide to switch to POWER?
> > >
> > > that's what i really want to know.
> > >
> >
> > Efficiency would depend on usecases (like usual). I'm making an educated
> > guess that the code would run slower in some important cases, and I know
> > for sure that there is a code-size penalty (which implies a power penalty
> > due to larger number of instructions that need to be read from the
> i-cache
> > and decoded and scheduled). there's probably not a need for larger
> i-caches
> > due to code-size because there aren't generally a lot of atomic
> > instructions, some of them just happen to be in hot loops.
>
>
> Ok then it's important. Add c++11 atomics, ir nothing else as a 16 bit
> opcode.
>

16-bit opcode isn't necessary, but something smaller than 192-bits is. I'd
aim for 32 (or 48/64) bits.

>
>
> > >
> > > > That seems like a huge downside honestly given how important C++11
> is.
> > > > Maybe just stick with RISC-V instead?
> > >
> > > ohhh hell no.  if Hugh gets back to me that the other OpenPower
> > > Members (NXP, IBM etc.) are ok with the "breakout" system
> > > (ISANS/ISAMUX), in an "official" capacity, it's worth it, just for the
> > > acceptance.
> > >
> >
> > I think that if we decide we should go with a PowerISA implementation,
> that
> > we should at least support user-mode RV64GC code for compatibility,
> because
> > we have risc-v in our name, and because of being simple to implement.
>
>
> Two ISAs. dang.
>
> Well, it's doable.
>
>
> >
> > If all the above happens I'm fine with proceeding to switch to Power --
> I'm
> > not strongly for or against it.
>
>
>  Ok great. I think, really, RV does not deserve our efforts to improve the
> ISA.
>
> However with dual ISAs we can have the 3D shader apps in PowerISA, in Kazan
> and RADV, then add accelerated PowerISA UNIX later.
>
> Translating from a 2nd ISA to an internal microcode isn't that hard.
>
> The only problem is the intransigence of the RISCV Foundation, the
> ISAMUX/NS switch is needed to get into PowerISA mode.
>

my idea is that the supervisor would be in Power mode and the user would be
in rv64gc mode (or Power or other isa), switching between them just uses
the standard risc-v system call instructions. the isamux would only need to
be in the Power side for the MVP.

this is similar to how a x86_64 kernel can run ia32 programs.

this isn't intended to allow intra-program RISC-V/Power interoperability as
much as to allow running RISC-V programs without a software emulator.

> > we can then always design and add c++-atomic-compatible instructions
> > > (if it turns out that the implementation of standard power-atomics is
> > > really that awkward).
> > >
> >
> > sounds good, though we should try to standardize them, since we wouldn't
> be
> > the only ones who would benefit from better atomics.
>
>
>
> Yehyeh
>
> Ok will update page notes.
>
>
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>


More information about the libre-riscv-dev mailing list