| ghostmansd[m] | Speaking of comments, another thing makes me nervous: I'm used to the fact that semicolon is a comment in Intel assembly flavour. I'd rather not join the lines with "; ", but instead output all of them separately. I know it's annoying that 1 assembly line generates 3, though, so kinda unsure about it. Opinions? | 00:35 |
|---|---|---|
| programmerjake | imho we shouldn't join lines with `;`, which allows us to re-add the comment of the svp64 instruction on the svp64 prefix .long -- since that's what shows up in debug traces, the suffix gets skipped in SILENCELOG=!instr_in_outs mode | 00:38 |
| programmerjake | though if all else fails, we should add the comment using /* sv.myinstr */ rather than # sv.myinstr | 00:39 |
| programmerjake | which allows ; to still work | 00:40 |
| lkcl | ghostmansd[m], the ISACaller simulator critically relies on one instruction in the listing corresponding to one binary instruction | 01:55 |
| lkcl | it's incapable of performing disassembly at the moment so "cheats" by having direct one-to-one association with a pre-provided pre-arranged list | 01:55 |
| lkcl | which is why it is not ok to add comments on separate lines | 01:55 |
| lkcl | and it is why the .longs are on a single line | 01:56 |
| programmerjake | .longs always on a separate line -- hence why I thought it was fine to add a comment on the prefix .long | 02:03 |
| programmerjake | lkcl: > if the compiler was used even by 200 people it would begin to just about justify a rewrite. | 05:24 |
| programmerjake | imho a rewrite is justified because our simulator is the *only* one which automatically matches the spec, since it ingests the spec's pseudocode. | 05:24 |
| programmerjake | therefore our simulator should be one that other people designing PowerISA cpus or new instructions for PowerISA (I expect Libre-SOC will be far from the only ones doing that) would want to test against, which requires a rewrite because currently our code is in such a sorry state that most people would look elsewhere. | 05:24 |
| programmerjake | Because of that, I think it's justifiable to dedicate one person's time for 2 weeks to trying to do that. We should strive for our simulator to become a official OpenPower Foundation endorsed reference simulator imho. | 05:24 |
| programmerjake | or at least it's the only one I'm aware of that ingests the spec's pseudocode. | 05:25 |
| ghostmansd[m] | I think we actually now can construct the assembly even for the legacy instructions. | 06:20 |
| programmerjake | yay! | 06:21 |
| ghostmansd[m] | We have opcodes and list of operands, grouped in one place, power_insn. | 06:21 |
| ghostmansd[m] | So we could perhaps make our pysvp64asm output binary data directly, or at least output .long/.llong... | 06:22 |
| ghostmansd[m] | ...then extend the disassembly bits to deal with all possible codes... | 06:22 |
| ghostmansd[m] | (I mean both pysvp64dis and any other parts which need the disassembly) | 06:23 |
| ghostmansd[m] | This still will be a big task, but I think it's doable. | 06:23 |
| ghostmansd[m] | lkcl, could you, please, raise the task about unifying the code wrt fields, and pysvp64dis? This definitely goes above and beyond binutils. I'd do it on my own, but I'm not sure what the parent task would be. | 07:43 |
| ghostmansd[m] | Or, please, at least point me to the right parent task, so that I at least have a place to raise children tasks. | 07:44 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 07:44 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 07:55 | |
| programmerjake | lkcl: I found a strange bug/feature, when assembling, svstep subtracts 1 from SVi, but sv.svstep doesn't...is this a special case or an accident? | 08:16 |
| programmerjake | imho the assembler should treat SVi identically between svstep and sv.svstep | 08:23 |
| ghostmansd | programmerjake, do you mean pysvp64asm? | 08:30 |
| ghostmansd | as for svstep, there's `def svstep` insn which handles this | 08:30 |
| programmerjake | I mean src/openpower/sv/trans/svp64.py | 08:32 |
| programmerjake | there's both def svstep which handles "svstep" but not "sv.svstep" and a special case for "sv.svstep" | 08:32 |
| ghostmansd | Yeah to best of my knowledge there's none | 08:34 |
| ghostmansd | Should there be? I've been under impression it'll subtract 1 from the remapped instruction | 08:34 |
| ghostmansd | That is, there will be .long prefix + svstep | 08:35 |
| programmerjake | special case (before commits I just pushed): https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=1bb8e697db2356b1b98a298d610b5ac5bb953fb7;hb=34372f94118eacf57d142be3a5323f2f9422119a#l1284 | 08:35 |
| programmerjake | I changed it to use CUSTOM_INSNS for everything by default, but to get the tests to pass, I had to add: | 08:36 |
| programmerjake | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=53bc77287d7023250bd18a7a850096472674535c;hb=HEAD#l1298 | 08:36 |
| programmerjake | I also added a decorator that makes defining custom instructions look a whole lot nicer: https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=63fd4ebc03ea0a7d51a1cf8d215affe45e0f0b33 | 08:38 |
| programmerjake | as for wether or not the subtract 1 should happen, idk, hence why I asked lkcl | 08:38 |
| ghostmansd | programmerjake, I like the decorator, thanks! | 08:40 |
| ghostmansd | Ideally we should build these from power_insn Database... | 08:40 |
| programmerjake | :) | 08:40 |
| ghostmansd | I remember about it, just don't have time for that now | 08:41 |
| programmerjake | yeah, nicer is better, but not needing to write instruction assembler functions is best | 08:41 |
| markos | programmerjake, lkcl if the simulator should be rewritten, please do it in a compiled language, be it Rust or C, I agree with programmerjake on this, though I highly doubt it would just take 2 weeks, unless you eat/breath coffee :) | 09:07 |
| markos | I wish I was better at rust, fwiw | 09:08 |
| markos | python is easy to read/write but it's slooow... | 09:08 |
| programmerjake | I didn't say 2 weeks to be completed, I said 2 weeks to be mostly working. | 09:08 |
| programmerjake | at that point, we'd just have to find all the missing corner cases. | 09:08 |
| markos | heh, it's the remaining 20% that takes 80% of the time :D | 09:09 |
| markos | but ok, I admit I don't know how complex the codebase is | 09:09 |
| programmerjake | also, I'm rewriting the parser, not the whole simulator... | 09:10 |
| programmerjake | imho it should be C++ or Rust. we can get away with not using python because the compiler doesn't need to talk to python as it's running, only the generated output c/python file does. | 09:11 |
| programmerjake | so, e.g. we could write it in XSLT (yuck) and it could still work, no XSLT<-> python bindings needed | 09:12 |
| markos | I could help with C++ but not Rust, otoh, I'd be more interested in a Rust rewrite, if only to directly compare and see the benefits | 09:13 |
| markos | but ofc it's not my decision | 09:13 |
| markos | C++ I know it will work, after a daily dose of cursing and swearing at the language, but it will work and it will be fast in the end | 09:14 |
| programmerjake | c++ vs. rust, execution speed would be similar, speed to write and understandability would take a big hit with c++ though... | 09:14 |
| programmerjake | and c++ would be prone to randomly segfaulting for crazy inputs | 09:15 |
| markos | esp tracking down stupid bugs | 09:15 |
| markos | story of my life | 09:15 |
| programmerjake | rust is actually nicer than both c++ and python, it's really easy to refactor, python you'll be left with a bunch of stuff just waiting to give you a TypeError, c++ will give you a 587 page template backtrace, and when you finally get it to compile, it'll segfault | 09:17 |
| programmerjake | (exaggerating for effect...) | 09:17 |
| programmerjake | python: or AttributeError, or ValueError, or silently wrong output... | 09:18 |
| programmerjake | though technically python is a compiled language...it compiles to cpython byte code and gets stored in .pyc files, kinda like Java | 09:21 |
| markos | let me rephrase that, a *fast* compiled language :) | 09:41 |
| ghostmansd | Folks, do we have some way to understand which field is not an operand? | 10:01 |
| ghostmansd | Speaking of fields.text. We know that Rc field goes into instruction itself. So is, I guess, OE? | 10:02 |
| ghostmansd | Any others? | 10:02 |
| ghostmansd | I'd like to be able to skip fields which are not operand-related... | 10:02 |
| ghostmansd | ...but I have no idea how to do it in sane way. | 10:02 |
| programmerjake | not that I'm aware of, though I could have missed something | 10:03 |
| programmerjake | assuming you're talking about fields in fields.txt and similar | 10:03 |
| programmerjake | yes, afaict | 10:03 |
| programmerjake | maybe load/store size? | 10:04 |
| programmerjake | or cr operation? icr if those are a separate field or just mushed into PO/XO | 10:05 |
| markos | OT, lkcl toshywoshy remember that discussion about movemask on power? turns out vgbbd (vec_gb intrinsic) works out great, 2x and in some cases 3x perf increase already :) | 10:05 |
| markos | only needs vec_gb and a perm to move the bytes around and voila, there's your movemask | 10:06 |
| ghostmansd | programmerjake Hm. I think the safest way is determining those which are operands. | 10:07 |
| ghostmansd | We have all these inX/outX stuff... Perhaps we could rely on these. | 10:07 |
| programmerjake | maybe add it to fields.txt right before `Formats: ...` in each field? | 10:07 |
| ghostmansd | And then, everything else, is going to be non-operand. | 10:07 |
| programmerjake | since iirc that's free-form text there | 10:08 |
| ghostmansd | IIRC yes, but I bet lkcl would oppose changing that. :-) | 10:08 |
| ghostmansd | But I think we're safe with checking the operands instead. | 10:08 |
| programmerjake | but that won't work because immediates... | 10:10 |
| ghostmansd | I think we can even manage the order in which these follow... | 10:10 |
| programmerjake | immediates aren't an input/output but they show up in arguments in asm | 10:10 |
| ghostmansd | They are operands still. | 10:10 |
| ghostmansd | e.g. addic has SI operand | 10:11 |
| ghostmansd | And we see that addic is (RT,RA,SI) | 10:11 |
| ghostmansd | So this is the order... | 10:11 |
| programmerjake | not all of them are... e.g. cmpli iirc | 10:11 |
| ghostmansd | lemme check | 10:11 |
| ghostmansd | No, it has UI operand | 10:11 |
| ghostmansd | (BF,L,RA,UI) | 10:12 |
| programmerjake | yes, but the asm also has BF and L operands | 10:12 |
| ghostmansd | For each instruction, we're able to understand its form | 10:12 |
| programmerjake | which I had remembered not being passed to the fu in soc as immediate inputs, just decoded from the instruction instead | 10:13 |
| ghostmansd | And we're also able to get its operands (mdwn I think?) | 10:13 |
| programmerjake | ah, yeah, I guess it works there...since the markdown has the assembly syntax | 10:14 |
| programmerjake | though imho if you use the pseudocode as a source of truth, double check that it's not missing anything in your code, since there are probably some edge cases somewhere | 10:15 |
| ghostmansd | I have nothing better to rely on... :-) | 10:16 |
| programmerjake | e.g. if you're filtering the list of fields by the list of asm operands, check that all asm operands are included in the fields, otherwise we have a discrepancy | 10:16 |
| ghostmansd | If it's broken -- well, no better option. | 10:16 |
| ghostmansd | But yeah, I'll cross-check these. | 10:16 |
| ghostmansd | I'm not sure whether we collect this information, though. | 10:17 |
| ghostmansd | I mean, we for sure collect it somewhere, but likely it's missing from power_insn. | 10:17 |
| programmerjake | iirc for the script lkcl wrote to generate the svp64 forms, he just has a allowlist hardcoded in the script | 10:17 |
| ghostmansd | Perhaps you know the place where we collect this stuff from mdwn? | 10:19 |
| ghostmansd | I recall these are converted to Python... | 10:19 |
| ghostmansd | But when it's used? Do we have some place where I could take, say, instruction name, and find its operands? | 10:19 |
| ghostmansd | Ah yeah, the infamous pywriter... | 10:21 |
| programmerjake | it's parsed in src/openpower/decoder/pseudo/pagereader.py line 244 commit cfd0215fc6f716317eb22d04d965028eb794965b | 10:21 |
| ghostmansd | Aha, thank you! | 10:23 |
| programmerjake | so if you run pagereader.py, it'll dump the regs for all the ops, in ISA.pprint_ops() | 10:23 |
| programmerjake | called regs, but really just the asm operands | 10:23 |
| ghostmansd | Yes... ISA.instr | 10:26 |
| ghostmansd | OK, this should be sufficient. I even recall we grab parts of these. | 10:26 |
| ghostmansd | Yeah I think all we needed is src/openpower/decoder/isa/all.py. | 10:30 |
| ghostmansd | No pun intended, all we need is all.py :-) | 10:30 |
| ghostmansd | Fuck. We have a cyclic dependency. | 10:42 |
| ghostmansd | I need an ISA from openpower.decoder.isa.all | 10:42 |
| ghostmansd | That one depends on openpower.decoder.isa.caller... | 10:42 |
| ghostmansd | and the caller, since recent, depends on power_insn. | 10:43 |
| ghostmansd | Which needs to import ISA. | 10:43 |
| lkcl | ghostmansd, there are two "ISA"s. you may have the wrong one | 10:44 |
| ghostmansd | Do you suggest this? from openpower.decoder.pseudo.pagereader import ISA | 10:44 |
| programmerjake | that's what I'd do... | 10:45 |
| ghostmansd | Hm, seems it should do the trick... | 10:46 |
| ghostmansd | Let me check | 10:46 |
| programmerjake | though maybe see if you can pass it an option to not fully parse the mdwn, we don't need the AST here... | 10:46 |
| lkcl | markos, the python-ply-based compiler is used once and only once per change of mdwn spec files. speed is not in the least bit important. | 10:46 |
| programmerjake | speed is somewhat important, I don't want to have to wait 10m each time I change the pseudocode | 10:46 |
| lkcl | programmerjake, *when* other people begin designing Power ISA CPUs using our techniques they can also PAY us MONEY to satisfy THEIR need. | 10:47 |
| programmerjake | somewhere <10-15s is fine | 10:47 |
| ghostmansd | Do you mean pywriter? It takes 6 seconds. | 10:47 |
| programmerjake | when other people begin designing cpus using our techniques, they'll look at our code and say "I'm doing this myself, their code is too messy to use" | 10:48 |
| programmerjake | so they won't be paying us for that, because they don't want a repeat of our code | 10:48 |
| lkcl | definitely a bug if SVi is not the same across sv.svstep and sv.svstep. | 10:48 |
| lkcl | > <programmerjake> also, I'm rewriting the parser, not the whole simulator... | 10:49 |
| lkcl | if you are doing that please STOP | 10:49 |
| lkcl | i have already told you NO | 10:49 |
| programmerjake | i meant that's what I proposed to do, I'm not currently doing that | 10:49 |
| programmerjake | the discrepancy is between sv.svstep vs plain svstep, not between Rc=0/1 | 10:50 |
| programmerjake | wow, CI took >2hr and one of the pytest processes crashed: https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/3164692 | 12:15 |
| programmerjake | looks like I'll have to optimize the tests somewhat | 12:15 |
| programmerjake | maybe a memory leak? | 12:15 |
| lkcl | there's a problem with python 3.7 that actually triggers actual segfaults in /usr/bin/python3.7 | 12:25 |
| lkcl | i had to add at least two workarounds | 12:25 |
| programmerjake | it looked more like maybe SIGKILL to me, though i'd have to read the logs in more detail -- tomorrow. need sleep before meeting | 12:27 |
| ghostmansd | the pagereader is broken for cases when operands have spaces | 12:30 |
| ghostmansd | e.g. `* grev RT, RA, RB (Rc=0)` | 12:30 |
| ghostmansd | it'll think RA and RB are opcodes, too | 12:31 |
| ghostmansd | This is caused by the fact that pagereader is way too limited in parsing | 12:31 |
| ghostmansd | I'll fix it | 12:31 |
| ghostmansd | lkcl, in case you missed, https://libre-soc.org/irclog/%23libre-soc.2022-08-30.log.html#t2022-08-30T07:43:19 | 12:31 |
| *** octavius <octavius!~octavius@197.147.93.209.dyn.plus.net> has joined #libre-soc | 12:58 | |
| lkcl | ghostmansd, yes, this is an error in the pseudocode. it should not have been written with spaces. | 13:19 |
| ghostmansd | Well I've taught it to consider spaces anywhere | 13:19 |
| lkcl | that may have knock-on complications. | 13:20 |
| lkcl | the correct action is to remove the spaces which i will do now | 13:20 |
| ghostmansd | Because logically there's no problem with spaces per se (opcode SPACE dynamic-operands SPACE static-operands-with-values-in-parantheses) | 13:20 |
| ghostmansd | And, what's worse, the parser does not at all bothers by the fact that input is broken | 13:21 |
| lkcl | further down the line there is code that will also rely on no spaces | 13:21 |
| lkcl | because it was written in an extreme hurry because we are under funding and time pressure | 13:21 |
| ghostmansd | Yeah I know | 13:23 |
| ghostmansd | My point is, I'm fixing these things now, and letting you know what I fix and why | 13:23 |
| lkcl | i'm currently going through things i can't discuss in detail publicly to get SVP64 upstream. | 13:23 |
| ghostmansd | Because the fact that it's broken is not an issue. The issue is that it's _silently_ broken. | 13:24 |
| ghostmansd | So yeah I decided you might want to know. | 13:24 |
| lkcl | there's resistance because we don't have working demos, power estimates, performance estimates | 13:24 |
| lkcl | it would be better to throw an error if spaces are found, yes. | 13:24 |
| lkcl | pagereader.py simply reads the line and shoves it in a dict | 13:24 |
| ghostmansd | Well I taught it to recognize regardless of spaces. | 13:24 |
| lkcl | it does *not* actually parse it | 13:24 |
| ghostmansd | And raise an error if nothing can be recognized. | 13:25 |
| lkcl | that will result in down-stream errors | 13:25 |
| lkcl | because of assumptions in the rest of the code that there will be no spaces | 13:25 |
| ghostmansd | Anything particular to test? | 13:25 |
| lkcl | so it is better to throw an error if spaces are detected | 13:25 |
| ghostmansd | I've checked src/openpower/decoder/pseudo/pagereader.py | 13:25 |
| ghostmansd | That is, its main | 13:25 |
| lkcl | i didn't get round to writing unit tests for it as it's so critical it gets run all the time | 13:26 |
| lkcl | programmerjake, you broke svstep. look again at the spec please. | 14:02 |
| lkcl | https://libre-soc.org/openpower/sv/svstep/ | 14:02 |
| lkcl | please for goodness sake do not make arbitrary changes like this | 14:02 |
| lkcl | you have absolutely no idea what you are doing, because you have not been directly involved in actually implementing anything. | 14:03 |
| lkcl | programmerjake, you have not kept to 1-purpose 1-commit | 14:08 |
| lkcl | *please follow the rules* | 14:08 |
| lkcl | i cannot now revert the mistake that you made, i am forced to investigate where the fuck it is | 14:08 |
| lkcl | you *cannot* make assumptions and blithely go ahead and make arbitrary changes like this | 14:09 |
| lkcl | fucking fucking hell | 14:13 |
| lkcl | ERROR: test_svstep_iota (__main__.DecoderTestCase) | 14:13 |
| lkcl | tests svstep "straight", placing srcstep, dststep into vector | 14:13 |
| lkcl | line 490, in __getattr__ | 14:13 |
| lkcl | return globals()[attr] | 14:13 |
| lkcl | KeyError: 'remap_idxs' | 14:13 |
| lkcl | will people *PLEASE* be more careful. | 14:13 |
| lkcl | this is in master branch | 14:13 |
| lkcl | you CANNOT blithely make arbitrary changes without FULL testing. | 14:16 |
| lkcl | programmerjake, i'm backing out EVERYTHING that you've done. i'm really cross with you for wasting my time here, you KNOW you have to be more careful. | 14:19 |
| lkcl | if you cannot act responsibly here i am going to ban you from write-access to openpower-isa and only permit you to operate in branches | 14:22 |
| lkcl | which will force you to undergo a proper review and proper testing before committing | 14:22 |
| * lkcl now re-running all the unit tests. | 14:24 | |
| lkcl | ghostmansd, your code is left in (not reverted) because i can see that it's in areas that do not impact the simulator / translation | 14:24 |
| lkcl | i'm re-running all unit tests just to make absolutely sure, though | 14:25 |
| ghostmansd | sure, Luke | 14:47 |
| ghostmansd | please let me know if any issues appear | 14:47 |
| ghostmansd | I generally try to stay away from master, as you know | 14:47 |
| ghostmansd | unless the changes are really minor or not used by anyone but me (sv_binutils, pysvp64dis, etc.) | 14:48 |
| ghostmansd | OK it seems to work now | 15:11 |
| ghostmansd | WAS | 15:11 |
| ghostmansd | addo [['RB'], 'Rc=0'] | 15:11 |
| ghostmansd | Oops | 15:11 |
| ghostmansd | WAS | 15:11 |
| ghostmansd | [['RT', 'RA', 'RB'], '(OE=1', 'Rc=0)'] | 15:11 |
| ghostmansd | for addo | 15:11 |
| ghostmansd | popcntb [['RA', ''], 'RS'] | 15:12 |
| ghostmansd | BECAME | 15:12 |
| ghostmansd | addo [['RB'], 'Rc=0'] | 15:12 |
| ghostmansd | popcntb [['RA', 'RS']] | 15:12 |
| ghostmansd | so yeah, the issue was not only in bitmanip | 15:12 |
| ghostmansd | lkcl, when you have time, could you, please, take a look at pagereader branch? | 15:14 |
| ghostmansd | updated that branch one more time | 15:26 |
| ghostmansd | addo (Operand(name='RT', value=None), Operand(name='RA', value=None), Operand(name='RB', value=None), Operand(name='OE', value='1'), Operand(name='Rc', value='0')) | 15:30 |
| ghostmansd | addo. (Operand(name='RT', value=None), Operand(name='RA', value=None), Operand(name='RB', value=None), Operand(name='OE', value='1'), Operand(name='Rc', value='1')) | 15:30 |
| ghostmansd | Cool. Cool cool cool. | 15:30 |
| ghostmansd | Congrats folks, now we know exactly all instructions and which operands they have. | 15:31 |
| ghostmansd | Even better! | 15:40 |
| ghostmansd | addo (DynamicOperand(name='RT'), DynamicOperand(name='RA'), DynamicOperand(name='RB'), StaticOperand(name='OE', value=1), StaticOperand(name='Rc', value=0)) | 15:40 |
| ghostmansd | addo. (DynamicOperand(name='RT'), DynamicOperand(name='RA'), DynamicOperand(name='RB'), StaticOperand(name='OE', value=1), StaticOperand(name='Rc', value=1)) | 15:40 |
| ghostmansd | We can differ between dynamic operands (provided by caller) and static ones (being part of instruction). | 15:41 |
| ghostmansd | I'm now putting it all together. FYI, we have 4 sources in total: "scalar" CSVs (which I called PPC database for unknown reasons), "svp64" CSVs (LDST|RM ones), fields.text and markdown (pagereader). | 16:13 |
| ghostmansd | All should act together, and can be used for instruction encoding/decoding. | 16:14 |
| ghostmansd | Obviously the situation is more complicated than it looks. PPC database doesn't differ Rc (that is, one entry for both add and add.). Some instructions can be available under different names (mtcrf/mtocrf). Some have awful names (0/14=fctiw). And, of course, many more. | 16:22 |
| lkcl | ghostmansd, willdo, 1 sec | 16:49 |
| ghostmansd | sorry, this was with regexes :-) | 16:50 |
| ghostmansd | this was simpler and shorter than handling corner cases | 16:50 |
| ghostmansd | There's an error which drops sv.WHATEVER instructions, will update | 17:02 |
| ghostmansd | Done | 17:02 |
| ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=898#c31 | 17:07 |
| lkcl | is that checking that operands do not have a space and then throwing an assertion? | 17:07 |
| ghostmansd | No, it considers the spaces, too. But act more intuitively. | 17:07 |
| lkcl | apologies, i wasn't clear: i don't want spaces *at all* to be accepted in the operation. | 17:08 |
| ghostmansd | It checks for OPCODE (optional OPERANDS) (optional KEY=VALUE operands) | 17:08 |
| lkcl | this is because there is other code downstream which assumes that there is no spaces | 17:08 |
| lkcl | and we do not have time to go hunting for that code, let alone "fixing" it | 17:08 |
| ghostmansd | Why do we have spaces, then? | 17:09 |
| lkcl | there is only 4.5 weeks remaining until we can no longer claim any money | 17:09 |
| lkcl | because jacob made the mistake of putting the spaces in and i did not notice | 17:09 |
| ghostmansd | And why this code downstream doesn't check for spaces? | 17:09 |
| ghostmansd | Again: it's not only Jacob | 17:09 |
| ghostmansd | popcnt* also affected. | 17:09 |
| lkcl | because i wrote that code - and it was two years ago - and i cannot now remember and... | 17:09 |
| lkcl | then i will fix that | 17:09 |
| ghostmansd | And many others. | 17:09 |
| lkcl | right now | 17:10 |
| ghostmansd | OK but please _validate_ the input | 17:10 |
| ghostmansd | addo [['RT', 'RA', 'RB'], '(OE=1', 'Rc=0)'] | 17:10 |
| ghostmansd | This is _not_ the kind of validation I'd expect | 17:10 |
| ghostmansd | popcntb [['RA', ''], 'RS'] | 17:10 |
| ghostmansd | This is not either | 17:11 |
| ghostmansd | If there's a code downstream which silently "works" with this -- well, we have a problem | 17:11 |
| ghostmansd | I can adopt the regex so that it doesn't allow spaces | 17:11 |
| ghostmansd | But my point is, how does it even work now? | 17:12 |
| lkcl | i don't know - and i don't have time to investigate | 17:12 |
| ghostmansd | OK I'll adopt the regex | 17:12 |
| lkcl | *i* am under pressure at the moment, i have too much going on | 17:12 |
| ghostmansd | I am too | 17:12 |
| ghostmansd | These 4.5 weeks are for me too | 17:13 |
| lkcl | the other Grants are active, still - cavatools and bitmanip | 17:13 |
| lkcl | they're USD 50,000 each so is not a problem | 17:14 |
| lkcl | it's all the other ones that are going away | 17:14 |
| ghostmansd | The thing is that two months of work go down the drain, then | 17:14 |
| ghostmansd | It's kinda personal | 17:14 |
| lkcl | ...? | 17:14 |
| ghostmansd | I mean, I really want to complete binutils works | 17:14 |
| ghostmansd | Under the grant this was established | 17:14 |
| lkcl | that work can continue.... under the *other* grant | 17:15 |
| lkcl | the cavatools one in particular | 17:15 |
| lkcl | and within about 4-7 weeks we will then hear whether the two *more* grants (each EUR 100,000 each) have been accepted | 17:16 |
| ghostmansd | Isn't this grant gonna be expired? | 17:16 |
| ghostmansd | I mean, the one for binutils | 17:16 |
| lkcl | cavatools no | 17:16 |
| lkcl | there are *eight* grants with another 2 applied for | 17:16 |
| ghostmansd | This would mean that money for binutils simply burn | 17:16 |
| lkcl | 6 of those grants end mid-october | 17:16 |
| lkcl | 2 of those grants do ***NOT*** repeat ***NOT*** end | 17:16 |
| lkcl | one of those 2 grants is cavatools | 17:17 |
| lkcl | your work can CONTINUE under the CAVATOOLS grant | 17:17 |
| lkcl | which does NOT repeat NOT end in mid-october | 17:17 |
| ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=898 | 17:17 |
| ghostmansd | Assuming this task. What happens to the budget? | 17:17 |
| lkcl | but the less that is done right now BEFORE mid-october, the less money will be for everyone else who will have to do work on cavatools | 17:18 |
| lkcl | that one is for one of the 6 grants | 17:18 |
| lkcl | it *has* to be done before mid-october | 17:18 |
| ghostmansd | Yes, this is my point. | 17:18 |
| lkcl | therefore things like working on pagereader are a serious distraction | 17:18 |
| ghostmansd | If it's not done, the money will have to be allocated from cavatools. | 17:18 |
| lkcl | yes, precisely. | 17:19 |
| lkcl | which puts pressure on everyone else, financially, because EUR 50,000 will not go a long way between 4-5 people | 17:19 |
| lkcl | so the more that is done before mid-october, the more money for everyone else | 17:19 |
| lkcl | "nice-to-have" *has* to take a back seat at the moment | 17:20 |
| ghostmansd[m] | OK, then we're on the same page | 17:21 |
| ghostmansd[m] | I'll update the regex | 17:22 |
| ghostmansd[m] | And fix the broken entries with spaces | 17:22 |
| ghostmansd[m] | Deal? | 17:22 |
| lkcl | ok :) | 17:23 |
| lkcl | whilst we've been talking i've done popcnt already | 17:23 |
| ghostmansd | lkcl, speaking of "static" operands, e.g. Rc=1, Oe=1, etc. | 17:36 |
| ghostmansd | Should these be separated by comma or by space | 17:36 |
| ghostmansd | e.g. `* addo. RT,RA,RB (OE=1 Rc=1)` | 17:37 |
| lkcl | space. no change to those | 19:06 |
| lkcl | (actually anything in brackets is completely ignored) | 19:06 |
| ghostmansd | > (actually anything in brackets is completely ignored) | 19:08 |
| ghostmansd | no longer :-) | 19:08 |
| ghostmansd | or should I say, never more? | 19:08 |
| ghostmansd | Quoth the Raven “Nevermore!" | 19:09 |
| ghostmansd | Can it be that there are only "static" operands? | 19:16 |
| ghostmansd | That is, no user-provided operands on input/output, but only Rc/OE | 19:16 |
| ghostmansd | lkcl, done | 19:43 |
| ghostmansd | +bpermd, cdtbcd, cbcdtd | 19:44 |
| ghostmansd | The code seems to be simplified compared to original version. I now check all components separately. | 19:44 |
| ghostmansd | pagereader branch | 19:45 |
| ghostmansd | I checked pywriter and pagereader, both seem to work. | 19:45 |
| lkcl | ok brilliant, let me run some tests.... | 20:11 |
| ghostmansd | cf also dis branch | 20:12 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=12cbb1b9e1f9c2978c9721cbad04e892d2cbbc5f;hb=adefa3af2343f5bce4bd8048db4a54f4a2bf355c#l471 | 20:12 |
| ghostmansd | I think we finally handled Rc and Oe properly | 20:13 |
| ghostmansd | So basically the only missing bit for scalar disassembler, I think, are dynamic operands | 20:13 |
| lkcl | you mean pseudo-operations? like "beq" is.. something like... "bc 20," or something? | 20:16 |
| lkcl | those are completely off the list, i don't want to go anywhere near them | 20:17 |
| lkcl | ouch. loadavg 21 running tests. can't do browser at same time | 20:18 |
| ghostmansd | nope, I mean the disassembler and the operands | 20:22 |
| ghostmansd | to encode/decode, we must know the operands ranges | 20:22 |
| lkcl | oh you mean what was discussed yesterday? | 20:23 |
| ghostmansd | nope | 20:24 |
| ghostmansd | how would I :-) | 20:24 |
| *** dhill[m] <dhill[m]!~dhilldecr@2001:470:69fc:105::1:64d9> has joined #libre-soc | 20:25 | |
| lkcl | branches with LK=1 do not have their own csv line in microwatt because microwatt tackles LK=1 explicitly inside the pipelines | 20:26 |
| *** dhill[m] <dhill[m]!~dhilldecr@2001:470:69fc:105::1:64d9> has left #libre-soc | 20:27 | |
| lkcl | LK=1 is bit 31, like Rc=1 | 20:27 |
| lkcl | so just like you get "." on the end and that means Rc=1 | 20:27 |
| lkcl | you also get "l" on the end and that means LK=1 | 20:28 |
| lkcl | but you do *not* get a separate csv line for "add." | 20:28 |
| lkcl | you just get, "add" | 20:28 |
| lkcl | and likewise you do *not* get a separate csv line for "bcctrl" | 20:28 |
| lkcl | you just get, "bcctr" | 20:28 |
| ghostmansd | Well, I think we should be ready for such tricks now | 20:31 |
| ghostmansd | Hooray! | 20:32 |
| ghostmansd | I got scalar disassembler working | 20:32 |
| ghostmansd | At least for these two instructions I checked :-) | 20:32 |
| lkcl | ok all good in pagereader branch. rebased and pushed | 20:37 |
| ghostmansd | Thanks! | 20:38 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 20:45 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 20:46 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC | 20:55 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 20:55 | |
| *** josuah <josuah!~irc@46.23.94.12> has quit IRC | 20:55 | |
| *** yambo <yambo!~yambo@184.166.146.205> has quit IRC | 20:55 | |
| *** ckie <ckie!~ckie@user/cookie> has quit IRC | 20:55 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has quit IRC | 20:55 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC | 20:55 | |
| *** mx08 <mx08!~mx08@user/mx08> has quit IRC | 20:55 | |
| *** kanzure <kanzure!~kanzure@user/kanzure> has quit IRC | 20:55 | |
| *** rsc <rsc!~robert@fedora/rsc> has quit IRC | 20:55 | |
| *** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC | 20:55 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 20:56 | |
| *** josuah <josuah!~irc@46.23.94.12> has joined #libre-soc | 20:56 | |
| *** yambo <yambo!~yambo@184.166.146.205> has joined #libre-soc | 20:56 | |
| *** ckie <ckie!~ckie@user/cookie> has joined #libre-soc | 20:56 | |
| *** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has joined #libre-soc | 20:56 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc | 20:56 | |
| *** rsc <rsc!~robert@fedora/rsc> has joined #libre-soc | 20:56 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc | 20:56 | |
| *** kanzure <kanzure!~kanzure@user/kanzure> has joined #libre-soc | 20:56 | |
| *** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc | 20:56 | |
| *** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc | 20:56 | |
| *** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC | 20:57 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC | 20:57 | |
| *** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc | 20:58 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC | 20:59 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC | 20:59 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC | 20:59 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC | 20:59 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 21:00 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 21:02 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 21:02 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC | 21:03 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 21:20 | |
| *** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc | 21:27 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 21:32 | |
| *** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc | 21:58 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc | 22:31 | |
| *** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc | 23:17 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc | 23:20 | |
| *** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc | 23:25 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!