[libre-riscv-dev] SVprefix v0.2

Jacob Lifshay programmerjake at gmail.com
Mon Feb 18 09:44:28 GMT 2019


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

> On Mon, Feb 18, 2019 at 9:30 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > I had meant for a redesign using tomasulo's algorithm that we (or someone
> > else) might do for a successor to our SoC.
>
> yyeahh, after evaluating all the different options, i think it's
> fairly safe to say that anyone not using the type of register file
> split and not doing the hierarchical reservation stations with split
> (shared) Function Units would have a bitch of a job supporting element
> widths not equal to the register file width.
>
> and, from what mitch alsup said, it's a well-known bitch-of-a-problem
> to shoe-horn SIMD-style "lanes" on top of a general-purpose register
> file, that's caused no end of problems for decades.
>
> the only reason i feel comfortable with it is because of that
> hierarchical reservation concept, where use of an 8-bit or 16-bit
> element cascades up to reserve the (full) 32-bit register and the
> 64-bit register as well.  and that's only really possible to do using
> a Scoreboard design (as best i can tell).
>
> basically, other microarchitectures would need to forego support for
> varying element widths and punt it to traps.
>
x86 is able to support varying widths, so it can't be too much of a pain
(vzeroupper and giant performance penalties on some intel processors
notwithstanding).

>
> l.
>
> _______________________________________________
> 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