Wednesday, 2022-05-04

*** mannerism <mannerism!~tic@> has left #libre-soc02:11
lkclprogrammerjake, nicely done on cldivrem. pity about the other algorithm09:59
programmerjakereading 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
programmerjakeoh, well10:47
lkcldoh :)10:48
lkclghostmansd, 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 autogenerated11:39
lkclthe hassle that saves would be immense.11:39
lkcland, 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
ghostmansdlkcl, gotcha12:15
ghostmansdwill drop the comments12:16
ghostmansdfor now I'll keep disclaimer as "/* part of Libre-SOC, sponsored by NLnet */"; this, however, must be updated before submission to FSF12:21
ghostmansdPerhaps something like this?
lkclyeah that'd work really well12:39
lkclthere'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 95707312:40
littlebobeeplkcl: 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 admit13:56
lkclghostmansd[m], :)14:57
lkcllittlebobeep, DDR RAM init is just something that is required by that DRAM ICs14:57
lkcland also the physical communication link between them14:57
lkclthe data lines are so fast that you cannot have reflections bouncing back and forth if there is an impedance mis-match14:58
lkclso you have to "train" the interface (at both ends)14:58
lkclthat *can* be done entirely in hardware, but it's easier to do it in software.14:58
lkclit is *often* done as a "boxed solution with self-contained proprietary processor and firmware which is secretive"14:59
lkclbecause, why would you buy anything other than a "boxed solution"?14:59
lkclas in, "pay us USD 2 million. we'll give you everything you need. in a box."17:23
ghostmansdlkcl, updated the copyrights17:37
ghostmansdI used an interactive rebase for svp64 to update copyrights, since I want to avoid "one huge commit" strategy17:38
ghostmansdand, upon rebase, I thought that the fact that we use an explicit indexing at Array class in sv_binutils is not good17:38
ghostmansdbecause, well, whenever any entry is added, we also re-generate the rest of the fields17:39
ghostmansdso I dropped it17:39
ghostmansdcf. the last commit to sv_binutils.py17:39
lkclghostmansd, cool19:13
ghostmansd[m]lkcl, do setvl/setvl./fcoss/etc. (that is, all exceptions in 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 soon20:24
ghostmansdLet's consider I'm going to add setvl/setvl. here:;a=blob;f=opcodes/ppc-opc.c;h=22cb9da3a2861273f74401f2780702e1f64cd4a3;hb=refs/heads/svp64#l1132820:29
ghostmansdLooking at;a=blob;f=src/openpower/sv/trans/;h=b1954160b493e54911c6451a94db8a5cef65e123;hb=HEAD#l19120:30
ghostmansd...we have 6 operands, where each one must have its own entry here:;a=blob;f=opcodes/ppc-opc.c;h=22cb9da3a2861273f74401f2780702e1f64cd4a3;hb=refs/heads/svp64#l275220:32
ghostmansdThe thing is, all these operands are accessed by 8-bit index:;a=blob;f=include/opcode/ppc.h;h=5e2d143d81bb71799f29b5143ee02ab1c71dc1a9;hb=refs/heads/svp64#l6520:33
ghostmansdSo, 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
lkcl256 operator indices, que? oh you mean the operand types? like "RA" is "operand index 5", "DS" is "operand index 30"?21:41
lkclhad to happen some time...21:42
lkclyou also want to look at fields.txt21:42
lkcl(bear in mind those are arse-about-face MSB0 numbering columns)21:43
lkclyep... 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
lkclcesar, toshywoshy, octavius, programmerjake, bi-weekly meeting 15m21:45
ghostmansd[m]lkcl, nope, cf.;a=blob;f=include/opcode/ppc.h;h=5e2d143d81bb71799f29b5143ee02ab1c71dc1a9;hb=refs/heads/svp64#l6521:46
ghostmansd[m]That array of operands in URL above stores indices to this table:;a=blob;f=opcodes/ppc-opc.c;h=22cb9da3a2861273f74401f2780702e1f64cd4a3;hb=refs/heads/svp64#l275221:47
ghostmansd[m]So yeah, the simplest way is to ensure that we have enough bits to store the index21:48
ghostmansd[m]Ok, this matches my vision21:48
lkclit's 8 entries long so that shouuuuld be ok21: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
lkclwait... is the major opcode one of them? (PO - Primary Opcode - EXT01, EXT19 etc)?21:50
* lkcl scanning through the list...21:51
lkclnope, primary ocode isn't in the list, that i could see21:52
lkclso that's only 8 (whew)21:53
programmerjake@lkcl: i'll join the meeting in a few min22:00

Generated by 2.17.1 by Marius Gedminas - find it at!