[Libre-soc-bugs] [Bug 325] create POWER9 TRAP pipeline

[bugzilla-daemon at libre-soc.org]

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

--- Comment #112 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Samuel A. Falvo II from comment #110)
> (In reply to Samuel A. Falvo II from comment #108)
> > This seems like a gaping hole in the spec, and I'd argue it needs top
> > priority for resolution by the OpenPower group.
> 
> To add two more things to this train of thought:
> 
> 1. If bit 0 of a field is the least significant bit, 

it's not - it's the MSB.  read the spec again.  p4.  section 1.3.2

- The leftmost bit of a sequence of bits is the
  most significant bit of the sequence.


> just written to the
> left of the most significant bit, then why do we bother with the 63-x
> computation at all?  It shouldn't matter how the bits are printed on paper.

see above.


> 2. This implies that some 32-bit registers (those which are documented using
> bits ranging from 32 to 63) actually occupy the upper half of a GPR when
> moved, not the lower-half.

that's incorrect.  a register of length 64 bits, the lower half LSBs are
in bit positions numbered 32-63.

yes.  it's very very odd.  mulli pseudocode for example:

    XO-Form

        mulhw RT,RA,RB (Rc=0)
        mulhw. RT,RA,RB (Rc=1)

    Pseudo-code:

        prod[0:63] <- MULS((RA)[32:63], (RB)[32:63])
        RT[32:63] <- prod[0:31]

funfunfun - note there we're taking the *high* word from the
product... by taking the *lower*-indexed parts of prod!

oh and because it's 32-bit inputs, the LSBs are taken from
RA and RB using indexing RA[32:63].

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