| lkcl | https://science.slashdot.org/comments.pl?sid=20605841&cid=62175767 | 00:57 |
|---|---|---|
| lkcl | :) | 00:57 |
| lkcl | mikolajw, have a look through soc and nmutil you will find literally dozens of examples of how to use Record | 16:04 |
| lkcl | the function make_wb_layout() is a good one | 16:04 |
| lkcl | you do not have to "sub-class" Layout, it's probably not a good idea | 16:04 |
| lkcl | whitequark has a habit of using if type(obj) == ClassName instead of "if isinstance(obj, ClassName)" which interferes with sub-classing | 16:05 |
| lkcl | stdcx. now setting CR0 correctly | 16:32 |
| lkcl | that means spinlocks should work | 16:33 |
| lkcl | mikolajw, doh, i meant octavius :) | 16:47 |
| lkcl | octavius, there's tons of examples. this one is "sophisticated" by nmigen standards | 16:48 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/minerva/wishbone.py;h=6786ff5291a17bff8f210fcbbf19ff464005e92a;hb=a5bd4d6324e1c72a8e1e8874962aad6246061676#l17 | 16:48 |
| octavius | Thanks, I was just trying to find some now | 16:48 |
| lkcl | because the parameters to make_wb_layout() adjust the Record created from it | 16:48 |
| lkcl | find . -name "*.py" | xargs grep Record | 16:48 |
| lkcl | :) | 16:48 |
| octavius | Oh yeah XD | 16:49 |
| lkcl | RecordObject btw is a little more sophisticated | 16:49 |
| lkcl | you create like you'd expect: a class with Signals and other RecordObjects in its constructor | 16:49 |
| octavius | I noticed DIR_FANOUT, is it really for specifying the fanout? I would've thought that would be specified by the node | 16:50 |
| lkcl | surpriiise, it creates the Record layout automatically for you, through introspection | 16:50 |
| lkcl | ignore it entirely | 16:50 |
| lkcl | don't bother - don't use it | 16:50 |
| lkcl | the direction is automatically detected based on usage | 16:50 |
| octavius | So 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 |
| lkcl | the nice thing is, nmigen squashes it down, linearly, as if it was a sequence of bits | 16:51 |
| lkcl | ... | 16:51 |
| lkcl | i recommend you don't sub-class Record | 16:51 |
| octavius | So I shouldn't create a Record? | 16:51 |
| lkcl | use the same trick as make_wb_layout | 16:52 |
| lkcl | you said "record class" | 16:52 |
| lkcl | not "record instance" | 16:52 |
| lkcl | creating a "Record class" implies "creating a subclass of Record" | 16:52 |
| lkcl | which i do not recommend | 16:52 |
| lkcl | if you meant, "so when creating a Record *instance*".... | 16:52 |
| octavius | res in that case is just a tuple, I thought you needed to create a class inhereting Layout, and then a class inhereting Record | 16:52 |
| lkcl | no. | 16:53 |
| lkcl | neither of those things are required. | 16:53 |
| octavius | So it's just a list then? | 16:53 |
| lkcl | and subclassing Layout as i said above may actually interfere | 16:53 |
| lkcl | no, it's not a list | 16:53 |
| octavius | but it has [] | 16:53 |
| lkcl | a Record instance contains Signals [and other Records] that as far as nmigen is concerned are "like a sequence of bits" | 16:54 |
| lkcl | where is the list? | 16:54 |
| octavius | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/minerva/wishbone.py;h=6786ff5291a17bff8f210fcbbf19ff464005e92a;hb=a5bd4d6324e1c72a8e1e8874962aad6246061676#l25 | 16:54 |
| lkcl | that's just the layout | 16:54 |
| octavius | ... | 16:54 |
| octavius | XD | 16:54 |
| lkcl | when passed as the "layout=res" argument to Record, Record knows what to do. | 16:55 |
| lkcl | you should have the source code of nmigen open and be looking at it, right now | 16:55 |
| lkcl | don't ever assume that nmigen is a "black box" | 16:55 |
| lkcl | your *immediate* reaction should be to find and open the source code of *anything* that you are going to use | 16:55 |
| lkcl | run "ctags -R" in the top-level directory then ":tag Record" <return> | 16:56 |
| lkcl | that will take you to the first [tagged] instance of "anything named Record" | 16:56 |
| lkcl | if its' not the one you want type ":tn" (tag next) | 16:56 |
| lkcl | for example obviously you don't want this one | 16:57 |
| lkcl | "nmigen/compat/genlib/record.py" | 16:58 |
| lkcl | that's the old "compatibility" layer | 16:58 |
| lkcl | "nmigen/hdl/rec.py" | 16:58 |
| lkcl | ah ha! | 16:58 |
| lkcl | https://git.libre-soc.org/?p=nmigen.git;a=blob;f=nmigen/hdl/rec.py;h=125bb4cede02e5e7ccdf71c9d72f31498a7e3c74;hb=e88d283ed30448ed5fe3ba264e3e56b48f2a4982#l115 | 16:58 |
| lkcl | first 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 |
| octavius | Running "ctags -R" within the nmigen top dir give me no results | 16:59 |
| lkcl | [you should be doing this automatically btw. it should be second-nature] | 16:59 |
| lkcl | ls -altr | 16:59 |
| lkcl | -rw-r--r-- 1 lkcl lkcl 413184 Jan 16 16:59 tags | 17:00 |
| lkcl | now run "vi" | 17:00 |
| lkcl | and type ":Record" | 17:00 |
| lkcl | emacs also supports tags but i don't know the commands so can't advise | 17:00 |
| octavius | opening 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 |
| lkcl | sorry, ":tag Record" | 17:01 |
| lkcl | then ":tn" to jump to the 2nd occurrence | 17:02 |
| lkcl | you can also put the cursor on a word and use "Ctrl-]" and it will jump to the definition | 17:02 |
| lkcl | extremely useful | 17: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 |
| octavius | Ok, my brain's fried XD I run off vimtutor, so I never really delved beyond that. I'll look at Record then. | 17:05 |
| lkcl | :) | 17:05 |
| lkcl | basically Record's 1st argument can either be a list or it can be a Layout that's constructed *from* a list | 17:06 |
| lkcl | you therefore *do not* need to create a Layout instance, just pass in a list comprising what layout you want. | 17:06 |
| lkcl | it's all much much simpler than you're imagining it is | 17:06 |
| lkcl | hence the crispiness :) | 17:06 |
| lkcl | okaaay about the 30th linux-5.7 simulation underway, this one now have LR/SC and the MMU microwatt unit tests passing | 17:12 |
| lkcl | so stands a reasonable chance of progressing to an actual boot prompt | 17:12 |
| lkcl | some time in the next 60 hours, mind | 17:12 |
| lkcl | ghostmansd[m], i know it's a pain to have to focus on optimisation at an early stage of code being developed | 20:46 |
| lkcl | binutils 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 matter | 20:47 |
| lkcl | annoyingly. | 20:47 |
| lkcl | i can pretty much guarantee that when submitted upstream we'll be requested to redo anything that's sub-optimal | 20:48 |
| lkcl | perhaps 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 |
| lkcl | :) | 20:52 |
| ghostmansd[m] | My point is that we have no more than 8 bytes per PPC entry | 20:52 |
| ghostmansd[m] | Because I had pointers in mind, not 64-bit entries | 20: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_entry | 20:53 |
| ghostmansd[m] | Because, well, we have only about 300 of those | 20:53 |
| lkcl | that'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 struct | 20:53 |
| lkcl | no, there would be (10,000-300) NULL pointers and 300 entries | 20:54 |
| lkcl | which, remember, every single instruction in an assembly listing would result in double-lookup | 20:54 |
| lkcl | causing L1 cache fragmentation | 20:54 |
| ghostmansd[m] | Nope | 20:54 |
| ghostmansd[m] | You don't need to lookup | 20:54 |
| lkcl | de-referencing the pointer ==> "a lookup" | 20:55 |
| lkcl | ppc64_struct[n]->svp64_entry->XYZ | 20:55 |
| lkcl | that's a double lookup which will jump the L1 cache to a 2nd location, causing L1 cache fragmentation | 20:56 |
| ghostmansd[m] | That, unlike real lookup optimization, sounds like premature one | 20:56 |
| lkcl | it's exactly the sort of thing that a review on submission to binutils-dev will flag up | 20:56 |
| lkcl | if there was *any reason* why more than 64 bits of information was required, i would immediately agree with you | 20: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 |
| lkcl | because 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 |
| lkcl | they might then ask instead, "would QTY 2 64-bit values be ok instead" | 20:58 |
| lkcl | there's two phases. | 20:58 |
| lkcl | first phase: | 20:58 |
| lkcl | * creating the table (filling in the values). this is unavoidable | 20:58 |
| lkcl | second phase: | 20:58 |
| lkcl | * actually running and translating (potentially millions to hundreds of millions to billions of assembly lines) | 20:59 |
| lkcl | that 2nd phase is where this really, really matters | 20: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 |
| lkcl | mmm true. | 21:00 |
| ghostmansd[m] | We can do it | 21:00 |
| ghostmansd[m] | That's no problem :-) | 21:00 |
| lkcl | :) | 21:00 |
| ghostmansd[m] | If you insist, I'm OK | 21:01 |
| ghostmansd[m] | I simply want to explain the rationale | 21:01 |
| ghostmansd[m] | But I'm not a lunatic | 21:01 |
| programmerjake | see my comments on the bug...if it's not public API -- just refactor if/when you run out of space...it 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 |
| lkcl | i'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 saying | 21: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-option | 21:02 |
| lkcl | nice. | 21:02 |
| lkcl | yehyeh. i did the network reverse-engineering for samba nmbd and DCE/RPC, 20-25 years ago | 21:03 |
| programmerjake | imho bitfields are waay more clear...non-portability doesn't matter here cuz the compiler handles that...nothing reads/writes without going through that struct anyway | 21:03 |
| ghostmansd[m] | programmerjake, could you please post an URL? I'd like to refresh, but there're 80 comments there :-D | 21:03 |
| ghostmansd[m] | From mobile, it's a pain in the ass to navigate in the ticket | 21:04 |
| programmerjake | https://bugs.libre-soc.org/show_bug.cgi?id=550#c82 | 21: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 |
| lkcl | ghostmansd[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 slightly | 21:05 |
| programmerjake | please 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 email | 21:06 |
| programmerjake | unless it's just a spelling fix or something | 21:06 |
| lkcl | ghostmansd[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 |
| lkcl | comment 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 this | 21:07 |
| ghostmansd[m] | sigh | 21:07 |
| lkcl | i know. | 21:07 |
| lkcl | definitely don't edit old comments to fill in "extra stuff" | 21:08 |
| lkcl | if necessary we can start a new bugreport | 21:08 |
| lkcl | apart from anything, the load on the server (which i'm paying for) gets progressively higher as the number of comments increases | 21:08 |
| programmerjake | tho...the server fees are subsidised by our hosting provider...cuz they like libre-soc | 21:09 |
| lkcl | yeah which was really nice of them | 21:10 |
| * lkcl simulation has initialised the MMU and put in all VM pages | 21:10 | |
| lkcl | [ 0.000000] Normal zone: 896 pages used for memmap | 21:11 |
| lkcl | [ 0.000000] Normal zone: 0 pages reserved | 21:11 |
| lkcl | [ 0.000000] Normal zone: 65536 pages, LIFO batch:15 | 21:11 |
| octavius | lkcl, is there a way to refactor some of the older bugreports to use fewer resources? | 21:11 |
| octavius | Like lock to read-only? | 21:11 |
| lkcl | octavius, good question | 21:11 |
| lkcl | perhaps if i enable mod_pagespeed to cover it, it'll get cached automatically | 21: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 |
| lkcl | ghostmansd[m], ack. | 21:12 |
| programmerjake | bugzilla caching...sounds good...it's super slow | 21:12 |
| ghostmansd[m] | I like bitfields, and like pointer in PPC entry. But can give up on both. | 21:13 |
| programmerjake | or maybe just move to gitea eventually | 21:13 |
| lkcl | i'm definitely leaning towards macros/bits because it's the style used by binutils itself, and they have good reasons for doing so | 21:13 |
| programmerjake | i like bitfields but don't care much about pointer | 21:13 |
| programmerjake | they use macros cuz that's where non-portability really matters...it's instruction fields in the final machine code after all... | 21:14 |
| lkcl | and: 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 wrong | 21:14 |
| programmerjake | here non-portability doesn't matter so use bitfields cuz they're clearer | 21:14 |
| lkcl | that'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+ years | 21:16 |
| programmerjake | or...we could just ask on the binutils mailing lists/irc/etc... | 21:16 |
| lkcl | there'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 helpful | 21:17 |
| lkcl | there is! | 21:17 |
| lkcl | no problem ghostmansd[m] | 21:17 |
| programmerjake | idk if there's an irc channel..i just mean contact via whatever methods they have for public discussion | 21:17 |
| ghostmansd[m] | From some beholder's point of view, that might seem like a sort of yet another religious war though :-D | 21:17 |
| * lkcl joining #binutils on libera | 21:18 | |
| programmerjake | well...yeah your kinda right ghostmansd[m] | 21:18 |
| ghostmansd[m] | Still simpler than naming issues on the reviews :-D | 21:18 |
| lkcl | it's ##binutils not #binutils | 21:18 |
| programmerjake | bikeshedding is always fun!!! (not) | 21:18 |
| ghostmansd[m] | Ok I'll post to binutils tomorrow | 21:34 |
| ghostmansd[m] | Too tired today, both wife and kid got tested positively for covid, and I feel like I'm getting sick as well | 21:35 |
| ghostmansd[m] | See ya! | 21:35 |
| programmerjake | which mailing list...i need to turn email delivery back on and i forgot the url | 21:35 |
| programmerjake | hope your family feels better! | 21:36 |
| octavius | +1 | 21:36 |
| programmerjake | nm, found it https://sourceware.org/mailman/options/binutils | 21:37 |
| programmerjake | just finished watching a very interesting LCA2022 talk on the history of unix: https://youtu.be/ECCr_KFl41E | 22:33 |
| octavius | Thanks jake! I'll add this to my watchlist | 22:34 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!