[libre-riscv-dev] [Bug 314] Create Condition Register pipeline

[bugzilla-daemon at libre-soc.org]

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

--- Comment #6 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Michael Nolan from comment #3)
> The hell? IBM separately defines mtcrf and mtocrf, and reserves a bit to
> differentiate between the two. Except there's no functional difference
> between the two that I can tell, and the assembler will even assemble some
> instances of mtcrf as mtocrf. 

bizarre.

* mtcrf FXM,RS

    mask <- ([FXM[0]]*4 || [FXM[1]]*4 || [FXM[2]]*4 || [FXM[3]]*4 ||
             [FXM[4]]*4 || [FXM[5]]*4 || [FXM[6]]*4 || [FXM[7]]*4)
    CR <- ((RS)[32:63] & mask) | (CR & ¬mask)

* mtocrf FXM,RS

    count <- 0
    do i = 0 to 7
      if FXM[i] = 1 then
        n <- i
        count <- count + 1
    if count = 1 then
        CR[4*n+32:4*n+35] <- (RS)[4*n+32:4*n+35]
    else CR <- undefined


> Basically mtcrf fxm, reg uses fxm to construct a 32 bit mask, where each bit
> in fxm corresponds to 4 bits in the mask (so mtcrf 0xf1 would correspond to
> a mask of 0xffff000f). It then uses this mask to choose between bits of CR
> and the input register, and writes them back to CR

> mtocrf fxm, reg assumes fxm is a one hot encoded index into the bits of reg.
> It grabs those bits from reg and inserts them into cr, leaving the rest
> untouched. If fxm is not onehot, then the result is undefined.
> 
> Why these are different, I don't know.

clueless.  suggest to use nmutil PriorityPicker on FXM (see nmutil) because it
can be used do the one-hot detection very efficiently.

if the output is not exactly equal to the input from a PriorityPicker
(and is not zero) then this is the condition for detection that FXM
is one-hot.

p = PriorityPicker
p.i.eq(FXM)

is_onehot.eq(p.i == p.o & p.i != 0)

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