| lkcl | ghostmansd, moornin, i've found another EUR 800 to throw your way, and there's still EUR 2625 on top of that. | 10:47 |
|---|---|---|
| lkcl | sorry about the svstep "wtf" yesterday | 10:47 |
| lkcl | i'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 |
| lkcl | yes, i only added it... last week? | 11:35 |
| ghostmansd[m] | Ah OK | 11:35 |
| lkcl | it 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 well | 11:35 |
| lkcl | sure, yes, good idea | 11:36 |
| ghostmansd[m] | We'll later check blobs generated anyway, so we want them to be on par | 11:36 |
| ghostmansd[m] | Ok, will check this, and add to both pysvp64 and binutils | 11:36 |
| * lkcl just tracking down the bitfields... | 11:39 | |
| lkcl | ok done. SVI-Form added | 12:00 |
| lkcl | if we get another ro | 12:03 |
| lkcl | uund | 12:03 |
| lkcl | if we get another round of binutils patches, the pages are "safe" to submit, now | 12:03 |
| lkcl | https://libre-soc.org/openpower/sv/svstep/ in particular | 12:03 |
| lkcl | https://libre-soc.org/openpower/sv/setvl/ | 12: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 |
| lkcl | niiice | 12:19 |
| lkcl | https://www.google.com/search?q=svremap | 12:19 |
| lkcl | cool, top hit! | 12:19 |
| lkcl | second hit: TDI Remap for the 3.0TDI 'V6' Engine - Surrey Tuning Ltd | 12:20 |
| lkcl | :) | 12:20 |
| lkcl | oh ha ha, fuel remaps for high-performance tuned vehicles | 12:20 |
| lkcl | for the "Volkswagon Golf SV" :) | 12:21 |
| lkcl | urrrr. have to get google to stop f*****g about https://www.google.com/search?q=%22svstep%22&nfpr=1 | 12:29 |
| lkcl | wow, there's actually people named svstep | 12:29 |
| lkcl | octavius, bmask is BM2-Form, am just correcting svp64.py now | 15:06 |
| lkcl | +++ b/src/openpower/decoder/power_enums.py | 15:11 |
| lkcl | @@ -268,6 +268,7 @@ _insns = [ | 15:11 |
| lkcl | "b", "bc", "bcctr", "bclr", "bctar", | 15:11 |
| lkcl | + "bmask", # AV bitmanip | 15:11 |
| octavius | Yeah, 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 |
| octavius | Am I confusing the endian-ness or something? | 15:13 |
| lkcl | no, you'd used BM-Form rather than BM2-Form | 15:13 |
| lkcl | # DRAFT Bitmanip Masked | 15:13 |
| lkcl | BM2-Form | 15:13 |
| lkcl | in av.mdwn | 15:14 |
| lkcl | then used fcoss as the basis for the instruction | 15:14 |
| lkcl | so the number of fields as wrong, the insn |= was wrong, the major opcode was 59 not 22 | 15:14 |
| lkcl | etc. etc. | 15:14 |
| lkcl | and i put the wrong thing in the pseudocode | 15:15 |
| lkcl | i should have put a field named "bm" not "mask" or "mode", errr | 15:15 |
| lkcl | and i got the bit-offsets into mode wrong | 15:16 |
| lkcl | aand i got the variable names ra and a1 wrong, sigh | 15:18 |
| octavius | What 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 |
| lkcl | basically yes | 15:19 |
| lkcl | i 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 |
| lkcl | octavius: "<lkcl> i look at fields.txt" | 15:20 |
| lkcl | there are dozens of Forms, there, and hundreds of sub-uses of those Forms | 15:21 |
| octavius | Do you have to arrange all the bitfields of the new instruction, the play with the ordering until they resemble one the FORMS? | 15:21 |
| lkcl | sometimes yes | 15:21 |
| lkcl | ngggh frickin bits of bm are MSB0-ordered | 15:22 |
| lkcl | ngggggh | 15:23 |
| octavius | Where in the PowerISA spec can I find the different FORMs? | 15:23 |
| lkcl | #1.6.1 I-FORM | 15:23 |
| lkcl | |0 |6 |30|31 | | 15:23 |
| lkcl | | PO | LI |AA|LK | | 15:23 |
| lkcl | from fields.txt | 15:23 |
| octavius | Where do fields.txt come from? XD | 15:24 |
| lkcl | so it's a reasonable bet that it's section 1.6.1 :) | 15:24 |
| lkcl | from the Power ISA spec | 15:24 |
| octavius | Ah thanks | 15:24 |
| octavius | Ah.... | 15:24 |
| octavius | just noticed | 15:24 |
| lkcl | there's a hell of a lot of pieces that tie together | 15:24 |
| octavius | Yeah, starting to see it now | 15:25 |
| lkcl | it would be really useful if you documented this | 15:25 |
| octavius | Just started writing a text file now | 15:26 |
| octavius | any particular page it should go into? | 15:26 |
| lkcl | https://libre-soc.org/docs/ | 15:26 |
| lkcl | pick a page | 15:26 |
| octavius | ok | 15:27 |
| lkcl | waaa this pseudocode is doing my head in | 15:35 |
| ghostmansd | lkcl, I've checked binutils code; adding macros to the insn names themselves needs more work. | 15:36 |
| lkcl | ghostmansd, yyeah | 15:36 |
| ghostmansd | The binutils code is not quite ready for this, they do simply parse the insn name as string. | 15:37 |
| ghostmansd | In fact, they just proceed until they hit a whitespace. | 15:37 |
| lkcl | ah... even after the "/" processing? | 15:37 |
| ghostmansd | So yeah, step-by-step, I think. | 15:37 |
| lkcl | yeah | 15:37 |
| ghostmansd | Well / processing is on our behalf, eh? | 15:37 |
| lkcl | happy to shelve that one for a different patch / time / bugreport / budget | 15:37 |
| ghostmansd | If we need it, we must provide the code which does. | 15:38 |
| ghostmansd | Yes, / they don't consider. It's me who entered the scene after seeing "sv.". :-) | 15:38 |
| ghostmansd | I mean, I check for it plus CPU -mlibresoc flag, and we enter the scene. | 15:38 |
| ghostmansd | Splitting-cutting-trimming and so on. | 15:38 |
| ghostmansd | But no macros there. | 15:39 |
| ghostmansd | This is somewhat logical, to be honest: each sv.add with its own modifiers is kinda a separate instruction, in a way. | 15:39 |
| ghostmansd | I mean, they share the intrinsics... But the way how we encode them, kinda at least make them look like separate insns. :-) | 15:39 |
| ghostmansd | But this is doable, just sharing my findings in code. | 15:40 |
| lkcl | yes basically, they are. | 15:40 |
| lkcl | it's the arguments *to* the modifiers that are actually operands (and should have been done by commas) | 15:41 |
| ghostmansd | Perhaps many time later we might even consider to re-use the operands parser for parsing the modifiers. | 15:41 |
| ghostmansd | But 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 |
| lkcl | :) | 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 |
| lkcl | mmm really? ohh for macro-substitution. yuk | 15: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 |
| lkcl | octavius, hooray, got a first unit test going | 15:51 |
| octavius | Nice! | 15:51 |
| lkcl | it matches with SBF = 0b01010 # set before first | 15:51 |
| tplaten | From https://ds0.me/orconf18.pdf I know | 15:52 |
| tplaten | ● Arcs connect wires together and are configurable or fixed (aka pip) | 15:52 |
| tplaten | ● All arcs and wires are unidirectional – mux topology | 15:52 |
| tplaten | Warning: Failed to find a route for arc 2 of net ddrphy_ddr3_0__a__o_fclk. | 15:52 |
| tplaten | ddrphy_ddr3_0__a__o_fclk. is defined in gram/phy/ecp5ddrphy.py as ClockSignal("dramsync2x") | 15:52 |
| lkcl | octavius, if you can take over and do some more, it'll be a bit laborious | 15:53 |
| lkcl | https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/test_bmask.py;hb=HEAD | 15:53 |
| octavius | Not sure what's happening in that test there lkcl. Also I thought the test cases were in src/openpower/test/bitmanip/av_cases.py? | 15:57 |
| tplaten | I'm now having a look at FPGA-TN-02035-1-3-ECP5-ECP5-5G-HighSpeed-IO-Interface.pdf | 16:16 |
| lkcl | octavius, that's a demo as part of the wiki | 16:24 |
| lkcl | https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/vector_ops.mdwn;h=c510bcc4b5db0f9f27b45d2e20eaa618fc241539;hb=HEAD#l61 | 16:25 |
| lkcl | and you can *also* use bmask.py as a means and method of verifying the av_cases.py | 16:25 |
| lkcl | rather than pissing about trying to calculate the expected responses by hand | 16:26 |
| lkcl | yeh? | 16:26 |
| octavius | (x / ~x) does this mean x divided by bitwise NOT(x)? | 16:26 |
| octavius | Yeah, I'll try to get the av_cases.py, see what happens | 16:27 |
| octavius | Also drafting a guide doc | 16:28 |
| octavius | I asked about the op because I didn't see division in the pseudo-code. Does "/" mean something else? | 16:29 |
| octavius | lkcl, added a first draft page (doesn't link to anywhere yet): https://libre-soc.org/docs/adding_instr/ | 17:29 |
| octavius | bmask might not be the best example (as you're still working out the details), but we can change the instruction example later. | 17:30 |
| octavius | I'll go for a drive/walk while it's nice, so I'll be back | 17:30 |
| lkcl | "x / ~x" was just shorthand for noticing that either x or ~x was utilised in the x86 BMI pseudocode | 17:53 |
| lkcl | have a look here | 17:53 |
| lkcl | https://en.m.wikipedia.org/wiki/X86_Bit_manipulation_instruction_set#TBM_(Trailing_Bit_Manipulation) | 17:53 |
| lkcl | and see what patterns you can spot in the pseudocode | 17:53 |
| ghostmansd | lkcl, 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 |
| ghostmansd | Also, there must be a documentation which can be linked for binutils folks. I'll put https://libre-soc.org/openpower/sv/remap/ as link, that's the best I managed to find. | 19:14 |
| ghostmansd | > SVd - SV REMAP x/y dim | 19:15 |
| ghostmansd | It seems my guess is correct, but, still, please confirm it. | 19:15 |
| lkcl | ghostmansd, let me check it.... | 19:18 |
| ghostmansd | BTW, 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 |
| lkcl | ah that's a fascinating story, dating back to POWER 1 (1993/4) | 19:23 |
| lkcl | so imagine that you are making a really big CPU, in 130nm | 19:23 |
| lkcl | therefore things like shift-and-mask are damned expensive (relatively speaking) | 19:23 |
| lkcl | but, you're designing a powerful CPU, so you want LD/ST to have shift-and-mask | 19:24 |
| lkcl | so "normally" you would have | 19:24 |
| lkcl | a) one shift-and-mask in the LD/ST | 19:24 |
| lkcl | b) another shift-and-mask set of gates in the shifter instructions | 19:24 |
| lkcl | the team at IBM went, "that's dumb, and a waste of gates" | 19:25 |
| lkcl | so they decided to *share* the shift-and-mask logic between the shifter instructions and the LD/ST unit | 19:25 |
| lkcl | now | 19:25 |
| lkcl | here's the clever bit | 19:25 |
| lkcl | what they did was: provided a rudimentary form of micro-coding using the *register names* as "Broadcast Buses" between those units | 19:26 |
| lkcl | so there were five "Broadcast Buses" named | 19:26 |
| lkcl | RA | 19:26 |
| lkcl | RB | 19:26 |
| lkcl | RC | 19:26 |
| lkcl | RT | 19:26 |
| lkcl | RS | 19:26 |
| lkcl | and it was possible for the LD/ST unit to communicate *DIRECTLY* with the Shift-and-Mask unit | 19:26 |
| lkcl | by "broadcasting" the loaded data onto the "RS" bus | 19:27 |
| lkcl | (which the Shift-and-Mask unit would pick up) | 19:27 |
| lkcl | and perform the shift-and-mask work that the LD/ST unit needed | 19:27 |
| lkcl | AND THEN | 19:27 |
| lkcl | only then | 19:27 |
| lkcl | would the shift-and-mask unit ACTUALLY request that the result be stored in the regfile | 19:28 |
| lkcl | *NOT* the LD/ST unit from which the instruction had actually originated | 19:28 |
| lkcl | it's an incredibly simple and ingenious way of saving gates and reducing the internal design to one of RISC | 19:28 |
| ghostmansd | so it basically boils down to on which wires the signals are asserted, right? | 19:30 |
| ghostmansd | interesting, thanks for this historical intro! | 19:31 |
| lkcl | yes | 19:33 |
| lkcl | of course, now, nobody cares, and you have multiple pipelines | 19:33 |
| lkcl | in theory you could do the same thing but it's a bit of a pain. | 19:33 |
| lkcl | ghostmansd, added https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=b58dc6e2e35cf9c2cff80894f766770593482377 | 19:34 |
| ghostmansd | OK, and about size, was it a correct assumption? | 19:35 |
| lkcl | 5 bits | 19:35 |
| lkcl | # 1.6.28 SVI-FORM | 19: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 |
| lkcl | 16..20 | 19:36 |
| lkcl | so yes | 19:36 |
| lkcl | and yes it's one of those "off-by-one"ers | 19:36 |
| ghostmansd | yeah sorry meant not size | 19:36 |
| ghostmansd | but range | 19:36 |
| ghostmansd | darn | 19:36 |
| ghostmansd | OK thanks! | 19:37 |
| lkcl | 1..32 not 0..31 | 19:37 |
| * lkcl must document that | 19:37 | |
| lkcl | https://libre-soc.org/openpower/sv/remap/#svindex | 19:37 |
| lkcl | https://libre-soc.org/openpower/sv/remap/#svshape | 19:37 |
| lkcl | https://libre-soc.org/openpower/sv/remap/#svremap | 19:37 |
| lkcl | if you use those links they'll be happier | 19:37 |
| ghostmansd | Cool. Cool cool cool. | 19:39 |
| ghostmansd | Also, it seems there's yet another set of instructions which we lack: maxs/maxu. | 19:41 |
| ghostmansd | It seems I'm always one step behind. :-) | 19:41 |
| ghostmansd | Added 5 days ago. | 19:41 |
| ghostmansd | Please ping me in such cases, because I might easily miss these. | 19:42 |
| ghostmansd | Aaaargh, even moar | 19:43 |
| ghostmansd | 5f982fc b3acc3f 6cb0a83 a3a2fb9 5a0f17c fe39611 | 19:44 |
| ghostmansd | hell it's almost everything up to d2a1a73 | 19:45 |
| ghostmansd | Unless these are extremely experimental, please, ping me, otherwise these will be lost in binutils. | 19:45 |
| lkcl | they're extremely experimental | 19:45 |
| ghostmansd | OK then :-) | 19:45 |
| ghostmansd | (we might have experimented on binutils...) :-D | 19:46 |
| lkcl | things are moving rapidly at the moment because we've only got around 12 weeks | 19:50 |
| ghostmansd | For everything, including binutils? | 19:54 |
| lkcl | nggh yes | 19:55 |
| lkcl | except the cavatools (simulator) | 19:55 |
| lkcl | crypto-primitives | 19:55 |
| lkcl | and the new coriolis2 work | 19:55 |
| ghostmansd | Then we must find a way to speed up the FSF copyrights. | 19:56 |
| ghostmansd | Or would it be sufficient if we have it on our fork? | 19:56 |
| lkcl | ah no, that's not necessary, although it's good | 19:56 |
| lkcl | yes | 19:56 |
| ghostmansd | OK, cool | 19:56 |
| lkcl | *we* declare what the definition of "100% completed" is | 19:56 |
| ghostmansd | lkcl, what's XO field in svindex? | 20:07 |
| ghostmansd | > XO - standard 6-bit XO field | 20:09 |
| ghostmansd | that's all information I have for now, not particularly helpful ;-) | 20:09 |
| ghostmansd | It seems we must add minor_22.csv entry | 20:14 |
| ghostmansd | It 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 |
| ghostmansd | OK I'll let this to you lkcl, and will jist take some random crap for binutils (e.g. all 1s) for now | 20:19 |
| ghostmansd | Ping me when you update minor_22.csv so that I tune pysvp64asm and binutils | 20:19 |
| ghostmansd | Also, 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 |
| ghostmansd | OK that's how it looks like: {"svindex", SVI(22,63), SVI_MASK, SVP64, PPCVLE, {RS, SVImask, SVd, ew, yx, mm, sk}}, | 20:34 |
| ghostmansd | If we consider that XO is 0b111111 | 20:35 |
| ghostmansd | I'll proceed to operands tomorrow, enough for today | 20:36 |
| ghostmansd | lkcl please think about new opcode and minor_22.csv, and ping me | 20:36 |
| ghostmansd | gn | 20:36 |
| octavius | lkcl looked at the wiki page, BLSI is cool :D Slowly starting to make sense all this (especially with intel's reference manual) | 21:42 |
| octavius | Ok, I get why bmask is so complex (lot's of options) | 21:47 |
| lkcl | octavius, yyep. 24 different instructions, covered by just one | 21:50 |
| lkcl | ghostmansd[m], 1 sec, XO field iiis... | 21:50 |
| lkcl | 0.56.1011.1516.2021..2526....3031nameForm | 21:51 |
| lkcl | NN1 01 001svindexSVI-Form | 21:51 |
| lkcl | hm that came out badly :) | 21:51 |
| octavius | Are 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 |
| lkcl | octavius, i've done the one so that "stuff works" | 21:52 |
| lkcl | if you can do some more that would be good | 21:52 |
| octavius | ok | 21: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 |
| lkcl | so XO is, starting from bit 26 | 21:53 |
| lkcl | 101001 | 21:53 |
| lkcl | ghostmansd[m], basically it matches with svshape and svremap which are | 21:53 |
| lkcl | | NN | | | | | 0 11 00 |1 | svshape | SVM-Form | | 21:53 |
| lkcl | | NN | | | | | 1 11 00 |1 | svremap | SVRM-Form | | 21:53 |
| lkcl | i hear ya on "mask" | 21:54 |
| lkcl | done https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=de4bbb93189a8980c5e47501a28a8fa62a4231b6 | 22:00 |
| octavius | lkcl just made another test case for bmask, but as I was about to run it, noticed the generated python function in av.py is bad | 23:07 |
| octavius | it generates these statements "if eq(_RB, 0)" | 23:07 |
| octavius | I 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 |
| octavius | Also in your pseudo-code you're skipping bit 0 of "mode" (starting with mode[1]) | 23:41 |
| octavius | I'll be off, will work for a few hours tomorrow | 23:43 |
| octavius | gn | 23:43 |
| programmerjake | octavius: 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 argument | 23:45 |
| programmerjake | guess you'll see that tomorrow | 23:45 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!