[libre-riscv-dev] SVprefix v0.2

[Jacob Lifshay]

On Mon, Feb 18, 2019 at 1:25 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Mon, Feb 18, 2019 at 8:37 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > We would still need the Vstart CSR for loads/stores that fault after
> > executing part of the instruction.
>
>  yes.  i've got that in SV-Original, actually it's 2 VStart CSRs, as
> in twin-predication you need one for src and one for dest.
>
> > > and no need for a gather scatter instruction.
> > >
> > Gather/scatter is more powerful than twin predication.
>
>  oh, the MV.X thing, yes.  sorry, yes, i was thinking of something
> different.
>
> > for(int i = 0; i < 4; i++)
> > {
> >     dest[i] = src[indexes[i]];
> > }
>
> > >
> > >
> > >
> > > Also there is no bit for specifying zeroing or non zeroing mode in
> > > predication.  If there is no room, non zeroing (skipping elements)
> would i
> > > feel be preferable as it allows interleave of predicate with inverted
> > > predicate masks, to give 100% ALU utilisation on OoO.
> > >
> > > Which, if decided, would need to be documented.
> > >
> > Ok, lets go with leaving masked-off elements with their previous value.
> It
> > will just be a pain later if we want a higher-performance version,
> because
> > of needing the previous contents of rd to mux into the output,
>
I had meant for a redesign using tomasulo's algorithm that we (or someone
else) might do for a successor to our SoC.

>
>  only if doing lanes / traditional vector engines, or if the register
> file has write-enable lines that are much wider than (multiples of)
> the element width.
>
>  we're doing an OoO engine with write-enable right down to the byte
> level.  even if that design paradigm is expanded out to much higher
> performance, extra read ports are not needed.
>
>  ok, they'd be needed to get the higher performance: they would *not*
> be needed due specifically to masking.
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>