| *** rsc <rsc!~robert@fedora/rsc> has quit IRC | 07:00 | |
| *** rsc <rsc!~robert@linuxnetz.de> has joined #libre-soc | 07:00 | |
| *** rsc <rsc!~robert@linuxnetz.de> has quit IRC | 07:00 | |
| *** rsc <rsc!~robert@fedora/rsc> has joined #libre-soc | 07:00 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 07:32 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.134> has joined #libre-soc | 07:32 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.55.134> has quit IRC | 08:21 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 08:21 | |
| lkcl | > <ghostmansd> lkcl, beware, we only have 1 bit in svp64_desc left. | 09:15 |
|---|---|---|
| lkcl | willdo. there *really* should not be more. | 09:15 |
| lkcl | > ghostmansd> Is it at least close to final revision? | 09:16 |
| lkcl | impossible to say. i really *want* changes to stop, but we are now getting "actual feedback" | 09:16 |
| lkcl | plus remember if this is "wrong" and it's not noticed, that's it, we're done: there's no way back | 09:17 |
| lkcl | > <ghostmansd> class CROpFF5RM: RC1 = 1 | 09:18 |
| lkcl | yep. it works. i hacked that in so as to avoid a (significant) base-class shuffle | 09:18 |
| lkcl | it "works" because there *is* no mode other than RC=1 in CROpFF5RM. why? because there is no Rc=1 for CRops, therefore there is no Rc=0 to override, therefore RC1 is "on by default" | 09:22 |
| lkcl | sorry | 09:22 |
| lkcl | s/other than RC=1/other than RC1=1/ | 09:22 |
| *** octavius <octavius!~octavius@92.40.168.162.threembb.co.uk> has joined #libre-soc | 10:40 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 11:44 | |
| *** octavius <octavius!~octavius@92.40.168.162.threembb.co.uk> has quit IRC | 12:16 | |
| ghostmansd[m] | I don't get why we need RC1=1. Why not always output as if it's set? | 13:25 |
| ghostmansd[m] | I also noticed that with recent changes we can have common fields like ffrc1/ffrc0 regardless of actual LD/ST type or even for normal. Only CR ops are outsiders (as usual). | 13:27 |
| ghostmansd[m] | Perhaps I'll add these for binutils. The code gets messy there, because now I have to add checks like `if (svp64->record->mode == SVP64_MODE_LDST_IMM)`, but the actual field name only changes from imm to idx. | 13:29 |
| ghostmansd[m] | This eventually will make the logic simpler, we'll only end up with the assertion that mode is not CROP. | 13:29 |
| lkcl | yes i am trying to amortise the bits across functions | 14:41 |
| lkcl | because apart from simplifying your job | 14:41 |
| lkcl | it also drastically simplifies hardware, where it *really* matters | 14:41 |
| lkcl | RC=1 is supposed to be for instructions that don't have Rc=1 in the main 32-bit instruction. | 14:46 |
| lkcl | Rc=1 creates "Co-results" associated with Arithmetic instructions (add, subtract, min/max) | 14:46 |
| lkcl | so for example "add." if the result is zero, the *CO-RESULT* (CR0) is set to "0b0100" | 14:47 |
| lkcl | but some instructions like prtyd (parity double-word) just don't have Rc=1 (because it was deemed non-sensical) | 14:48 |
| lkcl | and unfortunately, all those instructions - even though there is a bit free - *IGNORE* bit 31 (the space where Rc=1 *COULD* have been put) | 14:49 |
| lkcl | therefore | 14:49 |
| lkcl | sigh | 14:49 |
| lkcl | we have to use a bit in the SVP64 RM field for the job | 14:49 |
| lkcl | sigh | 14:49 |
| lkcl | that's what RC1=1 is supposed to be for | 14:50 |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 15:13 | |
| lkcl | but of course CROps don't *have* a Rc=1 option. | 15:14 |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 15:15 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 15:44 | |
| ghostmansd | Folks, I've dropped some of my obsolete branches in openpower-isa, feel free to do the same :-) | 16:19 |
| ghostmansd | Folks, has anything been changed with setvl recently? | 16:37 |
| ghostmansd | I see that gas test suite fails after regeneration on setvl tests... | 16:37 |
| ghostmansd | So either the rebase was wrong, or the disassembly was changed. | 16:37 |
| ghostmansd | regexp "^.*: (37 00 00 58|58 00 00 37) setvl. r0,r0,1,0,0,0$" | 16:38 |
| ghostmansd | line " 0: 37 00 00 58 setvl. r0,0,1,0,0,0" | 16:38 |
| ghostmansd | Hm. It seems that one of the operands stopped being a register... | 16:41 |
| ghostmansd | OK checking this. Perhaps something with register operands went wrong. | 16:41 |
| ghostmansd | Hm. It actually was broken for a while, after I changed its RA operand to RA0 (RA_OR_ZERO per our lingo). | 16:44 |
| ghostmansd | #define RA0 RA + 1 /* As above, but 0 in the RA field means zero, not r0. */ | 16:45 |
| ghostmansd | It seems binutils are correct here and we're not. | 16:45 |
| ghostmansd | $(echo "setvl. r0,r0,1,0,0,0" | SILENCELOG=true pysvp64asm | powerpc64le-linux-gnu-as - -o /tmp/elf.o && powerpc64le-linux-gnu-objcopy -Obinary /tmp/elf.o /tmp/bin.o && pysvp64dis < /tmp/bin.o) | 16:45 |
| ghostmansd | 37 00 00 58 setvl. r0,r0,1,0,0,0 | 16:46 |
| ghostmansd | That's wrong, should be 0 instead of second r0. I'll handle it in our code base. | 16:47 |
| ghostmansd | Hm. It seems setvl also has RT_OR_ZERO. | 17:09 |
| ghostmansd | So `setvl. r0,r0,1,0,0,0` should instead be `setvl. 0,0,1,0,0,0`, if I'm not confused. | 17:10 |
| ghostmansd | Yes, indeed. | 17:11 |
| ghostmansd | if ((operand->flags & PPC_OPERAND_GPR) != 0 || ((operand->flags & PPC_OPERAND_GPR_0) != 0 && value != 0)) | 17:11 |
| ghostmansd | (*info->fprintf_styled_func) (info->stream, dis_style_register, "%sr%" PRId64, (vector ? "*" : ""), value); | 17:11 |
| ghostmansd | BTW setvl is the only instruction which has RT_OR_ZERO. | 17:14 |
| ghostmansd | Therefore binutils lack RT0 operand... | 17:15 |
| ghostmansd | You know what? I'm raising the task, this becomes too big to handle it in comments here. | 17:15 |
| ghostmansd | lkcl, FYI: https://bugs.libre-soc.org/show_bug.cgi?id=1093 | 17:22 |
| ghostmansd | Not a critical one, but I cannot tolerate broken binutils tests and incorrect disassembly in openpower-isa, I wasted too much time on it to keep it as is. :-) | 17:23 |
| ghostmansd | Heck, that's not trivial. Operands must know what exact selector is now in action. | 18:01 |
| ghostmansd | And guess what? The current code does not bother about it. | 18:01 |
| ghostmansd | That said... Is there a slightest opportunity, if operand is present on both input and output... that operand ends up being GPR_OR_ZERO for one and a simple GPR for another? This seems to be impossible, right? | 18:03 |
| *** yambo <yambo!~yambo@069-145-110-003.biz.spectrum.com> has quit IRC | 18:41 | |
| *** yambo <yambo!~yambo@069-145-110-003.biz.spectrum.com> has joined #libre-soc | 18:52 | |
| lkcl | ghostmansd, ahhh you know why? | 19:11 |
| lkcl | it's because the original version of sv/trans/svp64.py relied on binutils | 19:11 |
| lkcl | and - ahh setvl is a 32-bit scalar instruction | 19:12 |
| lkcl | i'm going to treat this as "review of setvl specification" because that's what it needs | 19:18 |
| *** knar <knar!~knar@2405:201:d02a:7803:606d:603b:c79b:3f75> has joined #libre-soc | 19:50 | |
| ghostmansd | lkcl, about selectors... they can't contradict to each other, can they? | 19:53 |
| ghostmansd | that is, if input selector is GPR_OR_ZERO, output cannot be simply GPR, and vice versa, right? | 19:54 |
| knar | I was interested in this bug report https://bugs.libre-soc.org/show_bug.cgi?id=980#c0 | 20:10 |
| knar | I have written a sort of toy transpiler which transpiles the RTL pseudo code to C code. | 20:10 |
| knar | I have also built Cavatools. | 20:10 |
| knar | Like Im wondering what exactly are we trying to do with the C code generated using Cavatools | 20:10 |
| knar | I apologies if this sounds too noobish | 20:10 |
| knar | Like | 20:12 |
| knar | if RA = 0 then b ← 0 | 20:12 |
| knar | else b ← (RA) | 20:12 |
| knar | EA ← b + (RB) | 20:12 |
| knar | RT ← EXTS(MEM(EA, 2) | 20:12 |
| knar | this would be simple to compile to C except handling the EXTS and MEM,(i need some guidance on that). | 20:12 |
| knar | also how exactly should i represent the registers in C | 20:12 |
| *** knar <knar!~knar@2405:201:d02a:7803:606d:603b:c79b:3f75> has quit IRC | 20:35 | |
| ghostmansd | I'd say GPRs are fixed-size integers, FPRs are float/double/integers-with-sw-float depending on your needs | 21:21 |
| ghostmansd | MEM is a simple memory I think | 21:21 |
| ghostmansd | That is, just plain bytes | 21:21 |
| lkcl | ghostmansd, no absolutely not - they're mutually-exclusive, definitely. | 21:34 |
| programmerjake | what is mutually-exclusive? there are several things that could refer to... | 21:36 |
| lkcl | knar: use it! the current python-based simulator (ineptly-named ISACaller after the class name) is 2,500 instructions per second. cavatools is over ten *THOUSAND* times faster than that, achieving around a 1:50 ratio of Host:Emulated speed | 21:36 |
| lkcl | peter hsu has requested a preference that all registers be held in uint64_t | 21:37 |
| lkcl | MEM would translate to a macro - because of the "2" it would be: (uint16_t)(*EA) | 21:38 |
| lkcl | cavatools "cheats" - it is not actually a "full guest emulator like qemu" | 21:38 |
| lkcl | it is a *userspace-only* simulator that ACTUALLY runs in the ACTUAL host (userspace) memory | 21:39 |
| programmerjake | lkcl, no, that's technically UB, you need to use read/write through union or memcpy because C has type-based alias analysis | 21:39 |
| lkcl | consequently you can only execute ELF binaries. you can *NOT* execute "the linux kernel" for example. | 21:39 |
| lkcl | programmerjake, this is "speed and pragmatism over correctness" and it would be behind a macro and/or inline function over which there is direct control to change (without messing with the output of the compiler) | 21:41 |
| programmerjake | so instead of *(uint16_t *)EA you need: | 21:42 |
| programmerjake | uint16_t v; | 21:42 |
| programmerjake | memcpy(&v, &mem[EA], sizeof(uint16_t)); // gets optimized to unaligned load | 21:42 |
| lkcl | that would only be used in cavatools if that function (memcpy) is an inline function. | 21:43 |
| lkcl | the function overhead is too great and would severely damage performance | 21:43 |
| ghostmansd | As for aliasing, this gets dumb over the years I'm looking at it. Over the years, I begin to understand why people disable strict aliasing. | 21:43 |
| ghostmansd | It sort of became cargo cult, TBH. | 21:44 |
| ghostmansd | Yes I know that's the letter of the standard. | 21:44 |
| programmerjake | memcpy is treated specially by every decent c compiler, it translates to whatever instruction sequence is fastest at copying for the given length, generally only actually calling memcpy if the length is dynamic or very big | 21:44 |
| ghostmansd | lkcl, didn't get about mutually exclusive | 21:44 |
| lkcl | cavatools is designed very specifically for high-performance | 21:45 |
| lkcl | ghostmansd: XOR. | 21:45 |
| ghostmansd | lol | 21:45 |
| programmerjake | in the case i posted, it will literally be just a single load instruction | 21:45 |
| ghostmansd | No I know what's mutually exclusive is in general | 21:45 |
| ghostmansd | I just cannot get what you mean applying it to CSVs | 21:45 |
| ghostmansd | Either one of these? | 21:46 |
| lkcl | hang on... | 21:46 |
| lkcl | "if input selector is GPR_OR_ZERO, output cannot be simply GPR," | 21:46 |
| ghostmansd | (I used GPR as placeholder for RA|RT) | 21:46 |
| ghostmansd | We cannot have insn record which states cr_in=RA, cr_out=RA_OR_ZERO | 21:47 |
| ghostmansd | That's what I asked | 21:47 |
| lkcl | ok.. thinksthinksthinks... | 21:47 |
| lkcl | there is no CR_OR_ZERO if that is what you mean | 21:47 |
| ghostmansd | Because how'd it work? | 21:47 |
| ghostmansd | No, that's not about CRs | 21:47 |
| ghostmansd | OK, let's take an example | 21:48 |
| lkcl | ahh no i got it | 21:48 |
| lkcl | ok so what "0" is doing here is it is simply changing the behaviour of the instruction | 21:48 |
| lkcl | there are 4 combinations: | 21:49 |
| lkcl | RA=0, RT=0 | 21:49 |
| lkcl | RA!=0, RT=0 | 21:49 |
| lkcl | RA=0, RT!=0 | 21:49 |
| lkcl | RA!=0, RT!=0 | 21:49 |
| lkcl | all four permutations are permitted | 21:49 |
| ghostmansd | That I get | 21:49 |
| ghostmansd | I'm talking about selectors | 21:49 |
| lkcl | but if we ever design an instruction that has in=RA_OR_ZERO,out=RA_OR_ZERO that would be catastrophically stupid of us | 21:50 |
| lkcl | likewise | 21:50 |
| lkcl | in=RT_OR_ZERO,out=RT_OR_ZERO | 21:50 |
| programmerjake | memcpy being a single load: https://gcc.godbolt.org/z/o6zzGfKGs | 21:50 |
| ghostmansd | If it can happen that the same operand is chosen for both in and out (say RA) | 21:50 |
| ghostmansd | Can we have record which contains in=RA,out=RA_OR_ZERO? | 21:50 |
| ghostmansd | only selectors | 21:51 |
| ghostmansd | don't think about SRC/DST | 21:51 |
| lkcl | programmerjake, okaay. somebody clearly thought about that. | 21:51 |
| lkcl | ghostmansd, again that would be catastrophically bad/stupid | 21:51 |
| lkcl | or would it... | 21:51 |
| ghostmansd | Yes that waas my intention too. Because that's basically the same operand. | 21:51 |
| ghostmansd | s/intention/guess/ | 21:52 |
| ghostmansd | I'm asking because I need to track operands marked as OR_ZERO | 21:52 |
| lkcl | ok in=RA_OR_ZERO,out=RA would be okay, because it's actually a "Read-Modify-Write" where you are giving the instruction the opportunity to set GPR(RA) to zero | 21:52 |
| ghostmansd | but my only option is tracking selectors | 21:52 |
| ghostmansd | I have nothing else to rely on | 21:52 |
| lkcl | but in=RA,out=RA_OR_ZERO would be pretty stupid. | 21:52 |
| ghostmansd | Nah don't think about this hardware | 21:53 |
| lkcl | well let us cross that bridge when we come to it. you have to be pretty desperate in terms of instruction design to do it | 21:53 |
| ghostmansd | Remember, I simply parse goddamn CSVs :-D | 21:53 |
| lkcl | :) | 21:53 |
| programmerjake | that's because c compilers generally use their builtin memcpy for struct assignments, obviously they'd try to optimize that to just a bunch of load/stores, memcpy just gets directly translated to the builtin memcpy | 21:53 |
| ghostmansd | And I need some ground to make an assumption "is it a simple RA or RA0" | 21:54 |
| ghostmansd | that's it, nothing else, no fancy stuff | 21:54 |
| lkcl | programmerjake, thank you for testing that - can you put the source code into the bugreport because godbolt.org is "too modern" for debian releases of firefox and chrome? | 21:54 |
| programmerjake | godbolt.org has a no-script variant... | 21:54 |
| lkcl | ghostmansd, mmmm.... that's making me nervous/twitchy for some reason | 21:54 |
| ghostmansd | lkcl, me too :-) | 21:55 |
| lkcl | programmerjake, no it's about actually putting the actual source code into the bugreport | 21:55 |
| programmerjake | which bug? | 21:55 |
| lkcl | as a non-external resource not controlled by us | 21:55 |
| lkcl | 1sec... | 21:55 |
| ghostmansd | itchy I'd say | 21:55 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=980 | 21:55 |
| lkcl | ghostmansd, is there any reason why you can't just pick up the insndb record and use that? | 21:57 |
| lkcl | it _should_ have in1=RA_OR_ZERO and/or out=RT_OR_ZERO in it | 21:57 |
| ghostmansd | yes, that's exactly what I'm going to use | 21:58 |
| ghostmansd | but the example you posted has different operands | 21:58 |
| ghostmansd | I'm asking whether some insns can have the same operand but differently "marked" | 21:59 |
| lkcl | ahh actually this is a general problem | 21:59 |
| ghostmansd | I just think whether I need to add some assertion or handle it specifically | 21:59 |
| lkcl | no, and any instruction that has different s:RA from d:RA needs to be red-flagged and sorted | 21:59 |
| ghostmansd | Yes, thanks | 21:59 |
| lkcl | it means there's a bug in sv_analysis.py | 21:59 |
| ghostmansd | That's what I wanted to hear | 22:00 |
| ghostmansd | :-) | 22:00 |
| ghostmansd | Sorry for not formulating it in an obvious way | 22:00 |
| lkcl | i finally understood what you were driving at, and fortunately it's something i've been keeping an eye on for 8+ months | 22:00 |
| lkcl | nono you raised it last week and i understood what you means | 22:01 |
| lkcl | ah i appreciate it's late, but i wanted to run an idea past you | 22:01 |
| ghostmansd | Go on :-) | 22:01 |
| ghostmansd | Is it a legal one? | 22:01 |
| * lkcl *snorts* | 22:01 | |
| lkcl | are you familiar with python's HTML and XML parser? | 22:02 |
| lkcl | https://docs.python.org/3/library/html.parser.html | 22:02 |
| lkcl | it's more an "in-order node/tree walker" | 22:02 |
| ghostmansd | Not really, hated XML throughout the entire life :-D | 22:02 |
| ghostmansd | Well I used it a couple of times | 22:02 |
| ghostmansd | dom tree or something like that | 22:02 |
| lkcl | XML just won't die, sigh | 22:02 |
| lkcl | DOM/SAX parsers, yes | 22:02 |
| ghostmansd | Nope, not in this multiverse | 22:03 |
| lkcl | one is in-memory, the other is stream-based | 22:03 |
| lkcl | well all that's bullshit, but it's along the right lines | 22:03 |
| lkcl | i'd like to consider bringing in the "node/tree-walker" thing into insndb. | 22:03 |
| ghostmansd | wow | 22:03 |
| ghostmansd | what for? :-) | 22:03 |
| ghostmansd | fields? | 22:04 |
| lkcl | not looking inwards | 22:04 |
| lkcl | but for looking outwards | 22:04 |
| lkcl | with a first view to being able to auto-generate the cavatools Decoder | 22:05 |
| lkcl | but *also* replace - ha ha - power_decoder.py by outputting *nmigen* that does the exact same job | 22:05 |
| lkcl | and | 22:05 |
| lkcl | outputting - replacing - the way that pysvp64dis works | 22:06 |
| lkcl | and (the big one): | 22:06 |
| lkcl | outputting binutils source code. | 22:06 |
| lkcl | conceptually it's a bit of a mind-bender, given that insndb is already hair-raising | 22:07 |
| ghostmansd | > given that insndb is already hair-raising | 22:08 |
| ghostmansd | that's true :-) | 22:08 |
| lkcl | but ultimately they are all of the form "here's this database, let me call a function for you, on every aspect of it: you get to do something with that" | 22:08 |
| ghostmansd | do you have some example configuration in mind? | 22:08 |
| ghostmansd | I don't quite get the structure of XMLs | 22:09 |
| lkcl | right now, there is a nested set of for-loops *explicitly* enumerating the database, inside insndb-binutils, right? | 22:09 |
| ghostmansd | Yes | 22:09 |
| ghostmansd | a total crap TBH | 22:09 |
| ghostmansd | but we have so many different formats | 22:09 |
| lkcl | (HTML/XML itself is irrelevant, a red herring: it's the *walking* that's important) | 22:09 |
| ghostmansd | I've been thinking of putting it in one giant config | 22:09 |
| ghostmansd | because we actually deal with it as a whole | 22:10 |
| lkcl | that set of nested for-loops *is* the beginning of the "walking" thing i am talking about. | 22:10 |
| lkcl | have a look at this and have a think about how it works and why it is so useful: https://docs.python.org/3/library/html.parser.html | 22:10 |
| ghostmansd | OK so you want to lookup insn's data by tag | 22:10 |
| ghostmansd | or, well, rather element | 22:11 |
| lkcl | at the moment you have: | 22:11 |
| ghostmansd | correct? | 22:11 |
| lkcl | for each insn do | 22:11 |
| lkcl | for each something in insn do | 22:11 |
| programmerjake | so you want a insndb visitor? | 22:11 |
| lkcl | action(insn, something) | 22:11 |
| lkcl | programmerjake, yes! | 22:11 |
| lkcl | ha, thank you for using the right word i couldn't think of. | 22:12 |
| lkcl | that becomes: | 22:12 |
| lkcl | for each insn do | 22:12 |
| lkcl | visitor->handle_insn(insn) | 22:12 |
| lkcl | for each something in insn do | 22:12 |
| lkcl | visitor->action(something) | 22:13 |
| ghostmansd | OK basically a walker | 22:13 |
| lkcl | that's basically what's in https://docs.python.org/3/library/html.parser.html | 22:13 |
| lkcl | yes. | 22:13 |
| ghostmansd | where does "something" come from? | 22:13 |
| ghostmansd | Ah wait | 22:13 |
| ghostmansd | It's subelement | 22:13 |
| lkcl | lkcl> for each -->>>something<<<-- in insn do | 22:13 |
| ghostmansd | aha | 22:13 |
| programmerjake | e.g. insn operands or properties | 22:14 |
| lkcl | and you can prooobbbably "morph" the existing binutils-for-loops *into* a "visitor" system | 22:14 |
| ghostmansd | Weeeeell I had some experience with parsing a huge file with x86 MSRs | 22:14 |
| programmerjake | tho imho it should call a different fn for each kind of insn thing | 22:14 |
| ghostmansd | (you can imagine how many MSRs today's Intel has) | 22:14 |
| lkcl | programmerjake, yes exactly like https://docs.python.org/3/library/html.parser.html | 22:14 |
| programmerjake | e.g. there should be an operand fn, and a encoding field fn, and etc. | 22:15 |
| lkcl | if you remember, i already ran into this problem, where i had to do a deep-dive into the insndb data structures | 22:15 |
| ghostmansd | first question: how about using lxml instead of builtin parser? | 22:15 |
| lkcl | eek, 8 months ago now | 22:16 |
| lkcl | no. | 22:16 |
| ghostmansd | sigh :-) | 22:16 |
| lkcl | the absolute worst possible thing would be to "convert" to lxml and/or xml | 22:16 |
| ghostmansd | that one was better TBH | 22:16 |
| ghostmansd | nono, I mean just lxml module | 22:16 |
| ghostmansd | for parsing vanilla xmls | 22:16 |
| ghostmansd | but OK, this doesn't matter that much | 22:16 |
| lkcl | no, because that would mean converting everything *to* xml | 22:16 |
| lkcl | which would be the absolute worst possible thing and, again, is a red-herring | 22:17 |
| lkcl | forget XML | 22:17 |
| programmerjake | if we were to use some format other than our existing format, i'd pick almost anything but xml | 22:17 |
| ghostmansd | :-D | 22:17 |
| ghostmansd | shouldn't we rename the chat to "XML haters" already? | 22:17 |
| lkcl | the only reason i mentioned it was because it is where the visitor concept exists (and is well-known) | 22:17 |
| lkcl | i am most definitely *not* saying "convert to a different database format" | 22:18 |
| programmerjake | better options would be json5 (json, but a bit more flexible around commas and includes comments) | 22:18 |
| lkcl | it is the "visitor-walker" that i am advocating | 22:18 |
| lkcl | programmerjake, no, please, no format-changing. | 22:18 |
| lkcl | that is completely off the table, as discussed several months ago | 22:18 |
| programmerjake | yeah, i agree, was mentioning what i'd pick *if* we wanted to change | 22:19 |
| ghostmansd | “XML is a classic political compromise: it balances the needs of man and machine by being equally unreadable to both.” – Matthew Might | 22:19 |
| lkcl | what is really badly needed - due to the amount of duplication that i can foresee and the complexity of using insndb - is visitor-walking | 22:19 |
| * lkcl snorts | 22:19 | |
| lkcl | programmerjake, ah got it | 22:19 |
| programmerjake | ghostmansd: XD | 22:19 |
| ghostmansd | http://harmful.cat-v.org/software/xml/ | 22:19 |
| ghostmansd | more stuff here | 22:20 |
| ghostmansd | like these pages | 22:20 |
| lkcl | oh god i don't even want to go there, i will never come back out | 22:20 |
| ghostmansd | that's just collection of quotes and notes on why XML is so fricking good :-) | 22:20 |
| * lkcl goes to the site immediately | 22:21 | |
| ghostmansd | :-D | 22:21 |
| ghostmansd | “XML combines the efficiency of text files with the readability of binary files” – unknown | 22:21 |
| ghostmansd | lmao | 22:21 |
| ghostmansd | you know, perhaps the only reason XML got invented is for people to be jerks about it :-) | 22:22 |
| lkcl | the moment XSLT came out i knew it had gone too far | 22:23 |
| lkcl | and that was... 24 years ago | 22:23 |
| lkcl | SOAP: Shit lOAds of Poop | 22:24 |
| ghostmansd | :-D | 22:24 |
| lkcl | http://harmful.cat-v.org/software/node.js | 22:25 |
| ghostmansd | these guys come from plan9 | 22:26 |
| lkcl | Node.js is one of the worst things to happen to the software industry in recent times, | 22:26 |
| ghostmansd | they always troll about other techs | 22:26 |
| ghostmansd | https://9p.io/magic/man2html/1/emacs | 22:26 |
| ghostmansd | the only section filled is BUGS | 22:26 |
| ghostmansd | the text is "Yes" | 22:26 |
| lkcl | frickin funny | 22:26 |
| ghostmansd | OS X is probably the worst *nix variant in use in the second decade of the 21sth century. | 22:27 |
| ghostmansd | Only Apple could come up with something as fucked up as an Init system built on XML. | 22:27 |
| ghostmansd | totally love'em | 22:27 |
| ghostmansd | anyway | 22:28 |
| ghostmansd | about _not_ format | 22:28 |
| lkcl | OS/X is actually FreeBSD. they demo'd it at Imperial College back in 1990. | 22:28 |
| ghostmansd | they sure diverged fricking a lot from FreeBSD | 22:28 |
| lkcl | they were so happy to have X11 "working", they hadn't had time to implement "window close" yet | 22:28 |
| lkcl | yes. | 22:28 |
| lkcl | okok one of the BSDs. | 22:28 |
| ghostmansd | 4.4BSD I think | 22:29 |
| lkcl | but we are talking *really* at the start - 1988/1989 | 22:29 |
| ghostmansd | still compared to BSDs this is a fricking nightmare | 22:29 |
| ghostmansd | (not that BSDs are pleasant per se) | 22:29 |
| ghostmansd | nothing is, though | 22:30 |
| ghostmansd | anyway, about this thing with visitors | 22:30 |
| ghostmansd | you want to keep the format | 22:30 |
| ghostmansd | you just want to replace bunch of methods related to iteration? | 22:30 |
| lkcl | it's just... different, but for me i get frustrated using BSDs because i have memorised commands for linux | 22:30 |
| ghostmansd | so that each insn element is "walkable"? | 22:31 |
| lkcl | abstract them to the "visitor" concept | 22:31 |
| lkcl | yes. | 22:31 |
| lkcl | it will evolve | 22:31 |
| ghostmansd | "and her walkman started to melt" | 22:31 |
| lkcl | the most obvious one will be "for insn in db: visitor->(insn)" | 22:31 |
| ghostmansd | the visitor is fed by user, right? | 22:32 |
| lkcl | but any moment that the visitor function has an explicit for-loop "for something in insnrecord" that is a sign that the visitor should have a new function added to it | 22:32 |
| lkcl | correct | 22:32 |
| ghostmansd | I guess I begin to understand where you head | 22:32 |
| lkcl | the guiding principle of visitor-walkers is: | 22:33 |
| ghostmansd | you want to feed different visitors depending on use case | 22:33 |
| ghostmansd | e.g. some visitor for binutils | 22:33 |
| ghostmansd | some for cavatools | 22:33 |
| ghostmansd | some for other stuff | 22:33 |
| lkcl | *under no circumstances" should the visitor-function *itself* perform iteration on the database-object | 22:33 |
| lkcl | correct. | 22:33 |
| lkcl | aaabsolutely | 22:33 |
| ghostmansd | and different modules with their own visitors | 22:33 |
| ghostmansd | I rarely say it | 22:34 |
| lkcl | 100% correct. | 22:34 |
| ghostmansd | but I fucking love the idea | 22:34 |
| lkcl | :) | 22:34 |
| ghostmansd | actually I've been thinking about it for a while | 22:34 |
| lkcl | it's one that keeps getting re-invented so is not a surprise | 22:34 |
| ghostmansd | because using insndb is way too complex as of now | 22:34 |
| lkcl | it's a "kinda-obvious OO thing" | 22:34 |
| lkcl | and all that "users" want to do is "just get on with it" | 22:35 |
| ghostmansd | kinda "gimme a big red button which makes stuff work" | 22:35 |
| lkcl | but for goodness sake do follow the pattern i suggest, which is to convert something that exists (like binutils-insndb) | 22:36 |
| lkcl | one for-loop at a time | 22:36 |
| lkcl | https://libre-soc.org/irclog/%23libre-soc.2023-05-29.log.html#t2023-05-29T22:32:49 | 22:36 |
| ghostmansd | I'd suggest "visit" method for db and "visit" method for record | 22:36 |
| lkcl | then those should be (following how it is done here: https://docs.python.org/3/library/html.parser.html) | 22:37 |
| lkcl | class MyInsnDBParser: | 22:37 |
| lkcl | def handle_db(self, ....): | 22:37 |
| lkcl | def handle_record(self, .....) | 22:38 |
| ghostmansd | So you think of checking whether there's a method to be called on visitor's instance | 22:38 |
| ghostmansd | not an explicit "visit" but rather "feed me a visitor, I'll check which methods it has" | 22:39 |
| lkcl | but bear in mind: you *will* need "entry" and "exit" functions | 22:39 |
| lkcl | yyeah there will be plenty of uses of "hasattr" here | 22:39 |
| ghostmansd | on entry and exit | 22:39 |
| lkcl | if hasattr(visitor, "handle_db"): visitor->handle_db(db) | 22:39 |
| lkcl | yes | 22:39 |
| programmerjake | you should pass indexes into the visitor too, they're useful for e.g. figuring out which index to use for a generated c array | 22:39 |
| ghostmansd | what'd be those in insndb? | 22:40 |
| lkcl | so it is more: | 22:40 |
| lkcl | class MyInsnDBParser: | 22:40 |
| lkcl | def handle_db_start(self, ....) | 22:40 |
| lkcl | def handle_db_end(self, ....) | 22:40 |
| lkcl | def handle_record_start(self, ....) | 22:40 |
| lkcl | def handle_record_end(self, ....) | 22:40 |
| ghostmansd | these start and end, what do they map to? | 22:41 |
| ghostmansd | as for simple "handle_record", it's clear: on iteration | 22:41 |
| ghostmansd | ah wait I see | 22:41 |
| programmerjake | seems easier to just have a NoOpVisitor with all the methods, just derive from that and override what you need | 22:41 |
| lkcl | well for example handle_db_start would spew out "struct x {\n" | 22:42 |
| ghostmansd | you want to handle iteration in insndb | 22:42 |
| ghostmansd | and call start on entry to iteration | 22:42 |
| lkcl | and handle_db_end would spew out the corresponding "} // end struct x;\n" | 22:42 |
| ghostmansd | and call end after | 22:42 |
| lkcl | correct. | 22:42 |
| ghostmansd | ok, this totally makes sense | 22:42 |
| lkcl | it's really detailed, but every "event" has to have a notification of some kind | 22:43 |
| ghostmansd | so folks just implement the methods they need | 22:43 |
| lkcl | correct | 22:43 |
| ghostmansd | OK, got it | 22:43 |
| lkcl | basically each and every for-loop has to have "start thing end" | 22:43 |
| ghostmansd | will get to it once finally these damn OR_ZERO are done | 22:43 |
| lkcl | so if you have nested for-loops that's six functions | 22:43 |
| programmerjake | rather than having to manually call a bunch of start/end pairs, it may be easier to use `with` | 22:44 |
| lkcl | that i suggest you output to a log file | 22:44 |
| lkcl | programmerjake, i know it's late for ghostmansd now | 22:44 |
| lkcl | (1am?) | 22:44 |
| lkcl | so let's let him get some rest and continue tomorrow. | 22:45 |
| programmerjake | sounds good, ttyl. gn | 22:45 |
| lkcl | i have a vague inkling of what "with" would look like with visitors | 22:45 |
| lkcl | and also would like to go over it | 22:45 |
| ghostmansd | yeah 1 am :-) | 22:46 |
| ghostmansd | let's continue this later | 22:46 |
| programmerjake | with visitor.db(db): | 22:46 |
| programmerjake | for insn in db: | 22:46 |
| programmerjake | with visitor.insn(insn): | 22:46 |
| programmerjake | for operand in insn: | 22:47 |
| programmerjake | ... | 22:47 |
| lkcl | 22:46 here | 22:47 |
| ghostmansd | lkcl, could you, please, raise the task? | 22:47 |
| ghostmansd | or point me to one which already exists | 22:47 |
| lkcl | ghostmansd, willdo | 22:47 |
| lkcl | it'll have to be cross-linked to a lot of other tasks | 22:47 |
| ghostmansd | I'm not sure about with thing | 22:48 |
| ghostmansd | I'd rather do visitor.visit(db) | 22:48 |
| ghostmansd | and that's it | 22:48 |
| ghostmansd | then a bunch of hasattr(visitor, "whatever") calls | 22:48 |
| ghostmansd | inside insndb | 22:48 |
| lkcl | programmerjake, ahh, the visitor has to then implement __entry__ and __exit__ on objects *in* the visitor | 22:48 |
| programmerjake | `with` basically auto-calls a start/end pair for you, makes it easy to not forget | 22:48 |
| lkcl | programmerjake, but those start/end pairs *have* to be named "__entry__" and "__exit__". | 22:49 |
| programmerjake | just use the whatever @contextmanager decorator, makes it really easy to implement | 22:49 |
| ghostmansd | but we'll end up with users implementing separate objects for each substaff | 22:49 |
| ghostmansd | and with html-like parser they just need to implement methods in one class | 22:50 |
| lkcl | yes. they'd need to create a visitor with an object visitor.db | 22:50 |
| lkcl | and another object visitor.insn | 22:50 |
| ghostmansd | yes | 22:50 |
| lkcl | each with their own separate __entry__ and __exit___ | 22:50 |
| ghostmansd | this might become messy and too classy | 22:50 |
| lkcl | i like it but it's not entirely intuitive | 22:50 |
| ghostmansd | but I'll think about it too | 22:50 |
| lkcl | if the database was flat it'd not be a problem at all | 22:50 |
| programmerjake | https://docs.python.org/3/library/contextlib.html#contextlib.contextmanager | 22:50 |
| ghostmansd | there are benefits here that it's, so to speak, modern and well-known | 22:51 |
| ghostmansd | but perhaps way too classy | 22:51 |
| programmerjake | ignore that it internally uses __enter__/__exit___ | 22:51 |
| ghostmansd | needs to be thought | 22:51 |
| ghostmansd | no the naming is not an issue | 22:51 |
| ghostmansd | separate classes are | 22:51 |
| lkcl | yes it does. ok i'll cross-ref it in the bugreport, let's pick it up another time | 22:51 |
| ghostmansd | but perhaps not a critical one | 22:51 |
| programmerjake | basically contextmanager puts the with body behind the yield in the method | 22:52 |
| programmerjake | so you can easily do stuff before/after the with body | 22:52 |
| ghostmansd | ah wait I see, it wraps __enter__/__exit__ for us | 22:52 |
| ghostmansd | then it might be a good choice | 22:53 |
| ghostmansd | the problem I worried about is that users will have to write these methods | 22:53 |
| lkcl | there's ways to make contextmanager a retro-fit | 22:53 |
| programmerjake | imho writing the methods are easy with contextmanager | 22:54 |
| lkcl | ok leave it with me to write the bugreport folks | 22:54 |
| programmerjake | thx lkcl | 22:54 |
| programmerjake | i'll add a comment with contextmanager idea | 22:55 |
| ghostmansd | thanks! | 22:55 |
| ghostmansd | see you later | 22:55 |
| ghostmansd | thanks for discussion | 22:56 |
| programmerjake | gn | 22:56 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 23:01 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!