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

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=553

--- Comment #10 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #9)
> (In reply to Jacob Lifshay from comment #7)
> 
> > I've proposed the high halves of f0-63 be f64-127.
> 
> i know.  it's not happening.  and it is completely unnecessary.

I strongly disagree:

basically, there's two choices for what to do with the high 64-bits of the vsx
registers:
1. 8/16/32/64-bit svp64 vectors use them -- this is incompatible to svp64
without vsx registers because which registers elements map to changes:
   f32x8 starting at f0:
   with vsx:
   el0-3 -- vsx reg 0 (f0)
   el4-7 -- vsx reg 1 (f1)
   without vsx:
   el0-1 -- f0
   el2-3 -- f1
   el4-5 -- f2
   el6-7 -- f3

   so if a program wants to use a scalar operation to read elements 4-5 of the
vector, does it use f2 and break if the cpu has vsx or use f1 and break if the
cpu doesn't have vsx?!

2. 8/16/32/64-bit svp64 vectors don't use the high halves of the vsx registers
-- you waste half your register file because you need 128 registers and the
registers have to be 128-bit but all but 128-bit operations can only pack their
vector elements in the low halves of the registers!

> when someone puts SVP64 on top of Scalar VSX, it happens automatically
> and implicitly because the VSX registers already have the mapping
> that you describe.

That's news to me, iirc we never changed the spec to state that f64-f127 ever
mapped to any existing registers.

if they don't, we still have exactly the problem i described above.

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