| ghostmansd[m] | lkcl, I'll fix power_decoder and CSVs | 08:37 |
|---|---|---|
| ghostmansd[m] | lkcl, could you, please, clarify, how I should edit CSV? | 08:42 |
| ghostmansd[m] | Mmm... I guess I should add a leading 0 bit to opcode, since we now have 1 more bit? | 08:47 |
| ghostmansd | lkcl, I've raised https://bugs.libre-soc.org/show_bug.cgi?id=838, could you, please, tune it appropriately? I have no idea of what should the parent task be, the budget, and likely the files list is not exhaustive. | 08:54 |
| ghostmansd[m] | lkcl, I've pushed the changes to CSV and power_decoder, please check these when you have time. I'm not sure of CSVs, but, as you told it was broken anyway, so, hey, it won't break more, I hope. | 08:59 |
| lkcl- | ghostmansd[m], yes, one more bit on each. | 11:09 |
| lkcl- | i think we can probably justify it as a binutils task by writing a unit test that cross-checks that instructions get correctly decoded by both | 11:17 |
| lkcl- | firstly, binutils should always produce the same binary as svp64.py | 11:17 |
| lkcl- | secondly, disassembly should always produce the same assembly mnemonic | 11:18 |
| ghostmansd | Ah, so you suggest to make it kinda static analyzer, and limit it to checking svp64.py vs sv_binutils.py? | 11:21 |
| ghostmansd | I've been thinking of some test which is run as pre-hook... | 11:21 |
| lkcl- | sort-of: i'm suggesting that as part of testing binutils, part of that testing be against svp64.py and oh look, we happened to solve the problem of consistency along the way | 11:22 |
| ghostmansd | Also if you make it binutils-related task I guess we're hitting the limits of 550. I think moving towards prefix-based encoding for magic insn deserves more, based on what I saw this will need more time. | 11:22 |
| lkcl- | i increased the budgets accordingly | 11:23 |
| ghostmansd | Ah well, missed it | 11:23 |
| lkcl- | only just did it 2-3 mins ago | 11:24 |
| ghostmansd | Well, for binutils, they know nothing of our machinery, yet have their own way of testing I'm aware of | 11:24 |
| lkcl- | yes, but there's a transition between use of svp64.py and binutils that needs to be confirmed | 11:24 |
| ghostmansd | They can take a list of instructions and compare the expected objdump output (regex support is present) | 11:24 |
| lkcl- | via unit tests | 11:24 |
| lkcl- | that are under our control not theirs | 11:25 |
| ghostmansd | Ah, so you suggest some test which takes svp64.py, sv_binutils.py, and checks that they match, right? | 11:25 |
| lkcl- | and binutils | 11:25 |
| ghostmansd | Or, perhaps, rather cloning binutils and applying our generator | 11:25 |
| lkcl- | svp64.py and binutils and everything and checks that they're consistent | 11:25 |
| ghostmansd | Yeah, that's what I've been thinking, yep | 11:25 |
| ghostmansd | Yeah, that'd be the best I think | 11:26 |
| lkcl- | and along the way in the middle of that, the issues you raised in #838 happen to get fixed / taken care of | 11:26 |
| ghostmansd | I think feeding some insns (perhaps randomized?) to both svp64.py and augmented binutils should be OK | 11:27 |
| lkcl- | i'm guessing amounts here, just let me know if you think more is needed. there's up to another EUR 5,000 (from 577) which can go towards this | 11:27 |
| lkcl- | yes randomised | 11:27 |
| ghostmansd | e.g. we generate insns we want to check, then feed this to (svp64.py + vanilla PPC gas) and (SVP64 gas) | 11:28 |
| lkcl- | but also i suggest full-loop on all values on individual fields whilst others are held either at a fixed value or are randomised | 11:28 |
| ghostmansd | then, for each of these, we have binary files | 11:28 |
| ghostmansd | and these can be compared | 11:28 |
| lkcl- | not nested for-loops though | 11:28 |
| lkcl- | for i in range(32) field.RA = i field.RB = random() field.etc = fixed -> test | 11:29 |
| lkcl- | then | 11:29 |
| lkcl- | for i in range(32) field.RA = random() field.RB = i field.etc = something -> test | 11:29 |
| ghostmansd | Why not nested? For each RA check each RB? | 11:29 |
| ghostmansd | Performance? | 11:29 |
| lkcl- | well for small fields, nested would be fine | 11:30 |
| lkcl- | 32x32 = 1024 tests | 11:30 |
| lkcl- | but for 3-operands that's 32x32x32 = 32768 unit tests | 11:30 |
| lkcl- | which for a single instruction starts to get a bit much | 11:31 |
| ghostmansd | We'll feed the entire list anyway... I guess we can even generate the whole listing with even all insns. | 11:31 |
| ghostmansd | Not necessarily all potential values, sure | 11:31 |
| ghostmansd | Some corner cases plus randomized, perhaps we don't need to e.g. check all 5 consecutive bits | 11:31 |
| lkcl- | but i think it's important to have each *individual* field go through all potential values | 11:31 |
| lkcl- | i've encountered bugs in e.g. signed/unsigned immediates | 11:32 |
| ghostmansd | https://pastebin.com/7h9PBWzm | 11:32 |
| lkcl- | but, sigh, there, 15-bit immediate or 16-bit immediate is going to be too much | 11:32 |
| ghostmansd | Something like this I wanted to use for testing grev* | 11:32 |
| ghostmansd | So a lot of nested loops, but it ended up as a big list of insns run as a single test | 11:33 |
| lkcl- | yes kept short enough like that is great | 11:33 |
| lkcl- | but it doesn't quite give the coverage. | 11:33 |
| lkcl- | ah i know | 11:33 |
| lkcl- | 1<<i | 11:33 |
| lkcl- | for i in range(width(RA)): | 11:33 |
| ghostmansd | So to check bit dicplacement | 11:34 |
| ghostmansd | Yeah | 11:34 |
| lkcl- | for j in range(width(RB) | 11:34 |
| ghostmansd | displacement | 11:34 |
| lkcl- | ... | 11:34 |
| lkcl- | RA=1<<i, RB=1<<j | 11:34 |
| lkcl- | it won't catch things with signed/unsigned immediates | 11:35 |
| ghostmansd | This can be added as non-randomized I think | 11:36 |
| ghostmansd | These are corner cases | 11:36 |
| ghostmansd | Well, the above is not randomized too | 11:36 |
| ghostmansd | Let's say there can be parts generated and parts which are "manual" | 11:36 |
| ghostmansd | BTW we must also provide tests for binutils, at least in form "assemble and compare the binary", just like I did for draft instructions. | 11:57 |
| ghostmansd | So new insns (svshape, svremap, etc.) plus many prefixed insns. | 11:58 |
| lkcl- | ghostmansd, test_caller_setvl.py no longer works | 11:58 |
| ghostmansd | I'll check and fix it | 11:59 |
| ghostmansd | It's again the opcodes? | 11:59 |
| * lkcl- investigating by going back a bit | 11:59 | |
| lkcl- | generally, commits should only be pushed when unit tests (existing or added) have been run | 12:00 |
| lkcl- | especially on something this low-level | 12:00 |
| ghostmansd | I admit, my bad. I thought that you forgot svp64.py. :-( | 12:00 |
| ghostmansd | Perhaps we can revert it for a while? | 12:00 |
| lkcl- | yep i leave it with you to deal with | 12:01 |
| ghostmansd | reverted so that nobody's blocked :-) | 12:04 |
| ghostmansd | I'll check and complete it. It's good to debug into it anyway, I guess it will make clearer how things work. | 12:05 |
| ghostmansd | But later, have to leave for a while. | 12:05 |
| lkcl- | ack | 12:11 |
| Veera[m] | lkcl-: Hi, is there some work for me! | 12:35 |
| lkcl- | Veera[m], hi, nice to see you back, yes i can think of something | 12:51 |
| lkcl- | perhaps you could help ghostmansd with the unit tests we're planning? | 12:52 |
| lkcl- | and there's always more diagrams :) | 12:52 |
| lkcl- | i just need to work out which budget those can go under | 12:52 |
| Veera[m] | lkcl-: that will be nice! both! | 12:54 |
| lkcl- | ok i found one that it can go under | 12:56 |
| lkcl- | and i added you to this cc https://bugs.libre-soc.org/show_bug.cgi?id=838 | 12:56 |
| lkcl- | Veera[m], ok the diagrams on here https://bugs.libre-soc.org/show_bug.cgi?id=839 | 13:01 |
| lkcl- | those need doing as SVG. i have a 3rd one TODO | 13:01 |
| josuah | thank you for this! https://libre-soc.org/docs/gtkwave_tutorial/ | 17:05 |
| josuah | I could not get glscopeclient working on OpenBSD, and editing signals in the GUI at every change became painful | 17:06 |
| cesar | josuah: Thanks for the feedback! Nice to see that my little tool is being useful. | 17:16 |
| josuah | cesar: that is perfect! with this I can have one .py file per "debug view" I need, and have the makefile generate the .gtkw on-demand: | 17:56 |
| josuah | .SUFFIXES: .py .gtkw | 17:56 |
| josuah | .py.gtkw: | 17:56 |
| josuah | python $< $* | 17:56 |
| josuah | wave: $W.gtkw simulation.vcd | 17:56 |
| josuah | ${GTKWAVE} -a $W.gtkw simulation.vcd | 17:56 |
| josuah | then if I run: $ make wave W=wb_spi | 17:57 |
| josuah | it opens the debug view (wb_spi.py calling write_gtkw) I prepared for the wb_spi part of the project | 17:58 |
| josuah | and with: $ make wave | 17:58 |
| josuah | it opens the default debug view (that I set in default.py) | 17:59 |
| josuah | I will use it every day! | 17:59 |
| lkcl- | josuah, that's a neat way to use it | 18:40 |
| ghostmansd | `opint=True, bitsel=(0, 5), suffix=None, subdecoders=[]` | 19:52 |
| ghostmansd | lkcl, how does it work with bitsel? | 19:53 |
| ghostmansd | because, well, I think I found the culprit | 19:53 |
| ghostmansd | https://pastebin.com/9fw0QivT | 19:54 |
| ghostmansd | cf. (setvl (XO + Rc)) and (svshape (XO))) | 19:55 |
| ghostmansd | sorry, not XO, but PO | 19:57 |
| ghostmansd | no, XO :-) | 19:59 |
| ghostmansd | so you can have 0b000001 for _both_ setvl. (XO=0b00000, Rc=0b1) _and_ svshape (XO=0b00001) | 19:59 |
| ghostmansd | either I miss something, or this is fundamentally broken | 19:59 |
| ghostmansd | and we have to choose another XO or use another PO (not 22) for either of them | 20:00 |
| lkcl- | ghostmansd, right, yes. a "-" needs to be in the bit that must be ignored / not-be-matched-against | 23:07 |
| lkcl- | which means changing the format to... | 23:08 |
| * lkcl- searches... | 23:08 | |
| lkcl- | see minor_5.csv | 23:08 |
| lkcl- | or minor_63.csv | 23:08 |
| lkcl- | drop the "0b" in front and for setvl and svshape instead of | 23:09 |
| lkcl- | setvl=0b00000 extended to 6-bit 000000 | 23:09 |
| lkcl- | it would be | 23:09 |
| lkcl- | 00000- | 23:09 |
| lkcl- | then even though bitsel=(0,6) | 23:10 |
| lkcl- | bit zero will be *ignored* as far as matching is concerned because bit zero is "-" | 23:10 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!