Bug 578 - python-based svp64 "generator" class
Summary: python-based svp64 "generator" class
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL: https://libre-soc.org/openpower/sv/im...
Depends on:
Blocks: 577
  Show dependency treegraph
Reported: 2021-01-22 15:23 GMT by Luke Kenneth Casson Leighton
Modified: 2022-09-25 19:19 BST (History)
2 users (show)

See Also:
NLnet milestone: NLNet.2019.10.032.Formal
total budget (EUR) for completion of task and all subtasks: 500
budget (EUR) for this task, excluding subtasks' budget: 500
parent task for budget allocation: 577
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:
lkcl = { amount = 500, submitted = 2022-08-28, paid = 2022-08-31 }


Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2021-01-22 15:23:29 GMT
a class is needed in python that takes svp64 assembly and generates
Opcode-1 prefixed v3.0B equivalent assembly listing suitable for feeding
into UNMODIFIED ppc64 binutils.
Comment 1 Luke Kenneth Casson Leighton 2021-01-22 15:26:36 GMT

lkcl> lxo: ping.
<lkcl> question for you: would you be happy to do a python-based "translator" from binutils-style svp64 syntax into ".long 0xnnnnn; opcodev3.0b"?
<lkcl> it's for use in the unit tests like this:
<lkcl> https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/alu/test/test_pipe_caller.py;h=92c12f632fdea9b382fdb18d2f7d00200fb39fa1;hb=3518c40bb13ea2c5bb036045afadf19bb04fc270#l54
<lkcl> so that would be:
<lkcl> lst = SVP64translator(["sv.extsw r3.v, r0.s"])
<lkcl> and the output would be:
<lkcl> [".long 0xnnnnn", "extsw 3, 0"]
<lkcl> the context needs to be "picked up" - the mode - unfortunately - by doing a lookup in the CSV output from the deduped opcodes program sv_analyse.py
<lkcl> https://libre-soc.org/openpower/opcode_regs_deduped/
<lkcl> end of this file https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv_analysis.py;hb=HEAD
<lkcl> and the SVP64translator can read those CSV files, create a dictionary by assembly-code name (first column in the CSV file) and look that up to find what the "mode" is, EXTRA2 or EXTRA3 etc.
Comment 2 Luke Kenneth Casson Leighton 2021-01-22 19:12:11 GMT
the scope here of what is needed in SVP64translator is EXTREMELY limited.

example assembly:

the list of required supported instructions (FP to be added later):
Comment 3 Luke Kenneth Casson Leighton 2021-01-22 19:19:17 GMT
example involving predication:

    lst = SVP64translator(["sv.addi r3.v, 5, mask=1<<r3"])


    [".long 0xnnnnnn", "addi r3, 5"]
Comment 4 Luke Kenneth Casson Leighton 2021-01-22 19:54:07 GMT
to get the register order a few hoops have to be jumped through.  the
information needed is:

* to identify which arguments are registers and which are immediates.


   cmp BF,L,RA,RB

* BF is a CR
* RA and RB are registers

here is a file which contains that information:


here is the program that extracts that information:


now, these are just the names and the order.  but, the svp64 prefix
needs to know the format (order) for the R_EXTRA2/3 section of the
Remapped Encoding
    (see https://libre-soc.org/openpower/sv/svp64/)

*that* information is in the CSV files, generated by sv_analysis.py


running that program will generate some svp64 "RM-XX-YYZZ" files, with
the following format and columns:

    insn,Ptype,Etype,0,1,2,3,in1,in2,in3,out,CR in,CR out

note that the format here says "EXTRA3", this tells us "3 bits per
register" in the Extra Remapped Encoding bits

and the numbering 0,1,2,3 tells us that:

* BF extension is to go into the first 3 bits
* RA extension is to into the second 3 bits
* RB extension is to go inth the third 3 bits

how do we get the information about which was BF, which was RA, which was RB?
we get that information by using pagereader.py to get the parameters

    cmp BF,L,RA,RB

L may be ignored (or, more: unmodified)

however, input may be as follows:

    cmp 64.v,L,35,120.v

* the first argument, thanks to pagereader, tells us it is BF (a CR)
* likewise 3rd argument is RA, 4th is RB


* BF=64.v
* RA=35.s
* RB=120.v

this we must BACK-encode into (using EXTRA3 rules)

* BF: EXTRA3=v and the other 2 bits are (probably) 0b00.
  also: the v3.0B encoding for BF, we must divide that 64 by 16
  (something like that)
* RA: EXTRA3=s and the other 2 bits are 0b01 because it is 35>>5
  also: the v3.0B encoding for RA will be 35&0b111111 (5 LSBs)
* likewise RB is decoded to be a vector and shifted down by 4

therefore, the output is:

  [".long NNNN 1st EXTRA3: 0b100 2nd EXTRA3: 0b001 3rd EXTRA3 0b100 NNN",
    "cmp 4,L,3,30"]
Comment 5 Luke Kenneth Casson Leighton 2021-01-22 20:04:59 GMT
this should *literally* be all that's needed:

    from soc.decoder.pseudo.pagereader import ISA

    isa = ISA()
    print (isa.instr["cmp"].regs

that's it.  confirmed.

diff --git a/src/soc/decoder/pseudo/pagereader.py b/src/soc/decoder/pseudo/pagereader.py
index 8583bf4b..a5d05cc5 100644
--- a/src/soc/decoder/pseudo/pagereader.py
+++ b/src/soc/decoder/pseudo/pagereader.py
@@ -284,3 +284,5 @@ class ISA:
 if __name__ == '__main__':
     isa = ISA()
+    # example on how to access cmp regs:
+    print ("cmp regs:", isa.instr["cmp"].regs)
Comment 6 Luke Kenneth Casson Leighton 2021-01-22 20:31:33 GMT
field name "deducers" are in v3.0B section 1.7 page 16

they are:

* CRs:
  - 3 bit: BF and BFA
  - 5 bit: BA BB BC BI, BT
  - BO is... "odd", see section 2.4 "branch instructions"
  - FXM is a "mask" we ignore this one for now.

confirm CRs with:

Comment 7 Luke Kenneth Casson Leighton 2021-01-23 21:02:44 GMT

almost complete preliminary version.  covers all modes (mapreduce, predresult,
saturation, fail-first), elwidths, subvl, predicate sources, and extra
encodings for scalar/vector numbering extensions.

need to "dissect" what transpired and document it, now.