| ghostmansd[m] | Thanks programmerjake! I'll rebase the branch. | 04:53 |
|---|---|---|
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.32> has quit IRC | 05:26 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.173> has joined #libre-soc | 05:26 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.173> has quit IRC | 05:29 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.173> has joined #libre-soc | 05:30 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.173> has quit IRC | 05:35 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.116> has joined #libre-soc | 05:36 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.160.116> has joined #libre-soc | 05:55 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC | 06:16 | |
| *** rsc <rsc!~robert@fedora/rsc> has quit IRC | 06:16 | |
| *** rsc <rsc!~robert@linuxnetz.de> has joined #libre-soc | 06:17 | |
| *** rsc <rsc!~robert@fedora/rsc> has joined #libre-soc | 06:17 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc | 06:21 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.160.116> has quit IRC | 06:31 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.160.116> has joined #libre-soc | 06:48 | |
| *** ghostmansd|2 <ghostmansd|2!~ghostmans@176.59.174.124> has joined #libre-soc | 07:20 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.116> has quit IRC | 07:20 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.160.116> has quit IRC | 07:20 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.124> has joined #libre-soc | 07:21 | |
| *** ghostmansd|2 <ghostmansd|2!~ghostmans@176.59.174.124> has quit IRC | 08:23 | |
| *** Amare <Amare!~Amare@2402:d000:8114:342c:25c2:6bed:8a37:e5a0> has joined #libre-soc | 08:44 | |
| Amare | Hello all, I was wondering if there is a way to visualize verilog module level hierarchy. | 08:45 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.124> has quit IRC | 08:46 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:46 | |
| *** ghostmansd|2 <ghostmansd|2!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:59 | |
| programmerjake | I didn't see anything in yosys's manual... if your verilog is generated 100% from nmigen, you can grep it for the nmigen.heirarchy attribute (iirc) and use that to generate a directory structure that you can look at with filesystem tree utilities... something like: | 09:11 |
| programmerjake | tr '.' '/' < out.v | sed 's/^.*[ *]nmigen\/heirarchy *= *"\([^"]*\)".*/\1/p; d' | (mapfile -t a; for i in "${a[@]}"; do mkdir -p -- /tmp/heirarchy/"$i"; done) | 09:16 |
| Amare | thanks, I can try that. | 10:19 |
| *** ghostmansd|2 <ghostmansd|2!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 11:09 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC | 12:29 | |
| *** jn <jn!~quassel@ip-095-223-044-149.um35.pools.vodafone-ip.de> has joined #libre-soc | 12:29 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc | 12:29 | |
| *** ghostmansd|2 <ghostmansd|2!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 12:54 | |
| lkcl | Amare: a quick search online - https://metacpan.org/dist/Verilog-Perl/view/vhier | 13:19 |
| *** Amare <Amare!~Amare@2402:d000:8114:342c:25c2:6bed:8a37:e5a0> has quit IRC | 13:34 | |
| *** octavius <octavius!~octavius@131.147.93.209.dyn.plus.net> has joined #libre-soc | 13:59 | |
| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has joined #libre-soc | 14:06 | |
| ghostmansd|2 | folks, I'm looking at src/openpower/decoder/power_svp64_rm.py | 14:40 |
| lkcl | ghostmansd|2, yep, fun one that one | 14:40 |
| *** ghostmansd|2 is now known as ghostmansd | 14:40 | |
| ghostmansd | How does Signal work with If, Switch and Case? Where to read about it w/o too much low-level HW details? | 14:41 |
| lkcl | it's needed to extract all the fields into very simple one-signal-thing | 14:41 |
| lkcl | basically they're exactly as you'd expect. | 14:42 |
| ghostmansd | Assuming I already decoded Prefix and RM, I'd simply like to re-construct the string for objdump | 14:42 |
| lkcl | power_svp64_rm.py would not necessarily be a good place to start for that. | 14:43 |
| ghostmansd | Which'd be good? | 14:44 |
| lkcl | honestly i'd start from scratch but from those tables | 14:44 |
| ghostmansd | Because doing it vice versa from pysvp64asm is even worse. | 14:44 |
| lkcl | should i do one in python, first? | 14:45 |
| ghostmansd | I assumed we had something already :-) | 14:46 |
| lkcl | (aside from anything, it'd be a good way to discuss it) | 14:46 |
| lkcl | nope :) | 14:46 |
| ghostmansd | Well, not exactly for conversion to string... | 14:46 |
| ghostmansd | ...but, I mean, something that actually _decodes_. | 14:46 |
| lkcl | the closest i have is, after using PowerDecoder, printing out the instruction name/string, in ISACaller. | 14:46 |
| lkcl | and, hm, i think it goes to some lengths to add the "o" "." or "o." on the end | 14:47 |
| lkcl | but that's about it | 14:47 |
| lkcl | ah. | 14:47 |
| lkcl | right. | 14:47 |
| lkcl | actually, it uses PowerDecoder2. | 14:47 |
| lkcl | because PowerDecoder2 has to decode the register numbers | 14:48 |
| lkcl | and that's a whole bundle-o-joy on its own. | 14:48 |
| lkcl | there... miiight... be somewhere i did that manually... | 14:48 |
| ghostmansd | Well, instruction name, its operands, its prefix, suffix, and even RM, are already decoded in binutils. | 14:48 |
| ghostmansd | I'm kinda dubious how to move next, though. | 14:48 |
| lkcl | found them | 14:48 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/caller.py;h=e7476231273a6e4b6dc200c93da232056902653c;hb=fc28a2092354be8d7b6469f245fd3a22f8844c87#l403 | 14:49 |
| ghostmansd | I want to convert the uint64_t to struct svp64_ctx (the same structure we fill when assemble). | 14:49 |
| lkcl | you can see that is _supposed_ to be using PowerDecoder2 | 14:49 |
| lkcl | remember that the mode varies depending on the type of operation (the column with LDST, ALU, BRANCH, CR in it) | 14:51 |
| ghostmansd | Yeah the mode is the most complicated part. | 14:51 |
| lkcl | that's the first step. | 14:51 |
| ghostmansd | I recall we have 4 modes, and they affect the stuff a lot. | 14:52 |
| lkcl | totally. like, totally different. and LDST has two sub-modes, for immediate ops and indexed ops | 14:52 |
| * lkcl afk for half an hour | 14:53 | |
| ghostmansd | Speaking of say get_pdecode_cr_in... what do these yield statements do? | 14:57 |
| lkcl | you know how python generators work? | 15:50 |
| lkcl | you have a top-level for-loop "for something in some_function()" | 15:51 |
| lkcl | and the function "yields" the results that get passed, on each iteration, as "something" | 15:51 |
| lkcl | in this case however if you ignore the keyword "yield" entirely and just go-with-the-flow, it basically gets the value | 15:52 |
| lkcl | in1_sel = yield op.in1_sel "gets" the value stored in op.in1_sel and puts it into the local variable, in1_sel | 15:52 |
| lkcl | that's all there is to it | 15:53 |
| ghostmansd | Ah OK. I thought we had some nice coroutines there. | 16:02 |
| ghostmansd | OK, here we kinda switch the context and get the value, right? | 16:02 |
| ghostmansd | It's like "yield to where you were, say in the event loop, and return to this point when it yields" | 16:03 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 16:07 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.170.223> has joined #libre-soc | 16:08 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.170.223> has quit IRC | 16:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 16:24 | |
| lkcl | yes, basically. you may be interested/fascinated/horrified to know that javascript also has yield | 16:42 |
| ghostmansd | I'm reading the code but frankly it gives even less clues than the vice versa translation of svp64.py | 16:43 |
| ghostmansd | These Signal concepts and similar stuff kinda hides the low-level details. | 16:44 |
| ghostmansd | I understand it goes from execute_one() and follows to call(). But all these nmigen classes and attributes hide what happens. | 16:45 |
| ghostmansd | If these were just simple classes, present in the same repository, it'd have been simpler. :-) | 16:46 |
| ghostmansd | I'd rather prefer something obvious like SelectableInt[SOME_BIT_WE_NEED]... | 16:47 |
| ghostmansd | But OK, I'll handle it eventually. | 16:47 |
| ghostmansd[m] | I think the main problem is, I'm thinking in terms of standalone 64-bit instructions. And the code we have thinks of decoders. | 16:57 |
| ghostmansd[m] | That is, when I think of bit masks, shifts and similar stuff applied to 64-bit unsigned integer, what we have is a complex set of nested decoders. | 16:58 |
| lkcl | ISACaller has a Finite State Machine built-in, because it needs to do "stepping". | 17:06 |
| lkcl | consequently it is possibly about the worst thing you could look at to try to understand what the hell's going on | 17:07 |
| lkcl | to "understand" nmigen you need to appreciate that actually it is a compiler [language translator] | 17:07 |
| lkcl | all those assignments comb += something.eq(somethingelse) are actually creating Abstract Syntax Tree code-fragments! | 17:08 |
| lkcl | the nmigen Simulator "understands" those but leverages them in such a way that... get this: it is AST-walked to create a *fragment of python code* which is then eval()ed and then run! | 17:09 |
| lkcl | it's complicated for a reason. | 17:10 |
| lkcl | the nested decoders is basically equivalent to doing - in c - switch(major_opcode) { .... switch(XO) { } ... } | 17:11 |
| lkcl | at some point i'd like to flatten that to a single-level | 17:11 |
| lkcl | switch(major_opcode|XO} { ........... } | 17:11 |
| lkcl | (sotto voice basically using the mask/value you just created) | 17:12 |
| ghostmansd | I get the concept, my point is, the way binutils do it differs (and the way my mind works matches binutils) | 17:52 |
| ghostmansd | > consequently it is possibly about the worst thing you could look at to try to understand what the hell's going on | 17:53 |
| ghostmansd | But this is exactly the chunk you also pointed me to! :-) Well, you pointed me to the standalone functions there, but they're also called in the ISACaller context, and to understand these I also have to understand ISACaller. | 17:54 |
| ghostmansd | But, anyway, I'll perhaps stick to bit-level stuff for now. | 17:55 |
| lkcl | yes, but _only_ those functions :) | 18:10 |
| lkcl | oh, err, hang on, i realised that all those functions do is turn in1/in2/in3 into RA/RB/RC / FRA/FRB/FRC | 18:11 |
| lkcl | they still actually rely on PowerDecoder2, sigh | 18:12 |
| ghostmansd | yep :-) | 18:13 |
| ghostmansd | I think going backwards would be simpler, to be honest. | 18:13 |
| lkcl | i think it's probably a good idea to do a reverse of sv/trans/svp64.py | 18:14 |
| lkcl | in python | 18:14 |
| ghostmansd | Yep, mine impression too. | 18:14 |
| lkcl | then do binutils based on that | 18:14 |
| lkcl | one _should_ be possible to use to test the other | 18:14 |
| ghostmansd | But, since I really run out of time, I'm not sure whether to start with the Python... | 18:14 |
| ghostmansd | ...on the other hand, writing the code there is way simpler. | 18:15 |
| lkcl | i'll help | 18:15 |
| ghostmansd | I'm worrying about time constraints. In the beginning of October, the carriage turns back into the pumpkin. :-) | 18:16 |
| lkcl | heh :) | 18:16 |
| lkcl | well there is the cavatools grant, the MoU hasn't been agreed on that one | 18:16 |
| ghostmansd | But OK, you persuaded me. | 18:16 |
| ghostmansd | I also think that it should be Python first. | 18:16 |
| lkcl | so in theory it is possible to put in a reasonable (not-massive) budget there | 18:16 |
| ghostmansd | First, it's simpler to write. Second, it's simpler to follow the Python script to implement something in C. Third... we need it anyway. | 18:17 |
| ghostmansd | At least for X-testing purposes. | 18:17 |
| lkcl | i could probably justify up to... mm.... probably EUR 8k if it also included some of the scalar instructions | 18:17 |
| lkcl | yehyeh | 18:17 |
| ghostmansd | I'll start doing it. I hope it won't take that much time that binutils grant is lost. :-) | 18:18 |
| lkcl | well it's perfectly reasonable to include it *as* part of binutils | 18:18 |
| lkcl | but we're scraping the corners of different Grants now | 18:18 |
| lkcl | daaang pack/unpack is going to be complicated in ISACaller | 18:20 |
| ghostmansd | Nope, I mean, I hope that the task won't eat to much time and I'll be able to complete binutils. | 18:20 |
| lkcl | i've put in a second NLnet grant request for it | 18:20 |
| lkcl | plus, as i said, we can justify adding a budget to cavatools. | 18:21 |
| lkcl | cavatools is *not* EU Horizon 2020 | 18:21 |
| ghostmansd | So other stuff also turned out to be more difficult, right? | 18:21 |
| lkcl | pack/unpack - hell yes. basically the order of the subvl/vl for-loops swaps *dynamically* | 18:21 |
| lkcl | and of course it's a Finite State Machine | 18:22 |
| ghostmansd | Since I already found myself hitting the wall several times, I kinda worried if it's my personal problem... :-) | 18:22 |
| lkcl | he, no :) | 18:22 |
| lkcl | this stuff really is... comprehensive | 18:22 |
| ghostmansd | sigh, yeah | 18:22 |
| ghostmansd | OK, let us have pysvp64disasm | 18:23 |
| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has quit IRC | 18:23 | |
| lkcl | i'm considering whether to extract the for-looping into a completely separate function that actually just calculates the src/dst-step (and subvl-src/dst-step) right there, right then | 18:23 |
| lkcl | and then ISACaller just enumerates through it in a mechanical by-rote fashion | 18:24 |
| lkcl | works for me | 18:24 |
| ghostmansd | ISACaller is kinda the heart of this | 18:26 |
| ghostmansd | I still recall how difficult it was to even make some mixins work with it | 18:26 |
| ghostmansd | I mean those helpers from the code generation | 18:27 |
| ghostmansd | So yeah, I understand how difficult refactoring there could be | 18:27 |
| lkcl | well it helps that i wrote it and have it semi-memorised | 18:34 |
| lkcl | and also wrote most of the words in the spec | 18:35 |
| lkcl | but i believe i may be overthinking the complexity, as it really is just "do some for-loops, drop the indices into a list" then "use that list in ISACaller" | 18:36 |
| lkcl | where that falls over - argh - is if SVSTATE is changed. | 18:36 |
| lkcl | argh | 18:36 |
| lkcl | yep, it's complicated :) | 18:36 |
| *** ibot` <ibot`!~supybot@libre-soc.org> has joined #libre-soc | 19:34 | |
| *** ibot <ibot!~supybot@libre-soc.org> has quit IRC | 19:34 | |
| *** octavius <octavius!~octavius@131.147.93.209.dyn.plus.net> has quit IRC | 20:00 | |
| ghostmansd | Drop a stub for pysvp64dis. Currently it only can read some binary file, get instructions and make a wild binutils-like guess whether the instruction is prefixed or not. | 20:31 |
| ghostmansd | *Dropped | 20:32 |
| ghostmansd | I'll switch it to SelectableInt, for now shifts are to simplify quick checks on my local laptop. | 20:32 |
| lkcl | ack | 20:44 |
| ghostmansd[m] | Migrated to SelectableInt, will continue tomorrow | 21:10 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 22:00 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 22:00 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 22:34 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 22:34 | |
| *** octavius <octavius!~octavius@131.147.93.209.dyn.plus.net> has joined #libre-soc | 23:04 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 23:17 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 23:18 | |
| *** octavius <octavius!~octavius@131.147.93.209.dyn.plus.net> has quit IRC | 23:53 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!