Thursday, 2022-06-02

rsclkcl: are you presenting at embedded world Conference in Nuremberg?00:05
lkclrsc, ah, i'm not travelling outside the uk.07:50
lkcl-ghostmansd[m], hooraay!09:48
lkcl-so that's worthwhile throwing a stake in the ground with an RFP, then doing unit tests and further integration into openpower-isa as a new bugreport09:50
lkcl-markos should be really happy not to have to use, and to be able to get the full macro support from binutils09:50
ghostmansd[m]Not sure how to split the budget, though09:51
ghostmansd[m]I guess the task about plugin can be closed09:51
ghostmansd[m]I still haven't got the recent payments, though.09:52
ghostmansd[m]Also, there's one big stuff that must be completed: getting rid of svmagic insn and replacing it with prefix.09:52
programmerjakehmm, for me the payments take 2-4weeks09:53
ghostmansd[m]I mean, I really want to see `sv.whatever` in disassembler, not `svmagic + non-magic` combo09:53
ghostmansd[m]programmerjake, they already sent the payment, I guess it's my favorite embargo09:54
programmerjakehmm, well, hopefully it works out for you...09:55
ghostmansd[m]It's funny how US and EU literally made more people love the regime here09:55
ghostmansd[m]Because, even though they talk about hitting the politicians, they hit the usual people more09:56
ghostmansd[m]And it's literally "we're under the siege" feeling09:56
programmerjakethere isn't really an effective way to target just politicians in a way that won't cause wwiii and will hurt them enough that they might change their everyone else gets caught up in it too09:59
lkcl-ghostmansd[m], yes the plugin one's invalid now10:24
lkcl-unfortunately they're assuming the politicians care what ordinary people think. i suspect, actually, it'll be the russian mafia that will make things happen :) piss them off - i.e. they can't do business and can't make money - and they'll start changing politicians minds pretty fast :)10:26
lkcl-or there suddenly won't _be_ any politicians lol10:27
lkcl-programmerjake, thinking through the suggestion that ValueCastable has a place in an abstracted world: it means that it is necessary to raise catastrophic exceptions (runtime exceptions) to prevent people from trying to mix UserValue-derived objects with ValueCastable objects10:29
lkcl-e.g. a strongly-typed UserValue derivative attempted to be Cat()ed with a ValueCastable will be forced to raise a runtime error terminating the production of HDL10:30
ghostmansd[m]lkcl, if plugin task is no longer needed, I think I can re-route its budget to task I'll raise, something like "binutils: initial implementation"10:30
ghostmansd[m]I'm still waiting for assignment. Alan said it takes about a week since recent.10:30
lkcl-because it is impossible to work out how to cast the ValueCastable to the "strong type" class, which is the highest-level class10:30
ghostmansd[m]Also he found my previous copyrights assignment for gnulib10:30
lkcl-oh good10:31
lkcl-ghostmansd[m], let me take a look...10:31
lkcl-programmerjake, i'm really sorry to have to point this out, but *any* suggestion that ValueCastable has a place in nmigen when the upcasting-function is in place is basically invalid10:34
lkcl-everything and i mean everything *has* to be up-cast to the highest determined class10:34
lkcl-*including* anything that is ValueCastable10:34
lkcl-failure to do so results in catastrophic unexpected behaviour10:35
programmerjakeit is, its upcast to the highest Value subclass...ValueCastable is just not a value so is converted to a Value, then the highest subclass is found10:35
lkcl-if there is a mix of items deriving from UserValue10:36
lkcl-and another set that derives from ValueCastable10:36
lkcl-and it is a hard requirement that *every* single item within the mix be up-cast to the one *and only* one highest identifiable class10:36
lkcl-how can that class even be determined?10:37
programmerjakethen you get highest_subclass(user_value, value_castable.as_value())10:37
lkcl-when ValueCastable was specifically designed *not* to inherit from Value()?10:37
programmerjakewell, ValueCastable *isn't* a value. don't treat it as one10:38
lkcl-and that's the problem10:38
lkcl-the value_castable.as_value() catastrophically destroys the information10:38
lkcl-by calling that function, the entire purpose is destroyed10:38
lkcl-it's like type-casting down in base classes in c++10:38
lkcl-then trying to up-cast back again10:38
lkcl-(without having c++ RTTI enabled)10:39
programmerjakeno it doesn't, the return value is chosen by the ValueCastable can return a UserValue subclass10:39
lkcl-i encountered this problem in webkit10:39
lkcl-once you've downcast (by calling ValueCastable.as_value()) it has literally destroyed everything.10:39
lkcl-it is absolutely absolutely critically important *not* to do precisely and exactly what you have suggested10:40
lkcl-once the ValueCastable is cast to a Value by calling that function, it is Game Over10:40
lkcl-like casting a complex number to a float10:40
programmerjakeno, because as_value isn't downcasting, it's conversion to whatever Value subclass that ValueCastable wants to behave like in nmigen Value contexts10:40
lkcl-then trying to restore the complex number information10:41
lkcl-it's conversion to a Value sublass10:41
lkcl-which is precisely and exactly what you must not do10:41
lkcl-the entire paradigm - the entire abstraction paradigm - specifically relies on letting *the highest class* perform that downcasting10:42
programmerjakeUserValue subclasses are Value subclasses, you just return your custom uservalue subclass from as_value() if you want custom behavior, no problem10:42
lkcl-because only the highest class has the full context and information needed to perform the correct downcasting10:42
lkcl-no: Uservalue subclasses *specifically* contain within them an *override* of the casting function that performs an if/elif/elif check of all possible permutations of downcasting10:43
lkcl-going through aalll the possible classes leading down (eventually) to Value10:43
programmerjakeyou can have a ValueCastable that returns a UserValue that has those overrides...10:43
lkcl-and then you have two pieces of code to maintain and also, worse, third party pieces of information which the two have to be aware of10:44
lkcl-it's too much.10:44
lkcl-if this was something that was entirely controlled solely and exclusively by us10:44
lkcl-then we could have all the permutations of possible interactions between UserValue and ValueCastable casting10:45
lkcl-as a massive god-awful morass of unmaintainable crap, but it would "work"10:45
lkcl-but that's not what it's for: this is for *third parties* to develop castable objects10:45
lkcl-and that means that all third parties would need to be intimately aware of all other third parties casting characteristics10:46
lkcl-that is flat-out impossible to expect.10:46
lkcl-we'd be laughed at for even suggesting it10:46
programmerjakewell, if you remove ValueCastable, then SmtBitVec will just be a DIY ValueCastable -- it'll have an as_value() method and require you to call it to get something that can be used as a nmigen Value -- because SmtBitVec isn't a Value10:46
lkcl-please just make it a UserValue10:47
lkcl-because otherwise the casting will fail and/or have to be explicitly integrated in as a replacement for ValueCastable10:47
lkcl-i.e. g/s/r ValueCastable w/ SmtBitVec10:48
programmerjakeit can't be a UserValue, the APIs don't work together since SmtBitVec follows the smtlib2 api, not the nmigen value api10:48
lkcl-with temporary support for ValueCastable and... no10:48
lkcl-i see the problem now.10:49
lkcl-i have no idea how to resolve that10:49
lkcl-ok thank you for being patient with me and explaining it.10:50
programmerjakenow do you see how ValueCastable can work, but UserValue won't work there?10:50
lkcl-i don't, but i at least understand the scope of the problem10:51
lkcl-i'm taking you at your word on the incompatibility between smtlib2 and Value10:51
lkcl-i need to think how to deal with it.  DIY ValueCastable is what immediately springs to mind (yet another type)10:52
lkcl-i need time to absorb the implications, and work through it10:53
programmerjakek, i'll go to sleep then. ttyl10:53
lkcl-rest well10:54
ghostmansdlkcl, could you, please, check tasks 550 and 844 so that I'm sure that this is done correctly?13:01
ghostmansdI also consider that 850:150 would be a good budget for updating the code so that it really decodes the instructions, i.e. no more svmagic insn, but a real prefix-based decoder.13:01
ghostmansdThis leaves us only 350 for code cleanup (including future discussions with Alan) and binutils tests for SVP64.13:01
ghostmansdAt least we already allocated the budget for 838, cool. :-)13:01
ghostmansdI had to re-send the stuff above; IRC connection sucks13:01
ghostmansdI didn't find it in logs, so I assumed it hasn't been sent; sorry for double-posting, if this all arrived twice13:02
lkcl-ghostmansd, yeah i know, is dropping messages13:10
lkcl-there's plenty to be able to increase 550's budget by at least double what it is, now13:10
ghostmansdI assume you mean its parent task, right?13:11
ghostmansdOK, I guess we'll come to it when I'll write the tests13:11
lkcl-ah yes, the parent13:11
ghostmansdI'm going to write tests after refactoring for prefix, because otherwise it's kinda like doing it twice :-)13:11
lkcl-577 has another EUR 5750 spare13:11
ghostmansdah OK then13:12
lkcl-i kinda like svmagic13:12
lkcl-other words would be "svp64" or "svprefix"13:12
ghostmansdI think in some revision it even was svp64 :-)13:12
lkcl-svp64 is probably best because there's the possibility of svp48 and even svp16 at some point13:13
lkcl-or... you get the idea13:13
ghostmansdstill, I consider  it to be an intermediate stage, because I'd rather prefer -mlibresoc flag to act as expected, that is, show `sv.add`, not `sv.magic XXX, add`.13:14
ghostmansdsvmagic is good to show how the encoding happens, but doesn't help to get the listing, at all :-)13:14
lkcl-i'm astounded that objdump works at all13:14
ghostmansdwell this is frankly not surprizing: the libopcode is shared between all binutils stuff13:15
ghostmansdwe'll likely get something else working :-)13:15
lkcl-let me say, "impressed" as well as "astounded"13:15
lkcl-mixing with v3.1 64-bit prefixes is where it will get hairy.13:15
ghostmansdthis is also, btw, partly the reason why we end up being integrated into the huge opcode table: this table is throughout the entire code base13:15
lkcl-but let's put all that into a second bugreport13:15
ghostmansdyes, I think prefix task will be a difficult one13:15
ghostmansdif you're ok with 550 and 844, I'll raise the task on prefix and put something there, e.g. 850:15013:16
ghostmansdreally, depending on how gory it ends up, perhaps it'd be even more, I'm not sure13:17
ghostmansdon the first glance, handling prefixes is somewhat... messy, so to speak13:17
ghostmansdsubmitted task 845,
ghostmansdlet me know if I can send an RFP for 84413:22
lkcl-yes sure go for it on 844 - do put a copy of the pastebin into the bugreport demo'ing that it works14:14
lkcl-(pastebin btw is not "audit-friendly", unless we run our own pastebin)14:14
lkcl-btw as i'm guiding you through these, it'd be nice for me to have some budget as well :)14:16
*** lkcl- is now known as lkcl14:32
rsclkcl: oh, okay. Preferring an island? :)14:48
lkclrsc: basically when there are no medical checks required to get in or out of the UK i'll be able to travel.14:50
rsclkcl: oh, but that's UK-specific, right?14:55
lkclyes it is.14:57
lkcltravel outside of the UK is prohibited at the moment without a medical check.14:57
lkclif i was already within the european union it would not be a problem14:58
ghostmansd[m]lkcl, please update the tasks how you feel appropriately. As you see I'm not good in budgets (it's almost always 1000 and either plus or minus 15%). We have 1350 even now, please allocate from these, I have no idea how to estimate the discussions and debates we had, not that I'm really sure I estimated the code itself correctly. :-)15:58
ghostmansd[m]I for sure feel that the main part I already did is huge, it took a lot of time and efforts, I hope it'll be easier with prefixes, so I think that primary task should be estimated somewhat better than prefixes. But I have really no idea of ratio, and can only judge about the code when it's done.16:02
ghostmansd[m]I suggest that I allocate the sum I feel reasonable in the future, then you update it with your part. Is it OK?16:04
ghostmansd[m]I mean, I'll simply put the sum I think is fair, then post link to the task here, then you come and update it as you think it's good and reasonable. And then we send RFPs. :-)16:05
lkclghostmansd[m], as you probably noticed over the past few months i've upped 550 several times, and am happy to keep doing that.16:54
lkclif you at least keep track in each bugreport, posting summaries and links to the commit "diffs", it becomes possible for me to do a quick scan of the bugreport and do an adjustment16:55
lkclsure, works for me.16:55
ghostmansd[m]lkcl, I'm not talking about raising the budget now (though this will be needed when the patches are published in binutils mailing lists). I want you to decide on the exact allocations, because I frankly have no idea. And, as I mentioned, I don't want to even know the details how this chunk is split and whether it's split at all. What I suggest is that you edit the budget respectively, without going into details with me. :-)17:11
ghostmansdI'm continue to clean up the patches. Some perhaps should be united, but, on the other hand, others should be split. For example, the patch about parsing is almost 900 added lines. It's way too much.18:22
lkclghostmansd[m], ah ok got it.21:19
lkclhmmm i think if adding just a new file, they'll be fine with it21:19
lkclanother trick is if you need to add functions to e.g. ppc-opc.c, add them in a separate file, along with a header21:20
lkclas one patch21:20
lkclthen a *separate* one making actual use of them21:20

Generated by 2.17.1 by Marius Gedminas - find it at!