| openpowerbot | [irc] <vpandya> IIUC svp64 instructions are of following format | 10:47 |
|---|---|---|
| openpowerbot | [irc] <vpandya> `sv.asmcode/mode.vec{N}.ew=8,sw=16,m={pred},sm={pred} reg.v, src.s` | 10:47 |
| openpowerbot | [irc] <vpandya> I am not able to find 64 bit instructions on OpenPower ISA v3.1 page | 11:06 |
| openpowerbot | [irc] <vpandya> is it something libre-soc proposing? | 11:06 |
| openpowerbot | [irc] <lkcl> vpandya: yes. | 11:25 |
| openpowerbot | [irc] <lkcl> more like: sv.asmcode/vec{N}/ew=N/sw=N reg.{vs}, src1.{vs}, src2.{vs} | 11:26 |
| openpowerbot | [irc] <lkcl> we _may_ have to change the "=" to something else because it conflicts with the gnu-as macro use of "=" | 11:27 |
| openpowerbot | [irc] <lkcl> you may have missed this, yesterday: https://libre-soc.org/irclog/%23libre-soc.2021-07-02.log.html#t2021-07-02T13:42:32 | 11:28 |
| openpowerbot | [irc] <lkcl> or it looks like i forgot to mention: see in the Makefile, we have to run a "pre-processing" phase | 11:29 |
| openpowerbot | [irc] <lkcl> which turns "sv.asmcode/...." into ".long 0xNNNNNNN asmcode ...." | 11:29 |
| lkcl | lxo: we're starting to need that binutils support | 11:30 |
| openpowerbot | [irc] <lkcl> vpandya, btw one thing we do not want to be doing is to *hand-write* the SVP64 encoder/detecters. | 11:36 |
| openpowerbot | [irc] <lkcl> that's a resounding No. | 11:37 |
| openpowerbot | [irc] <lkcl> there's a program, sv_analysis.py, which can be used to auto-generate header files, data structures, etc. etc. which allow detection / parsing / support of SVP64 | 11:38 |
| lkcl | vpandya: this is a great document, very clear https://www.embecosm.com/appnotes/ean10/ean10-howto-llvmas-1.0.html | 11:41 |
| lxo | lkcl, thanks for letting me know. I've been having trouble getting myself to work on it. hopefully this knowledge will make it easier rather than harder. I still don't fully understand what's going on with me | 11:52 |
| lxo | I recall we'd run into an issue WRT generated files and corresponding sources at some point, has that been sorted out yet? | 11:53 |
| openpowerbot | [irc] <vpandya> In llvm world , back end can be written with domain specific language called tablegen. Information from .Td files are used in all places in llvm back end | 12:02 |
| lkcl | lxo: i've been there. it feels like you've an engine revving at 5,000 RPM but "nothing moves forward" | 12:12 |
| lkcl | it was more, "if the SVP64-parser-table sources are written by hand this is not only a waste of time it's also very risky" | 12:13 |
| lkcl | so i would greatly - strongly - prefer that any tables used in gas / gcc are auto-generated | 12:14 |
| lkcl | vpandya: great. ok so once we know what the format is (by making one or two by hand, first - same for you, lxo) then we will need an auto-generator in sv_analysis.py to create a table which can be included in the .Td file | 12:18 |
| lkcl | we absolutely do not need the hassle of 200+ hand-edited SVP64 parsing files in *two* compilers getting wildly out of sync. | 12:18 |
| lkcl | plus the format may need to change, and now the corresponding tables are out-of-date | 12:19 |
| openpowerbot | [irc] <vpandya> Auto generation of td file feels like research project of itsself , I know even in big orgs people are trying that | 12:19 |
| lkcl | vpandya: at least some tables which are #included | 12:25 |
| lkcl | 1 sec i will find something | 12:25 |
| lkcl | https://ftp.libre-soc.org/sv_decode.vhdl | 12:27 |
| lkcl | like this. | 12:27 |
| lkcl | that's entirely *auto-generated* | 12:27 |
| lkcl | so that whomever adds SVP64 to microwatt does *not* have to type out those lines by hand | 12:27 |
| lkcl | doesn't end up making transliteration mistakes | 12:27 |
| lkcl | and doesn't have the hassle of being told, "sorry, we changed the format, you have to update line 132 column 5 with some arbitrary 1-bit change" | 12:28 |
| lkcl | likewise, this is auto-generated as well: | 12:29 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isatables/LDSTRM-2P-1S1D.csv;h=51717dea5ccf46994801820d1f607f97a35ae50a;hb=c342c5f9f6cdf98afdb0c163b89c8ce6d3bdae1e | 12:29 |
| lkcl | vpandya: SVP64 is incredibly regular and strongly well-defined | 12:32 |
| lkcl | this is very, very deliberate. | 12:32 |
| lkcl | we have had recommendations to have rules such as "if XYZ then the format changes" and i have, every single time, said NO. | 12:33 |
| lkcl | just recently (last week) to support LD/ST bit-reversing, i experimented for the very first time to allow an "override" (a new LD format), and it was absolute hell | 12:34 |
| lkcl | it was so bad that ordinarily i would have said "no damn way in hell this is going into SVP64" | 12:35 |
| lkcl | but it's for FFT and DCT which has so many applications and such high importance i very reluctantly let it in | 12:35 |
| *** jn <jn!~quassel@user/jn/x-3390946> has left #libre-soc | 12:37 | |
| lkcl | bottom line, unlike other ISAs where i would expect them to struggle to auto-generate anything useful, SVP64 is sufficiently abstracted and regular that it can be. | 12:40 |
| lkcl | by the time you've done even two examples by hand, the patterns should be blindingly obvious. | 12:40 |
| lkcl | wait... hang on... | 13:19 |
| lkcl | vpandya: does the LLVM-IR phase emit *binaries* or does it emit *assembler*? | 13:20 |
| lkcl | if it's assembler, please ignore everything i said above :) | 13:20 |
| lkcl | because it's the process of turning SVP64 *assembler* into *binary* that is regular. | 13:20 |
| openpowerbot | [irc] <vpandya> It can emit assembly or ELF both , | 13:35 |
| lkcl | vpandya: okaaay. i see. ok, then the binary generation should be using auto-generated tables which match the regular patterning of SVP64, exactly as is done here https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;hb=HEAD | 14:15 |
| lkcl | or, similar, you know what i mean | 14:15 |
| lkcl | but if emitting assembler, that will need to be done by hand, non-automated. | 14:15 |
| lkcl | given that that tool, svp64.py, can perform the translation from "sv.{asm}" into ".long {asm}" right now, the most productive use of time is to use it, as a post-processing tool, just like is done in the MP3 examples. | 14:18 |
| lkcl | svp64.py understands ".set {regnum} tosomething" syntax so you can emit simple macros | 14:18 |
| lkcl | if you need anything more than simple macros, we'll need the full binutils gas program to understand svp64 | 14:19 |
| openpowerbot | [irc] <vpandya> for `sv.asmcode/mode.vec{N}.ew=8,sw=16,m={pred},sm={pred} reg.v, src.s` | 15:25 |
| openpowerbot | [irc] <vpandya> I think every thing related to mode, vec, ew, ... should be common | 15:25 |
| openpowerbot | [irc] <vpandya> in llvm's .TD | 15:25 |
| openpowerbot | [irc] <vpandya> only thing changes is asmcode | 15:25 |
| openpowerbot | [irc] <vpandya> unless if I misunderstood and there can be some condition on other fields based on asmcode | 15:26 |
| openpowerbot | [irc] <vpandya> for tablegen pattern matching it will be large based on number of combinations of all fields | 15:27 |
| openpowerbot | [irc] <vpandya> that can be improved later with automatically generating patterns | 15:28 |
| lkcl | basically that's it, yes. there should be absolutely no relation whatsoever between the prefix and the suffix (no limitation that is) | 15:36 |
| lkcl | except, duh, of course, that, y'know, some v3.0B asm opcodes have 3 regs, some have 2, some even have 4 | 15:36 |
| openpowerbot | [irc] <vpandya> I am checking if llvm already has ppc backend that supports OpenPower ISA v3.1 | 15:37 |
| lkcl | v3.1? that's quite unlikely. | 15:37 |
| openpowerbot | [irc] <vpandya> yes :( | 15:37 |
| lkcl | and it's a dead-end for us anyway | 15:37 |
| openpowerbot | [irc] <vpandya> that may increase work | 15:37 |
| lkcl | as in: there's nothing useful that it would add for us | 15:37 |
| openpowerbot | [irc] <vpandya> but I would like to explore what can be done | 15:38 |
| lkcl | as in: we don't do SVP64-of-v3.1 | 15:38 |
| lkcl | it would need 3x32 = 96-bit opcodes | 15:39 |
| lkcl | and that's too much | 15:39 |
| lkcl | {SVP64-prefix}{v3.1-prefix}{v3.0-suffix} | 15:39 |
| lkcl | it's far too complicated at this early stage | 15:40 |
| lkcl | btw one thing: there are concepts in SVP64 that simply don't exist in any other ISA. | 15:40 |
| lkcl | twin-predication is a good example. | 15:40 |
| lkcl | one predicate mask for the source, one predicate mask for the destination | 15:41 |
| openpowerbot | [irc] <vpandya> SVP64 backend in LLVM is very instersting project | 15:41 |
| lkcl | yes. it's quite challenging to do elegantly. | 15:42 |
| openpowerbot | [irc] <vpandya> yes | 15:42 |
| lkcl | keep in mind, always, that it's basically a hardware for-loop | 15:42 |
| lkcl | a generic hardware-level for-loop (like x86 "REP" instruction) | 15:43 |
| lkcl | VideoCore IV GPU also has the same concept | 15:43 |
| lkcl | and the recent introduction of ARM SVE/SVE2 will make life a little easier | 15:43 |
| openpowerbot | [irc] <vpandya> for MESA based flow, we need LLVM | 15:57 |
| openpowerbot | [irc] <vpandya> otherwise develop complete flow with something like ACO | 15:57 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!