| *** vup2 is now known as vup | 01:07 | |
| *** mepy <mepy!~mepy@151.75.96.251> has left #libre-soc | 11:39 | |
| lkcl | lxo: ping. | 15:13 |
|---|---|---|
| lkcl | question for you: would you be happy to do a python-based "translator" from binutils-style svp64 syntax into ".long 0xnnnnn; opcodev3.0b"? | 15:14 |
| lkcl | it's for use in the unit tests like this: | 15:14 |
| 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 | 15:15 |
| lkcl | so that would be: | 15:15 |
| lkcl | lst = SVP64translator(["sv.extsw r3.v, r0.s"]) | 15:16 |
| lkcl | and the output would be: | 15:16 |
| lkcl | [".long 0xnnnnn", "extsw 3, 0"] | 15:17 |
| 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 | 15:18 |
| lkcl | https://libre-soc.org/openpower/opcode_regs_deduped/ | 15:18 |
| lkcl | end of this file https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv_analysis.py;hb=HEAD | 15:19 |
| 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. | 15:21 |
| lxo | lkcl, I suppose I could do that. my primary concern is that it amounts to duplicating pretty much all of the opcode & operand parsing code from binutils. it's a substantial amount of code | 15:53 |
| lxo | makes me wonder if it's not more sensible to just do it in binutils proper | 15:54 |
| lxo | OTOH, I can see how the svp-specific transformations would be easier to do in python | 16:02 |
| lkcl | that was my thoughts, and it has the advantage of understanding and rapid prototyping, getting everything straight before going to binutils.. but being able to use *unmodified* binutils, right now. | 17:24 |
| lkcl | it shouuuld be possible to use sv_analyse.py to auto-generate header files and/or other data structures for use in binutils when it comes to it, saving a huge amount of work | 17:24 |
| lkcl | urr i just learned that power-gem5 doesn't have the remote gdb support we need. gem5 has the underlying concept (base classes) just not the over-rides needed | 17:25 |
| lxo | should this binutils work take priority over the compiler one (558)? I was planning to return to the latter today, after catching up with emails I haven't even looked at yet | 17:27 |
| lxo | I'm glad to tackle them both, and to address first whatever would be most useful first | 17:28 |
| lkcl | python class first, binutils next, gcc third. | 17:34 |
| lkcl | because the python class can be used *right now*, binutils will take a bit of time, and gcc is critically dependent on binutils | 17:35 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!