| *** mannerism <mannerism!~tic@107.191.100.185> has left #libre-soc | 02:11 | |
| lkcl | programmerjake, nicely done on cldivrem. pity about the other algorithm | 09:59 |
|---|---|---|
| programmerjake | thx! | 10:00 |
| programmerjake | reading it again, i realized i totally forgot to change the docstring for CLDivRemFSMStage to actually match the API it has now, rather than what I was thinking of writing but didn't end up writing. | 10:47 |
| programmerjake | oh, well | 10:47 |
| lkcl | doh :) | 10:48 |
| lkcl | ghostmansd, had a meeting last night, we came up with the idea of simply not putting "auto-generated, please do not edit" into opc-svp64.c and simply not telling binutils it's autogenerated | 11:39 |
| lkcl | the hassle that saves would be immense. | 11:39 |
| lkcl | and, reading between the lines, we suspect that ppc-opc.c is likely auto-generated as well. it has some of the hallmarks of autogenerated source. | 11:40 |
| ghostmansd | lkcl, gotcha | 12:15 |
| ghostmansd | will drop the comments | 12:16 |
| ghostmansd | for now I'll keep disclaimer as "/* part of Libre-SOC, sponsored by NLnet */"; this, however, must be updated before submission to FSF | 12:21 |
| ghostmansd | Perhaps something like this? https://pastebin.com/iHr6pQNG | 12:24 |
| lkcl | yeah that'd work really well | 12:39 |
| lkcl | there's some specific voodoo incantation for NLnet and NGI POINTER grants... | 12:39 |
| lkcl | # Sponsored by NLnet and NGI POINTER under EU Grants 871528 and 957073 | 12:40 |
| littlebobeep | lkcl: Is DDR RAM init code quite separate from the main processor? Is there an example of this in Libre-Soc, and why does this functionality sometimes require loadable firmware? | 13:09 |
| ghostmansd[m] | lkcl, I'd make sure nobody reads it loud, looks like some dark incantation from Necronomicon :-) | 13:56 |
| ghostmansd[m] | A really dark incantation I have to admit | 13:56 |
| lkcl | ghostmansd[m], :) | 14:57 |
| lkcl | littlebobeep, DDR RAM init is just something that is required by that DRAM ICs | 14:57 |
| lkcl | and also the physical communication link between them | 14:57 |
| lkcl | the data lines are so fast that you cannot have reflections bouncing back and forth if there is an impedance mis-match | 14:58 |
| lkcl | so you have to "train" the interface (at both ends) | 14:58 |
| lkcl | that *can* be done entirely in hardware, but it's easier to do it in software. | 14:58 |
| lkcl | it is *often* done as a "boxed solution with self-contained proprietary processor and firmware which is secretive" | 14:59 |
| lkcl | because, why would you buy anything other than a "boxed solution"? | 14:59 |
| lkcl | as in, "pay us USD 2 million. we'll give you everything you need. in a box." | 17:23 |
| ghostmansd | lkcl, updated the copyrights | 17:37 |
| ghostmansd | I used an interactive rebase for svp64 to update copyrights, since I want to avoid "one huge commit" strategy | 17:38 |
| ghostmansd | and, upon rebase, I thought that the fact that we use an explicit indexing at Array class in sv_binutils is not good | 17:38 |
| ghostmansd | because, well, whenever any entry is added, we also re-generate the rest of the fields | 17:39 |
| ghostmansd | so I dropped it | 17:39 |
| ghostmansd | cf. the last commit to sv_binutils.py | 17:39 |
| lkcl | ghostmansd, cool | 19:13 |
| ghostmansd[m] | lkcl, do setvl/setvl./fcoss/etc. (that is, all exceptions in svp64.py translate_one) follow some logic? As I see, I have to introduce operands for all of them, but this would force us to move outside of 256 operator indices. | 20:24 |
| ghostmansd[m] | I'll post some URLs soon | 20:24 |
| ghostmansd | Let's consider I'm going to add setvl/setvl. here: https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-opc.c;h=22cb9da3a2861273f74401f2780702e1f64cd4a3;hb=refs/heads/svp64#l11328 | 20:29 |
| ghostmansd | Looking at svp64.py: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=b1954160b493e54911c6451a94db8a5cef65e123;hb=HEAD#l191 | 20:30 |
| ghostmansd | ...we have 6 operands, where each one must have its own entry here: https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-opc.c;h=22cb9da3a2861273f74401f2780702e1f64cd4a3;hb=refs/heads/svp64#l2752 | 20:32 |
| ghostmansd | The thing is, all these operands are accessed by 8-bit index: https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=include/opcode/ppc.h;h=5e2d143d81bb71799f29b5143ee02ab1c71dc1a9;hb=refs/heads/svp64#l65 | 20:33 |
| ghostmansd | So, considering amount of non-standard stuff, I must either: a) extend operand index size to e.g. uint16_t; b) handle these in a special way, unlike binutils does it; c) could, perhaps, re-use some existing entries in a totally counter-intuitive way. | 20:35 |
| lkcl | 256 operator indices, que? oh you mean the operand types? like "RA" is "operand index 5", "DS" is "operand index 30"? | 21:41 |
| lkcl | had to happen some time... | 21:42 |
| lkcl | you also want to look at fields.txt | 21:42 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isatables/fields.text;hb=HEAD#l258 | 21:42 |
| lkcl | (bear in mind those are arse-about-face MSB0 numbering columns) | 21:43 |
| lkcl | yep... that'll need to be an unsigned short. deep joy. i'd recommend running that as a completely separate patch, making damn sure all unit tests work. | 21:45 |
| lkcl | cesar, toshywoshy, octavius, programmerjake, bi-weekly meeting 15m | 21:45 |
| ghostmansd[m] | lkcl, nope, cf. https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=include/opcode/ppc.h;h=5e2d143d81bb71799f29b5143ee02ab1c71dc1a9;hb=refs/heads/svp64#l65 | 21:46 |
| ghostmansd[m] | That array of operands in URL above stores indices to this table: https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-opc.c;h=22cb9da3a2861273f74401f2780702e1f64cd4a3;hb=refs/heads/svp64#l2752 | 21:47 |
| ghostmansd[m] | So yeah, the simplest way is to ensure that we have enough bits to store the index | 21:48 |
| ghostmansd[m] | Ok, this matches my vision | 21:48 |
| lkcl | it's 8 entries long so that shouuuuld be ok | 21:49 |
| lkcl | 259 |0 |6 |11 |16 |23 |24 |25 |26 |31 | | 21:49 |
| lkcl | 260 | PO | RT | RA | SVi |ms |vs |vf | XO |Rc | | 21:49 |
| lkcl | 9?? | 21:50 |
| lkcl | drat | 21:50 |
| lkcl | wait... is the major opcode one of them? (PO - Primary Opcode - EXT01, EXT19 etc)? | 21:50 |
| * lkcl scanning through the list... | 21:51 | |
| lkcl | nope, primary ocode isn't in the list, that i could see | 21:52 |
| lkcl | so that's only 8 (whew) | 21:53 |
| programmerjake | @lkcl: i'll join the meeting in a few min | 22:00 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!