Thursday, 2022-05-19

ghostmansd[m]lkcl, I'll fix power_decoder and CSVs08: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
ghostmansdlkcl, I've raised, 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 both11:17
lkcl-firstly, binutils should always produce the same binary as svp64.py11:17
lkcl-secondly, disassembly should always produce the same assembly mnemonic11:18
ghostmansdAh, so you suggest to make it kinda static analyzer, and limit it to checking vs
ghostmansdI'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 and oh look, we happened to solve the problem of consistency along the way11:22
ghostmansdAlso 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 accordingly11:23
ghostmansdAh well, missed it11:23
lkcl-only just did it 2-3 mins ago11:24
ghostmansdWell, for binutils, they know nothing of our machinery, yet have their own way of testing I'm aware of11:24
lkcl-yes, but there's a transition between use of and binutils that needs to be confirmed11:24
ghostmansdThey can take a list of instructions and compare the expected objdump output (regex support is present)11:24
lkcl-via unit tests11:24
lkcl-that are under our control not theirs11:25
ghostmansdAh, so you suggest some test which takes,, and checks that they match, right?11:25
lkcl-and binutils11:25
ghostmansdOr, perhaps, rather cloning binutils and applying our generator11:25 and binutils and everything and checks that they're consistent11:25
ghostmansdYeah, that's what I've been thinking, yep11:25
ghostmansdYeah, that'd be the best I think11:26
lkcl-and along the way in the middle of that, the issues you raised in #838 happen to get fixed / taken care of11:26
ghostmansdI think feeding some insns (perhaps randomized?) to both and augmented binutils should be OK11: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 this11:27
lkcl-yes randomised11:27
ghostmansde.g. we generate insns we want to check, then feed this to ( + 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 randomised11:28
ghostmansdthen, for each of these, we have binary files11:28
ghostmansdand these can be compared11:28
lkcl-not nested for-loops though11:28
lkcl-for i in range(32) field.RA = i  field.RB = random() field.etc = fixed -> test11:29
lkcl-for i in range(32) field.RA = random() field.RB = i field.etc = something -> test11:29
ghostmansdWhy not nested? For each RA check each RB?11:29
lkcl-well for small fields, nested would be fine11:30
lkcl-32x32 = 1024 tests11:30
lkcl-but for 3-operands that's 32x32x32 = 32768 unit tests11:30
lkcl-which for a single instruction starts to get a bit much11:31
ghostmansdWe'll feed the entire list anyway... I guess we can even generate the whole listing with even all insns.11:31
ghostmansdNot necessarily all potential values, sure11:31
ghostmansdSome corner cases plus randomized, perhaps we don't need to e.g. check all 5 consecutive bits11:31
lkcl-but i think it's important to have each *individual* field go through all potential values11:31
lkcl-i've encountered bugs in e.g. signed/unsigned immediates11:32
lkcl-but, sigh, there, 15-bit immediate or 16-bit immediate is going to be too much11:32
ghostmansdSomething like this I wanted to use for testing grev*11:32
ghostmansdSo a lot of nested loops, but it ended up as a big list of insns run as a single test11:33
lkcl-yes kept short enough like that is great11:33
lkcl-but it doesn't quite give the coverage.11:33
lkcl-ah i know11:33
lkcl-for i in range(width(RA)):11:33
ghostmansdSo to check bit dicplacement11:34
lkcl-    for j in range(width(RB)11:34
lkcl-            ...11:34
lkcl-              RA=1<<i, RB=1<<j11:34
lkcl-it won't catch things with signed/unsigned immediates11:35
ghostmansdThis can be added as non-randomized I think11:36
ghostmansdThese are corner cases11:36
ghostmansdWell, the above is not randomized too11:36
ghostmansdLet's say there can be parts generated and parts which are "manual"11:36
ghostmansdBTW 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
ghostmansdSo new insns (svshape, svremap, etc.) plus many prefixed insns.11:58
lkcl-ghostmansd, no longer works11:58
ghostmansdI'll check and fix it11:59
ghostmansdIt's again the opcodes?11:59
* lkcl- investigating by going back a bit11:59
lkcl-generally, commits should only be pushed when unit tests (existing or added) have been run12:00
lkcl-especially on something this low-level12:00
ghostmansdI admit, my bad. I thought that you forgot :-(12:00
ghostmansdPerhaps we can revert it for a while?12:00
lkcl-yep i leave it with you to deal with12:01
ghostmansdreverted so that nobody's blocked :-)12:04
ghostmansdI'll check and complete it. It's good to debug into it anyway, I guess it will make clearer how things work.12:05
ghostmansdBut later, have to leave for a while.12:05
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 something12: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 under12:52
Veera[m]lkcl-: that will be nice! both!12:54
lkcl-ok i found one that it can go under12:56
lkcl-and i added you to this cc
lkcl-Veera[m], ok the diagrams on here
lkcl-those need doing as SVG.  i have a 3rd one TODO13:01
josuahthank you for this!
josuahI could not get glscopeclient working on OpenBSD, and editing signals in the GUI at every change became painful17:06
cesarjosuah: Thanks for the feedback!  Nice to see that my little tool is being useful.17:16
josuahcesar: 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 .gtkw17:56
josuah        python $< $*17:56
josuahwave: $W.gtkw simulation.vcd17:56
josuah        ${GTKWAVE} -a $W.gtkw simulation.vcd17:56
josuahthen if I run: $ make wave W=wb_spi17:57
josuahit opens the debug view ( calling write_gtkw) I prepared for the wb_spi part of the project17:58
josuahand with: $ make wave17:58
josuahit opens the default debug view (that I set in
josuahI will use it every day!17:59
lkcl-josuah, that's a neat way to use it18:40
ghostmansd`opint=True, bitsel=(0, 5), suffix=None, subdecoders=[]`19:52
ghostmansdlkcl, how does it work with bitsel?19:53
ghostmansdbecause, well, I think I found the culprit19:53
ghostmansdcf. (setvl (XO + Rc)) and (svshape (XO)))19:55
ghostmansdsorry, not XO, but PO19:57
ghostmansdno, XO :-)19:59
ghostmansdso you can have 0b000001 for _both_ setvl. (XO=0b00000, Rc=0b1) _and_ svshape (XO=0b00001)19:59
ghostmansdeither I miss something, or this is fundamentally broken19:59
ghostmansdand we have to choose another XO or use another PO (not 22) for either of them20:00
lkcl-ghostmansd, right, yes.  a "-" needs to be in the bit that must be ignored / not-be-matched-against23:07
lkcl-which means changing the format to...23:08
* lkcl- searches...23:08
lkcl-see minor_5.csv23:08
lkcl-or minor_63.csv23:08
lkcl-drop the "0b" in front and for setvl and svshape instead of23:09
lkcl-setvl=0b00000 extended to 6-bit 00000023:09
lkcl-it would be23: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 2.17.1 by Marius Gedminas - find it at!