| rsc | lkcl: are you presenting at embedded world Conference in Nuremberg? | 00:05 |
|---|---|---|
| lkcl | rsc, 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 bugreport | 09:50 |
| lkcl- | markos should be really happy not to have to use svp64.py, and to be able to get the full macro support from binutils | 09:50 |
| ghostmansd[m] | Not sure how to split the budget, though | 09:51 |
| ghostmansd[m] | I guess the task about plugin can be closed | 09: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 |
| programmerjake | hmm, for me the payments take 2-4weeks | 09:53 |
| ghostmansd[m] | I mean, I really want to see `sv.whatever` in disassembler, not `svmagic + non-magic` combo | 09:53 |
| ghostmansd[m] | programmerjake, they already sent the payment, I guess it's my favorite embargo | 09:54 |
| programmerjake | hmm, 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 here | 09:55 |
| ghostmansd[m] | Because, even though they talk about hitting the politicians, they hit the usual people more | 09:56 |
| ghostmansd[m] | And it's literally "we're under the siege" feeling | 09:56 |
| programmerjake | there 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 mind...so everyone else gets caught up in it too | 09:59 |
| lkcl- | ghostmansd[m], yes the plugin one's invalid now | 10: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 lol | 10: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 objects | 10: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 HDL | 10: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 class | 10:30 |
| ghostmansd[m] | Also he found my previous copyrights assignment for gnulib | 10:30 |
| lkcl- | oh good | 10: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 invalid | 10:34 |
| lkcl- | everything and i mean everything *has* to be up-cast to the highest determined class | 10:34 |
| lkcl- | *including* anything that is ValueCastable | 10:34 |
| lkcl- | failure to do so results in catastrophic unexpected behaviour | 10:35 |
| programmerjake | it 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 found | 10:35 |
| lkcl- | if there is a mix of items deriving from UserValue | 10:36 |
| lkcl- | and another set that derives from ValueCastable | 10: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 class | 10:36 |
| lkcl- | how can that class even be determined? | 10:37 |
| programmerjake | then 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 |
| programmerjake | well, ValueCastable *isn't* a value. don't treat it as one | 10:38 |
| lkcl- | and that's the problem | 10:38 |
| lkcl- | the value_castable.as_value() catastrophically destroys the information | 10:38 |
| lkcl- | by calling that function, the entire purpose is destroyed | 10:38 |
| lkcl- | it's like type-casting down in base classes in c++ | 10:38 |
| lkcl- | then trying to up-cast back again | 10:38 |
| lkcl- | (without having c++ RTTI enabled) | 10:39 |
| programmerjake | no it doesn't, the return value is chosen by the ValueCastable subclass...it can return a UserValue subclass | 10:39 |
| lkcl- | i encountered this problem in webkit | 10: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 suggested | 10:40 |
| lkcl- | once the ValueCastable is cast to a Value by calling that function, it is Game Over | 10:40 |
| lkcl- | like casting a complex number to a float | 10:40 |
| programmerjake | no, because as_value isn't downcasting, it's conversion to whatever Value subclass that ValueCastable wants to behave like in nmigen Value contexts | 10:40 |
| lkcl- | then trying to restore the complex number information | 10:41 |
| lkcl- | eeeexacccctlyyyyyy | 10:41 |
| lkcl- | it's conversion to a Value sublass | 10:41 |
| lkcl- | which is precisely and exactly what you must not do | 10:41 |
| lkcl- | the entire paradigm - the entire abstraction paradigm - specifically relies on letting *the highest class* perform that downcasting | 10:42 |
| programmerjake | UserValue subclasses are Value subclasses, you just return your custom uservalue subclass from as_value() if you want custom behavior, no problem | 10:42 |
| lkcl- | because only the highest class has the full context and information needed to perform the correct downcasting | 10: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 downcasting | 10:43 |
| lkcl- | going through aalll the possible classes leading down (eventually) to Value | 10:43 |
| programmerjake | you 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 of | 10:44 |
| lkcl- | it's too much. | 10:44 |
| lkcl- | if this was something that was entirely controlled solely and exclusively by us | 10:44 |
| lkcl- | then we could have all the permutations of possible interactions between UserValue and ValueCastable casting | 10: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 objects | 10:45 |
| lkcl- | and that means that all third parties would need to be intimately aware of all other third parties casting characteristics | 10:46 |
| lkcl- | that is flat-out impossible to expect. | 10:46 |
| lkcl- | we'd be laughed at for even suggesting it | 10:46 |
| programmerjake | well, 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 Value | 10:46 |
| lkcl- | please just make it a UserValue | 10:47 |
| lkcl- | because otherwise the casting will fail and/or have to be explicitly integrated in as a replacement for ValueCastable | 10:47 |
| lkcl- | i.e. g/s/r ValueCastable w/ SmtBitVec | 10:48 |
| programmerjake | it can't be a UserValue, the APIs don't work together since SmtBitVec follows the smtlib2 api, not the nmigen value api | 10:48 |
| lkcl- | with temporary support for ValueCastable and... no | 10:48 |
| lkcl- | nggggh | 10:48 |
| lkcl- | ah. | 10:49 |
| lkcl- | frick | 10:49 |
| lkcl- | i see the problem now. | 10:49 |
| lkcl- | i have no idea how to resolve that | 10:49 |
| lkcl- | ok thank you for being patient with me and explaining it. | 10:50 |
| programmerjake | now 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 problem | 10:51 |
| lkcl- | i'm taking you at your word on the incompatibility between smtlib2 and Value | 10: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- | hmmmm | 10:52 |
| lkcl- | i need time to absorb the implications, and work through it | 10:53 |
| programmerjake | k, i'll go to sleep then. ttyl | 10:53 |
| lkcl- | rest well | 10:54 |
| programmerjake | thx | 10:54 |
| ghostmansd | lkcl, could you, please, check tasks 550 and 844 so that I'm sure that this is done correctly? | 13:01 |
| ghostmansd | I 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 |
| ghostmansd | This leaves us only 350 for code cleanup (including future discussions with Alan) and binutils tests for SVP64. | 13:01 |
| ghostmansd | At least we already allocated the budget for 838, cool. :-) | 13:01 |
| ghostmansd | I had to re-send the stuff above; IRC connection sucks | 13:01 |
| ghostmansd | I didn't find it in logs, so I assumed it hasn't been sent; sorry for double-posting, if this all arrived twice | 13:02 |
| lkcl- | ghostmansd, yeah i know, libera.chat is dropping messages | 13:10 |
| lkcl- | there's plenty to be able to increase 550's budget by at least double what it is, now | 13:10 |
| ghostmansd | I assume you mean its parent task, right? | 13:11 |
| ghostmansd | OK, I guess we'll come to it when I'll write the tests | 13:11 |
| lkcl- | ah yes, the parent | 13:11 |
| ghostmansd | I'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 spare | 13:11 |
| ghostmansd | ah OK then | 13:12 |
| lkcl- | i kinda like svmagic | 13:12 |
| lkcl- | other words would be "svp64" or "svprefix" | 13:12 |
| ghostmansd | I 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 point | 13:13 |
| lkcl- | or... you get the idea | 13:13 |
| ghostmansd | still, 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 |
| lkcl- | yehyeh | 13:14 |
| ghostmansd | svmagic 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 all | 13:14 |
| ghostmansd | well this is frankly not surprizing: the libopcode is shared between all binutils stuff | 13:15 |
| ghostmansd | we'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 |
| ghostmansd | this is also, btw, partly the reason why we end up being integrated into the huge opcode table: this table is throughout the entire code base | 13:15 |
| lkcl- | but let's put all that into a second bugreport | 13:15 |
| ghostmansd | yes, I think prefix task will be a difficult one | 13:15 |
| ghostmansd | if you're ok with 550 and 844, I'll raise the task on prefix and put something there, e.g. 850:150 | 13:16 |
| ghostmansd | really, depending on how gory it ends up, perhaps it'd be even more, I'm not sure | 13:17 |
| ghostmansd | on the first glance, handling prefixes is somewhat... messy, so to speak | 13:17 |
| ghostmansd | submitted task 845, https://bugs.libre-soc.org/show_bug.cgi?id=845 | 13:22 |
| ghostmansd | let me know if I can send an RFP for 844 | 13:22 |
| lkcl- | yes sure go for it on 844 - do put a copy of the pastebin into the bugreport demo'ing that it works | 14: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 lkcl | 14:32 | |
| rsc | lkcl: oh, okay. Preferring an island? :) | 14:48 |
| lkcl | rsc: basically when there are no medical checks required to get in or out of the UK i'll be able to travel. | 14:50 |
| rsc | lkcl: oh, but that's UK-specific, right? | 14:55 |
| lkcl | yes it is. | 14:57 |
| lkcl | travel outside of the UK is prohibited at the moment without a medical check. | 14:57 |
| lkcl | if i was already within the european union it would not be a problem | 14: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 |
| lkcl | ghostmansd[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 |
| lkcl | if 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 adjustment | 16:55 |
| lkcl | sure, 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 |
| ghostmansd | I'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 |
| lkcl | ghostmansd[m], ah ok got it. | 21:19 |
| lkcl | hmmm i think if adding just a new file, they'll be fine with it | 21:19 |
| lkcl | another trick is if you need to add functions to e.g. ppc-opc.c, add them in a separate file, along with a header | 21:20 |
| lkcl | as one patch | 21:20 |
| lkcl | then a *separate* one making actual use of them | 21:20 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!