[Libre-soc-isa] [Bug 905] create Scalar reg access encoding (SVP64-Single)

[bugzilla-daemon at libre-soc.org]

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

--- Comment #5 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #2)
> (In reply to Luke Kenneth Casson Leighton from comment #1)
> > thinking out loud for bitallocations
> > 
> > * 12 EXTRA4x3
> 
> alternately 12 EXTRA3 x4

if you meant "3 extra scalar bits", yes.

[SVP64.EXTRA3 contains scalar/vector - vector is redundant for SVP64Single].

to get up to 2^7 there are 4 extra bits required
because all CR fields are only 3 bit.

> 2 saturate -- unsigned/signed saturate differently, we'll want both -- this
> should be encoded as a signed/unsigned bit and a saturate bit, since the
> signed/unsigned bit is also useful for deciding to sign/zero extend
> inputs/outputs when src/destelwid differ.

ahh ok

> also fp ops have different values worth saturating to:
> * standard 0.0 to 1.0
> * standard -1.0 to 1.0
> * i32? u32? i8? u8? i16? u16?

change of meaning of the operation must not occur.  saturate to
those values *and still be a float* (i.e. convert to int, saturate,
then convert back to float), not a problem.  change the meaning
of the operation to store in an *int*, we can't do that.

but... hmmm... saturating on some of the fp-to-int operations,
yes not a problem there.


> > 
> > totals 21, 3 spare. EXTRA5? leave as reserved?
> 
> imho we should leave as reserved because that reduces the amount of space
> required to 1/4th (accounting for 2 saturate bits) as much as svp64, greatly
> reducing opcode pressure.

there's no reserved encoding *at all* for SVP64 so yes, good to start
doing that.

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