[Libre-soc-isa] [Bug 569] svp64 register predicates vs BE arrays of bits

[bugzilla-daemon at libre-soc.org]

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

--- Comment #19 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #18)
> (In reply to Jacob Lifshay from comment #17)
> > (In reply to Luke Kenneth Casson Leighton from comment #15)
> > > if you are volunteering to write the Grant Appplication and develop
> > > the simulator and the HDL, after first finishing the delivery of the
> > > commitments we are already obliged to complete, then great.
> > 
> > for what exactly? byteswapping the regfile into memory order?
> 
> all of it. the full and comprehensive instruction analysis, modifications
> required to the spec, everything.  it's so large that i'd suggest you
> write the Grant at the full EUR 50,000.

ok, I can work on that, though I'd likely put it off till later, as you
mentioned. Just wanted to make sure you were onboard with the idea of Libre-SOC
working on that.

> (In reply to Jacob Lifshay from comment #16)
> 
> > no reversals are required because you never touch an integer predicate, you
> > go from vector of ints (not a predicate) to the cmpi into a vector of cr
> > bits (not an integer predicate so bitreversal doesn't happen) to whatever
> > instruction is predicated where the cr vector is used as a predicate (not an
> > integer predicate so bitreversal doesn't happen)
> 
> to say that the problem may be "avoided" by not using precisely and exactly
> one of the beneficial features of SVP64 is... well, i'm not sure what to say

my point is that predicates are only bitreversed when in integer registers (or
in memory). CRs are already kinda a Vector<i1, N>, stored in logical element
order, one bit per CR, so no bitreversing needs to happen, because bitreversing
happens whenever the cpu is translating between the type Vector<i1, N> and it's
memory layout. Integer predicates are bitreversed because they are Vector<i1,
N> but converted to the in-memory layout, then the in-memory bytes are
interpreted as a 64-bit integer.
> 
> > actually, it's perfectly possible to have that property in BE, simply store
> > the bigint in BE:
> 
> the example that you gave when picking 32-bit means that
> when setting elwidth to 64-bit the words in each 64-bit
> element are in the wrong order.

how so, afaict it's the right order.

Example with a different 256-bit number so you can distinguish 64-bit parts:
8-bit words:
[0x12, 0x34, 0x56, 0x78, 0x9a, 0xbc, 0xde, 0xfe,
0xdc, 0xba, 0x98, 0x76, 0x54, 0x32, 0x10, 0x13,
0x57, 0x9b, 0xdf, 0x2, 0x46, 0x8a, 0xce, 0xca,
0x86, 0x42, 0xf, 0xdb, 0x97, 0x53, 0x1a, 0xa5]
16-bit words:
[0x1234, 0x5678, 0x9abc, 0xdefe, 0xdcba, 0x9876, 0x5432, 0x1013,
0x579b, 0xdf02, 0x468a, 0xceca, 0x8642, 0xfdb, 0x9753, 0x1aa5]
32-bit words:
[0x12345678, 0x9abcdefe, 0xdcba9876, 0x54321013,
0x579bdf02, 0x468aceca, 0x86420fdb, 0x97531aa5]
64-bit words:
[0x123456789abcdefe, 0xdcba987654321013,
0x579bdf02468aceca, 0x86420fdb97531aa5]
128-bit words:
[0x123456789abcdefedcba987654321013, 0x579bdf02468aceca86420fdb97531aa5]
256-bit words:
[0x123456789abcdefedcba987654321013579bdf02468aceca86420fdb97531aa5]

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