Wednesday, 2022-08-17

lkcleek! yes SelectableInt is pretty fundamental, has to be some care taken there00:22
lkclsuch as:00:22
lkclpython3 decoder/isa/ >& /tmp/f00:22
lkcl    return FieldSelectableInt(si=instance, br=self.__field).asint(msb0=True)00:23
lkcl  File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/", line 139, in asint00:23
lkcl    bit =[key].value00:23
lkclAttributeError: 'NoneType' object has no attribute 'value'00:23
lkclmissed a bit00:25
lkcl    yield from self.translate_one(insn)00:25
lkcl  File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/sv/trans/", line 879, in translate_one00:25
lkcl    svp64_rm.extra3[idx].eq(00:25
lkcl  File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/", line 487, in __get__00:25
lkcl    return FieldSelectableInt(si=instance, br=self.__field).asint(msb0=True)00:26
lkcl  File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/", line 139, in asint00:26
lkcl    bit =[key].value00:26
lkclAttributeError: 'NoneType' object has no attribute 'value'00:26
lkclok br is being set to a dict (not to a BitRange)00:54
lkcl-        cls.__fields = dict(map(field, fields.items()))00:54
lkclthis ensured that the values of the fields were either a SelectableInt or a slice()00:55
lkclinstead what is being passed through to SelectableInt.__getitem__() is a tuple00:55
lkcli've committed some debug-log messages (and an assert) showing where the error ends up00:57
programmerjake...why type assertions are useful...01:04
lkclye, but you go to such an extreme jacob that it becomes massively irritating and literally doubles the size of the code01:06
lkclmaking it unreadable in the process01:06
lkclthis particular code relies on type-detection in its arguments - __getattr__ must receive only either another SelectableInt or a slice01:07
lkcland for some [as yet unknown] reason it's been passed a tuple01:08
lkclit's quite a complex piece of code, providing MSB0-ordering and bit-level-addressable sub-selection of an underlying MSB0-ordered number01:09
programmerjakethe lack of types my ide can figure out is massively irritating and doubles the time required to work on such code...e.g. most of the pipelining infrastructure01:17
lkclwe have gone over this ten, eleven, twelve, thirteen, fourteen times05:10
lkcli have *no problem* with you putting the required types into a .pyi file that is for your own convenience05:10
lkcland even committing that to the repositories05:10
lkclas long as under no circumstances those types are added to any of the HDL05:11
programmerjakethat doesn't work very well...05:11
lkclwell why did you not mention that before??05:11
lkclthat is the first time you have ever responded and told me that05:12
programmerjakebecause I gave up...05:12
lkclif you don't tell me then we can't work something out05:12
lkcli assumed you were always using the .pyi files and were just ignoring me... because you didn't communicate that they weren't working well for you05:13
programmerjakeas you can see from the total lack of .pyi files and the nmigen type annotations repo having it's last commit years ago05:13
lkclhow am i in *any way* supposed to be able to deduce that?05:14
lkclcome on, jacob05:14
lkcli am not in the least bit interested in using any kind of IDE or any form of mouse-assisted "hints"05:14
lkclso if i never use those tools, how am i supposed to "guess" that they're not working for you??05:15
lkcli have an ability to model most interactions (from doing remote debugging on mailing lists)05:15
programmerjakeadmittedly it took me several months to realize they don't work well, i only realized that gradually so there wasn't really a moment where I suddenly knew it wasn't working05:16
lkclbut that's impossible to do if i don't have *any* clue about how to use a tool05:16
programmerjakeso telling you didn't occur to me05:16
lkclwell, now you've told me. so that's good.05:16
lkcli find sometimes it takes a while for things to crystallise as well05:16
lkcli take it that's something to do with this?
programmerjakeone of the biggest reasons .pyi files don't work is because of the time cost of basically having to duplicate the whole public API and maintain it...also a .pyi file doesn't get used for type hinting in the file it's associated with, just when other code imports that file05:19
lkclah - that's different.05:20
lkclapparently pycharm can check05:21
programmerjakeafaict it does it basically the same way as vscode does -- which i'm using.05:27
programmerjakehi klys05:27
klys_just trying to grok what I'm reading here05:27
klys_"...just when other code imports that file"05:27
programmerjakeso if you have with type hints in a.pyi, the type hints are used in that imports a, but are not used when editing a.py05:28
klys_so something to do with the ide doesn't use the file you're working with?  mebby it's a naive assumption tho got to start somewhere05:29
programmerjakein particular that is the behavior of the mypy type checker last i checked05:29
klys_mypy, do you have a link to it?05:30
programmerjakewhich was used by vscode at the time05:30
programmerjakevscode has since changed to pyright, which is written in typescript05:30
klys_does pyright do type checking the same way, palpably?05:30
programmerjakei have no reason to expect pyright to behave differently05:31
klys_so, you aren't describing a bug in one of the above05:33
programmerjakenot afaict05:33
programmerjakethough, lemme check05:33
klys_would it offer some consolation to create a simple which imports a.pyi (or x.pyi, etc.) and then use with import o?05:36
klys_or does the python source you're working with mirror the type hints you're using?05:37
programmerjakethe python source mirrors the type hints because the type hints mirror the API of the source file05:38
klys_sorry I can't really double check as I don't have a local vscode05:38
programmerjakemypy and pyright can be used from the command line or other editors with LSP support (e.g. vim, emacs, eclipse, etc.)05:39
programmerjakemypy is used through pyls if you want LSP support05:40
klys_it's a didactic or textual issue, not a programming issue, if I am understanding it correctly05:40
programmerjakenot sure...05:41
klys_having to do with how you view and interface with your code in the ide, and having very little to do with compiled code05:42
programmerjakeno, mypy just doesn't use a.pyi when type checking, which makes writing code in a.pyi or more error prone05:44
klys_okay, thinking it's understood now, carry on!05:44
Veera[m]Hi, need help with coriolis06:25
Veera[m]cd alliance-check-toolkit/benchs/adder/cmos06:27
Veera[m]make lvx06:27
Veera[m]It is taking more than 2 hours in talos and still running06:27
Veera[m]web page says it will complete in 5mins!!!!06:27
Veera[m]does make lvx invoke GUI interface?06:28
Veera[m]bin/cougar -c -f chip_r chip_r_ext is running 100% cpu for 170mins!06:54
*** ghostmansd <ghostmansd!> has joined #libre-soc08:06
lkclklys_, ah! i've been trying to reach you for a few months - there is EUR available for you from NLnet08:14
lkclbut you have to submit a Request for Payment08:14
lkcli can't send it to you, myself (aside from anything i don't have your bank account details)08:15
lkclit's something like EUR 1,300 so is not an insubstantial amount08:17
lkclthe last email i sent you - i've not received a response to any of them - i said that if i do not hear from you i will have to assume that it's to be donated08:18
lkclwe have a deadline of beginning of October (about 7 weeks)08:19
lkclanything submitted after that we *lose the money entirely*08:19
ghostmansd[m]lkcl, thanks for debug! The tuple likely comes from one of the fields classes, I'll check it now.08:38
ghostmansdOK found the reason. Yeah, we have to differentiate a special case for multi-dimensioned fields, like extra2 and extra3.09:38
ghostmansdSince we cannot quickly guess if we have a tuple of bits or a tuple of tuples of bits, the implementation used a trick: we expressed a tuple of tuples as a dict of tuples.09:39
ghostmansdI forgot to port this to new implementation, so yeah, it was broken.09:39
ghostmansdNow I backported it. However, with this in mind: there better should have been some better way. I'm not doing it now due to time constraints. However, we should think of this hierarchy more.09:41
ghostmansdsrc/openpower/decoder/isa/ runs fine09:41
ghostmansdsrc/openpower/decoder/isa/ is fine, too09:42
ghostmansdLuke, I'm going to merge this to master, please let me know if there are other tests I might need to consider.09:42
ghostmansdmmmmm.... had you already merged it to master???09:43
ghostmansdah now, got confused by git log09:44
ghostmansdlkcl, how does one determine the function (LDST, BRANCH or whatever)?10:20
ghostmansdAh I think I know... src/openpower/decoder/
*** octavius <octavius!~octavius@> has joined #libre-soc10:39
octaviusMorning lkcl, seems you and dmitriy submitted RFPs for bug 884, can I do that as well?10:47
octaviusI haven't been introduced to the new hidden system10:47
octaviusAlso for bug 758 (pypowersim), you did quite a bit of work, so perhaps we should split that one?10:49
ghostmansdit looks like we'll need to generate some helper stuff to determine the opcode function11:57
ghostmansdand we need this to distinguish between NORMAL/LDST/BRANCH/CROP11:58
ghostmansdfor python code and pysvp64dis, this is simple: we now have insndb, and can loop through all entries and check the major opcode12:00
ghostmansdlike this:
ghostmansdor, well, rather this:
ghostmansdNah, why consider only major?
ghostmansdThis grabs the database entry based on the whole instruction.12:24
lkclghostmansd, brilliant.  that code's fast becoming voodoo-magic13:01
ghostmansdlkcl, you might opt checking pysvp64dis branch again :-)13:02
lkclon it...13:02
lkclahh good, subvl test passed13:02
ghostmansdI already adopted the insndb so that it can lookup the opcodes on its own13:02
ghostmansdso you can simply open the insndb, pass it an opcode and get the record13:03
lkclyes the unit is intended to tell you that.13:04
lkclwhich corresponds directly with which RM table to start from13:04
lkclyou can't only consider the MAJOR field.13:05
lkcl(EXTNNN bits 0-5)13:05
lkclit does have to also be the XO field13:06
lkcloctavius, yes of course 1 sec13:06
ghostmansdthe insndb comnsiders both13:06
ghostmansdthe opcode property is exactly the stuff we used in binutils13:06
ghostmansdthat is, it considers bitsels and is aware of both value and mask13:06
lkclgreat.  that will allow - PowerDecoder - to be done as a flat for-loop at some point instead of a hierarchical walk13:07
lkclthe only reason it's not a flat for-loop at the moment is precisely because there wasn't the pre-processing phase that is now in insndb13:08
lkcloctavius, i'm good. the idea is to get you some $.13:10
lkclSelectableInt should itself have its own unit test13:11
lkcland, err.. there isn't one for FieldSelectableInt, err...13:12
ghostmansdfor FieldSelectableInt there should be13:13
ghostmansdI certainly saw something in this regard13:13
lkclghostmansd, i'm going to run which is a big one and if that passes it runs so damn much it's ok13:13
lkclyep found it. duh13:14
ghostmansdCool! Cool cool cool.13:14
ghostmansd.llong 0x054000007c410214 # sv.add13:14
lkclgive it 25 mins or so13:14
ghostmansdGradually, slowly, step-by-step, but we're moving towards disassembly.13:14
ghostmansdI'll add the unit recognition now, since it affects anything we do upon decoding, and then continue moving with the rest of the bits.13:16
lkcli found a pep8 (>80chars) thing, committed.13:21
lkcl        if (not isinstance(value, int) or13:21
lkcl            (value < 0) or (value > ((1 << 32) - 1))):13:21
lkcl            raise ValueError(value)13:21
lkcli'm fussy about that because i have 12 to 14 80x65 xterms on-screen at once.13:21
lkclklys_, one of the reasons why i'm strict about code-density is because i have short-term memory problems / a type of learning/memorisation difficulty.13:22
lkclif the code's not in front of me (because i had to page-down page-up page-down page-up) i literally can't remember what i saw on the page-down in order to match it with the page-up13:23
lkcli therefore frequently have to open the same file *twice* (!) in neighbouring xterms13:23
lkclthen there's function definitions which get nested in complex code-bases like this, often to an "alarming" depth, for someone not used to this size of codebase13:24
ghostmansd[m]I don't really bother checking these now13:26
ghostmansd[m]That said, perhaps we could have a git hook?13:26
ghostmansd[m]So that the code is not pushed if it doesn't pass this limitation13:27
lkclbasically if you do a "git diff" before a commit and it overruns the 80-char terminal then that's a visual red flag13:29
lkclthat of course assumes that you're using 80xNN terminals13:29
ghostmansd[m]lkcl, I've been thinking, perhaps we could output the unit along with the rest of our desc in binutils?13:31
ghostmansd[m]Ah no, I guess this wouldn't help that much.13:31
ghostmansd[m]Or wait... together with the mask... yes it would.13:32
ghostmansd[m]We still have 15 unused bits in svp64_desc.13:33
ghostmansd[m]Function has 15 distinct values... So this needs 4 bits.13:34
ghostmansd[m]So yeah, I guess, we'll look the record based on opcode/mask, then check the function field (obviously we'll have different values, not the ones Function has).13:36
lkclghostmansd[m], passes (or, has the same errors it's had for the past few months)13:40
lkclso a merge is fine13:41
lkclFunction.. 1 sec... yyyeah... i'd make it 513:42
lkcli can foresee us adding 2 new pipeline types in the future.  3D, BITMANIP, other13:43
ghostmansd[m]Well if you extend this it'll be updated automatically13:43
ghostmansd[m]Because I made the code care of number of entries13:43
ghostmansd[m]And it calculates bits on its own13:43
lkclmm... true... which is... ok. yep.13:44
lkclyou use offsetof() and friends, right?13:44
lkclor... never mind, it'll be fine :)13:45
lkclhoo f****g rah it's actually rained for the first time in 10 weeks here13:45
lkclgrass in the park opposite had actually gone beyond yellow and was going white13:46
ghostmansd[m]Nope, I mean the generator code13:46
ghostmansd[m]When we take enum and convert it to field13:46
lkclignore me - i was wittering to myself13:46
ghostmansd[m]Ok :-)13:47
* lkcl head spinning, still haven't had time to do pack/unpack. dang13:47
*** ghostmansd <ghostmansd!> has quit IRC14:14
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC14:21
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc14:21
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC14:58
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc14:58
*** ghostmansd <ghostmansd!> has joined #libre-soc15:18
*** ghostmansd <ghostmansd!> has quit IRC15:25
*** ghostmansd <ghostmansd!> has joined #libre-soc15:26
ghostmansdprogrammerjake, lkcl, I wonder whether such statements are correct: rm_dec.rc_in.eq(rc_out)15:34
ghostmansdlkcl, I need few comments regarding everything since src/openpower/decoder/
ghostmansdmy question is, why don't we always use `fn = self.op_get("function_unit")`?15:42
ghostmansdThe function_unit for the records we handle at line 1039 should already have LDST in this case, doesn't it?15:45
ghostmansdI'm asking since I obtain _MORE_ records if I check for function_unit...15:45
ghostmansdThe`"functions` set ends up being larger than `opcodes`15:47
ghostmansdthe difference:
*** ghostmansd <ghostmansd!> has quit IRC15:55
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC16:07
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:09
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC16:25
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc16:26
*** tplaten <tplaten!> has joined #libre-soc16:28
lkclghostmansd[m], 1 sec on phone16:31
ghostmansd[m]no rush, take your time16:33
*** ghostmansd <ghostmansd!> has joined #libre-soc16:41
lkclfrickin ell that was a long call17:02
lkclokaay, right.17:04
lkclto explain what op_get() does: this is an instruction decoder17:04
lkclthere exists an override mechanism17:04
lkclwhere if there is an Illegal Instruction, we want to be able to execute a Trap instruction17:05
lkclthe easiest way to do that?17:05
lkcl... override the decoded instruction so that it *becomes* a trap instruction17:05
lkclah i just talked about do_get(), not op_get()17:06
lkclignore all that :)17:06
lkclop_get - you can see it is:17:06
lkcl    def op_get(self, op_field):17:06
lkcl        return getattr(self.op, op_field, None)17:06
lkclthis because PowerDecoder2 - like PowerDecoder - is *reconfigureable*17:07
lkclyou can create a PowerDecoder2 which deals with a *subset* of operations and thus has a *subset* of fields (by column) from the CSV files17:07
lkclthe reason is because if you decoded everything you end up with a mmmmaaaassssiiiivvve 300+ set of wires branching out to every single pipeline17:08
lkclquantity 15 (so far, and likely to be a lot more)17:08
lkclwhat you could do is17:08
lkclpass the instruction (qty 32 wires - 64 if SVP64) to those 15 pipelines, giving a much smaller fan-out17:09
lkcland have *satellite* decoders at the last minute17:09
lkcland that's why the entirety of PowerDecoder2 is so reconfigureable, and uses getattr(self.op, field_name, None)17:09
lkclgiven that i REMOVED the LD/ST-shift crap17:11
lkclthe override "is_major_ld" there can now *also* be removed17:11
lkclit was an "early notification" to the SVP64-side of the decoder (rm_dec.fn_in) to detect a LD/ST operation17:12
lkcli'll do that now17:12
*** ghostmansd <ghostmansd!> has quit IRC17:22
*** tplaten <tplaten!> has quit IRC17:26
lkclghostmansd[m], done;a=commitdiff;h=81e8161ab8656d1611493c323d319a03c4da748e17:28
lkclstrictly speaking the one further down - SVP64 FFT mode - should also not exist either17:29
ghostmansd[m]Perfect! Now this code really looks like what I expected. :-)17:30
lkclyes.  and also is in line with the spec saying "we DO NOT make different interpretations of 32-bit suffixes just because they are prefixed"17:30
lkcli mean, you can see the god-awful mess it makes17:31
lkclyou have to do a partial-detect of the operation17:31
lkclpass that to the SVP64.RM decoder17:31
lkclwhich then comes *BACK* to the PowerDecoder2 to tell you how to decode the 32-bit operation!17:32
lkclehhhmmmm... no.17:32
*** ghostmansd <ghostmansd!~ghostmans@> has joined #libre-soc17:42
*** ghostmansd <ghostmansd!~ghostmans@> has quit IRC18:34
*** ghostmansd <ghostmansd!> has joined #libre-soc18:55
ghostmansdLuke, recently I've been struggling why on regeneration of blobs do I have some instructions changed... and I found that some entries are duplicated.19:40
ghostmansdThe only difference I see is the opcode. Did you mean rldicl., with RC?19:41
ghostmansdSame with the rest of instructions here.19:42
ghostmansdAnother perfectly viable option is that I miss something. :-)19:42
ghostmansdNot blobs, C code.19:45
*** tplaten <tplaten!> has joined #libre-soc19:45
*** octavius <octavius!~octavius@> has quit IRC19:54
ghostmansdlkcl, here's what it takes to have a new enum in binutils:;a=commit;h=783d7c6c2ab159b4ca38d6fa6254697e8151939f20:18
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC20:23
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc20:26
ghostmansdHere's how we affect the code generation:
*** tplaten <tplaten!> has quit IRC20:33
ghostmansdlkcl, would it be difficult to allow FieldSelectableInt accept _another_ FieldSelectableInt?20:55
ghostmansdThis would help cases like FieldSelectableInt(insn.prefix.rm.mode, SVP64MODE.MOD2)20:56
ghostmansdHm. Since bit width of FSI is always len( One might refer to the same SI then, but just adjust the bits.20:58
ghostmansdOK yes, this seems to do the trick:;a=commit;h=58a4537b6fb0fff3d8ec156994d3b46f6b280ea621:18
ghostmansdHell I'm really surprised how many side work is there with binutils :-)21:19
ghostmansdStill, it seems this is highly re-usable, so I don't hesitate to do it21:19
lkclpffh that's so difficult, adding function.21:34
lkclhang on let's look at microwatt decode1.vhdl21:35
lkclhang on paul's done a redesign21:36
lkclok it should be converted to "000-"21:37
lkclmmm if fsi can take another fsi that's not exactly planned but it is not a surprise if it works21:39
lkclhorrendous in terms of resources....21:39
*** octavius <octavius!~octavius@> has joined #libre-soc21:50
ghostmansdNot really horrendous21:56
ghostmansdThey refer the same SI21:56
ghostmansdOny BR must be updated, but that's basically...21:56
ghostmansd+            for (i, v) in br.items():21:56
ghostmansd+                _br[i] =[v]21:56
ghostmansdcf. some recent commits; I supported further slicing for FSI21:58
ghostmansdAs result, we can do;a=commit;h=e5b39fe980824bee0aa478d3bb0257ee95c0754821:58
ghostmansdPerhaps we can even make it work on elaborate() side, with the caveat that it must be a thin wrapper capable of providing info for nmigen21:59
ghostmansdBut, at the same time, it should stay away from dependencies on nmigen22:00
ghostmansdIdeally, for binutils, this stuff should be generated, too22:00
ghostmansdAt least all these fields, etc.22:00
ghostmansdBut I don't have time to do it, so I'll simply repeat and adopt this code to C22:01
ghostmansdLikely it'll be not really readable, but at least it increases the chances to complete till October22:01
ghostmansdIn fact, we have so little time that I think I'll gradually populate binutils with the code too22:03
ghostmansdOK enough for today22:03
Veera[m]lkcl: I ran the bin/cougar is still running for 10 hrs. for cmos; make lvx it was running for 170mins instead of 5mins.22:07
Veera[m]lkcl: does powerpcle Talos capable of building coriolis22:08
*** octavius <octavius!~octavius@> has quit IRC23:09

Generated by 2.17.1 by Marius Gedminas - find it at!