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.
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> 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> 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.
the scope here of what is needed in SVP64translator is EXTREMELY limited.
the list of required supported instructions (FP to be added later):
example involving predication:
lst = SVP64translator(["sv.addi r3.v, 5, mask=1<<r3"])
[".long 0xnnnnnn", "addi r3, 5"]
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.
* 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
*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
L may be ignored (or, more: unmodified)
however, input may be as follows:
* the first argument, thanks to pagereader, tells us it is BF (a CR)
* likewise 3rd argument is RA, 4th is RB
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",
this should *literally* be all that's needed:
from soc.decoder.pseudo.pagereader import ISA
isa = ISA()
that's it. confirmed.
diff --git a/src/soc/decoder/pseudo/pagereader.py b/src/soc/decoder/pseudo/pagereader.py
index 8583bf4b..a5d05cc5 100644
@@ -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)
field name "deducers" are in v3.0B section 1.7 page 16
- 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.
* GPRs: RA RB RC RS RT
* FPRs: FRA FRB FRC FRS FRT
confirm CRs with:
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.