[Libre-soc-isa] [Bug 213] SimpleV Standard writeup needed

[bugzilla-daemon at libre-soc.org]

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

--- Comment #76 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #74)
> (In reply to Jacob Lifshay from comment #73)
> > (In reply to Luke Kenneth Casson Leighton from comment #71)
> > > 
> > > we _could_ conceivably do bit-level DM subdivision onto 64 bit integer regs
> > > but... no, please, no :)  it makes a mess of the "Register Cache" idea,
> > > unfortunately.
> > 
> > it would totally work, those
> 
> oops forgot to finish:
> 
> all we need to do is treat those two mask-optimized int regs as separate
> from the rest -- kinda like CTR is treated differently than the int regs.

i get it.  they still need bit-level DM tracking, and if they are designated as
int regs as well it becomes even more hell, at the point where they interact
with "real" int regs.

if they are treated as completely separate regs (SPRs in effect) they need
their own opcodes, and i really don't want to go down that route.

> > > 
> > > whereas CRs we have the freedom *to* decide how many we want to extend it to.
> 
> the set of integer registers optimized for masking can be extended too,

please understand: it really is too complex to track the dependencies for
something that specialised.

> without needing all the mess of CRs.

think it through, jacob: vector CMPs and standard Rc=1 vectorised operations
*still require a minimum 64 CRs anyway*

if we have to have vector CRs anyway, they need to be DM tracked
(individually).

if they have to be individually tracked then the logic to put them into the
Shadow Matrices for predication is far less: no shifts, no masks, just use the
DMs.

or we abandon CRs pretty much entirely for vectors and this is not an option i
am happy to consider, it will cause havoc for gcc and llvm conpiler developers.

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