[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 #22 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #20)
> (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.

well, there is pseudocode for stbcx. in the v3.1B pdf (page 1089 (1115)) that
writes to a variable named CR0
> 
> > > 
> > > 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.

well, it makes sense to me, it's also exactly what Rc=1 effectively does.
> 
> >  -- 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.

I thought having CRX would be less weird than saying CR is a 512-bit register
but the MSB is bit 32 and the LSB is bit 543, bits 0-31 are constant zeros that
aren't included in the 512 bits.

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