| lkcl | ghostmansd[m], for when you're awake - i'm going to start tackling Pack/Unpack which means a new "/thing" - "/vp" for pack and "/vu" for unpack and "/pu" for both flags | 05:29 |
|---|---|---|
| lkcl | yes it's a pair of RM.EXTRA mode-bits | 05:30 |
| lkcl | i'll have to work out which instructions it applies to, so sv_analysis.py and sv_binutils.py will need to know about that | 05:31 |
| lkcl | i really didn't want to start this until everthing else is upstream but it's taking too long | 05:31 |
| ghostmansd[m] | lkcl, perfect, ping me when these concepts are established. Adding new flags to binutils is extremely simple, thanks to the callbacks table I introduced. | 06:40 |
| lkcl | awesome. | 13:42 |
| lkcl | ghostmansd[m], okaaay i've added one range of ops, LD/ST-with-immediate such as lwz, stz | 18:59 |
| lkcl | sv_analysis.py now adds an extra column, "PU" which stands for pack/unpack | 19:00 |
| lkcl | when set, then /vp or /pu will set bit 14 of RM.EXTRA | 19:01 |
| lkcl | and /vu or /pu will set bit 15 of RM.EXTRA | 19:01 |
| lkcl | https://libre-soc.org/openpower/sv/svp64/#index12h1 | 19:01 |
| lkcl | i still have to put that into sv/trans/svp64.py | 19:12 |
| lkcl | but at least you know what to expect | 19:12 |
| lkcl | and now for a relaxing evening watching funny kittens on youtube. until i get bored | 19:12 |
| * lkcl graduated from funny kittens to "whose line is it anyway"... | 19:39 | |
| ghostmansd[m] | Fuck. I've just found we need another mapping, where we map the opcode to the SVP64 description (the structure with the bits we need). | 20:30 |
| ghostmansd[m] | We already have a mapping between name and desc... But this is available only in assembler's source code. | 20:31 |
| ghostmansd[m] | And disassembler needs a mapping between opcode and desc. We already can retrieve the "original" name from the suffix, but we cannot re-use this name in _disassembler's_ sources to lookup the entry in _assembler's_ sources. | 20:33 |
| ghostmansd[m] | Fuck fucking fuck. | 20:34 |
| ghostmansd[m] | Binutils split the "usual" insns (including prefixes) into so called segments. And then from opcode they retrieve the segment and iterate over subarray. | 20:35 |
| ghostmansd[m] | Basically they have large arrays split into buckets. Kind of a hash table, but splitting a contiguous array into chunks. When an instruction is proceeded, its major opcode is converted into the segment, and this segment just knows where the subsection of array starts (and the next segment shows where it ends). | 20:37 |
| ghostmansd[m] | And guess what? We don't have the opcodes. We only have name:desc mapping. | 20:38 |
| ghostmansd[m] | Basically we haven't needed these, since for suffix we re-use the opcode from vanilla instruction, and for prefix we calculate the stuff on the fly. And, well, we only needed name here. | 20:39 |
| ghostmansd[m] | I need to think about it with a fresh head. Storing a vanilla opcode could be one option; perhaps there might be some caveats with VLE/SPE2 instructions. | 20:41 |
| ghostmansd[m] | Anyway, once we have something to be used as bucket, we'll re-use the same approach binutils use. | 20:43 |
| ghostmansd[m] | We have opcodes in our CSV tables, even though these are not used for svp64.py. | 20:49 |
| ghostmansd[m] | I recall someone mentioning we won't ever be needing the opcodes... ;-) | 20:54 |
| ghostmansd[m] | OK, at least I had some code in binutils regarding this stuff, so I can restore it. As usual, the first idea which comes to mind is likely the right one (unless it's terribly wrong). | 20:57 |
| ghostmansd[m] | Anyway, enough for today. | 20:57 |
| lkcl | nooo plans to do Vectorised VLE. | 21:42 |
| lkcl | not without at least 3-4 months study of it, 3+ months analysis of it, 4 months implementation time in the Simulator... | 21:43 |
| lkcl | it'll be about a year's work all-in. | 21:44 |
| lkcl | on top of that it would punish multi-issue execution by forcing a need to hunt for 16 *and* 32 *and* 48 *and* 64-bit instruction boundaries. | 21:45 |
| lkcl | right now we can use a Carry-Lookahead algorithm (thanks to jacob on that one) right in the decode phase, which is O(log N) | 21:45 |
| lkcl | to detect beginnings of multi-issue 32/64 | 21:46 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!