Saturday, 2022-09-17

ghostmansd[m]Well it cheats a lot00:04
ghostmansd[m]Ideally we should have some special cases, like non-zero operands00:05
ghostmansd[m]As for 5-bit or 3-bit... it's simple, the operands are span-aware00:05
ghostmansd[m]But yeah I also thought about it00:06
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC03:51
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc03:58
*** lxo <lxo!> has quit IRC07:22
*** lxo <lxo!> has joined #libre-soc07:49
*** octavius <octavius!> has joined #libre-soc08:00
*** lxo <lxo!> has quit IRC08:40
*** octavius <octavius!> has quit IRC08:44
*** ghostmansd <ghostmansd!> has joined #libre-soc09:20
*** octavius <octavius!> has joined #libre-soc09:59
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC10:00
*** octavius <octavius!> has quit IRC10:17
*** midnight <midnight!~midnight@user/midnight> has quit IRC10:32
*** midnight <midnight!~midnight@user/midnight> has joined #libre-soc10:35
markosis the python simulator up to the task of emulating a full binary, ie not just a small routine? ie, say I have a linux executable and I replace one function with an svp64 one -compiled with binutils12:58
markosI don't care if it takes a few hours to run13:02
markosit's a testcase basically and I want to test the function13:12
openpowerbot[mattermost] <lkcl> yes it is - just with no I/O.13:26
openpowerbot[mattermost] <lkcl> although in theory if you added call-out support for "sc" (syscalls) that should really be possible.13:27
openpowerbot[mattermost] <lkcl>
openpowerbot[mattermost] <lkcl> we have to put that into the cavatools-ppc64le port anyway13:28
openpowerbot[mattermost] <lkcl> but otherwise, you would be really surprised - perhaps not - to learn that the difference between a function and a binary is: absolutely nothing.13:29
openpowerbot[mattermost] <lkcl> look again more closely at the mp3 tests and how they are run.13:30
openpowerbot[mattermost] <lkcl> you can test *any* function by setting up the input parameters and memory as desired.13:31
openpowerbot[mattermost] <lkcl> should we add ELF-loading support and at least the "sc"s for stdin, stdout, and stderr? mmm... probably :)13:33
openpowerbot[mattermost] <lkcl> i think if we added the read() systemcall it would at least allow "helloworld".
ghostmansd[m]What'd be the right name for stuff like /vec2, /vec3, /dm=1<< r3, and so on? Qualifiers? Specifiers? Something else?14:10
markoslkcl, that's fine, it's a self-contained testsuite, all the reference data is constructed in-program anyway, ok cool, I'll give it a shot14:35
markosah, no it won't work14:35
markosjust what I meant by running a program, ELF-loading and stdin/stdout/stderr should work14:37
markosI could call the simulator from inside the program14:37
markosusing a wrapper function that takes the input, passes it to the simulator, and puts the results back to the expected output14:39
markosthat would probably be easier to do14:39
markoscould I call the simulator from C++ directly? or would I have to dump the data to files, and call the simulator as a program? that should definitely work but would be much slower14:48
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC15:00
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc15:01
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC15:16
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc15:18
lkclyou'll need to do the trick of extracting the binary out of the .o, manually, yourself15:43
lkclcode has not been added to comprehend and automatically extract ELF... yet15:44
lkclthere are almost certainly ways to call pure-python programs from any other programming language15:44
lkclevery one of them will involve linking to /usr/lib/pythonNN.lib15:45
lkcland doing the job *of* /usr/bin/pythonN.N-the-executable15:45
lkclit's all doable15:46
markosyes, found that, I would have to create a wrapper, the tricky part would be the conversion of arguments/results15:46
lkclhonestly it may be easier to put in support for elf-loading and the bare minimum support for system calls read/write15:47
lkclthen just use exec()/pipe()15:47
markosI'd think that to be much much more difficult15:47
lkclpfffh naah15:47
markosbut then again I don't know the internals of the simulator15:47
lkclit's a task that is easily put on the TODO list for the cavatools-ppc64 port15:48
lkclpython-based elf-reading already exists15:48
lkcli would expect it to be a handful of lines involved.  maybe... 70.  absolute max 100.15:49
lkclooo, scaary. that looks hard :)15:50
lkcland sc is basically "if address == 0xC00 do_something_with_it()"15:52
lkclso that involves a bit-of-a-hack-job in the Simulator (i'm happy to help guide you through it)15:54
lkcl"if self.PC == 0xC00 and self.userspace_executable_mode is True then self.do_something_weird_with_systemcalls()"15:55
lkclwhere the very last thing would be to enact the exact same thing that's in "rfid" - return from interrupt.15:56
markosnot sure, I think I'd prefer simulating only the function involved rather than the whole program, so performance penalty would be minimized15:58
lkcltracing this through - with the sc pseudocode trying to set MSR to "new_value see table in p1063" that's probably not a bad strategy :)15:59
markosjust to make it clear why I need this, testing svp64 code like this would be much easier and development would be faster as it would allow me to directly test the function within actual code16:01
markosmuch easier than dumping the output of a buffer16:02
ghostmansdfuck I could not even suggest that SelectableInt compares _signed_ numbers16:02
ghostmansdand tricks such as `if (subvl > 0): ...` won't work16:03
lkclghostmansd, that's why the slt helpers exist16:03
ghostmansdbecause, well, guess what? subvl is 2-bit, and can end up being negative16:03
ghostmansdwhat is slt?16:04
lkcl1 sec16:04
lkclahh unsigned16:04
lkclltu and gtu16:04
lkclfrom openpower.decoder.selectable_int import selectltu as ltu16:04
lkclfrom openpower.decoder.selectable_int import selectgtu as gtu16:04
ghostmansdah, this16:04
ghostmansdit's a pity, because I passed and operator.eq16:05
ghostmansdstill int(si0) < int(si1) works16:05
lkclif you look in v3.0 section 1.3.4 you will ese "signed comparison relations"16:05
lkcland unsigned comparison relations "<u" and ">u"16:05
ghostmansdyeah fair enough16:06
ghostmansdit's just me that I think about collections of bits in unsigned way16:06
lkclthis one caused much head-banging for a few months due to the pseudo-code *not* having the correct signed/unsigned operators in some places16:06
ghostmansdby the way, why don't we apply functools.total_ordering to simply generate the rest of the operators?16:07
ghostmansdwith it, __lt__ and __eq__ are the only ones which need to be defined16:08
ghostmansdit's slow, I know, but it saves some typing and allows to avoid errors16:09
lkclnever knew about it.  work's done now.16:12
lkclghostmansd, ooooOoo, posh RM-decoding, oooo :)16:21
ghostmansdlkcl, you could've simply told me you're fine with that change, I already had the patch :-)16:23
* lkcl hand-waving...16:26
lkcli'm up to my neck in SVP64 prefix design16:26
lkclhave been for several days16:26
markosanother question, can the simulator take compiled/binary code or does it have to be assembly?16:30
lkclit *only* takes native binaries16:35
lkclnative (raw)16:35
markosperfect, so stuff that is compiled by ghostmansd's binutils assembler16:35
lkclcorrect.  again: see the scripts behind the media examples.16:36
lkcli think i also added a README or at least a page somewhere on it16:36
lkcloctavius helped16:36
lkcl1 sec16:36
lkclyeah there you go16:36
markosah, I was confusing it with the pysvp64asm tool16:36
markosok, that's what I need16:37
markosI will give a shot to the pypowersim running under a C++ wrapper for the ported function16:37
lkclbe fascinated to hear how that works out - and please do put it into the openpower-isa/media repo16:38
ghostmansdmarkos, if you need raw binaries, w/o elf, use objcopy16:38
ghostmansdobjcopy -Obinary elf.o raw.o16:38
lkclas long as it's not ridiculously massive of course!16:39
markosghostmansd, cool thanks for the tip16:39
ghostmansdI'm not sure if there's an option in assembler to do it by default16:39
markosonly thing that worries me is the arguments/results conversion16:39
lkclmarkos, all documented. part of ppc64le ABI16:39
ghostmansdalso, be aware that last time I checked EXTRA2 handling was incorrect16:39
markoscalling python from C/C++ is tricky but it's easy16:40
ghostmansdif you find something broken, I sometimes convert the code via pysvp64asm and compile it with as16:40
ghostmansdeven vanilla PPC asm goes16:40
markosif that works it would help porting code to SVP64 much easier16:40
ghostmansdI'm planning to fix EXTRA2 and also refactor the code once I'm done with Python disassembler16:41
markosI have selectively pulled a bunch of functions from vp9 including their testcases16:41
markosand added svp64 versions of the functions16:41
markoswhich ofc for now are plain C16:41
lkclmarkos, try to keep the arguments to function calls to integer and pointers-to-memory.16:41
markosbut I want to incrementally port them to svp64 assembly16:42
markosmost of those are like this16:42
lkcloh - if you need binary data *please under no circumstances* commit it to the openpower-isa repo16:42
markosI'm not doing floats for the moment16:42
markosno binary data needed at all16:42
lkcldrop a tarball at me and i'll upload it to ftp.libre-soc.org16:42
markosand edited the files so that I don't have to pull all of vp9 include files16:43
markoskept it to a very few needed ones16:43
markosand possibly can be stripped down more16:43
markosonly problem is dependency of googletest library as I didn't want to rework all the test suite as well16:44
markosit's packaged in debian16:45
lkclput it in the README as a... ahhh no problem16:45
markosso not a big problem really16:45
markosif calling the simulator from c++ works then we're set, I'll try a very small program to see it works16:46
lkclgoogletest-tools - Google's C++ test framework sources16:46
markosit's actually the headers, libgtest-dev that I need16:46
lkcldone, added to install-hdl-dev-reqs16:48
ghostmansdIs stuff like `sv.add./sats 0,1,2` even legal?17:27
*** octavius <octavius!> has joined #libre-soc17:28
ghostmansdI'm asking since pysvp64asm accepts this, but it doesn't set RM.mode to 0b10.17:29
ghostmansd0-1     2     3 4     description17:30
ghostmansd10     N     dz sz     sat mode: N=0/1 u/s17:30
ghostmansdHm, should be set. I'll re-check this.17:35
markosok, so calling python from C works :)17:35
markosnow, question is how to call simulator directly -ie, without calling pypowersim17:36
markosas that way I would have to dump arguments to a file and the opposite for the arguments17:36
lkclmarkos, no, /sats is not yet supported.17:43
lkclghostmansd, tests+rebase done17:44
lkclok so you'll likely have to set up the arguments using PyObject_xyz etc. directly17:45
markoslkcl, that was probably for ghostmansd  :)17:46
markosyes, that's exactly what I'm doing17:46
lkcl1.3. Pure Embedding17:46
lkcli've usually done [lots of, in the past] writing c-based modules17:47
markoswhat I'd like is the convention and which method to call17:47
lkcl1 sec17:47
lkcllook in setup.py17:47
lkclline 8417:48
lkcl  84             'pypowersim=openpower.decoder.isa.pypowersim:run_simulation',17:48
lkclwhich at line 36017:49
lkclgives you what you want17:50
lkclto be honest you would be better off writing a straight (much simpler) function, drop it in there17:50
markosProgram() is the method17:50
lkclno, Program() is an object17:50
lkclyou're better off rather than pissing about to write (add) a straight function17:51
markosin python you mean17:52
markosone that takes the args that Program expects17:52
lkclotherwise you have to piss about creating a Program() object followed by passing it to the run_tst() function as one of its arguments17:53
markosmy python foo is not that good, but I'll give it a shot17:53
lkclno, combining the role of the "with" and the call to run_tst()17:53
ghostmansdarhg, it's so damn difficult to disassemble specifiers17:53
lkclbasically move lines 359 to 366 to a new function17:53
ghostmansdmainly because some modes listed separately are put together17:53
* lkcl rueful17:54
lkclall of which makes me wish we'd thought of the idea of doing RM as XO/CSV-files and rm_fields.txt a lot earlier17:54
lkclbut the technique can still be applied - just without the rm_fields.txt reading and without the csv reading17:55
ghostmansd[m]What do you mean?18:01
ghostmansd[m]I'm speaking of stuff like /satu => mode=0b10, N=018:02
lkclthe 24-bit parsing i feel should be... ahh yeah18:02
ghostmansd[m]And, whilst this is easy to track...18:03
ghostmansd[m]The vice versa is not true18:03
ghostmansd[m]Because we don't operate on these in a per-mode way18:03
lkclohh yes18:04
lkcli remember18:04
ghostmansd[m]But collect it and do shifts instead18:04
lkclyeah i shared some of them between modes18:04
ghostmansd[m]I don't even know where to start. Stuff like dz/sz was obvious.18:04
ghostmansd[m]Next I think I'll do sw and ew.18:05
ghostmansd[m]I also did sats/satu, but there's an issue with this one.18:05
lkclwell... ya know... ya have the bits all decoded18:06
lkcli mean... it shouldn't be...18:06
lkcl1 sec let me check satu/sats18:06
lkcl'sv.extsw./satu/sz/dz/sm=r3/dm=r3 5, 31',18:07
lkclworks fine18:07
lkcldid you take out pack/unpack?18:07
ghostmansdI mean the disassembly part18:09
ghostmansdThe difficulties are when I reconstruct what was in assembly18:10
lkclfrom that list - with known bits - it really should not be hard18:11
lkclhe said18:12
lkclthe only thing being, hmmm, *comparing* them will be tricky unless the ordering is strictly-defined18:13
lkcli'd recommend lexicographical order18:13
lkclthen anything in is done - manually - in (same) lexicographical order18:14
lkclelwidth should just be18:16
lkcl    def specifiers(self):18:16
lkcl        if self.elwidth > 0:18:16
lkcl            yield "ew=%d" % (self.elwidth * 8)18:16
lkclbear in mind18:16
lkclthere's a sw= dw= and ew=18:17
*** ghostmansd <ghostmansd!> has quit IRC18:17
lkclew= is used to mean **BOTH** sw=dw=NN18:17
*** ghostmansd <ghostmansd!> has joined #libre-soc18:18
ghostmansd[m]Yeah same as with zz/dz/sz18:19
lkclsigh, how do you get at the values within Fields?18:19
lkclhow do you get the actual integer value?18:19
lkclyep that works18:19
lkclurrr f****g things are MSB0-ordered, sigh18:20
lkclgot it18:21
lkclat least the basics for ew.18:21
lkcl    def specifiers(self):18:21
lkcl        if self.elwidth != 0:18:21
lkcl            yield "ew=%d" % (8<<(3-int(self.elwidth)))18:21
lkclghostmansd[m], you good if i commit that?18:22
lkcl(in BaseRM - possibly not the best place for it but it's a start)18:23
ghostmansd[m]Nope, please don't do it18:23
lkclbut you get the idea18:23
ghostmansd[m]First of all, I'm doing ew now :-)18:23
lkclwell, that's the calculation (above)18:23
ghostmansd[m]Second, %d is totally allien on this PHP fest18:23
ghostmansd[m]Third, I'm not sure this is for BaseRM. some modes re-use fields from BaseRM.18:24
lkclthen i'll work on adding that to the HDL_workflow style guidelines for the project, that it's prohibited except for unusual circumstances (large strings, repeated occurrences of variables)18:25
ghostmansd[m]I'm currently checking it but it seems we have to do it on per-mode basis18:25
ghostmansd[m]Ok if there's a rationale18:25
ghostmansd[m]PHP hate is not a rationale18:25
ghostmansd[m](I hate it too, though)18:25
lkclyes there's a rationale.18:25
lkclit's unreadable18:25
ghostmansd[m]We already discussed it, it's just an opinion18:26
ghostmansd[m]yield "ew=%d" % (8<<(3-int(self.elwidth))) is a piece of unreadable crap18:26
ghostmansd[m]See? This is a game for two!18:26
lkclit's very clear - the format is on the left, the code is on the right18:28
lkclyou know that a decimal number is going into the format ("%d)18:28
lkclit's compact and known for 30 years from c18:28
ghostmansd[m]That's also clear: it's string interpolation present in many languages, and even proposed to Python std library18:28
ghostmansd[m]And yes, it's known for years, too18:28
ghostmansd[m]Not everything I know from C deserves to be dragged18:29
lkclbeing in multiple languages does not make it a good idea18:29
ghostmansd[m]It does compared to idea if Python was the only one18:29
lkclif it is just as unreadable in those languages18:29
ghostmansd[m]Also, formatting multiple things makes the stuff even worse18:29
lkcli did Zope/Plone programming back in 2000-200618:29
lkclZope/Plone attempted to copy the templating of PHP, by embedding python code into XML18:30
lkclit was awful.18:30
markosZope! oh the horrors! why did you bring these memories!18:30
lkcli ended up maintaining some of the worst-written code i've ever seen18:30
ghostmansd[m]I don't know why you talk about PHP18:30
lkclbecause it's exactly the same principle18:30
lkcl"it's okay to embed code into ASCII strings"18:31
ghostmansd[m]No, it's not. This one has support with __format__, and is extendable.18:31
lkclthat's the fundamental deeply-flawed justification for creating nightmare scenarios18:31
markosisn't that what one of the js things do these days?18:31
markoskeep forgetting the name18:31
lkclit's exactly the same principle18:31
ghostmansd[m]And no, it's not like embedding code18:31
markosembed js into HTML18:31
ghostmansd[m]It's interpolation18:31
lkclit's using eval() behind-the-scenes18:31
ghostmansd[m]If you use it for bad purposes, it's your fault18:31
ghostmansd[m]Like anything else in Python18:32
lkclthe fragments of code, which are in between curly-braces, are passed to eval()18:32
lkclwhich is exactly the same principle used by PHP18:32
lkclwhich was the exact same principle used by Zope/Plone18:32
lkclit's all the same, and it's a total nightmare18:32
ghostmansd[m]Well this is interpolation18:32
ghostmansd[m]Again: this is a personal opinion18:32
lkclif you look at the source code of python, i can pretty much guarantee 100% that they call the eval() function18:33
ghostmansd[m]If you want to deal with it — fine, add it to guidelines and format the code18:33
ghostmansd[m]I won't waste time on this. At all.18:33
lkclif you can at least keep eval()ed expressions out of the format strings that will help18:33
ghostmansd[m]It won't make it non-evaluatable.18:34
lkclas in, please don't do f"{'/'.join(list_of_args}"18:34
ghostmansd[m]There still will be a variable to be evaluated.18:34
lkcli know - but it's a reasonable compromise to keep to...18:34
lkclyes, which i am not happy about in the least18:34
ghostmansd[m]This is a kind of cargo cult like "goto is harmful"18:35
lkclparticularly when if you want to ...18:35
ghostmansd[m]Or "use tabs"18:35
lkclit's about readability.18:35
lkclgoto isn't harmful18:35
ghostmansd[m]Yes, and readability is somewhat personal.18:35
lkclit saves hugely on if/else-nesting on error-handling18:35
ghostmansd[m]Again: to me % is not as readable.18:35
ghostmansd[m]Yes, that's why I brought exactly this example.18:36
lkclthey're something i learned 28 years ago and haven't forgotten18:36
ghostmansd[m]You'd be surprised to know how many lunatics I met who even do loops with breaks.18:36
ghostmansd[m]Just to not use goto.18:36
lkcli actually have to look up what the fuck some of the hex format-string fuckwittery is18:36
lkcli've read a lot of linux kernel source code, it's a really good example of how to use goto correctly18:37
ghostmansd[m]This is the same except it's interpolated and extendable.18:37
ghostmansd[m]Yes, me too. And I use goto a lot.18:37
lkclwhich is precisely where the nightmare comes in.18:37
ghostmansd[m]My point is not about that.18:37
lkcldon't put code into format-strings18:37
lkcli can't read it.18:37
ghostmansd[m]OK I will use variables.18:37
ghostmansd[m]I won't stop using the f strings per se.18:38
lkcli'm fine with that18:38
lkclwhat i'm going to put is that use of format-strings is frowned on18:38
markosghostmansd, I'm one of those lunatics, anytime you feel you think you need to use goto, think again, there is a way to do the same thing without goto and the code will be much cleaner and better18:38
lkclbut is recognised as useful if the arguments are repeated18:38
lkclif you have 12 "%s" four of which are repeated *that* gets to be a total nightmare18:39
ghostmansd[m]Moreover, I will replace a single % which has tons of f around with f, because code should keep the spirit. The vice versa is also true.18:39
ghostmansd[m]markos, I'm mostly using it for resources deallocation on fail path.18:39
ghostmansd[m]Especially if there are multiple resources or stages.18:40
ghostmansd[m]Though there are some other interesting goto uses.18:40
markosghostmansd, yes, cleanup is the main argument in favour of goto, and still there are other ways18:40
ghostmansd[m]Anyway, my point is: I'm not wasting my time on opinion debates unless something has maintainability issues.18:41
ghostmansd[m]This doesn't.18:42
lkclit's unmaintainable because i can't read it18:42
ghostmansd[m]And I don't come and complain that %d should be removed.18:43
ghostmansd[m]Ok so I cannot read your whitespaces. Or large %(crap) sections.18:43
ghostmansd[m]With whitespaces, I simply surrendered.18:43
ghostmansd[m]With %d, I even not battled.18:44
ghostmansd[m]Do as you wish.18:44
ghostmansd[m]If you want to adjust some parts of the project to your personal taste, OK, it's up to you to convert the code. I'll stick to this then.18:44
ghostmansd[m]But for sure I won't support it.18:45
ghostmansd[m]But, as maintainer, you have this right18:45
*** ghostmansd <ghostmansd!> has quit IRC18:46
markosghostmansd, I think this is unfair, owners/lead developers definitely have the right to impose code styles, and the rest just have to follow, this has happened to *every* company I've worked in18:46
markoswtf has happened18:46
ghostmansd[m]Yes, that's exactly what I said18:46
ghostmansd[m]Luke has this right18:46
markoswe don't have to agree18:46
markosor share the same opinion, but it is what it is18:47
ghostmansd[m]So I don't see anything unfair here: I explicitly told he can impose it.18:47
lkclbasically... embarrassed/uncomfortable as i am with it, i'm the one whose time is precious when it comes to reviewing18:47
ghostmansd[m]I said that I wouldn't like it and won't waste my time on converting it manually.18:47
lkclif i can't read it, then that's a serious problem18:47
ghostmansd[m]I already told my opinion, it's your right as the maintainer.18:50
ghostmansd[m]I won't dive into replacing either f or %, because I really don't think this deserves wasting my time, unless this is enforced.18:52
octaviuslkcl, I added a comment on the pinmux 846 bug with my latest development, please give it a gander if you have time. The waveforms are pretty :)18:53
ghostmansd[m]Disassembly deserves my time way more, but I still spend the time on this idiotic time-consuming discussion.18:53
ghostmansd[m]Instead of this, we could have discussed how to make pysvp64asm readable and 1:1 similar to disassembly, but sure this is of lesser concern than f strings.18:54
lkcloctavius, brilliant18:54
ghostmansd[m]So I prefer to surrender, I don't think this discussion is worth the efforts I'm putting here.18:54
lkclghostmansd[m], i'm keenly conscious/aware of time. do the best you can18:59
lkcloctavius, ok the pinset information is far easier. it's self-describing.18:59
lkcljtag already has direction/type19:00
lkcl* means bi-directional19:00
lkcl- is in19:00
octaviusI know lkcl19:00
lkcl+ is out19:00
lkcl< is tri-state19:00
lkclso actually, it's far easier to create a pinmux from the Pinouts() dict than it is manually!19:00
ghostmansd[m]Even if we had, I wouldn't support this idea, but, as I said, it's up to you. A project without maintainer is not a project all. If this is the price we have to pay to keep you sane and project-devoted, I'm ready to pay it. :-)19:00
ghostmansd[m]*at all19:00
lkcland the record layouts don't have to be created, or if they are they're created from the IOType19:01
octaviusOk, I'll implement these types. Still, the pad information is also required (which pad the muxes are actually connected to, in my examples N1-N4)19:01
ghostmansd[m]As I said, this is more of preferences, and your preferences are valuable more. No, this is not a joke, I'm serious.19:01
lkclyes - the pad *numbering*, yes, which should be a key into the dictionary created/maintained by the class19:02
lkclbut if you can do it as a dict-of-dicts that's even better19:02
lkclfirst dict, N/S/E/W19:02
lkclsecond dict, 0/1/2/3/4/519:02
lkclsomething like that19:02
lkcl(or, better, just match what the Pinouts dict does)19:03
lkcljust match exactly the Pinouts layout19:03
lkclthat way, "walking" is dead-easy19:03
lkclghostmansd[m], it's ok.19:04
octaviusAh yes19:04
lkcli added (pushed) a new unit test sv.addi./ew=8 (and 16 and 32)19:04
lkclwhich passes with the hack-job19:04
lkcl    def specifiers(self):19:05
lkcl        if self.elwidth != 0:19:05
lkcl            yield "ew=%d" % (8<<(3-int(self.elwidth)))19:05
lkclthe "3-ew" is a weird trick that inverts the bit-order, i can't remember where i learned it from19:05
ghostmansd[m]Is it master? I think I might have some commits in dis beyond.19:06
lkcl0123 becomes 321019:06
lkclcommit e07b6d3819:06
ghostmansd[m]Ok will check19:06
lkcli rebased master with vec2/3/4 already19:06
lkclghostmansd[m], mmode and mask should be easy19:07
ghostmansd[m]There's some confusion with sv_mode, mode and smmode/mmode19:08
ghostmansd[m]But I'll beat it I think19:08
lkclmmode and mask are fixed (non-Mode-dependent)19:10
lkclbut smask (sigh) is dependent on... on... aaaagh19:10
lkclfrickinell that's awful19:11
lkclthat's a candidate for being a column in the RM-*.csv files, that is19:11
lkclfrom sv_analysis.py19:12
lkclfrick, frick frick, fricking frick19:25
lkclthe entire RM-2P-2S1D group has been classified as EXTRA319:25
lkclah hang on... it looks like (thank god) that group only has mtcrf in it19:27
lkclghostmansd[m], i added a new csv column, SM - stands for "MASK_SRC"19:38
lkcland associated SVmask_src19:39
lkclotherwise you haven't a hope in hell of disassembling/detecting whether smask should be looked for19:39
lkclok to add it to
ghostmansd[m]Thanks! I'm refactoring RM's one more time, reducing nest level.19:40
ghostmansd[m]I realized there's some common functionality between all normal RM modes (and so for the rest).19:40
lkcladding SVmask_src (right next to SVEtype) shouldn't conflict with that19:40
ghostmansd[m]So I'm decoupling a base class to put common specifiers there...19:40
ghostmansd[m]Yeah go ahead, I'll rebase it with dis later19:41
lkclare you altering any code with... ack19:41
ghostmansd[m]I still have a lot to do19:41
ghostmansd[m]We cannot put everything into BaseRM, some modes don't have some fields19:41
ghostmansd[m]But all normal modes have something in common, like all branch modes, cr_op modes, ld/st modes, etc.19:42
ghostmansd[m]You get the idea.19:42
lkclwatch out for some of the bits which change position.19:42
lkcli tried avoiding that as much as practical19:42
*** ghostmansd <ghostmansd!> has joined #libre-soc19:42
lkclok done. very basic. no tests on it19:46
lkclnow it's possible to tell if "sm=" is even allowed19:47
lkcljust putting some comments in19:49
ghostmansd[m]About pack/unpack. Which of RM classes have it?19:49
lkclabsolutely none.19:49
ghostmansd[m]Cool, I'll drop these.19:49
lkclalready did19:49
lkclgit rebase19:49
ghostmansd[m]Oh this will be a difficult rebase :-)19:49
lkcljooooy.  sorry :)19:49
lkclthen i won't add comments (yet) into BaseRM19:50
lkclbecause that would be a thorough pain19:50
lkclthere was going to be a hack/caveat on that, but i think even that's gone now19:51
lkclyep i can revert it19:52
*** octavius <octavius!> has quit IRC20:01
ghostmansd[m]No need20:01
ghostmansd[m]Incidentally I could rebase!20:01
ghostmansd[m]Likely because from diff point of view it was rather adding a new code20:01
ghostmansd[m]Despite that I only changed indent and names20:01
ghostmansd[m]Ok checking why Mapping[xxx] doesn't work as I expect20:03
ghostmansdHm. For `sv.add./sats 0,1,2`, I get 0b00110 for RM.mode, but I'd have expected 0b10 somewhere.20:13
ghostmansdIt's all over this shitty MSB0, eh?20:14
ghostmansdelif encmode == 'sats':20:17
ghostmansd    saturation = 120:17
ghostmansd    sv_mode = 0b1020:17
lkclah no, the revert was in sv/trans/ - for adding sv.setvl/pack20:24
lkclthat had to go20:24
lkclyeees, it's barse-ackwards-MSB020:25
lkclirony is that actually MSB0 is natural left-to-right reading-order20:25
lkclit's LSB0 that is, technically, for humans, "borked", because numbers are expressed in digits the wrong bloody way round!20:26
lkcl  File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/", line 169, in __len__20:29
lkcl    return self.__class__.__len__()20:29
lkclTypeError: __len__() missing 1 required positional argument: 'self'20:29
lkclbit more context20:30
lkcl  File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/", line 1312, in specifiers20:30
lkcl    if
lkcl  File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/", line 169, in __len__20:30
lkcl    return self.__class__.__len__()20:30
lkclTypeError: __len__() missing 1 required positional argument: 'self'20:30
ghostmansdhell, got lost somewhere in between rebases20:30
ghostmansdyeah, 1 sec20:30
ghostmansdhm... is it caled from test?20:30
ghostmansdah OK20:31
lkclpython3 src/openpower/sv/trans/  > /tmp/f20:31
ghostmansdshould be better now, 3 failures with ew=20:32
ghostmansdit's not in branch yet, I've just rebased classes20:33
lkclack... checking... confirmed20:33
lkcloh wait20:33
lkcl- sv.lfs *40,256(5)20:33
lkcl+ sv.lfs/dz/sz *40,256(5)20:33
lkcl?       ++++++20:33
lkclFAIL: test_7_batch (__main__.SVSTATETestCase) [63:sv.lfs]20:33
ghostmansd1 sec20:34
ghostmansdaha OK confirm20:35
ghostmansdso we don't have sz/dz specifiers?20:35
lkclmarkos, you know about this page?
lkclyees, but they're... 1 sec20:35
lkclthey're only enabled on predication20:35
ghostmansdAh I guess it's not for these who have zz20:36
lkclthat'd be correct20:36
lkcllet's pick sv.lfs first20:36
lkcl'sv.lfs/dz/sz *32,256(4)'20:36
lkclthat's a LD/ST-with-immediate Mode20:36
lkclsection 4, that's "zz"20:37
lkclclass LDSTImmSimpleRM(LDSTImmBaseRM):20:38
lkcl    """ld/st immediate: simple mode"""20:38
lkclmode is 5-bit20:38
lkclthe specifiers "sz" and "dz" are banned, it should be zz20:39
ghostmansddz and sz are aliases20:39
lkclbut *reading* is... yes20:39
ghostmansdI thought to re-use them later...20:39
lkclbut now i am suspecting that sv/trans/ is wrong, here20:39
ghostmansdI guess we shouldn't output them in specifiers though20:39
ghostmansdBut what to output, then?20:39
lkclno, it should definitely be zz20:39
lkclbecause it's a mistake in sv/trans/ to allow sz/dz20:40
ghostmansdI We don't even have zz in pysvp64asm20:40
lkclwhich, argh, is probably the source of the mistake20:40
ghostmansdOK, let's split these issues20:40
ghostmansdI'll drop aliases for dz/sz to zz20:40
ghostmansd(should I output /zz in specifiers?)20:41
lkclnono, don't drop the aliases, they're useful20:41
lkclyes, output /zz as the specifier20:41
lkcl    zz: BaseRM.mode[3]20:41
lkcl    dz: BaseRM.mode[3]20:41
lkcl    sz: BaseRM.mode[3]20:42
lkcl            | --- | --- |---------|--------------------------- |20:42
lkcl            | 00  | 0   |  dz els | normal mode                |20:42
lkcl            | 00  | 1   |  dz shf | shift mode                 |20:42
lkclin sv/trans/svp64.py20:42
ghostmansdI looked in the docs20:42
lkclyep that's good20:42
ghostmansdDo you refer to comment in pysvp64asm?20:43
lkcli'm fixing svp64.py20:43
ghostmansdAh OK that's a relief20:43
lkclyes it's wrong20:43
lkclcan you tell me easily, is "zz" mode[3] in all cases?20:44
ghostmansdSometimes it's BaseRM[6]20:45
ghostmansd1 sec20:45
lkclahh yeah20:45
lkcli'm ignoring that for now20:46
lkclhaven't implemented any sv.crops at all20:46
ghostmansdI pushed zz changes but it won't help the test20:47
ghostmansdWe'll simply have /zz instead of /dz/sz20:47
lkclyes which is really weird'20:48
ghostmansdAnd I guess it's again due to MSB0, but still no idea why20:48
lkcldo you have a repro case on the dump?20:48
ghostmansdBecause I should've indexed SelectableInt by the span20:48
lkclan 'echo \xnnnnn | pysvp64dis'?20:48
ghostmansd00 20 40 05 00 01 04 c120:48
ghostmansd1 sec20:48
ghostmansdecho -en "\x00\x20\x40\x05\x00\x01\x04\xc1" | pysvp64dis20:49
ghostmansdI wasn't aware you already did an alias to pysvp64dis :-)20:50
lkcl        RM.zz20:50
lkcl            020:50
lkcl            1120:50
lkclis there a __bool__() method added to Field()?20:50
lkclif self.zz == 0b1 would do it20:50
ghostmansdnope, there's none20:51
lkclthat's probably why then20:51
ghostmansdah so it's always True20:51
lkclit's going "is the length of self.zz equal to zero?"20:51
ghostmansdfuck why do they do it in Python?20:51
lkclit's a precedence thing20:51
ghostmansd1 sec20:51
ghostmansdI'll add boolean to all of them20:51
lkclif there's no __bool__ method then "you must want an iterator, check the length"20:51
lkclwhich should be "is the underlying integer value non-zero"20:52
ghostmansdbtw I recently discovered yet another magical method20:52
lkcloo much joy20:52
lkclo dear20:52
ghostmansdit makes crap work with bin, hex, oct, and some other stuff20:52
ghostmansdI even wasn't aware20:52
ghostmansdonly found when I defined __int__ and assumed "hey, now bin() will work"20:53
ghostmansdnot at all!20:53
ghostmansdthen I googled and found they invented yet another magic20:53
lkclfer f'ss sake :)20:53
lkcli do wish they'd stop fuckign around with python20:53
lkclthere's a point at which you have to actually *stop* adding features20:54
ghostmansdnope, I guess they don't have such limits20:54
ghostmansdbut I suspect this stuff is really old20:54
ghostmansdI mean, __index__20:54
ghostmansdjust not that many idiots like me want to call hex() on object directly20:55
* lkcl snort20:55
ghostmansdOK the error with zz is gone, nice catch20:55
ghostmansdat least on echo20:55
ghostmansdchecking test20:55
lkclokaaay we're getting somewhere20:55
lkclAssertionError: 'sv.add./ew=8 *3,*7,*11' != 'sv.add./sz *3,*7,*11'20:55
lkcl- sv.add./ew=8 *3,*7,*1120:55
lkcl?         ^^^^20:55
lkcl+ sv.add./sz *3,*7,*1120:55
lkclthat's worth ignoring for now :)20:56
lkcl1 sec20:56
ghostmansdI guess the problem has to do with span20:57
ghostmansdand how bits lay there in practice20:57
ghostmansdthere are three points: Mapping, Field and Reference20:57
* lkcl compiling sv.add./ew=32 *3,*7,*1120:58
lkcl   4:   15 12 01 7c     add.    r0,r1,r220:59
lkclecho -n -e '\xe0\x34\x44\x05\x15\x12\x01\x7c' | pysvp64dis -v20:59
lkcland we get...21:00
lkclRM.elwidth=01 [12,13]21:00
lkclRM.ewsrc=00 [14,15]21:00
lkclRM.smask=111 [24,25,26]21:00 [11]21:00 [12]21:01
lkclarse. wrong one.21:01
lkclsv.add/ew=8 was the one that was incorrect21:01
lkcloh that's interesting in its own right21:01
lkclahhh you see?21:01
lkclRM.elwidth=[****12****,13]21:02 [*****12*****]21:02
lkclbut where...21:02
ghostmansd1 sec21:02
ghostmansdyep I see this overlap21:05
ghostmansdchecking the sources21:05
ghostmansdlikely I fucked up at RM classes21:05
lkcl        RM.mode21:06
lkcl            0000021:06
lkcl            27, 28, 29, 30, 3121:06
lkclthat can't be right and be bit 11 at the same time21:06
ghostmansdso it's normal simple21:07
lkclwell let's assume they're correct relative to the 32-bit21:08
ghostmansdIn this sense we should be fine I think21:08
lkclit would mean that should be.... 30? yes.21:09
lkcland should be bit... 3121:09
lkcl27 28 29 30 3121:09
lkcl0  1  2  3  421:09
lkcl000dz szsimple mode21:09
ghostmansd'mode': Mode({'_': Field(19, 20, 21, 22, 23)})21:09
lkclso dz = bit 3021:09
ghostmansdthis is from BaseRM, before remapping21:10
ghostmansdI guess fine here21:10
lkcli am looking at the output from the echo command above21:10
lkcl        RM.mode21:10
lkcl            0000021:10
lkcl            27, 28, 29, 30, 3121:10
lkcl        RM.dz21:10
lkcl            021:10
lkcl            1121:10
lkcl        RM.sz21:10
lkcl            021:10
lkcl            1221:10
ghostmansdyep, RM.mode is fine21:11
ghostmansdsz is fucked21:11
ghostmansdI guess __getitem__ on field side...21:11
ghostmansdor, rather, at FieldMeta21:11
lkcl    sz: BaseRM.mode[4]21:13
lkclshould be21:13
lkcl  sz:BaseRM.remap(range(4))?21:14
ghostmansdnope, that's one bit21:14
ghostmansdAh you mean remap21:15
ghostmansdI guess the problem is that it's relative to Mode21:15
ghostmansdand, well, for Mode, when we access it...21:15
ghostmansdwe have (0, 1, 2, 3, 4)21:15
ghostmansdand this is in fact correct21:15
ghostmansd1 sec21:16
ghostmansdhm    dz: BaseRM.mode[3]21:17
ghostmansdsz: BaseRM.mode[4]21:17
ghostmansdcocojumbo: BaseRM.mode21:17
ghostmansd'dz': Mode(3,), 'sz': Mode(4,), 'cocojumbo': Mode({'_': Field(19, 20, 21, 22, 23))21:18
ghostmansdSo the error is in the code which does __getitem__21:18
lkclwhich should be 27, 28, 29, 30, 3121:18
ghostmansdit's before remap21:18
lkcli get:21:18
lkcl        RM.coco21:18
lkcl            0000021:18
lkcl            27, 28, 29, 30, 3121:18
ghostmansdthat's because you look at RM class21:19
ghostmansdnot BaseRM21:19
ghostmansdI look at the BaseRM class because error happens here21:19
ghostmansddz: BaseRM.mode[3]21:19
lkclclass NormalSimpleRM(NormalBaseRM):21:19
lkcl    dz: BaseRM.mode[3]21:19
lkcl    sz: BaseRM.mode[4]21:19
lkcl    coco: BaseRM.mode21:19
ghostmansdAh yes, fuck21:20
ghostmansdhang on21:20
* lkcl drink!!!21:20
ghostmansdyep the issue is in mapping21:21
ghostmansdclass Mode(_Mapping):21:21
ghostmansd    _: _Field = range(0, 5)21:21
ghostmansdWe have this field21:21
ghostmansdThen we remap it mode: Mode.remap(range(19, 24))21:22
ghostmansdBut, when we do dz: BaseRM.mode[3], the operator does the wrong thing21:22
ghostmansdand uses range(0, 5) as stuff to check21:22
ghostmansdnot the stuff after remap21:22
ghostmansdbut the original range21:22
ghostmansdthis code is totally incorrect21:23
* lkcl ngggggh21:24
ghostmansd'dz': Field(22,), 'sz': Field(23,), 'gg': Mode({'_': Field(19, 20, 21, 22, 23)})})21:24
ghostmansdOK should be fine now, but assumes that at least this class or some of its parents defined _ field which enlists the whole mapping21:25
ghostmansdluckily for us, the code already has this dependency21:25
ghostmansd1 sec, need to check on real example21:25
lkcltotally cheating, i like it :)21:25
ghostmansdnow back to this insn21:27
lkcl        RM.dz21:27
lkcl            021:27
lkcl            3021:27
lkcl        RM.sz21:27
lkcl            021:27
lkcl            3121:27
lkclecho -n -e '\xe0\x34\x44\x05\x15\x12\x01\x7c' | pysvp64dis -v21:27
ghostmansdmetaclasses are a real creep21:27
lkclokaay so /dz and /sz have disappeared21:27
lkcl- sv.add./ew=8 *3,*7,*1121:27
lkcl?        -----21:27
lkcl+ sv.add. *3,*7,*1121:27
lkclthis is good21:27
ghostmansdsats still doesn't work21:28
lkclgimme sec to add an example / check21:28
ghostmansdecho -ne "\x06\x00\x40\x05\x15\x12\x01\x7c" | pysvp64dis21:29
ghostmansdthis should've been sv.add./sats 0,1,221:29
lkclok let me add that to the tests, to check21:29
lkclsat,sat,where the hell is sat...21:29
ghostmansdHm it thinks it's parallel reduce mode...21:30
lkcl        RM.mode21:30
lkcl            0011021:30
lkcl            27, 28, 29, 30, 3121:30
ghostmansdand it should've been recognized as saturation21:30
lkcl# for "normal" arithmetic:
lkcl| 0-1 |  2  |  3   4  |  description              |21:30
lkcl| 10  |   N | dz   sz |  sat mode: N=0/1 u/s |21:31
ghostmansdback to MSB0 :-)21:31
ghostmansdwe need to make the code behave like spec21:31
ghostmansdcf select function21:32
lkcl            elif encmode == 'satu':21:32
lkcl                assert sv_mode is None21:32
ghostmansdelif rm.mode[0:2] == 0b10:21:32
lkcl                sv_mode = 0b1021:32
ghostmansd                if self.subvl == 0b00:21:32
ghostmansd                    rm = rm.sat21:32
ghostmansdI know on pysvp64asm things are great :-)21:32
lkcli'm not assuming that, at all!21:32
ghostmansdthis line  rm.mode[0:2] == 0b10:21:32
ghostmansddoesn't work21:32
ghostmansdno I think the code there is correct21:33
ghostmansdwell, constant matches21:33
ghostmansdso we could only lose at shift...21:33
lkclRM.mode = 00110 isn't correct, i don't believe21:33
lkclit should be... 10 0 0 021:34
ghostmansdyep, I think too21:34
lkclwhere the hell 00110 came from i have no idea21:34
ghostmansdbut mode is calculated as mode |= sv_mode21:34
ghostmansdI guess that's where we should have got 0b1021:35
* lkcl head-banging but gently because it's 21:35 here21:35
*** lxo <lxo!> has joined #libre-soc21:35
ghostmansd23:35 here :-)21:36
ghostmansd1 sec, I'm adding prints to pysvp64asm21:36
ghostmansdI have one cheat!21:36
lkcl    mode   19-23: 0b11021:37
lkclthat's in LSB0 order21:38
lkcleffin frick.21:38
lkclahh you said sats not satu21:39
lkclsatu i get21:39
lkcl    mode   19-23: 0b1021:39
lkclso it's getting mode[2] correct at least21:39
ghostmansdfeel free to ignore all but .normal21:40
ghostmansdthat's the whole dump of svp64 instruction from pysvp64asm21:40
lkclcan you commit that as a test program somewhere?21:41
lkclit's really useful to be able to run21:41
ghostmansdSVP64.prefix.rm.normal.sat.mode 00110 (27, 28, 29, 30, 31)21:41
lkcli mean, "the way it's generated"?21:41
lkclyep i know what's wrong21:41
ghostmansd1 sec, it was print instead of log21:41
lkcldoesn't matter21:41
lkclprint is good21:41
ghostmansdbut beware, it's mixed with SelectableInt stuff21:42
ghostmansda _lot_21:42
lkcldoesn't matter, i found myself needing it yesterday21:42
ghostmansddis branch as usual21:42
ghostmansdthis is actually a very simple and short21:43
ghostmansdwhen you traverse the mapping you get for all fields the path, the value and the span21:43
ghostmansdI use it lot, just mostly not on the whole SVP64 instruction21:43
ghostmansdbecause there it's barely readable21:43
ghostmansdSVP64.prefix.rm.normal.sat.mode 00110 (27, 28, 29, 30, 31)21:44
ghostmansdI could have understood if it was at least 0b0010121:45
lkcl    mode   19-23: 0b1010021:45
lkcl   0:   14 00 40 05     .long 0x540001421:46
lkcl   4:   15 12 01 7c     add.    r0,r1,r221:46
lkcly", line 1359, in specifiers21:46
lkcl    if self.sat:21:46
lkclAttributeError: 'NormalSaturationRM' object has no attribute 'sat'21:46
lkclecho -ne "\x14\x00\x40\x05\x15\x12\x01\x7c" | pysvp64dis -v21:46
ghostmansdI don't quite get what you do :-)21:47
lkcltry that echo21:47
ghostmansdah right21:47
ghostmansdshould've been N21:47
lkclecho 'sv.add./sats 0,1,2' | pysvp64asm21:47
lkclgit rebase first21:48
lkclor git pull master21:48
* lkcl rerunning all tests21:48
lkcl14 00 40 05    sv.add./sats r0,r1,r221:49
lkcl15 12 01 7c21:49
lkcl    RM21:49
lkcl        normal: sat mode: N=0/1 u/s, SUBVL=121:49
ghostmansdso it was on pysvp64asm, after all21:49
lkcl        RM.N21:49
lkcl            121:49
lkcl            2921:49
lkclwhich may - or may not - completely bollox things up. have to see21:49
ghostmansdI pushed the fix for N too21:49
ghostmansdlet me rebase master21:49
ghostmansdI'm two commits beyond21:50
lkcli think this is the first time anything other than mode[0:1] has been non-zero21:50
ghostmansdcan you run the tests?21:50
ghostmansdwith the recent21:50
ghostmansd1 sec, pushing21:50
lkclscalar-reduction which i implemented is also 00 in mode[0:1]21:50
lkclyep on it21:50
ghostmansdteam work!21:51
ghostmansdkinda have an impression we're doing paired programming21:51
lkclurrrr reminds me of university...21:51
ghostmansdah, my university had Latin instead, lol21:51
ghostmansdso I only became aware of paired programming at work21:52
ghostmansdOK this also means binutils are affected too21:52
ghostmansdyet another reason to use the generated fields21:52
ghostmansdyeah finally I got sats!21:53
ghostmansdstands for SATisfactory resultS21:53
ghostmansdOK I guess I surrender for today :-)21:54
lkclyeah it's late enough21:54
ghostmansdthank for your help!21:54
lkclnicely done21:54
ghostmansdgn, will continue tomorrow21:54
*** ghostmansd <ghostmansd!> has quit IRC21:59

Generated by 2.17.1 by Marius Gedminas - find it at!