[Libre-soc-isa] [Bug 553] svp64 register mapping to accomidate AltiVec vectors expanding fp registers

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Fri Jan 15 00:47:24 GMT 2021


Jacob Lifshay <programmerjake at gmail.com> changed:

           What    |Removed                     |Added
         Resolution|WONTFIX                     |---
             Status|RESOLVED                    |DEFERRED

--- Comment #5 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #4)
> the only way that this is going to work is if implementation proceeds *right
> now*, without further delay, getting the core details out into code that can
> be reviewed, understood, and incrementally adjusted accordingly.

Ok, then we should start implementing stuff! if you write it all out in code,
it will likely become easier to think about! Writing it out can be one of the
ways to think through the consequences.

The changes that implementing this bug report would require are pretty
localized to the decoder anyway, so, if we decide that we need it (which we may
want despite the extra work in gcc due to needing to efficiently support
128-bit data values for AES/SHA256/etc.), it should be pretty easy to add on

One future option (that you don't need to think about now -- just start writing
code) is to instead conceptually base the SV isa on 128-bit registers, where
all integer and fp registers are rearranged into 64 128-bit registers (instead
of 128 64-bit registers) and standard 64-bit scalar operations just operate on
the lower 64-bits. Vector operations tack a sequence of 128-bit registers
together to form the backing storage for SV vectors.

I'm marking this bug as deferred, since we *do* need to think about it later,
just not right now, instead of saying we'll never do it.

We can defer this till after we have an initial working cpu design.

You are receiving this mail because:
You are on the CC list for the bug.

More information about the Libre-SOC-ISA mailing list