| ghostmansd[m] | Well it cheats a lot | 00:04 |
|---|---|---|
| ghostmansd[m] | Ideally we should have some special cases, like non-zero operands | 00:05 |
| ghostmansd[m] | As for 5-bit or 3-bit... it's simple, the operands are span-aware | 00:05 |
| ghostmansd[m] | But yeah I also thought about it | 00:06 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 03:51 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 03:58 | |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has quit IRC | 07:22 | |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has joined #libre-soc | 07:49 | |
| *** octavius <octavius!~octavius@213.147.93.209.dyn.plus.net> has joined #libre-soc | 08:00 | |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has quit IRC | 08:40 | |
| *** octavius <octavius!~octavius@213.147.93.209.dyn.plus.net> has quit IRC | 08:44 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 09:20 | |
| *** octavius <octavius!~octavius@213.147.93.209.dyn.plus.net> has joined #libre-soc | 09:59 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC | 10:00 | |
| *** octavius <octavius!~octavius@213.147.93.209.dyn.plus.net> has quit IRC | 10:17 | |
| *** midnight <midnight!~midnight@user/midnight> has quit IRC | 10:32 | |
| *** midnight <midnight!~midnight@user/midnight> has joined #libre-soc | 10:35 | |
| markos | is 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 binutils | 12:58 |
| markos | I don't care if it takes a few hours to run | 13:02 |
| markos | it's a testcase basically and I want to test the function | 13: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> https://www.kernel.org/doc/html/v5.10/powerpc/syscall64-abi.html | 13:27 |
| openpowerbot | [mattermost] <lkcl> we have to put that into the cavatools-ppc64le port anyway | 13: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". https://marcin.juszkiewicz.com.pl/download/tables/syscalls.html | 13:36 |
| 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 |
| markos | lkcl, 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 shot | 14:35 |
| markos | ah, no it won't work | 14:35 |
| markos | just what I meant by running a program, ELF-loading and stdin/stdout/stderr should work | 14:37 |
| markos | unless... | 14:37 |
| markos | I could call the simulator from inside the program | 14:37 |
| markos | using a wrapper function that takes the input, passes it to the simulator, and puts the results back to the expected output | 14:39 |
| markos | that would probably be easier to do | 14:39 |
| markos | could 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 slower | 14:48 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 15:00 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.170.200> has joined #libre-soc | 15:01 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.170.200> has quit IRC | 15:16 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 15:18 | |
| lkcl | you'll need to do the trick of extracting the binary out of the .o, manually, yourself | 15:43 |
| lkcl | code has not been added to comprehend and automatically extract ELF... yet | 15:44 |
| lkcl | there are almost certainly ways to call pure-python programs from any other programming language | 15:44 |
| lkcl | every one of them will involve linking to /usr/lib/pythonNN.lib | 15:45 |
| lkcl | and doing the job *of* /usr/bin/pythonN.N-the-executable | 15:45 |
| lkcl | it's all doable | 15:46 |
| markos | yes, found that, I would have to create a wrapper, the tricky part would be the conversion of arguments/results | 15:46 |
| lkcl | honestly it may be easier to put in support for elf-loading and the bare minimum support for system calls read/write | 15:47 |
| lkcl | then just use exec()/pipe() | 15:47 |
| markos | I'd think that to be much much more difficult | 15:47 |
| lkcl | pfffh naah | 15:47 |
| markos | but then again I don't know the internals of the simulator | 15:47 |
| lkcl | it's a task that is easily put on the TODO list for the cavatools-ppc64 port | 15:48 |
| lkcl | python-based elf-reading already exists | 15:48 |
| lkcl | i would expect it to be a handful of lines involved. maybe... 70. absolute max 100. | 15:49 |
| lkcl | https://github.com/eliben/pyelftools | 15:49 |
| lkcl | https://github.com/eliben/pyelftools/blob/master/examples/elf_low_high_api.py | 15:50 |
| lkcl | ooo, scaary. that looks hard :) | 15:50 |
| lkcl | and sc is basically "if address == 0xC00 do_something_with_it()" | 15:52 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isa/system.mdwn;h=74f06c50b1bfaacf1c8164a0b3a08f2a54db8bae;hb=974db03758845ff56537eba7bbba06a7d57a095c#l22 | 15:52 |
| lkcl | so 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 |
| lkcl | where the very last thing would be to enact the exact same thing that's in "rfid" - return from interrupt. | 15:56 |
| markos | not sure, I think I'd prefer simulating only the function involved rather than the whole program, so performance penalty would be minimized | 15:58 |
| lkcl | tracing 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 |
| markos | just 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 code | 16:01 |
| markos | much easier than dumping the output of a buffer | 16:02 |
| ghostmansd | fuck I could not even suggest that SelectableInt compares _signed_ numbers | 16:02 |
| ghostmansd | and tricks such as `if (subvl > 0): ...` won't work | 16:03 |
| lkcl | ghostmansd, that's why the slt helpers exist | 16:03 |
| ghostmansd | because, well, guess what? subvl is 2-bit, and can end up being negative | 16:03 |
| ghostmansd | what is slt? | 16:04 |
| lkcl | signed-less-than | 16:04 |
| lkcl | signed-greater | 16:04 |
| lkcl | 1 sec | 16:04 |
| lkcl | ahh unsigned | 16:04 |
| lkcl | ltu and gtu | 16:04 |
| lkcl | from openpower.decoder.selectable_int import selectltu as ltu | 16:04 |
| lkcl | from openpower.decoder.selectable_int import selectgtu as gtu | 16:04 |
| ghostmansd | ah, this | 16:04 |
| lkcl | yes. | 16:04 |
| ghostmansd | it's a pity, because I passed operator.lt and operator.eq | 16:05 |
| ghostmansd | still int(si0) < int(si1) works | 16:05 |
| lkcl | if you look in v3.0 section 1.3.4 you will ese "signed comparison relations" | 16:05 |
| lkcl | and unsigned comparison relations "<u" and ">u" | 16:05 |
| ghostmansd | yeah fair enough | 16:06 |
| ghostmansd | it's just me that I think about collections of bits in unsigned way | 16:06 |
| lkcl | this one caused much head-banging for a few months due to the pseudo-code *not* having the correct signed/unsigned operators in some places | 16:06 |
| ghostmansd | by the way, why don't we apply functools.total_ordering to simply generate the rest of the operators? | 16:07 |
| ghostmansd | with it, __lt__ and __eq__ are the only ones which need to be defined | 16:08 |
| ghostmansd | it's slow, I know, but it saves some typing and allows to avoid errors | 16:09 |
| lkcl | never knew about it. work's done now. | 16:12 |
| lkcl | ghostmansd, ooooOoo, posh RM-decoding, oooo :) | 16:21 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=917#c57 | 16:22 |
| ghostmansd | lkcl, you could've simply told me you're fine with that change, I already had the patch :-) | 16:23 |
| * lkcl hand-waving... | 16:26 | |
| lkcl | i'm up to my neck in SVP64 prefix design | 16:26 |
| lkcl | have been for several days | 16:26 |
| markos | another question, can the simulator take compiled/binary code or does it have to be assembly? | 16:30 |
| lkcl | it *only* takes native binaries | 16:35 |
| lkcl | native (raw) | 16:35 |
| markos | perfect, so stuff that is compiled by ghostmansd's binutils assembler | 16:35 |
| lkcl | correct. again: see the scripts behind the media examples. | 16:36 |
| lkcl | i think i also added a README or at least a page somewhere on it | 16:36 |
| lkcl | octavius helped | 16:36 |
| lkcl | 1 sec | 16:36 |
| lkcl | https://libre-soc.org/docs/pypowersim/ | 16:36 |
| lkcl | yeah there you go | 16:36 |
| markos | ah, I was confusing it with the pysvp64asm tool | 16:36 |
| markos | ok, that's what I need | 16:37 |
| markos | I will give a shot to the pypowersim running under a C++ wrapper for the ported function | 16:37 |
| lkcl | be fascinated to hear how that works out - and please do put it into the openpower-isa/media repo | 16:38 |
| markos | definitely | 16:38 |
| ghostmansd | markos, if you need raw binaries, w/o elf, use objcopy | 16:38 |
| ghostmansd | objcopy -Obinary elf.o raw.o | 16:38 |
| lkcl | as long as it's not ridiculously massive of course! | 16:39 |
| markos | ghostmansd, cool thanks for the tip | 16:39 |
| ghostmansd | I'm not sure if there's an option in assembler to do it by default | 16:39 |
| markos | only thing that worries me is the arguments/results conversion | 16:39 |
| lkcl | markos, all documented. part of ppc64le ABI | 16:39 |
| ghostmansd | also, be aware that last time I checked EXTRA2 handling was incorrect | 16:39 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=media/calling-conv;hb=HEAD | 16:40 |
| markos | calling python from C/C++ is tricky but it's easy | 16:40 |
| ghostmansd | if you find something broken, I sometimes convert the code via pysvp64asm and compile it with as | 16:40 |
| ghostmansd | even vanilla PPC asm goes | 16:40 |
| markos | if that works it would help porting code to SVP64 much easier | 16:40 |
| ghostmansd | I'm planning to fix EXTRA2 and also refactor the code once I'm done with Python disassembler | 16:41 |
| markos | I have selectively pulled a bunch of functions from vp9 including their testcases | 16:41 |
| markos | and added svp64 versions of the functions | 16:41 |
| markos | which ofc for now are plain C | 16:41 |
| lkcl | markos, try to keep the arguments to function calls to integer and pointers-to-memory. | 16:41 |
| markos | but I want to incrementally port them to svp64 assembly | 16:42 |
| markos | most of those are like this | 16:42 |
| lkcl | oh - if you need binary data *please under no circumstances* commit it to the openpower-isa repo | 16:42 |
| markos | I'm not doing floats for the moment | 16:42 |
| markos | no binary data needed at all | 16:42 |
| lkcl | drop a tarball at me and i'll upload it to ftp.libre-soc.org | 16:42 |
| lkcl | whewwww | 16:42 |
| markos | and edited the files so that I don't have to pull all of vp9 include files | 16:43 |
| markos | kept it to a very few needed ones | 16:43 |
| markos | and possibly can be stripped down more | 16:43 |
| markos | only problem is dependency of googletest library as I didn't want to rework all the test suite as well | 16:44 |
| lkcl | joooy | 16:44 |
| markos | it's packaged in debian | 16:45 |
| lkcl | put it in the README as a... ahhh no problem | 16:45 |
| markos | so not a big problem really | 16:45 |
| markos | if calling the simulator from c++ works then we're set, I'll try a very small program to see it works | 16:46 |
| lkcl | googletest-tools - Google's C++ test framework sources | 16:46 |
| markos | it's actually the headers, libgtest-dev that I need | 16:46 |
| lkcl | ack | 16:47 |
| lkcl | done, added to install-hdl-dev-reqs | 16:48 |
| markos | cool | 16:49 |
| ghostmansd | Is stuff like `sv.add./sats 0,1,2` even legal? | 17:27 |
| *** octavius <octavius!~octavius@213.147.93.209.dyn.plus.net> has joined #libre-soc | 17:28 | |
| ghostmansd | I'm asking since pysvp64asm accepts this, but it doesn't set RM.mode to 0b10. | 17:29 |
| ghostmansd | https://libre-soc.org/openpower/sv/normal/ | 17:29 |
| ghostmansd | 0-1 2 3 4 description | 17:30 |
| ghostmansd | 10 N dz sz sat mode: N=0/1 u/s | 17:30 |
| ghostmansd | Hm, should be set. I'll re-check this. | 17:35 |
| markos | ok, so calling python from C works :) | 17:35 |
| markos | now, question is how to call simulator directly -ie, without calling pypowersim | 17:36 |
| markos | as that way I would have to dump arguments to a file and the opposite for the arguments | 17:36 |
| lkcl | markos, no, /sats is not yet supported. | 17:43 |
| lkcl | ghostmansd, tests+rebase done | 17:44 |
| lkcl | ok so you'll likely have to set up the arguments using PyObject_xyz etc. directly | 17:45 |
| markos | lkcl, that was probably for ghostmansd :) | 17:46 |
| lkcl | https://docs.python.org/3/extending/embedding.html | 17:46 |
| markos | yes, that's exactly what I'm doing | 17:46 |
| lkcl | 1.3. Pure Embedding | 17:46 |
| lkcl | i've usually done [lots of, in the past] writing c-based modules | 17:47 |
| markos | what I'd like is the convention and which method to call | 17:47 |
| lkcl | 1 sec | 17:47 |
| lkcl | look in setup.py | 17:47 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=setup.py;h=58a7ec32ec65d50bc838b8502860564310842a23;hb=a8387e23437f4187df4145160de7be2f71b0c3fe#l84 | 17:48 |
| lkcl | line 84 | 17:48 |
| lkcl | 84 'pypowersim=openpower.decoder.isa.pypowersim:run_simulation', | 17:48 |
| markos | excellent | 17:48 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/pypowersim.py;h=20edf56560b248df965d17cb6430a7803e2e3737;hb=a8387e23437f4187df4145160de7be2f71b0c3fe#l284 | 17:49 |
| lkcl | which at line 360 | 17:49 |
| lkcl | gives you what you want | 17:50 |
| lkcl | to be honest you would be better off writing a straight (much simpler) function, drop it in there | 17:50 |
| markos | Program() is the method | 17:50 |
| lkcl | no, Program() is an object | 17:50 |
| lkcl | you're better off rather than pissing about to write (add) a straight function | 17:51 |
| markos | in python you mean | 17:52 |
| lkcl | yes. | 17:52 |
| markos | one that takes the args that Program expects | 17:52 |
| lkcl | otherwise you have to piss about creating a Program() object followed by passing it to the run_tst() function as one of its arguments | 17:53 |
| markos | my python foo is not that good, but I'll give it a shot | 17:53 |
| lkcl | no, combining the role of the "with" and the call to run_tst() | 17:53 |
| ghostmansd | arhg, it's so damn difficult to disassemble specifiers | 17:53 |
| lkcl | basically move lines 359 to 366 to a new function | 17:53 |
| ghostmansd | mainly because some modes listed separately are put together | 17:53 |
| * lkcl rueful | 17:54 | |
| lkcl | all of which makes me wish we'd thought of the idea of doing RM as XO/CSV-files and rm_fields.txt a lot earlier | 17:54 |
| lkcl | but the technique can still be applied - just without the rm_fields.txt reading and without the csv reading | 17:55 |
| ghostmansd[m] | What do you mean? | 18:01 |
| ghostmansd[m] | I'm speaking of stuff like /satu => mode=0b10, N=0 | 18:02 |
| lkcl | the 24-bit parsing i feel should be... ahh yeah | 18:02 |
| ghostmansd[m] | And, whilst this is easy to track... | 18:03 |
| ghostmansd[m] | The vice versa is not true | 18:03 |
| ghostmansd[m] | Because we don't operate on these in a per-mode way | 18:03 |
| lkcl | ohh yes | 18:04 |
| lkcl | i remember | 18:04 |
| ghostmansd[m] | But collect it and do shifts instead | 18:04 |
| lkcl | yeah i shared some of them between modes | 18:04 |
| ghostmansd[m] | Yep | 18: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 |
| lkcl | well... ya know... ya have the bits all decoded | 18:06 |
| lkcl | i mean... it shouldn't be... | 18:06 |
| lkcl | 1 sec let me check satu/sats | 18:06 |
| lkcl | 'sv.extsw./satu/sz/dz/sm=r3/dm=r3 5, 31', | 18:07 |
| lkcl | works fine | 18:07 |
| lkcl | did you take out pack/unpack? | 18:07 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=917#c40 | 18:08 |
| ghostmansd | I mean the disassembly part | 18:09 |
| ghostmansd | The difficulties are when I reconstruct what was in assembly | 18:10 |
| lkcl | from that list - with known bits - it really should not be hard | 18:11 |
| lkcl | he said | 18:12 |
| lkcl | the only thing being, hmmm, *comparing* them will be tricky unless the ordering is strictly-defined | 18:13 |
| lkcl | i'd recommend lexicographical order | 18:13 |
| lkcl | qualifers.sort() | 18:13 |
| lkcl | "/".join(qualifiers) | 18:13 |
| lkcl | then anything in test_pysvp64dis.py is done - manually - in (same) lexicographical order | 18:14 |
| lkcl | elwidth should just be | 18:16 |
| lkcl | def specifiers(self): | 18:16 |
| lkcl | if self.elwidth > 0: | 18:16 |
| lkcl | yield "ew=%d" % (self.elwidth * 8) | 18:16 |
| lkcl | but | 18:16 |
| lkcl | bear in mind | 18:16 |
| lkcl | there's a sw= dw= and ew= | 18:17 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 18:17 | |
| lkcl | ew= is used to mean **BOTH** sw=dw=NN | 18:17 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 18:18 | |
| ghostmansd[m] | Yeah same as with zz/dz/sz | 18:19 |
| lkcl | sigh, how do you get at the values within Fields? | 18:19 |
| lkcl | how do you get the actual integer value? | 18:19 |
| lkcl | int(x)? | 18:19 |
| lkcl | yep that works | 18:19 |
| lkcl | urrr f****g things are MSB0-ordered, sigh | 18:20 |
| lkcl | got it | 18:21 |
| lkcl | at 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 |
| lkcl | ghostmansd[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 it | 18:23 |
| lkcl | ack | 18:23 |
| lkcl | but you get the idea | 18:23 |
| ghostmansd[m] | First of all, I'm doing ew now :-) | 18:23 |
| lkcl | :) | 18:23 |
| lkcl | well, that's the calculation (above) | 18:23 |
| ghostmansd[m] | Second, %d is totally allien on this PHP fest | 18:23 |
| ghostmansd[m] | Third, I'm not sure this is for BaseRM. some modes re-use fields from BaseRM. | 18:24 |
| lkcl | then 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 basis | 18:25 |
| ghostmansd[m] | Ok if there's a rationale | 18:25 |
| ghostmansd[m] | PHP hate is not a rationale | 18:25 |
| ghostmansd[m] | (I hate it too, though) | 18:25 |
| lkcl | yes there's a rationale. | 18:25 |
| lkcl | it's unreadable | 18:25 |
| ghostmansd[m] | We already discussed it, it's just an opinion | 18:26 |
| ghostmansd[m] | yield "ew=%d" % (8<<(3-int(self.elwidth))) is a piece of unreadable crap | 18:26 |
| ghostmansd[m] | See? This is a game for two! | 18:26 |
| lkcl | it's very clear - the format is on the left, the code is on the right | 18:28 |
| lkcl | you know that a decimal number is going into the format ("%d) | 18:28 |
| lkcl | it's compact and known for 30 years from c | 18:28 |
| ghostmansd[m] | That's also clear: it's string interpolation present in many languages, and even proposed to Python std library | 18:28 |
| ghostmansd[m] | And yes, it's known for years, too | 18:28 |
| ghostmansd[m] | Not everything I know from C deserves to be dragged | 18:29 |
| lkcl | being in multiple languages does not make it a good idea | 18:29 |
| ghostmansd[m] | It does compared to idea if Python was the only one | 18:29 |
| lkcl | if it is just as unreadable in those languages | 18:29 |
| ghostmansd[m] | Also, formatting multiple things makes the stuff even worse | 18:29 |
| lkcl | i did Zope/Plone programming back in 2000-2006 | 18:29 |
| lkcl | Zope/Plone attempted to copy the templating of PHP, by embedding python code into XML | 18:30 |
| lkcl | it was awful. | 18:30 |
| markos | Zope! oh the horrors! why did you bring these memories! | 18:30 |
| lkcl | i ended up maintaining some of the worst-written code i've ever seen | 18:30 |
| ghostmansd[m] | I don't know why you talk about PHP | 18:30 |
| lkcl | because it's exactly the same principle | 18: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 |
| lkcl | that's the fundamental deeply-flawed justification for creating nightmare scenarios | 18:31 |
| markos | isn't that what one of the js things do these days? | 18:31 |
| markos | keep forgetting the name | 18:31 |
| lkcl | it's exactly the same principle | 18:31 |
| ghostmansd[m] | And no, it's not like embedding code | 18:31 |
| markos | embed js into HTML | 18:31 |
| ghostmansd[m] | It's interpolation | 18:31 |
| lkcl | it's using eval() behind-the-scenes | 18:31 |
| ghostmansd[m] | If you use it for bad purposes, it's your fault | 18:31 |
| ghostmansd[m] | Like anything else in Python | 18:32 |
| lkcl | the fragments of code, which are in between curly-braces, are passed to eval() | 18:32 |
| lkcl | which is exactly the same principle used by PHP | 18:32 |
| lkcl | which was the exact same principle used by Zope/Plone | 18:32 |
| lkcl | it's all the same, and it's a total nightmare | 18:32 |
| ghostmansd[m] | Well this is interpolation | 18:32 |
| ghostmansd[m] | Again: this is a personal opinion | 18:32 |
| lkcl | if you look at the source code of python, i can pretty much guarantee 100% that they call the eval() function | 18:33 |
| ghostmansd[m] | If you want to deal with it — fine, add it to guidelines and format the code | 18:33 |
| ghostmansd[m] | I won't waste time on this. At all. | 18:33 |
| lkcl | if you can at least keep eval()ed expressions out of the format strings that will help | 18:33 |
| ghostmansd[m] | It won't make it non-evaluatable. | 18:34 |
| lkcl | as 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 |
| lkcl | i know - but it's a reasonable compromise to keep to... | 18:34 |
| lkcl | yes, which i am not happy about in the least | 18:34 |
| ghostmansd[m] | This is a kind of cargo cult like "goto is harmful" | 18:35 |
| lkcl | particularly when if you want to ... | 18:35 |
| ghostmansd[m] | Or "use tabs" | 18:35 |
| lkcl | it's about readability. | 18:35 |
| lkcl | goto isn't harmful | 18:35 |
| ghostmansd[m] | Yes, and readability is somewhat personal. | 18:35 |
| lkcl | it saves hugely on if/else-nesting on error-handling | 18: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 |
| lkcl | they're something i learned 28 years ago and haven't forgotten | 18: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 |
| lkcl | i actually have to look up what the fuck some of the hex format-string fuckwittery is | 18:36 |
| lkcl | i've read a lot of linux kernel source code, it's a really good example of how to use goto correctly | 18: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 |
| lkcl | which is precisely where the nightmare comes in. | 18:37 |
| lkcl | pleaes | 18:37 |
| ghostmansd[m] | My point is not about that. | 18:37 |
| lkcl | don't put code into format-strings | 18:37 |
| lkcl | i can't read it. | 18:37 |
| ghostmansd[m] | Sigh | 18:37 |
| ghostmansd[m] | OK I will use variables. | 18:37 |
| ghostmansd[m] | But. | 18:38 |
| ghostmansd[m] | I won't stop using the f strings per se. | 18:38 |
| lkcl | i'm fine with that | 18:38 |
| lkcl | what i'm going to put is that use of format-strings is frowned on | 18:38 |
| markos | ghostmansd, 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 better | 18:38 |
| lkcl | but is recognised as useful if the arguments are repeated | 18:38 |
| lkcl | if you have 12 "%s" four of which are repeated *that* gets to be a total nightmare | 18: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 |
| markos | ghostmansd, yes, cleanup is the main argument in favour of goto, and still there are other ways | 18: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 |
| lkcl | it's unmaintainable because i can't read it | 18: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 right | 18:45 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 18:46 | |
| markos | ghostmansd, 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 in | 18:46 |
| markos | wtf has happened | 18:46 |
| ghostmansd[m] | Yes, that's exactly what I said | 18:46 |
| ghostmansd[m] | Luke has this right | 18:46 |
| markos | we don't have to agree | 18:46 |
| markos | or share the same opinion, but it is what it is | 18:47 |
| ghostmansd[m] | So I don't see anything unfair here: I explicitly told he can impose it. | 18:47 |
| lkcl | basically... embarrassed/uncomfortable as i am with it, i'm the one whose time is precious when it comes to reviewing | 18:47 |
| ghostmansd[m] | I said that I wouldn't like it and won't waste my time on converting it manually. | 18:47 |
| lkcl | if i can't read it, then that's a serious problem | 18: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 |
| octavius | lkcl, 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 |
| lkcl | octavius, brilliant | 18:54 |
| ghostmansd[m] | So I prefer to surrender, I don't think this discussion is worth the efforts I'm putting here. | 18:54 |
| lkcl | ghostmansd[m], i'm keenly conscious/aware of time. do the best you can | 18:59 |
| lkcl | octavius, ok the pinset information is far easier. it's self-describing. | 18:59 |
| lkcl | jtag already has direction/type | 19:00 |
| lkcl | * means bi-directional | 19:00 |
| lkcl | - is in | 19:00 |
| octavius | I know lkcl | 19:00 |
| lkcl | + is out | 19:00 |
| lkcl | < is tri-state | 19:00 |
| lkcl | so 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 all | 19:00 |
| lkcl | and the record layouts don't have to be created, or if they are they're created from the IOType | 19:01 |
| octavius | Ok, 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 |
| lkcl | yes - the pad *numbering*, yes, which should be a key into the dictionary created/maintained by the class | 19:02 |
| lkcl | but if you can do it as a dict-of-dicts that's even better | 19:02 |
| lkcl | first dict, N/S/E/W | 19:02 |
| lkcl | second dict, 0/1/2/3/4/5 | 19:02 |
| lkcl | something like that | 19:02 |
| lkcl | (or, better, just match what the Pinouts dict does) | 19:03 |
| lkcl | just match exactly the Pinouts layout | 19:03 |
| lkcl | that way, "walking" is dead-easy | 19:03 |
| lkcl | ghostmansd[m], it's ok. | 19:04 |
| octavius | Ah yes | 19:04 |
| lkcl | i added (pushed) a new unit test sv.addi./ew=8 (and 16 and 32) | 19:04 |
| lkcl | which passes with the hack-job | 19: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 |
| lkcl | the "3-ew" is a weird trick that inverts the bit-order, i can't remember where i learned it from | 19:05 |
| ghostmansd[m] | Is it master? I think I might have some commits in dis beyond. | 19:06 |
| lkcl | 0123 becomes 3210 | 19:06 |
| lkcl | commit e07b6d38 | 19:06 |
| ghostmansd[m] | Ok will check | 19:06 |
| lkcl | i rebased master with vec2/3/4 already | 19:06 |
| lkcl | ghostmansd[m], mmode and mask should be easy | 19:07 |
| ghostmansd[m] | There's some confusion with sv_mode, mode and smmode/mmode | 19:08 |
| ghostmansd[m] | But I'll beat it I think | 19:08 |
| lkcl | mmode and mask are fixed (non-Mode-dependent) | 19:10 |
| lkcl | but smask (sigh) is dependent on... on... aaaagh | 19:10 |
| lkcl | RM-2P-1S1D/2S | 19:10 |
| lkcl | RM-2P-2S1D/1S2D/3S | 19:10 |
| lkcl | frickinell that's awful | 19:11 |
| lkcl | that's a candidate for being a column in the RM-*.csv files, that is | 19:11 |
| lkcl | from sv_analysis.py | 19:12 |
| lkcl | frick, frick frick, fricking frick | 19:25 |
| lkcl | the entire RM-2P-2S1D group has been classified as EXTRA3 | 19:25 |
| lkcl | ah hang on... it looks like (thank god) that group only has mtcrf in it | 19:27 |
| lkcl | whewww | 19:27 |
| lkcl | ghostmansd[m], i added a new csv column, SM - stands for "MASK_SRC" | 19:38 |
| lkcl | and associated power_enums.py SVmask_src | 19:39 |
| lkcl | otherwise you haven't a hope in hell of disassembling/detecting whether smask should be looked for | 19:39 |
| lkcl | ok to add it to power_insn.py? | 19:39 |
| 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 |
| lkcl | adding SVmask_src (right next to SVEtype) shouldn't conflict with that | 19: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 later | 19:41 |
| lkcl | are you altering any code with... ack | 19:41 |
| ghostmansd[m] | I still have a lot to do | 19:41 |
| ghostmansd[m] | We cannot put everything into BaseRM, some modes don't have some fields | 19: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 |
| lkcl | yehyeh | 19:42 |
| lkcl | watch out for some of the bits which change position. | 19:42 |
| lkcl | i tried avoiding that as much as practical | 19:42 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 19:42 | |
| ghostmansd[m] | ack | 19:43 |
| lkcl | ok done. very basic. no tests on it | 19:46 |
| lkcl | now it's possible to tell if "sm=" is even allowed | 19:47 |
| ghostmansd[m] | Perfect! | 19:48 |
| lkcl | just putting some comments in | 19:49 |
| ghostmansd[m] | About pack/unpack. Which of RM classes have it? | 19:49 |
| lkcl | absolutely none. | 19:49 |
| ghostmansd[m] | Cool, I'll drop these. | 19:49 |
| lkcl | already did | 19:49 |
| lkcl | git rebase | 19:49 |
| ghostmansd[m] | Oh this will be a difficult rebase :-) | 19:49 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=fb368245201d48c639548279e693b895e8571264 | 19:49 |
| lkcl | jooooy. sorry :) | 19:49 |
| lkcl | then i won't add comments (yet) into BaseRM | 19:50 |
| lkcl | because that would be a thorough pain | 19:50 |
| lkcl | there was going to be a hack/caveat on that, but i think even that's gone now | 19:51 |
| lkcl | yep i can revert it | 19:52 |
| *** octavius <octavius!~octavius@213.147.93.209.dyn.plus.net> has quit IRC | 20:01 | |
| ghostmansd[m] | No need | 20:01 |
| ghostmansd[m] | Incidentally I could rebase! | 20:01 |
| ghostmansd[m] | Likely because from diff point of view it was rather adding a new code | 20:01 |
| ghostmansd[m] | Despite that I only changed indent and names | 20:01 |
| ghostmansd[m] | Ok checking why Mapping[xxx] doesn't work as I expect | 20:03 |
| ghostmansd | Hm. For `sv.add./sats 0,1,2`, I get 0b00110 for RM.mode, but I'd have expected 0b10 somewhere. | 20:13 |
| ghostmansd | It's all over this shitty MSB0, eh? | 20:14 |
| ghostmansd | elif encmode == 'sats': | 20:17 |
| ghostmansd | saturation = 1 | 20:17 |
| ghostmansd | sv_mode = 0b10 | 20:17 |
| lkcl | ah no, the revert was in sv/trans/svp64.py - for adding sv.setvl/pack | 20:24 |
| lkcl | that had to go | 20:24 |
| lkcl | yeees, it's barse-ackwards-MSB0 | 20:25 |
| lkcl | irony is that actually MSB0 is natural left-to-right reading-order | 20:25 |
| lkcl | it's LSB0 that is, technically, for humans, "borked", because numbers are expressed in digits the wrong bloody way round! | 20:26 |
| lkcl | ghostmansd, | 20:29 |
| lkcl | File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/power_fields.py", line 169, in __len__ | 20:29 |
| lkcl | return self.__class__.__len__() | 20:29 |
| lkcl | TypeError: __len__() missing 1 required positional argument: 'self' | 20:29 |
| lkcl | bit more context | 20:30 |
| lkcl | File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/power_insn.py", line 1312, in specifiers | 20:30 |
| lkcl | if self.dz: | 20:30 |
| lkcl | File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/power_fields.py", line 169, in __len__ | 20:30 |
| lkcl | return self.__class__.__len__() | 20:30 |
| lkcl | TypeError: __len__() missing 1 required positional argument: 'self' | 20:30 |
| ghostmansd | hell, got lost somewhere in between rebases | 20:30 |
| ghostmansd | yeah, 1 sec | 20:30 |
| ghostmansd | hm... is it caled from test? | 20:30 |
| lkcl | yyep | 20:30 |
| ghostmansd | ah OK | 20:31 |
| lkcl | python3 src/openpower/sv/trans/test_pysvp64dis.py > /tmp/f | 20:31 |
| ghostmansd | should be better now, 3 failures with ew= | 20:32 |
| ghostmansd | it's not in branch yet, I've just rebased classes | 20:33 |
| lkcl | ack... checking... confirmed | 20:33 |
| lkcl | oh wait | 20:33 |
| ghostmansd | ? | 20:33 |
| lkcl | - sv.lfs *40,256(5) | 20:33 |
| lkcl | + sv.lfs/dz/sz *40,256(5) | 20:33 |
| lkcl | ? ++++++ | 20:33 |
| lkcl | FAIL: test_7_batch (__main__.SVSTATETestCase) [63:sv.lfs] | 20:33 |
| ghostmansd | 1 sec | 20:34 |
| ghostmansd | aha OK confirm | 20:35 |
| ghostmansd | so we don't have sz/dz specifiers? | 20:35 |
| lkcl | markos, you know about this page? https://libre-soc.org/task_db/mdwn/markos/ | 20:35 |
| lkcl | yees, but they're... 1 sec | 20:35 |
| lkcl | they're only enabled on predication | 20:35 |
| lkcl | but... | 20:35 |
| ghostmansd | Ah I guess it's not for these who have zz | 20:36 |
| lkcl | that'd be correct | 20:36 |
| lkcl | let's pick sv.lfs first | 20:36 |
| lkcl | 'sv.lfs/dz/sz *32,256(4)' | 20:36 |
| lkcl | that's a LD/ST-with-immediate Mode | 20:36 |
| lkcl | https://libre-soc.org/openpower/sv/ldst/ | 20:37 |
| lkcl | section 4, that's "zz" | 20:37 |
| lkcl | class LDSTImmSimpleRM(LDSTImmBaseRM): | 20:38 |
| lkcl | """ld/st immediate: simple mode""" | 20:38 |
| lkcl | mode is 5-bit | 20:38 |
| ghostmansd | yep | 20:38 |
| lkcl | the specifiers "sz" and "dz" are banned, it should be zz | 20:39 |
| ghostmansd | dz and sz are aliases | 20:39 |
| lkcl | but *reading* is... yes | 20:39 |
| ghostmansd | I thought to re-use them later... | 20:39 |
| lkcl | but now i am suspecting that sv/trans/svp64.py is wrong, here | 20:39 |
| ghostmansd | I guess we shouldn't output them in specifiers though | 20:39 |
| ghostmansd | But what to output, then? | 20:39 |
| lkcl | no, it should definitely be zz | 20:39 |
| lkcl | because it's a mistake in sv/trans/svp64.py to allow sz/dz | 20:40 |
| ghostmansd | I We don't even have zz in pysvp64asm | 20:40 |
| lkcl | which, argh, is probably the source of the mistake | 20:40 |
| lkcl | yes. | 20:40 |
| lkcl | sigh | 20:40 |
| lkcl | frick | 20:40 |
| ghostmansd | OK, let's split these issues | 20:40 |
| ghostmansd | I'll drop aliases for dz/sz to zz | 20:40 |
| ghostmansd | (should I output /zz in specifiers?) | 20:41 |
| lkcl | nono, don't drop the aliases, they're useful | 20:41 |
| lkcl | yes, output /zz as the specifier | 20:41 |
| lkcl | only | 20:41 |
| lkcl | zz: BaseRM.mode[3] | 20:41 |
| lkcl | correct | 20:41 |
| lkcl | dz: BaseRM.mode[3] | 20:41 |
| lkcl | sz: BaseRM.mode[3] | 20:42 |
| lkcl | correct. | 20:42 |
| lkcl | | --- | --- |---------|--------------------------- | | 20:42 |
| lkcl | | 00 | 0 | dz els | normal mode | | 20:42 |
| lkcl | | 00 | 1 | dz shf | shift mode | | 20:42 |
| lkcl | WRONG | 20:42 |
| lkcl | in sv/trans/svp64.py | 20:42 |
| ghostmansd | I looked in the docs | 20:42 |
| lkcl | yep that's good | 20:42 |
| ghostmansd | Do you refer to comment in pysvp64asm? | 20:43 |
| lkcl | i'm fixing svp64.py | 20:43 |
| ghostmansd | Ah OK that's a relief | 20:43 |
| lkcl | yes it's wrong | 20:43 |
| lkcl | can you tell me easily, is "zz" mode[3] in all cases? | 20:44 |
| ghostmansd | Nope | 20:45 |
| lkcl | frick | 20:45 |
| ghostmansd | Sometimes it's BaseRM[6] | 20:45 |
| ghostmansd | cr_ops | 20:45 |
| ghostmansd | 1 sec | 20:45 |
| lkcl | ahh yeah | 20:45 |
| lkcl | i'm ignoring that for now | 20:46 |
| ghostmansd | https://libre-soc.org/openpower/sv/cr_ops/ | 20:46 |
| lkcl | haven't implemented any sv.crops at all | 20:46 |
| ghostmansd | I pushed zz changes but it won't help the test | 20:47 |
| ghostmansd | We'll simply have /zz instead of /dz/sz | 20:47 |
| lkcl | yes which is really weird' | 20:48 |
| ghostmansd | And I guess it's again due to MSB0, but still no idea why | 20:48 |
| lkcl | do you have a repro case on the dump? | 20:48 |
| ghostmansd | Because I should've indexed SelectableInt by the span | 20:48 |
| lkcl | an 'echo \xnnnnn | pysvp64dis'? | 20:48 |
| ghostmansd | 00 20 40 05 00 01 04 c1 | 20:48 |
| ghostmansd | 1 sec | 20:48 |
| ghostmansd | echo -en "\x00\x20\x40\x05\x00\x01\x04\xc1" | pysvp64dis | 20:49 |
| lkcl | ack | 20:49 |
| ghostmansd | I wasn't aware you already did an alias to pysvp64dis :-) | 20:50 |
| lkcl | RM.zz | 20:50 |
| lkcl | 0 | 20:50 |
| lkcl | 11 | 20:50 |
| lkcl | :) | 20:50 |
| lkcl | is there a __bool__() method added to Field()? | 20:50 |
| lkcl | if self.zz == 0b1 would do it | 20:50 |
| ghostmansd | nope, there's none | 20:51 |
| lkcl | that's probably why then | 20:51 |
| ghostmansd | ah so it's always True | 20:51 |
| lkcl | it's going "is the length of self.zz equal to zero?" | 20:51 |
| ghostmansd | fuck why do they do it in Python? | 20:51 |
| lkcl | it's a precedence thing | 20:51 |
| ghostmansd | 1 sec | 20:51 |
| ghostmansd | I'll add boolean to all of them | 20:51 |
| lkcl | if there's no __bool__ method then "you must want an iterator, check the length" | 20:51 |
| lkcl | which should be "is the underlying integer value non-zero" | 20:52 |
| ghostmansd | btw I recently discovered yet another magical method | 20:52 |
| ghostmansd | __index__ | 20:52 |
| lkcl | oo much joy | 20:52 |
| lkcl | o dear | 20:52 |
| ghostmansd | it makes crap work with bin, hex, oct, and some other stuff | 20:52 |
| ghostmansd | I even wasn't aware | 20:52 |
| ghostmansd | only found when I defined __int__ and assumed "hey, now bin() will work" | 20:53 |
| ghostmansd | nope | 20:53 |
| ghostmansd | not at all! | 20:53 |
| ghostmansd | then I googled and found they invented yet another magic | 20:53 |
| lkcl | fer f'ss sake :) | 20:53 |
| lkcl | i do wish they'd stop fuckign around with python | 20:53 |
| lkcl | there's a point at which you have to actually *stop* adding features | 20:54 |
| ghostmansd | nope, I guess they don't have such limits | 20:54 |
| ghostmansd | but I suspect this stuff is really old | 20:54 |
| ghostmansd | I mean, __index__ | 20:54 |
| ghostmansd | just not that many idiots like me want to call hex() on object directly | 20:55 |
| * lkcl snort | 20:55 | |
| ghostmansd | OK the error with zz is gone, nice catch | 20:55 |
| ghostmansd | at least on echo | 20:55 |
| ghostmansd | checking test | 20:55 |
| lkcl | okaaay we're getting somewhere | 20:55 |
| lkcl | AssertionError: 'sv.add./ew=8 *3,*7,*11' != 'sv.add./sz *3,*7,*11' | 20:55 |
| lkcl | - sv.add./ew=8 *3,*7,*11 | 20:55 |
| lkcl | ? ^^^^ | 20:55 |
| lkcl | + sv.add./sz *3,*7,*11 | 20:55 |
| lkcl | that's worth ignoring for now :) | 20:56 |
| lkcl | almost | 20:56 |
| lkcl | 1 sec | 20:56 |
| ghostmansd | I guess the problem has to do with span | 20:57 |
| ghostmansd | and how bits lay there in practice | 20:57 |
| ghostmansd | there are three points: Mapping, Field and Reference | 20:57 |
| * lkcl compiling sv.add./ew=32 *3,*7,*11 | 20:58 | |
| lkcl | 4: 15 12 01 7c add. r0,r1,r2 | 20:59 |
| lkcl | echo -n -e '\xe0\x34\x44\x05\x15\x12\x01\x7c' | pysvp64dis -v | 20:59 |
| lkcl | and we get... | 21:00 |
| lkcl | RM.elwidth=01 [12,13] | 21:00 |
| lkcl | RM.ewsrc=00 [14,15] | 21:00 |
| lkcl | RM.mode=00000 | 21:00 |
| lkcl | RM.smask=111 [24,25,26] | 21:00 |
| lkcl | RM.dz=0 [11] | 21:00 |
| lkcl | RM.sz=0 [12] | 21:01 |
| lkcl | arse. wrong one. | 21:01 |
| lkcl | sv.add/ew=8 was the one that was incorrect | 21:01 |
| lkcl | oh that's interesting in its own right | 21:01 |
| lkcl | ahhh you see? | 21:01 |
| lkcl | RM.elwidth=[****12****,13] | 21:02 |
| lkcl | RM.sz= [*****12*****] | 21:02 |
| lkcl | overlap | 21:02 |
| lkcl | off-by-one | 21:02 |
| lkcl | but where... | 21:02 |
| ghostmansd | 1 sec | 21:02 |
| ghostmansd | yep I see this overlap | 21:05 |
| ghostmansd | checking the sources | 21:05 |
| ghostmansd | likely I fucked up at RM classes | 21:05 |
| lkcl | RM.mode | 21:06 |
| lkcl | 00000 | 21:06 |
| lkcl | 27, 28, 29, 30, 31 | 21:06 |
| lkcl | that can't be right and RM.dz be bit 11 at the same time | 21:06 |
| ghostmansd | so it's normal simple | 21:07 |
| lkcl | yep. | 21:07 |
| lkcl | well let's assume they're correct relative to the 32-bit | 21:08 |
| ghostmansd | In this sense we should be fine I think | 21:08 |
| lkcl | it would mean that RM.dz should be.... 30? yes. | 21:09 |
| lkcl | and RM.sz should be bit... 31 | 21:09 |
| lkcl | 27 28 29 30 31 | 21:09 |
| lkcl | 0 1 2 3 4 | 21:09 |
| lkcl | 000dz szsimple mode | 21:09 |
| ghostmansd | 'mode': Mode({'_': Field(19, 20, 21, 22, 23)}) | 21:09 |
| lkcl | so dz = bit 30 | 21:09 |
| ghostmansd | this is from BaseRM, before remapping | 21:10 |
| ghostmansd | I guess fine here | 21:10 |
| lkcl | i am looking at the output from the echo command above | 21:10 |
| lkcl | RM.mode | 21:10 |
| lkcl | 00000 | 21:10 |
| lkcl | 27, 28, 29, 30, 31 | 21:10 |
| lkcl | RM.dz | 21:10 |
| lkcl | 0 | 21:10 |
| lkcl | 11 | 21:10 |
| lkcl | RM.sz | 21:10 |
| lkcl | 0 | 21:10 |
| lkcl | 12 | 21:10 |
| ghostmansd | yep, RM.mode is fine | 21:11 |
| ghostmansd | sz is fucked | 21:11 |
| ghostmansd | I guess __getitem__ on field side... | 21:11 |
| ghostmansd | or, rather, at FieldMeta | 21:11 |
| lkcl | joy | 21:11 |
| lkcl | sz: BaseRM.mode[4] | 21:13 |
| lkcl | should be | 21:13 |
| lkcl | sz:BaseRM.remap(range(4))? | 21:14 |
| ghostmansd | nope, that's one bit | 21:14 |
| ghostmansd | Ah you mean remap | 21:15 |
| lkcl | yes | 21:15 |
| ghostmansd | I guess the problem is that it's relative to Mode | 21:15 |
| lkcl | yes | 21:15 |
| ghostmansd | and, well, for Mode, when we access it... | 21:15 |
| ghostmansd | we have (0, 1, 2, 3, 4) | 21:15 |
| ghostmansd | and this is in fact correct | 21:15 |
| ghostmansd | 1 sec | 21:16 |
| ghostmansd | hm dz: BaseRM.mode[3] | 21:17 |
| ghostmansd | sz: BaseRM.mode[4] | 21:17 |
| ghostmansd | cocojumbo: BaseRM.mode | 21:17 |
| ghostmansd | 'dz': Mode(3,), 'sz': Mode(4,), 'cocojumbo': Mode({'_': Field(19, 20, 21, 22, 23)) | 21:18 |
| ghostmansd | So the error is in the code which does __getitem__ | 21:18 |
| lkcl | which should be 27, 28, 29, 30, 31 | 21:18 |
| ghostmansd | it's before remap | 21:18 |
| lkcl | wtf? | 21:18 |
| lkcl | i get: | 21:18 |
| lkcl | RM.coco | 21:18 |
| lkcl | 00000 | 21:18 |
| lkcl | 27, 28, 29, 30, 31 | 21:18 |
| ghostmansd | yeah | 21:18 |
| ghostmansd | that's because you look at RM class | 21:19 |
| ghostmansd | not BaseRM | 21:19 |
| lkcl | ngggggh | 21:19 |
| ghostmansd | I look at the BaseRM class because error happens here | 21:19 |
| ghostmansd | dz: BaseRM.mode[3] | 21:19 |
| lkcl | class NormalSimpleRM(NormalBaseRM): | 21:19 |
| lkcl | dz: BaseRM.mode[3] | 21:19 |
| lkcl | sz: BaseRM.mode[4] | 21:19 |
| lkcl | coco: BaseRM.mode | 21:19 |
| ghostmansd | Ah yes, fuck | 21:20 |
| ghostmansd | hang on | 21:20 |
| * lkcl drink!!! | 21:20 | |
| lkcl | https://www.youtube.com/watch?v=2TQuacxEjAU | 21:21 |
| ghostmansd | yep the issue is in mapping | 21:21 |
| ghostmansd | class Mode(_Mapping): | 21:21 |
| ghostmansd | _: _Field = range(0, 5) | 21:21 |
| ghostmansd | We have this field | 21:21 |
| ghostmansd | Then we remap it mode: Mode.remap(range(19, 24)) | 21:22 |
| ghostmansd | But, when we do dz: BaseRM.mode[3], the operator does the wrong thing | 21:22 |
| ghostmansd | and uses range(0, 5) as stuff to check | 21:22 |
| ghostmansd | not the stuff after remap | 21:22 |
| ghostmansd | but the original range | 21:22 |
| ghostmansd | lol | 21:23 |
| ghostmansd | this code is totally incorrect | 21:23 |
| * lkcl ngggggh | 21:24 | |
| ghostmansd | 'dz': Field(22,), 'sz': Field(23,), 'gg': Mode({'_': Field(19, 20, 21, 22, 23)})}) | 21:24 |
| ghostmansd | OK should be fine now, but assumes that at least this class or some of its parents defined _ field which enlists the whole mapping | 21:25 |
| ghostmansd | luckily for us, the code already has this dependency | 21:25 |
| ghostmansd | 1 sec, need to check on real example | 21:25 |
| lkcl | totally cheating, i like it :) | 21:25 |
| ghostmansd | pushed | 21:26 |
| ghostmansd | now back to this insn | 21:27 |
| lkcl | RM.dz | 21:27 |
| lkcl | 0 | 21:27 |
| lkcl | 30 | 21:27 |
| lkcl | RM.sz | 21:27 |
| lkcl | 0 | 21:27 |
| lkcl | 31 | 21:27 |
| lkcl | hooray | 21:27 |
| lkcl | echo -n -e '\xe0\x34\x44\x05\x15\x12\x01\x7c' | pysvp64dis -v | 21:27 |
| ghostmansd | metaclasses are a real creep | 21:27 |
| lkcl | okaay so /dz and /sz have disappeared | 21:27 |
| lkcl | - sv.add./ew=8 *3,*7,*11 | 21:27 |
| lkcl | ? ----- | 21:27 |
| lkcl | + sv.add. *3,*7,*11 | 21:27 |
| lkcl | this is good | 21:27 |
| ghostmansd | sats still doesn't work | 21:28 |
| lkcl | gimme sec to add an example / check | 21:28 |
| ghostmansd | echo -ne "\x06\x00\x40\x05\x15\x12\x01\x7c" | pysvp64dis | 21:29 |
| ghostmansd | this should've been sv.add./sats 0,1,2 | 21:29 |
| lkcl | ok let me add that to the tests, to check | 21:29 |
| lkcl | sat,sat,where the hell is sat... | 21:29 |
| ghostmansd | Hm it thinks it's parallel reduce mode... | 21:30 |
| lkcl | RM.mode | 21:30 |
| lkcl | 00110 | 21:30 |
| lkcl | 27, 28, 29, 30, 31 | 21:30 |
| ghostmansd | and it should've been recognized as saturation | 21:30 |
| lkcl | # for "normal" arithmetic: https://libre-soc.org/openpower/sv/normal/ | 21:30 |
| lkcl | | 0-1 | 2 | 3 4 | description | | 21:30 |
| lkcl | | 10 | N | dz sz | sat mode: N=0/1 u/s | | 21:31 |
| ghostmansd | yep | 21:31 |
| ghostmansd | back to MSB0 :-) | 21:31 |
| lkcl | nhhhh | 21:31 |
| ghostmansd | we need to make the code behave like spec | 21:31 |
| lkcl | sv/trans/svp64.py... | 21:32 |
| ghostmansd | cf select function | 21:32 |
| lkcl | elif encmode == 'satu': | 21:32 |
| lkcl | assert sv_mode is None | 21:32 |
| ghostmansd | elif rm.mode[0:2] == 0b10: | 21:32 |
| lkcl | sv_mode = 0b10 | 21:32 |
| ghostmansd | if self.subvl == 0b00: | 21:32 |
| ghostmansd | rm = rm.sat | 21:32 |
| ghostmansd | yehyeh | 21:32 |
| ghostmansd | I know on pysvp64asm things are great :-) | 21:32 |
| lkcl | i'm not assuming that, at all! | 21:32 |
| ghostmansd | this line rm.mode[0:2] == 0b10: | 21:32 |
| ghostmansd | doesn't work | 21:32 |
| ghostmansd | no I think the code there is correct | 21:33 |
| ghostmansd | well, constant matches | 21:33 |
| ghostmansd | so we could only lose at shift... | 21:33 |
| lkcl | RM.mode = 00110 isn't correct, i don't believe | 21:33 |
| lkcl | it should be... 10 0 0 0 | 21:34 |
| ghostmansd | yep, I think too | 21:34 |
| lkcl | where the hell 00110 came from i have no idea | 21:34 |
| ghostmansd | but mode is calculated as mode |= sv_mode | 21:34 |
| lkcl | yehyeh | 21:34 |
| ghostmansd | I guess that's where we should have got 0b10 | 21:35 |
| * lkcl head-banging but gently because it's 21:35 here | 21:35 | |
| *** lxo <lxo!~lxo@linux-libre.fsfla.org> has joined #libre-soc | 21:35 | |
| ghostmansd | 23:35 here :-) | 21:36 |
| ghostmansd | 1 sec, I'm adding prints to pysvp64asm | 21:36 |
| ghostmansd | I have one cheat! | 21:36 |
| lkcl | :) | 21:36 |
| lkcl | mode 19-23: 0b110 | 21:37 |
| lkcl | frick. | 21:37 |
| lkcl | that's in LSB0 order | 21:38 |
| lkcl | effin frick. | 21:38 |
| lkcl | ahh you said sats not satu | 21:39 |
| lkcl | satu i get | 21:39 |
| lkcl | mode 19-23: 0b10 | 21:39 |
| lkcl | so it's getting mode[2] correct at least | 21:39 |
| ghostmansd | https://pastebin.com/xXCBf4mM | 21:40 |
| ghostmansd | feel free to ignore all but .normal | 21:40 |
| ghostmansd | that's the whole dump of svp64 instruction from pysvp64asm | 21:40 |
| lkcl | can you commit that as a test program somewhere? | 21:41 |
| lkcl | it's really useful to be able to run | 21:41 |
| ghostmansd | SVP64.prefix.rm.normal.sat.mode 00110 (27, 28, 29, 30, 31) | 21:41 |
| lkcl | i mean, "the way it's generated"? | 21:41 |
| ghostmansd | ah | 21:41 |
| ghostmansd | yep | 21:41 |
| lkcl | yep i know what's wrong | 21:41 |
| ghostmansd | 1 sec, it was print instead of log | 21:41 |
| lkcl | doesn't matter | 21:41 |
| lkcl | print is good | 21:41 |
| ghostmansd | but beware, it's mixed with SelectableInt stuff | 21:42 |
| ghostmansd | a _lot_ | 21:42 |
| lkcl | doesn't matter, i found myself needing it yesterday | 21:42 |
| ghostmansd | pushed | 21:42 |
| ghostmansd | dis branch as usual | 21:42 |
| ghostmansd | this is actually a very simple and short | 21:43 |
| ghostmansd | when you traverse the mapping you get for all fields the path, the value and the span | 21:43 |
| ghostmansd | I use it lot, just mostly not on the whole SVP64 instruction | 21:43 |
| ghostmansd | because there it's barely readable | 21:43 |
| ghostmansd | SVP64.prefix.rm.normal.sat.mode 00110 (27, 28, 29, 30, 31) | 21:44 |
| ghostmansd | I could have understood if it was at least 0b00101 | 21:45 |
| lkcl | mode 19-23: 0b10100 | 21:45 |
| lkcl | 0: 14 00 40 05 .long 0x5400014 | 21:46 |
| lkcl | 4: 15 12 01 7c add. r0,r1,r2 | 21:46 |
| lkcl | y", line 1359, in specifiers | 21:46 |
| lkcl | if self.sat: | 21:46 |
| lkcl | AttributeError: 'NormalSaturationRM' object has no attribute 'sat' | 21:46 |
| lkcl | ha! | 21:46 |
| lkcl | :) | 21:46 |
| lkcl | echo -ne "\x14\x00\x40\x05\x15\x12\x01\x7c" | pysvp64dis -v | 21:46 |
| lkcl | progress | 21:46 |
| ghostmansd | I don't quite get what you do :-) | 21:47 |
| lkcl | try that echo | 21:47 |
| ghostmansd | ah right | 21:47 |
| ghostmansd | should've been N | 21:47 |
| lkcl | echo 'sv.add./sats 0,1,2' | pysvp64asm | 21:47 |
| ghostmansd | sigh | 21:47 |
| lkcl | git rebase first | 21:48 |
| lkcl | or git pull master | 21:48 |
| ghostmansd | pushed | 21:48 |
| * lkcl rerunning all tests | 21:48 | |
| lkcl | 14 00 40 05 sv.add./sats r0,r1,r2 | 21:49 |
| lkcl | 15 12 01 7c | 21:49 |
| lkcl | haaaa | 21:49 |
| ghostmansd | Aaaaah | 21:49 |
| lkcl | RM | 21:49 |
| lkcl | normal: sat mode: N=0/1 u/s, SUBVL=1 | 21:49 |
| ghostmansd | so it was on pysvp64asm, after all | 21:49 |
| lkcl | RM.N | 21:49 |
| lkcl | 1 | 21:49 |
| lkcl | 29 | 21:49 |
| lkcl | yep. | 21:49 |
| lkcl | which may - or may not - completely bollox things up. have to see | 21:49 |
| ghostmansd | I pushed the fix for N too | 21:49 |
| ghostmansd | let me rebase master | 21:49 |
| ghostmansd | ? | 21:49 |
| ghostmansd | I'm two commits beyond | 21:50 |
| lkcl | i think this is the first time anything other than mode[0:1] has been non-zero | 21:50 |
| lkcl | ack | 21:50 |
| ghostmansd | *ahead | 21:50 |
| ghostmansd | lol | 21:50 |
| ghostmansd | can you run the tests? | 21:50 |
| ghostmansd | with the recent | 21:50 |
| ghostmansd | 1 sec, pushing | 21:50 |
| lkcl | scalar-reduction which i implemented is also 00 in mode[0:1] | 21:50 |
| lkcl | yep on it | 21:50 |
| ghostmansd | pushed | 21:50 |
| ghostmansd | team work! | 21:51 |
| lkcl | :) | 21:51 |
| ghostmansd | kinda have an impression we're doing paired programming | 21:51 |
| lkcl | urrrr reminds me of university... | 21:51 |
| ghostmansd | ah, my university had Latin instead, lol | 21:51 |
| ghostmansd | so I only became aware of paired programming at work | 21:52 |
| ghostmansd | OK this also means binutils are affected too | 21:52 |
| ghostmansd | yet another reason to use the generated fields | 21:52 |
| ghostmansd | yeah finally I got sats! | 21:53 |
| ghostmansd | stands for SATisfactory resultS | 21:53 |
| ghostmansd | OK I guess I surrender for today :-) | 21:54 |
| lkcl | :) | 21:54 |
| lkcl | yeah it's late enough | 21:54 |
| ghostmansd | thank for your help! | 21:54 |
| lkcl | nicely done | 21:54 |
| lkcl | ge | 21:54 |
| ghostmansd | gn, will continue tomorrow | 21:54 |
| lkcl | nightman | 21:54 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 21:59 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!