[Libre-soc-isa] [Bug 933] prefix-code (like huffman code) decode/encode instructions

[bugzilla-daemon at libre-soc.org]

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

--- Comment #19 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #16)
>     CR0 <- final_rb_used || 0b0 || (output = 0) || so_bit
> 
> deep breath, there is no register CR0 and it will not
> be picked up (back in ISACaller namespace).... yet.

it needs to be added, writing to CR0 also occurs in stbcx.'s pseudo-code.

> 
> then also it is not going to work for SV, either, because
> writing continuously to CR0 is not the desired behaviour.

I'm imagining that SV will simply take the CR0 output and write it to the
correct CR field for the current element -- that's what it should do for stbcx.
anyway (stbcx. could be used in VF mode imho, there would just need to be more
than 1 reservation).
> 
> writing directly to the CR Field is not the desired behaviour
> *either* although with BF and BFA (etc) those can be over-ridden
> (extended/walked) forward just like RA/RB/RC/RT/RS for elements,
> such that CR[32+4*bf..] etc will actually write to the correct
> CR Field.
> 
> (keenly aware that CRfield numbers CR8 and above will over-run
>  CR, that's for another time)

iirc the CR register isn't a SPR (mfspr can't read it), so we could just make
it be a 512-bit register named CRX and CR[s:e] would be an alias for
CRX[s-32:e-32] to avoid needing to change all the pseudocode and mfcr and
friends would only read the msb 32-bits without being sv-prefixed.

CR[32:35] = CRX[0:3] = CR0
CR[36:39] = CRX[4:7] = CR1
...
CR[540:543] = CRX[508:511] = CR127

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