Sunday, 2022-01-16

lkclmikolajw, have a look through soc and nmutil you will find literally dozens of examples of how to use Record16:04
lkclthe function make_wb_layout() is a good one16:04
lkclyou do not have to "sub-class" Layout, it's probably not a good idea16:04
lkclwhitequark has a habit of using if type(obj) == ClassName instead of "if isinstance(obj, ClassName)" which interferes with sub-classing16:05
lkclstdcx. now setting CR0 correctly16:32
lkclthat means spinlocks should work16:33
lkclmikolajw, doh, i meant octavius :)16:47
lkcloctavius, there's tons of examples.  this one is "sophisticated" by nmigen standards16:48
octaviusThanks, I was just trying to find some now16:48
lkclbecause the parameters to make_wb_layout() adjust the Record created from it16:48
lkclfind . -name "*.py" | xargs grep Record16:48
octaviusOh yeah XD16:49
lkclRecordObject btw is a little more sophisticated16:49
lkclyou create like you'd expect: a class with Signals and other RecordObjects in its constructor16:49
octaviusI noticed DIR_FANOUT, is it really for specifying the fanout? I would've thought that would be specified by the node16:50
lkclsurpriiise, it creates the Record layout automatically for you, through introspection16:50
lkclignore it entirely16:50
lkcldon't bother - don't use it16:50
lkclthe direction is automatically detected based on usage16:50
octaviusSo when creating a record class, you can use either tuples or lists, and each tuple/list only contains the signal name and its size?16:51
lkclthe nice thing is, nmigen squashes it down, linearly, as if it was a sequence of bits16:51
lkcli recommend you don't sub-class Record16:51
octaviusSo I shouldn't create a Record?16:51
lkcluse the same trick as make_wb_layout16:52
lkclyou said "record class"16:52
lkclnot "record instance"16:52
lkclcreating a "Record class" implies "creating a subclass of Record"16:52
lkclwhich i do not recommend16:52
lkclif you meant, "so when creating a Record *instance*"....16:52
octaviusres in that case is just a tuple, I thought you needed to create a class inhereting Layout, and then a class inhereting Record16:52
lkclneither of those things are required.16:53
octaviusSo it's just a list then?16:53
lkcland subclassing Layout as i said above may actually interfere16:53
lkclno, it's not a list16:53
octaviusbut it has []16:53
lkcla Record instance contains Signals [and other Records] that as far as nmigen is concerned are "like a sequence of bits"16:54
lkclwhere is the list?16:54
lkclthat's just the layout16:54
lkclwhen passed as the "layout=res" argument to Record, Record knows what to do.16:55
lkclyou should have the source code of nmigen open and be looking at it, right now16:55
lkcldon't ever assume that nmigen is a "black box"16:55
lkclyour *immediate* reaction should be to find and open the source code of *anything* that you are going to use16:55
lkclrun "ctags -R" in the top-level directory then ":tag Record" <return>16:56
lkclthat will take you to the first [tagged] instance of "anything named Record"16:56
lkclif its' not the one you want type ":tn" (tag next)16:56
lkclfor example obviously you don't want this one16:57
lkclthat's the old "compatibility" layer16:58
lkclah ha!16:58
lkclfirst argument is typecast to a Layout with "Layout.cast"16:59
lkcl 127         self.layout = Layout.cast(layout, src_loc_at=1 + src_loc_at)16:59
octaviusRunning "ctags -R" within the nmigen top dir give me no results16:59
lkcl[you should be doing this automatically btw. it should be second-nature]16:59
lkclls -altr16:59
lkcl-rw-r--r-- 1 lkcl lkcl 413184 Jan 16 16:59 tags17:00
lkclnow run "vi"17:00
lkcland type ":Record"17:00
lkclemacs also supports tags but i don't know the commands so can't advise17:00
octaviusopening tags within vi, I can use /Record to find it, but :Record doesn't work (it's not a normal function of vi is it?)17:01
lkclsorry, ":tag Record"17:01
lkclthen ":tn" to jump to the 2nd occurrence17:02
lkclyou can also put the cursor on a word and use "Ctrl-]" and it will jump to the definition17:02
lkclextremely useful17:03
lkcl":e #" will get you back to the file you were previously editing, if that definition is in a totally different file (fairly normal)17:03
octaviusOk, my brain's fried XD I run off vimtutor, so I never really delved beyond that. I'll look at Record then.17:05
lkclbasically Record's 1st argument can either be a list or it can be a Layout that's constructed *from* a list17:06
lkclyou therefore *do not* need to create a Layout instance, just pass in a list comprising what layout you want.17:06
lkclit's all much much simpler than you're imagining it is17:06
lkclhence the crispiness :)17:06
lkclokaaay about the 30th linux-5.7 simulation underway, this one now have LR/SC and the MMU microwatt unit tests passing17:12
lkclso stands a reasonable chance of progressing to an actual boot prompt17:12
lkclsome time in the next 60 hours, mind17:12
lkclghostmansd[m], i know it's a pain to have to focus on optimisation at an early stage of code being developed20:46
lkclbinutils unfortunately has such a massive amount of processing to do, on such large files, that its efficiency, both in terms of memory used and the time taken, both matter20:47
lkcli can pretty much guarantee that when submitted upstream we'll be requested to redo anything that's sub-optimal20:48
lkclperhaps it would be a good idea to ask on binutils-dev for a review and for some guidance?20:49
ghostmansd[m]lkcl, I'm totally open to discussion, feel no pain at all :-)20:52
ghostmansd[m]My point is that we have no more than 8 bytes per PPC entry20:52
ghostmansd[m]Because I had pointers in mind, not 64-bit entries20:52
ghostmansd[m]And, once we keep pointer to svp64_entry in powerpc_opcode, it doesn't really matter that much how we organize svp64_entry20:53
ghostmansd[m]Because, well, we have only about 300 of those20:53
lkclthat's why i did the back-of-envelope calculations about 3 weeks back, it's only around 60 bits and that's confirmed by the struct20:53
lkclno, there would be (10,000-300) NULL pointers and 300 entries20:54
lkclwhich, remember, every single instruction in an assembly listing would result in double-lookup20:54
lkclcausing L1 cache fragmentation20:54
ghostmansd[m]You don't need to lookup20:54
lkclde-referencing the pointer ==> "a lookup"20:55
lkclthat's a double lookup which will jump the L1 cache to a 2nd location, causing L1 cache fragmentation20:56
ghostmansd[m]That, unlike real lookup optimization, sounds like premature one20:56
lkclit's exactly the sort of thing that a review on submission to binutils-dev will flag up20:56
lkclif there was *any reason* why more than 64 bits of information was required, i would immediately agree with you20:57
ghostmansd[m]I know about caches. My point is, how do you really care? You miss cache lines before, because you compare insn above.20:57
ghostmansd[m]You're not in hot cache at all there.20:57
lkclbecause there would be a justification for saying, on review, by the binutils-dev team, "sorry, this is going to require more info in future therefore it will need to be a pointer"20:57
lkclthey might then ask instead, "would QTY 2 64-bit values be ok instead"20:58
lkclthere's two phases.20:58
lkclfirst phase:20:58
lkcl* creating the table (filling in the values).  this is unavoidable20:58
lkclsecond phase:20:58
lkcl* actually running and translating (potentially millions to hundreds of millions to billions of assembly lines)20:59
lkclthat 2nd phase is where this really, really matters20:59
ghostmansd[m]The whole code above deals with text processing until it looks up some entries. The text resides in one part of the memory, then you go to hash table which resides in another one. At this point, when you reach hash, one dereference hardly matters.20:59
ghostmansd[m]Because you already have cache miss.21:00
lkclmmm true.21:00
ghostmansd[m]We can do it21:00
ghostmansd[m]That's no problem :-)21:00
ghostmansd[m]If you insist, I'm OK21:01
ghostmansd[m]I simply want to explain the rationale21:01
ghostmansd[m]But I'm not a lunatic21:01
programmerjakesee my comments on the bug...if it's not public API -- just refactor if/when you run out of doesn't matter much that you'd have to move fields to behind a pointer when you refactor. meanwhile just inline fields to avoid indirection.21:01
lkcli'm more comfortable with using macros/bits, particularly after seeing them in the original binutils code.21:01
ghostmansd[m]Even for macros, there's a point: principle of the least surprise is a totally valid argument.21:01
ghostmansd[m]Yep, that's what I'm saying21:02
ghostmansd[m]I also use masks and shifts since it's semantic is less, mmm, fragile, especially way more for network programming :-)21:02
ghostmansd[m]Where bitfields are simply non-option21:02
lkclyehyeh. i did the network reverse-engineering for samba nmbd and DCE/RPC, 20-25 years ago21:03
programmerjakeimho bitfields are waay more clear...non-portability doesn't matter here cuz the compiler handles that...nothing reads/writes without going through that struct anyway21:03
ghostmansd[m]programmerjake, could you please post an URL? I'd like to refresh, but there're 80 comments there :-D21:03
ghostmansd[m]From mobile, it's a pain in the ass to navigate in the ticket21:04
ghostmansd[m]Especially to edit the comment. Utter bullshit, since the text is at the end of the page, but "save" button is at the top.21:04
ghostmansd[m]Kudos to bugzilla for shitty mobile UX :-)21:05
lkclghostmansd[m], i knoow, it's a frickin pain. i use bugzilla on android, yay. i flip the page to "Desktop" mode on chrome and it gets better, but only slightly21:05
programmerjakeplease avoid editing comments (when it's not the top one or something)...nobody gets notified and many people just read only the original version in the email21:06
programmerjakeunless it's just a spelling fix or something21:06
lkclghostmansd[m], what programmerjake said. if you do edit, put [edited: xxxx]21:07
ghostmansd[m]I usually insert a new one, but when it's that many comments...21:07
lkclcomment 0 is the usual one we use for TODO lists, status info, etc.21:07
ghostmansd[m]Why don't they have pages or something like this21:07
lkcli know.21:07
lkcldefinitely don't edit old comments to fill in "extra stuff"21:08
lkclif necessary we can start a new bugreport21:08
lkclapart from anything, the load on the server (which i'm paying for) gets progressively higher as the number of comments increases21:08
programmerjaketho...the server fees are subsidised by our hosting provider...cuz they like libre-soc21:09
lkclyeah which was really nice of them21:10
* lkcl simulation has initialised the MMU and put in all VM pages21:10
lkcl[    0.000000]   Normal zone: 896 pages used for memmap21:11
lkcl[    0.000000]   Normal zone: 0 pages reserved21:11
lkcl[    0.000000]   Normal zone: 65536 pages, LIFO batch:1521:11
octaviuslkcl, is there a way to refactor some of the older bugreports to use fewer resources?21:11
octaviusLike lock to read-only?21:11
lkcloctavius, good question21:11
lkclperhaps if i enable mod_pagespeed to cover it, it'll get cached automatically21:12
ghostmansd[m]Folks, so, let's form some summary about bitfields in SVP64 entry and how to represent these in PPC entry?21:12
lkclghostmansd[m], ack.21:12
programmerjakebugzilla caching...sounds's super slow21:12
ghostmansd[m]I like bitfields, and like pointer in PPC entry. But can give up on both.21:13
programmerjakeor maybe just move to gitea eventually21:13
lkcli'm definitely leaning towards macros/bits because it's the style used by binutils itself, and they have good reasons for doing so21:13
programmerjakei like bitfields but don't care much about pointer21:13
programmerjakethey use macros cuz that's where non-portability really's instruction fields in the final machine code after all...21:14
lkcland: no more than 64 bits is ever going to be needed, because this is SVP64: there's only 24 bits available in the prefix and if that takes more than 64 bits to express then there's something drastically wrong21:14
programmerjakehere non-portability doesn't matter so use bitfields cuz they're clearer21:14
lkclthat's going to raise a flag by the binutils developers on review. i can pretty much guarantee they'll reject it because it's not following the coding style that they've followed for 30+ years21:16
programmerjakeor...we could just ask on the binutils mailing lists/irc/etc...21:16
lkclthere's a binutils irc channel?21:16
ghostmansd[m]Ok, I'll think of this once I come back to the code next time :-)21:16
ghostmansd[m]Thanks for discussion folks!21:16
ghostmansd[m]That's really helpful21:17
lkclthere is!21:17
lkclno problem ghostmansd[m]21:17
programmerjakeidk if there's an irc channel..i just mean contact via whatever methods they have for public discussion21:17
ghostmansd[m]From some beholder's point of view, that might seem like a sort of yet another religious war though :-D21:17
* lkcl joining #binutils on libera21:18
programmerjakewell...yeah your kinda right ghostmansd[m]21:18
ghostmansd[m]Still simpler than naming issues on the reviews :-D21:18
lkclit's ##binutils not #binutils21:18
programmerjakebikeshedding is always fun!!! (not)21:18
ghostmansd[m]Ok I'll post to binutils tomorrow21:34
ghostmansd[m]Too tired today, both wife and kid got tested positively for covid, and I feel like I'm getting sick as well21:35
ghostmansd[m]See ya!21:35
programmerjakewhich mailing list...i need to turn email delivery back on and i forgot the url21:35
programmerjakehope your family feels better!21:36
programmerjakenm, found it
programmerjakejust finished watching a very interesting LCA2022 talk on the history of unix:
octaviusThanks jake! I'll add this to my watchlist22:34

Generated by 2.17.1 by Marius Gedminas - find it at!