[libre-riscv-dev] GPU design

[lkcl]

On Fri, Dec 7, 2018 at 1:33 PM Jacob Lifshay <programmerjake at gmail.com> wrote:

> Actually, i'm pretty sure he meant mmx.

 he probably _said_ MMX, my recall's not that accurate :)

> didn't overwrite whatever mmx registers were in use, so that made the
> registers effectively unusable for fp when mmx was in use and unusable for
> mmx when fp was in use. There's even a special emms instruction to reset
> the registers so they can be used for fp again.

 ... exactly.

> In my proposal, the registers can be easily used for both at once since
> it's trivial to have the register allocator allocate different registers
> for different variables.

 it is... but not dynamically.  as in: it would be necessary to call a
function, or to have "if-then-else" logic, in a situation where saving
cycles to set up the CSRs is already critical.  i really really do not
think this is a good idea.

> This is similar to the reason that RV doesn't need
> dedicated address registers for all pointer-valued variables: it's trivial
> to share the registers with integer-valued variables.

 if it was a good idea, it would have been done in scalar RV, already.
there was a discussion / proposal to share the regfile between int and
fp in RV32EF.  the idea being, the FP reg numbers *are* the INT reg
numbers.

 in RV32 it's absolutely fine: all bets are off as far as
"compatibility" is concerned.  programs are customised, heck the
entire EC is customised to one specific goal.

 shared register files for *general-purpose* computing on the other
hand is, i believe, asking for trouble.

 unfortunately i don't have enough direct first-hand experience with
this to be able to "categorically" point to reasons why it's a bad
idea.  i just... "know/feel" that a full and comprehensive exploration
will end up digging up more and more reasons why it's not a good idea.

l.