[Libre-soc-isa] [Bug 535] setvl/setvli encoding & future reg file expansion

[bugzilla-daemon at libre-soc.org]

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

--- Comment #15 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #14)
> (In reply to Luke Kenneth Casson Leighton from comment #12)
> > in *compressed*, do we want a separate setvli? mmm... maayyybeee... although
> > i don't think there's space.
> 
> sounds like the perfect place to do some immediate reencoding to just use
> common values, giving us 1 bit for setvli vs. setmvli

do have a quick look at the imm table, see if it's worthwhile.

> > ok,ok, this is hilarious: if we allow setvl to be an SV-P48 prefixable
> > instruction, it *might* be possible (stress: might) to get CR0 retargetted
> > at an alternative CR.
> > 
> > one downside of Rc=1 is you can't doecify an alternative CR, end result you
> > have to move it to another CR then the bc can use that alternative target.
> 
> can't bc just use cr0 as-is?

yes, but think about it: intervening ops between the setvl and the branchpoint
will likely have trashed cr0 (other Rc=1 ops).  if either the intervening ops
can be retargetted or both the setvl and bc are retargetted..

.. of course, the irony is that if the overhead of using two SV-P48 prefixes
comes to 32 bit, you might as well just eat the cr move.  unless you use the
16-bit variant.

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