[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 #20 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #19)
> (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.

there *is* no stbcx pseudocode.

> > 
> > 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

naah. the precedent has to be explained to the OPF ISA WG.

>  -- that's what it should do for
> stbcx. anyway 

it's written out in english iirc or it is hard-set into CR, can't
recall which.


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

again, that changes the scalar spec, which will be unacceptable.

*hiding* the existence of CRX as a massive hack behind the scenes
in ISACaller, such that the OPF ISA WG never have to know it exists,
i have no problem with at all.

if however the ISA WG come forward with a proposal to change
the scalar spec to replace CR with CRX in all locations?
that i have no problem with either.

but us proposing it? that just gives them the chance to say "no"
and they will stick to it.

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