[Libre-soc-bugs] [Bug 865] implement vector bitmanip opcodes

[bugzilla-daemon at libre-soc.org]

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

--- Comment #13 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Andrey Miroshnikov from comment #12)

> I tried to make a minor_22.csv entry for bmask based on the info in
> https://libre-soc.org/openpower/sv/bitmanip/
> 
> but I don't really understand this well enough as the instruction bitfields
> are different:
> 10001,L,mode,ALU,OP_BMASK,RA,RB,NONE,RT,NONE,NONE,0,0,ZERO,0,NONE,0,0,0,0,0,
> 0,1,0,0,bmask,X,,1,unofficial until submitted and approved/renumbered by the
> opf isa wg

rright, ok, look at the CSV headings
https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isatables/minor_22.csv;hb=HEAD

opcode,unit,internal op,in1,in2,in3,out,CR in,CR out,
10001,L,mode,ALU,OP_BMASK,RA,RB,NONE

    opcode=10001
    unit=L??
    internal op = mode??
    in1 = ALU??

that cant' be right, can it?
how about this:

opcode,unit,internal op,in1,in2,in3,out,CR in,CR out,
10001,ALU,OP_BMASK,RA,RB,NONE

    opcode=10001 good
    unit=ALU     ah ha! that's making sense
    internal op=OP_BMASK ok that's better
    in1=RA               looking more like it

so that must be close.  what about the rest (at the end)?

sgn,rc,lk,sgl pipe,comment,form,CONDITIONS,unofficial,comment2
> 0,1,0,0,bmask,X,,1,unofficial un

     sgn=0  # ok
     rc=1   # wrong, it's not an Rc=1.
     lk=0   # ok
     sgl pipe=0     # ok
     comment=bmask  # correct
     form=X         # wrong, it's listed as BM2-Form

so that last bit should be:

    0,NONE,0,0,bmask,BM@,,1,unofficial un...


now, there's *one* more thing, which is slightly complicated.  look closely
at the OP_SETVL and e.g. OP_MINMAX entries:

-----11011-,VL,OP_SETVL,
-----011001,VL,OP_SVSHAPE,
-----111001,VL,OP_SVREMAP,
-----10011-,VL,OP_SVSTEP,
0111001110-,ALU,OP_MINMAX,
0011001110-,ALU,OP_MINMAX,
...

now let's look at the corresponding bitmanip table:

https://libre-soc.org/openpower/sv/bitmanip/

setvl:

   0.5         26....30  31  name   Form
   NN          11 011    Rc  setvl  SVL-Form

av max:

   0.5  21..25 26....30  31  name   Form
   NN   01110  01110     Rc  avmax  X-Form

can you see how in the bit-positions "21..25" for setvl, there is "------"?
this says to the PowerDecoder "don't try to match against those bits".
so we need to do the same thing for bmask, ***BUT***, look again at the
table:

bmask:

   0.5         26....30  31  name   Form
   NN          L 1000    1   bmask  BM2-Form

so that's going to be:

* five "-"s in bitpositions 21..25
* one  "-" in bitposition 26 (for the "L")
* four bits "1000" in 27..30
* one "1" in bit 31

to give:

 ------10001

so where you had this:


    opcode,unit,internal op,in1,in2,in3,out,CR in,CR out,
    10001,ALU,OP_BMASK,RA,RB,NONE....

it should in fact be this:

    opcode,unit,internal op,in1,in2,in3,out,CR in,CR out,
    ------10001,ALU,OP_BMASK,RA,RB,NONE....

that says "match ONLY bits 27..31 against 10001 but IGNORE 21..26"


a *second* job of PowerDecoder is to look up the av.mdwn file,
and get the "Form" (BM2) and the line "bmask RT,RA,RB,mode,L", then
the job of power_fields.py is to decode fields.txt, look at the
BM2 and find the bit-positions of L and mode (oh, and RT, RA and RB)

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