[Libre-soc-bugs] [Bug 745] OP_TERNLOG instruction

[bugzilla-daemon at libre-soc.org]

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

--- Comment #44 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #43)
> (In reply to Luke Kenneth Casson Leighton from comment #40)
> > ahh, and *this* works.
> > 
> > @@ -12,7 +12,7 @@ Pseudo-code:
> >      result <- [0] * XLEN
> >      do i = 0 to XLEN - 1
> >        idx <- (RT)[i] || (RA)[i] || (RB)[i]
> > -      result[i] <- (TLI & ROTL64(1, idx)) != 0
> > +      result[i] <- TLI[7-idx]
> >      RT <- result
> >  
> > nuts.  note the 7-idx.  IBM will have a fit about that,
> > it's LSB0-to-MSB0 conversion and i'm pretty sure they'll
> > want (insist on) MSB0 being in the spec.
> > 
> > deep breath: the spec needs to read:
> > 
> >       result[i] <- TLI[idx]
> 
> I'd strongly argue we need little-endian anyway for essentially the same
> reasons as SV integer predicates being in little-endian, if we're ever going
> to have the non-immediate form.

in some fashion or other, even if it's similar to bpermd.

i do wish this stuff wasn't so bleedin hard to get yer head round.

thoughts out loud:

* the lowest bit in e.g. RC has to be the lowest index
* therefore it will be 63-0
* therefore it is indeed ok to have MSB number inversion
* and, actually, that's consistent with everything else
  where we just did a massive XLEN-i substitution
* which i had totally forgotten about

so yes if questioned there exists a justification for keeping
7-idx because it will match with XLEN-id for the nonimmed version

am all caught up now.

ROTL64 just looks messy and unreadable. specifications are supposed
to be clear.

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