[libre-riscv-dev] GPU design
lkcl at libre-riscv.org
Fri Dec 7 15:28:00 GMT 2018
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.
> 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
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.
More information about the libre-riscv-dev