Friday, 2022-06-24

lkclghostmansd, moornin, i've found another EUR 800 to throw your way, and there's still EUR 2625 on top of that.10:47
lkclsorry about the svstep "wtf" yesterday10:47
lkcli've updated the page so i don't forget (again)10:48
ghostmansd[m]lkcl, so, judging from 867, we have an instruction not in pysvp64asm, but really existing, right?11:35
lkclyes, i only added it... last week?11:35
ghostmansd[m]Ah OK11:35
lkclit solves the insanity of GPR[RT] = GPR[GPR[RA]]11:35
ghostmansd[m]Well I suggest that I add it to pysvp64asm in scope of the task as well11:35
lkclsure, yes, good idea11:36
ghostmansd[m]We'll later check blobs generated anyway, so we want them to be on par11:36
ghostmansd[m]Ok, will check this, and add to both pysvp64 and binutils11:36
* lkcl just tracking down the bitfields...11:39
lkclok done. SVI-Form added12:00
lkclif we get another ro12:03
lkclif we get another round of binutils patches, the pages are "safe" to submit, now12:03
lkcl in particular12:03
ghostmansd[m]I'll wait for two-three days before anyone comes up with moar suggestions. But even if not, I'll refresh links in the description.12:08
ghostmansd[m]FWIW, if I google "svstep", libresoc is the fourth page. Not bad.12:09
lkclcool, top hit!12:19
lkclsecond hit: TDI Remap for the 3.0TDI 'V6' Engine - Surrey Tuning Ltd12:20
lkcloh ha ha, fuel remaps for high-performance tuned vehicles12:20
lkclfor the "Volkswagon Golf SV" :)12:21
lkclurrrr. have to get google to stop f*****g about
lkclwow, there's actually people named svstep12:29
lkcloctavius, bmask is BM2-Form, am just correcting now15:06
lkcl+++ b/src/openpower/decoder/power_enums.py15:11
lkcl@@ -268,6 +268,7 @@ _insns = [15:11
lkcl     "b", "bc", "bcctr", "bclr", "bctar",15:11
lkcl+    "bmask",                                  # AV bitmanip15:11
octaviusYeah, I'm still confused how the numbers in the brackets relate to the bitfields (e.g. fields[0] << (31-10)  # RT, bits 6-10)15:12
octaviusAm I confusing the endian-ness or something?15:13
lkclno, you'd used BM-Form rather than BM2-Form15:13
lkcl# DRAFT Bitmanip Masked15:13
lkclin av.mdwn15:14
lkclthen used fcoss as the basis for the instruction15:14
lkclso the number of fields as wrong, the insn |= was wrong, the major opcode was 59 not 2215:14
lkcletc. etc.15:14
lkcland i put the wrong thing in the pseudocode15:15
lkcli should have put a field named "bm" not "mask" or "mode", errr15:15
lkcland i got the bit-offsets into mode wrong15:16
lkclaand i got the variable names ra and a1 wrong, sigh15:18
octaviusWhat do you use to come up with such information? Are you essentially choosing the best opcode form yourself (since this is a new instruction), and have enough experience to choose the appropriate bitfields??15:19
lkclbasically yes15:19
lkcli look at fields.txt and go "err there's nothing remotely closely matching, so, err drat a new Form has to be added"15:19
octavius"err there's nothing remotely closely matching", matching to what?15:20
lkcloctavius: "<lkcl> i look at fields.txt"15:20
lkclthere are dozens of Forms, there, and hundreds of sub-uses of those Forms15:21
octaviusDo you have to arrange all the bitfields of the new instruction, the play with the ordering until they resemble one the FORMS?15:21
lkclsometimes yes15:21
lkclngggh frickin bits of bm are MSB0-ordered15:22
octaviusWhere in the PowerISA spec can I find the different FORMs?15:23
lkcl#1.6.1 I-FORM15:23
lkcl   |0     |6         |30|31 |15:23
lkcl   | PO   |      LI  |AA|LK |15:23
lkclfrom fields.txt15:23
octaviusWhere do fields.txt come from? XD15:24
lkclso it's a reasonable bet that it's section 1.6.1 :)15:24
lkclfrom the Power ISA spec15:24
octaviusAh thanks15:24
octaviusjust noticed15:24
lkclthere's a hell of a lot of pieces that tie together15:24
octaviusYeah, starting to see it now15:25
lkclit would be really useful if you documented this15:25
octaviusJust started writing a text file now15:26
octaviusany particular page it should go into?15:26
lkclpick a page15:26
lkclwaaa this pseudocode is doing my head in15:35
ghostmansdlkcl, I've checked binutils code; adding macros to the insn names themselves needs more work.15:36
lkclghostmansd, yyeah15:36
ghostmansdThe binutils code is not quite ready for this, they do simply parse the insn name as string.15:37
ghostmansdIn fact, they just proceed until they hit a whitespace.15:37
lkclah... even after the "/" processing?15:37
ghostmansdSo yeah, step-by-step, I think.15:37
ghostmansdWell / processing is on our behalf, eh?15:37
lkclhappy to shelve that one for a different patch / time / bugreport / budget15:37
ghostmansdIf we need it, we must provide the code which does.15:38
ghostmansdYes, / they don't consider. It's me who entered the scene after seeing "sv.". :-)15:38
ghostmansdI mean, I check for it plus CPU -mlibresoc flag, and we enter the scene.15:38
ghostmansdSplitting-cutting-trimming and so on.15:38
ghostmansdBut no macros there.15:39
ghostmansdThis is somewhat logical, to be honest: each sv.add with its own modifiers is kinda a separate instruction, in a way.15:39
ghostmansdI mean, they share the intrinsics... But the way how we encode them, kinda at least make them look like separate insns. :-)15:39
ghostmansdBut this is doable, just sharing my findings in code.15:40
lkclyes basically, they are.15:40
lkclit's the arguments *to* the modifiers that are actually operands (and should have been done by commas)15:41
ghostmansdPerhaps many time later we might even consider to re-use the operands parser for parsing the modifiers.15:41
ghostmansdBut not now, this is a huge work which is basically not needed at this stage (technically good and sweet, but not really useful at this stage).15:41
ghostmansd...unless they kick our asses in the mailing list though.15:42
ghostmansd[m]So I think in scope of 849 it's better we concentrate on operands parsing.15:43
ghostmansd[m]I'm slowly approaching towards reusing binutils stuff there, that needed some code refactoring, though.15:44
ghostmansd[m]But at least I'm already at the point where the main assembly routine which parses the operands and does the tricks indeed receives `struct svp64_ctx`.15:45
ghostmansd[m]With all the data we obtained (well, mainly modifiers).15:45
ghostmansd[m]The next step is teaching this routine to deal with the SVP64 context.15:46
ghostmansd[m]...e.g. letting it know "hey, for God's sake, I know this is RA operand, but in our world there might be more than 32 of these"15:47
ghostmansd[m]...and the actual remapping, actually.15:47
lkclmmm really? ohh for macro-substitution. yuk15:47
ghostmansd[m]In fact it went that far that I do it in another branch. And have two copies of binutils.15:47
ghostmansd[m]But at least I see that it makes it simpler to turn it into the prefix.15:48
ghostmansd[m]Not this magic insn we have.15:48
ghostmansd[m]So yeah, slowly and with pain, but at least I see the profit and even see how it might look in the end.15:49
ghostmansd[m]Ok, the main idea is, operands parsing and refactoring in scope of 849. And macros for modifiers are separate task.15:50
lkcloctavius, hooray, got a first unit test going15:51
lkclit matches with SBF = 0b01010 # set before first15:51
tplatenFrom I know15:52
tplaten● Arcs connect wires together and are configurable or fixed (aka pip)15:52
tplaten● All arcs and wires are unidirectional – mux topology15:52
tplatenWarning: Failed to find a route for arc 2 of net ddrphy_ddr3_0__a__o_fclk.15:52
tplatenddrphy_ddr3_0__a__o_fclk. is defined in gram/phy/ as ClockSignal("dramsync2x")15:52
lkcloctavius, if you can take over and do some more, it'll be a bit laborious15:53
octaviusNot sure what's happening in that test there lkcl. Also I thought the test cases were in src/openpower/test/bitmanip/
tplatenI'm now having a look at FPGA-TN-02035-1-3-ECP5-ECP5-5G-HighSpeed-IO-Interface.pdf16:16
lkcloctavius, that's a demo as part of the wiki16:24
lkcland you can *also* use as a means and method of verifying the av_cases.py16:25
lkclrather than pissing about trying to calculate the expected responses by hand16:26
octavius(x / ~x) does this mean x divided by bitwise NOT(x)?16:26
octaviusYeah, I'll try to get the, see what happens16:27
octaviusAlso drafting a guide doc16:28
octaviusI asked about the op because I didn't see division in the pseudo-code. Does "/" mean something else?16:29
octaviuslkcl, added a first draft page (doesn't link to anywhere yet):
octaviusbmask might not be the best example (as you're still working out the details), but we can change the instruction example later.17:30
octaviusI'll go for a drive/walk while it's nice, so I'll be back17:30
lkcl"x / ~x" was just shorthand for noticing that either x or ~x was utilised in the x86 BMI pseudocode17:53
lkclhave a look here17:53
lkcland see what patterns you can spot in the pseudocode17:53
ghostmansdlkcl, it seems SVd field for SVI form is not documented... I assume it follows the same logic as SVxd/SVyd/SVzd (that is, 5-bit and range is 1..n). Is it correct?19:12
ghostmansdAlso, there must be a documentation which can be linked for binutils folks. I'll put as link, that's the best I managed to find.19:14
ghostmansd> SVd - SV REMAP x/y dim19:15
ghostmansdIt seems my guess is correct, but, still, please confirm it.19:15
lkclghostmansd, let me check it....19:18
ghostmansdBTW, I've always forgotten to ask, but now I recall. What is the difference between RS and RT? They occupy the same bits, they're even identical in binutils (to the point #define RT RS). So, what's the deal here?19:22
lkclah that's a fascinating story, dating back to POWER 1 (1993/4)19:23
lkclso imagine that you are making a really big CPU, in 130nm19:23
lkcltherefore things like shift-and-mask are damned expensive (relatively speaking)19:23
lkclbut, you're designing a powerful CPU, so you want LD/ST to have shift-and-mask19:24
lkclso "normally" you would have19:24
lkcla) one shift-and-mask in the LD/ST19:24
lkclb) another shift-and-mask set of gates in the shifter instructions19:24
lkclthe team at IBM went, "that's dumb, and a waste of gates"19:25
lkclso they decided to *share* the shift-and-mask logic between the shifter instructions and the LD/ST unit19:25
lkclhere's the clever bit19:25
lkclwhat they did was: provided a rudimentary form of micro-coding using the *register names* as "Broadcast Buses" between those units19:26
lkclso there were five "Broadcast Buses" named19:26
lkcland it was possible for the LD/ST unit to communicate *DIRECTLY* with the Shift-and-Mask unit19:26
lkclby "broadcasting" the loaded data onto the "RS" bus19:27
lkcl(which the Shift-and-Mask unit would pick up)19:27
lkcland perform the shift-and-mask work that the LD/ST unit needed19:27
lkclAND THEN19:27
lkclonly then19:27
lkclwould the shift-and-mask unit ACTUALLY request that the result be stored in the regfile19:28
lkcl*NOT* the LD/ST unit from which the instruction had actually originated19:28
lkclit's an incredibly simple and ingenious way of saving gates and reducing the internal design to one of RISC19:28
ghostmansdso it basically boils down to on which wires the signals are asserted, right?19:30
ghostmansdinteresting, thanks for this historical intro!19:31
lkclof course, now, nobody cares, and you have multiple pipelines19:33
lkclin theory you could do the same thing but it's a bit of a pain.19:33
lkclghostmansd, added;a=commitdiff;h=b58dc6e2e35cf9c2cff80894f76677059348237719:34
ghostmansdOK, and about size, was it a correct assumption?19:35
lkcl5 bits19:35
lkcl# 1.6.28 SVI-FORM19:35
lkcl   |0     |6    |11    |16   |21 |23|24|25|26    31|19:35
lkcl   | PO   |  RS |mask  | SVd |ew |yx|mm|sk|   XO   |19:35
lkclso yes19:36
lkcland yes it's one of those "off-by-one"ers19:36
ghostmansdyeah sorry meant not size19:36
ghostmansdbut range19:36
ghostmansdOK thanks!19:37
lkcl1..32 not 0..3119:37
* lkcl must document that19:37
lkclif you use those links they'll be happier19:37
ghostmansdCool. Cool cool cool.19:39
ghostmansdAlso, it seems there's yet another set of instructions which we lack: maxs/maxu.19:41
ghostmansdIt seems I'm always one step behind. :-)19:41
ghostmansdAdded 5 days ago.19:41
ghostmansdPlease ping me in such cases, because I might easily miss these.19:42
ghostmansdAaaargh, even moar19:43
ghostmansd5f982fc b3acc3f 6cb0a83 a3a2fb9 5a0f17c fe3961119:44
ghostmansdhell it's almost everything up to d2a1a7319:45
ghostmansdUnless these are extremely experimental, please, ping me, otherwise these will be lost in binutils.19:45
lkclthey're extremely experimental19:45
ghostmansdOK then :-)19:45
ghostmansd(we might have experimented on binutils...) :-D19:46
lkclthings are moving rapidly at the moment because we've only got around 12 weeks19:50
ghostmansdFor everything, including binutils?19:54
lkclnggh yes19:55
lkclexcept the cavatools (simulator)19:55
lkcland the new coriolis2 work19:55
ghostmansdThen we must find a way to speed up the FSF copyrights.19:56
ghostmansdOr would it be sufficient if we have it on our fork?19:56
lkclah no, that's not necessary, although it's good19:56
ghostmansdOK, cool19:56
lkcl*we* declare what the definition of "100% completed" is19:56
ghostmansdlkcl, what's XO field in svindex?20:07
ghostmansd> XO - standard 6-bit XO field20:09
ghostmansdthat's all information I have for now, not particularly helpful ;-)20:09
ghostmansdIt seems we must add minor_22.csv entry20:14
ghostmansdIt seems we can't have either 1110- or 0110-, these are for bitmanip...20:17
ghostmansd-10001 appears to be occupied by cprop since recent...20:18
ghostmansdOK I'll let this to you lkcl, and will jist take some random crap for binutils (e.g. all 1s) for now20:19
ghostmansdPing me when you update minor_22.csv so that I tune pysvp64asm and binutils20:19
ghostmansdAlso, calling operator "mask" is quite a bad wording from binutils PoV. I'll call this operand SVImask for now, but it'd be great if we have a different name (following the spirit of all other field names).20:27
ghostmansdOK that's how it looks like: {"svindex",    SVI(22,63),    SVI_MASK,    SVP64,    PPCVLE,    {RS, SVImask, SVd, ew, yx, mm, sk}},20:34
ghostmansdIf we consider that XO is 0b11111120:35
ghostmansdI'll proceed to operands tomorrow, enough for today20:36
ghostmansdlkcl please think about new opcode and minor_22.csv, and ping me20:36
octaviuslkcl looked at the wiki page, BLSI is cool :D Slowly starting to make sense all this (especially with intel's reference manual)21:42
octaviusOk, I get why bmask is so complex (lot's of options)21:47
lkcloctavius, yyep. 24 different instructions, covered by just one21:50
lkclghostmansd[m], 1 sec, XO field iiis...21:50
lkclNN1 01 001svindexSVI-Form21:51
lkclhm that came out badly :)21:51
octaviusAre planning to do any test cases? If you don't I'd be happy to play with them, try to cover the 24 (we have 32 reg's to play with :D)21:51
lkcloctavius, i've done the one so that "stuff works"21:52
lkclif you can do some more that would be good21:52
lkcl| 0.5|6.10|11.15|16.20 |21..25   | 26....30  |31| name     | Form    |21:52
lkcl| NN |    |     |      |         | 1  01  00 |1 | svindex    | SVI-Form    |21:52
lkclso XO is, starting from bit 2621:53
lkclghostmansd[m], basically it matches with svshape and svremap which are21:53
lkcl| NN |    |     |      |         | 0  11  00 |1 | svshape    | SVM-Form    |21:53
lkcl| NN |    |     |      |         | 1  11  00 |1 | svremap   | SVRM-Form   |21:53
lkcli hear ya on "mask"21:54
octaviuslkcl just made another test case for bmask, but as I was about to run it, noticed the generated python function in is bad23:07
octaviusit generates these statements "if eq(_RB, 0)"23:07
octaviusI fixed that in my auto-generated python functions to try to run the test, but now noticed "mode" is not defined. It's part of the opcode, but does it need to be one of the input arguments?23:35
octaviusAlso in your pseudo-code you're skipping bit 0 of "mode" (starting with mode[1])23:41
octaviusI'll be off, will work for a few hours tomorrow23:43
programmerjakeoctavius: the instruction's fields are injected into the function's scope when it's ran, so, no, mode shouldn't need to be a function argument23:45
programmerjakeguess you'll see that tomorrow23:45

Generated by 2.17.1 by Marius Gedminas - find it at!