Tuesday, 2022-08-30

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
programmerjakeimho 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 mode00:38
programmerjakethough if all else fails, we should add the comment using /* sv.myinstr */ rather than # sv.myinstr00:39
programmerjakewhich allows ; to still work00:40
lkclghostmansd[m], the ISACaller simulator critically relies on one instruction in the listing corresponding to one binary instruction01:55
lkclit's incapable of performing disassembly at the moment so "cheats" by having direct one-to-one association with a pre-provided pre-arranged list01:55
lkclwhich is why it is not ok to add comments on separate lines01:55
lkcland it is why the .longs are on a single line01:56
programmerjake.longs always on a separate line -- hence why I thought it was fine to add a comment on the prefix .long02:03
programmerjakelkcl: > if the compiler was used even by 200 people it would begin to just about justify a rewrite.05:24
programmerjakeimho 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
programmerjaketherefore 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
programmerjakeBecause 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
programmerjakeor 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
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 IRC07:44
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc07:55
programmerjakelkcl: 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
programmerjakeimho the assembler should treat SVi identically between svstep and sv.svstep08:23
ghostmansdprogrammerjake, do you mean pysvp64asm?08:30
ghostmansdas for svstep, there's `def svstep` insn which handles this08:30
programmerjakeI mean src/openpower/sv/trans/svp64.py08:32
programmerjakethere's both def svstep which handles "svstep" but not "sv.svstep" and a special case for "sv.svstep"08:32
ghostmansdYeah to best of my knowledge there's none08:34
ghostmansdShould there be? I've been under impression it'll subtract 1 from the remapped instruction08:34
ghostmansdThat is, there will be .long prefix + svstep08:35
programmerjakespecial 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#l128408:35
programmerjakeI changed it to use CUSTOM_INSNS for everything by default, but to get the tests to pass, I had to add:08:36
programmerjakeI 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=63fd4ebc03ea0a7d51a1cf8d215affe45e0f0b3308:38
programmerjakeas for wether or not the subtract 1 should happen, idk, hence why I asked lkcl08:38
ghostmansdprogrammerjake, I like the decorator, thanks!08:40
ghostmansdIdeally we should build these from power_insn Database...08:40
ghostmansdI remember about it, just don't have time for that now08:41
programmerjakeyeah, nicer is better, but not needing to write instruction assembler functions is best08:41
markosprogrammerjake, 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
markosI wish I was better at rust, fwiw09:08
markospython is easy to read/write but it's slooow...09:08
programmerjakeI didn't say 2 weeks to be completed, I said 2 weeks to be mostly working.09:08
programmerjakeat that point, we'd just have to find all the missing corner cases.09:08
markosheh, it's the remaining 20% that takes 80% of the time :D09:09
markosbut ok, I admit I don't know how complex the codebase is09:09
programmerjakealso, I'm rewriting the parser, not the whole simulator...09:10
programmerjakeimho 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
programmerjakeso, e.g. we could write it in XSLT (yuck) and it could still work, no XSLT<-> python bindings needed09:12
markosI 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 benefits09:13
markosbut ofc it's not my decision09:13
markosC++ 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 end09:14
programmerjakec++ vs. rust, execution speed would be similar, speed to write and understandability would take a big hit with c++ though...09:14
programmerjakeand c++ would be prone to randomly segfaulting for crazy inputs09:15
markosesp tracking down stupid bugs09:15
markosstory of my life09:15
programmerjakerust 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 segfault09:17
programmerjake(exaggerating for effect...)09:17
programmerjakepython: or AttributeError, or ValueError, or silently wrong output...09:18
programmerjakethough technically python is a compiled language...it compiles to cpython byte code and gets stored in .pyc files, kinda like Java09:21
markoslet me rephrase that, a *fast* compiled language :)09:41
ghostmansdFolks, do we have some way to understand which field is not an operand?10:01
ghostmansdSpeaking of fields.text. We know that Rc field goes into instruction itself. So is, I guess, OE?10:02
ghostmansdAny others?10:02
ghostmansdI'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
programmerjakenot that I'm aware of, though I could have missed something10:03
programmerjakeassuming you're talking about fields in fields.txt and similar10:03
programmerjakeyes, afaict10:03
programmerjakemaybe load/store size?10:04
programmerjakeor cr operation? icr if those are a separate field or just mushed into PO/XO10:05
markosOT, 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
markosonly needs vec_gb and a perm to move the bytes around and voila, there's your movemask10:06
ghostmansdprogrammerjake Hm. I think the safest way is determining those which are operands.10:07
ghostmansdWe have all these inX/outX stuff... Perhaps we could rely on these.10:07
programmerjakemaybe add it to fields.txt right before `Formats: ...` in each field?10:07
ghostmansdAnd then, everything else, is going to be non-operand.10:07
programmerjakesince iirc that's free-form text there10:08
ghostmansdIIRC yes, but I bet lkcl would oppose changing that. :-)10:08
ghostmansdBut I think we're safe with checking the operands instead.10:08
programmerjakebut that won't work because immediates...10:10
ghostmansdI think we can even manage the order in which these follow...10:10
programmerjakeimmediates aren't an input/output but they show up in arguments in asm10:10
ghostmansdThey are operands still.10:10
ghostmansde.g. addic has SI operand10:11
ghostmansdAnd we see that addic is (RT,RA,SI)10:11
ghostmansdSo this is the order...10:11
programmerjakenot all of them are... e.g. cmpli iirc10:11
ghostmansdlemme check10:11
ghostmansdNo, it has UI operand10:11
programmerjakeyes, but the asm also has BF and L operands10:12
ghostmansdFor each instruction, we're able to understand its form10:12
programmerjakewhich I had remembered not being passed to the fu in soc as immediate inputs, just decoded from the instruction instead10:13
ghostmansdAnd we're also able to get its operands (mdwn I think?)10:13
programmerjakeah, yeah, I guess it works there...since the markdown has the assembly syntax10:14
programmerjakethough 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 somewhere10:15
ghostmansdI have nothing better to rely on... :-)10:16
programmerjakee.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 discrepancy10:16
ghostmansdIf it's broken -- well, no better option.10:16
ghostmansdBut yeah, I'll cross-check these.10:16
ghostmansdI'm not sure whether we collect this information, though.10:17
ghostmansdI mean, we for sure collect it somewhere, but likely it's missing from power_insn.10:17
programmerjakeiirc for the script lkcl wrote to generate the svp64 forms, he just has a allowlist hardcoded in the script10:17
ghostmansdPerhaps you know the place where we collect this stuff from mdwn?10:19
ghostmansdI recall these are converted to Python...10:19
ghostmansdBut when it's used? Do we have some place where I could take, say, instruction name, and find its operands?10:19
ghostmansdAh yeah, the infamous pywriter...10:21
programmerjakeit's parsed in src/openpower/decoder/pseudo/pagereader.py line 244 commit cfd0215fc6f716317eb22d04d965028eb794965b10:21
ghostmansdAha, thank you!10:23
programmerjakeso if you run pagereader.py, it'll dump the regs for all the ops, in ISA.pprint_ops()10:23
programmerjakecalled regs, but really just the asm operands10:23
ghostmansdYes... ISA.instr10:26
ghostmansdOK, this should be sufficient. I even recall we grab parts of these.10:26
ghostmansdYeah I think all we needed is src/openpower/decoder/isa/all.py.10:30
ghostmansdNo pun intended, all we need is all.py :-)10:30
ghostmansdFuck. We have a cyclic dependency.10:42
ghostmansdI need an ISA from openpower.decoder.isa.all10:42
ghostmansdThat one depends on openpower.decoder.isa.caller...10:42
ghostmansdand the caller, since recent, depends on power_insn.10:43
ghostmansdWhich needs to import ISA.10:43
lkclghostmansd, there are two "ISA"s. you may have the wrong one10:44
ghostmansdDo you suggest this? from openpower.decoder.pseudo.pagereader import ISA10:44
programmerjakethat's what I'd do...10:45
ghostmansdHm, seems it should do the trick...10:46
ghostmansdLet me check10:46
programmerjakethough maybe see if you can pass it an option to not fully parse the mdwn, we don't need the AST here...10:46
lkclmarkos, 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
programmerjakespeed is somewhat important, I don't want to have to wait 10m each time I change the pseudocode10:46
lkclprogrammerjake, *when* other people begin designing Power ISA CPUs using our techniques they can also PAY us MONEY to satisfy THEIR need.10:47
programmerjakesomewhere <10-15s is fine10:47
ghostmansdDo you mean pywriter? It takes 6 seconds.10:47
programmerjakewhen 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
programmerjakeso they won't be paying us for that, because they don't want a repeat of our code10:48
lkcldefinitely 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
lkclif you are doing that please STOP10:49
lkcli have already told you NO10:49
programmerjakei meant that's what I proposed to do, I'm not currently doing that10:49
programmerjakethe discrepancy is between sv.svstep vs plain svstep, not between Rc=0/110:50
programmerjakewow, CI took >2hr and one of the pytest processes crashed: https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/316469212:15
programmerjakelooks like I'll have to optimize the tests somewhat12:15
programmerjakemaybe a memory leak?12:15
lkclthere's a problem with python 3.7 that actually triggers actual segfaults in /usr/bin/python3.712:25
lkcli had to add at least two workarounds12:25
programmerjakeit looked more like maybe SIGKILL to me, though i'd have to read the logs in more detail -- tomorrow. need sleep before meeting12:27
ghostmansdthe pagereader is broken for cases when operands have spaces12:30
ghostmansde.g. `* grev RT, RA, RB (Rc=0)`12:30
ghostmansdit'll think RA and RB are opcodes, too12:31
ghostmansdThis is caused by the fact that pagereader is way too limited in parsing12:31
ghostmansdI'll fix it12:31
ghostmansdlkcl, in case you missed, https://libre-soc.org/irclog/%23libre-soc.2022-08-30.log.html#t2022-08-30T07:43:1912:31
*** octavius <octavius!~octavius@> has joined #libre-soc12:58
lkclghostmansd, yes, this is an error in the pseudocode. it should not have been written with spaces.13:19
ghostmansdWell I've taught it to consider spaces anywhere13:19
lkclthat may have knock-on complications.13:20
lkclthe correct action is to remove the spaces which i will do now13:20
ghostmansdBecause logically there's no problem with spaces per se (opcode SPACE dynamic-operands SPACE static-operands-with-values-in-parantheses)13:20
ghostmansdAnd, what's worse, the parser does not at all bothers by the fact that input is broken13:21
lkclfurther down the line there is code that will also rely on no spaces13:21
lkclbecause it was written in an extreme hurry because we are under funding and time pressure13:21
ghostmansdYeah I know13:23
ghostmansdMy point is, I'm fixing these things now, and letting you know what I fix and why13:23
lkcli'm currently going through things i can't discuss in detail publicly to get SVP64 upstream.13:23
ghostmansdBecause the fact that it's broken is not an issue. The issue is that it's _silently_ broken.13:24
ghostmansdSo yeah I decided you might want to know.13:24
lkclthere's resistance because we don't have working demos, power estimates, performance estimates13:24
lkclit would be better to throw an error if spaces are found, yes.13:24
lkclpagereader.py simply reads the line and shoves it in a dict13:24
ghostmansdWell I taught it to recognize regardless of spaces.13:24
lkclit does *not* actually parse it13:24
ghostmansdAnd raise an error if nothing can be recognized.13:25
lkclthat will result in down-stream errors13:25
lkclbecause of assumptions in the rest of the code that there will be no spaces13:25
ghostmansdAnything particular to test?13:25
lkclso it is better to throw an error if spaces are detected13:25
ghostmansdI've checked src/openpower/decoder/pseudo/pagereader.py13:25
ghostmansdThat is, its main13:25
lkcli didn't get round to writing unit tests for it as it's so critical it gets run all the time13:26
lkclprogrammerjake, you broke svstep.  look again at the spec please.14:02
lkclplease for goodness sake do not make arbitrary changes like this14:02
lkclyou have absolutely no idea what you are doing, because you have not been directly involved in actually implementing anything.14:03
lkclprogrammerjake, you have not kept to 1-purpose 1-commit14:08
lkcl*please follow the rules*14:08
lkcli cannot now revert the mistake that you made, i am forced to investigate where the fuck it is14:08
lkclyou *cannot* make assumptions and blithely go ahead and make arbitrary changes like this14:09
lkclfucking fucking hell14:13
lkclERROR: test_svstep_iota (__main__.DecoderTestCase)14:13
lkcltests svstep "straight", placing srcstep, dststep into vector14:13
lkcl line 490, in __getattr__14:13
lkcl    return globals()[attr]14:13
lkclKeyError: 'remap_idxs'14:13
lkclwill people *PLEASE* be more careful.14:13
lkclthis is in master branch14:13
lkclyou CANNOT blithely make arbitrary changes without FULL testing.14:16
lkclprogrammerjake, 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
lkclif you cannot act responsibly here i am going to ban you from write-access to openpower-isa and only permit you to operate in branches14:22
lkclwhich will force you to undergo a proper review and proper testing before committing14:22
* lkcl now re-running all the unit tests.14:24
lkclghostmansd, your code is left in (not reverted) because i can see that it's in areas that do not impact the simulator / translation14:24
lkcli'm re-running all unit tests just to make absolutely sure, though14:25
ghostmansdsure, Luke14:47
ghostmansdplease let me know if any issues appear14:47
ghostmansdI generally try to stay away from master, as you know14:47
ghostmansdunless the changes are really minor or not used by anyone but me (sv_binutils, pysvp64dis, etc.)14:48
ghostmansdOK it seems to work now15:11
ghostmansdaddo [['RB'], 'Rc=0']15:11
ghostmansd[['RT', 'RA', 'RB'], '(OE=1', 'Rc=0)']15:11
ghostmansdfor addo15:11
ghostmansdpopcntb [['RA', ''], 'RS']15:12
ghostmansdaddo [['RB'], 'Rc=0']15:12
ghostmansdpopcntb [['RA', 'RS']]15:12
ghostmansdso yeah, the issue was not only in bitmanip15:12
ghostmansdlkcl, when you have time, could you, please, take a look at pagereader branch?15:14
ghostmansdupdated that branch one more time15:26
ghostmansdaddo (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
ghostmansdaddo. (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
ghostmansdCool. Cool cool cool.15:30
ghostmansdCongrats folks, now we know exactly all instructions and which operands they have.15:31
ghostmansdEven better!15:40
ghostmansdaddo (DynamicOperand(name='RT'), DynamicOperand(name='RA'), DynamicOperand(name='RB'), StaticOperand(name='OE', value=1), StaticOperand(name='Rc', value=0))15:40
ghostmansdaddo. (DynamicOperand(name='RT'), DynamicOperand(name='RA'), DynamicOperand(name='RB'), StaticOperand(name='OE', value=1), StaticOperand(name='Rc', value=1))15:40
ghostmansdWe can differ between dynamic operands (provided by caller) and static ones (being part of instruction).15:41
ghostmansdI'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
ghostmansdAll should act together, and can be used for instruction encoding/decoding.16:14
ghostmansdObviously 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
lkclghostmansd, willdo, 1 sec16:49
ghostmansdsorry, this was with regexes :-)16:50
ghostmansdthis was simpler and shorter than handling corner cases16:50
ghostmansdThere's an error which drops sv.WHATEVER instructions, will update17:02
lkclis that checking that operands do not have a space and then throwing an assertion?17:07
ghostmansdNo, it considers the spaces, too. But act more intuitively.17:07
lkclapologies, i wasn't clear: i don't want spaces *at all* to be accepted in the operation.17:08
ghostmansdIt checks for OPCODE (optional OPERANDS) (optional KEY=VALUE operands)17:08
lkclthis is because there is other code downstream which assumes that there is no spaces17:08
lkcland we do not have time to go hunting for that code, let alone "fixing" it17:08
ghostmansdWhy do we have spaces, then?17:09
lkclthere is only 4.5 weeks remaining until we can no longer claim any money17:09
lkclbecause jacob made the mistake of putting the spaces in and i did not notice17:09
ghostmansdAnd why this code downstream doesn't check for spaces?17:09
ghostmansdAgain: it's not only Jacob17:09
ghostmansdpopcnt* also affected.17:09
lkclbecause i wrote that code - and it was two years ago - and i cannot now remember and...17:09
lkclthen i will fix that17:09
ghostmansdAnd many others.17:09
lkclright now17:10
ghostmansdOK but please _validate_ the input17:10
ghostmansdaddo [['RT', 'RA', 'RB'], '(OE=1', 'Rc=0)']17:10
ghostmansdThis is _not_ the kind of validation I'd expect17:10
ghostmansdpopcntb [['RA', ''], 'RS']17:10
ghostmansdThis is not either17:11
ghostmansdIf there's a code downstream which silently "works" with this -- well, we have a problem17:11
ghostmansdI can adopt the regex so that it doesn't allow spaces17:11
ghostmansdBut my point is, how does it even work now?17:12
lkcli don't know - and i don't have time to investigate17:12
ghostmansdOK I'll adopt the regex17:12
lkcl*i* am under pressure at the moment, i have too much going on17:12
ghostmansdI am too17:12
ghostmansdThese 4.5 weeks are for me too17:13
lkclthe other Grants are active, still - cavatools and bitmanip17:13
lkclthey're USD 50,000 each so is not a problem17:14
lkclit's all the other ones that are going away17:14
ghostmansdThe thing is that two months of work go down the drain, then17:14
ghostmansdIt's kinda personal17:14
ghostmansdI mean, I really want to complete binutils works17:14
ghostmansdUnder the grant this was established17:14
lkclthat work can continue.... under the *other* grant17:15
lkclthe cavatools one in particular17:15
lkcland within about 4-7 weeks we will then hear whether the two *more* grants (each EUR 100,000 each) have been accepted17:16
ghostmansdIsn't this grant gonna be expired?17:16
ghostmansdI mean, the one for binutils17:16
lkclcavatools no17:16
lkclthere are *eight* grants with another 2 applied for17:16
ghostmansdThis would mean that money for binutils simply burn17:16
lkcl6 of those grants end mid-october17:16
lkcl2 of those grants do ***NOT*** repeat ***NOT*** end17:16
lkclone of those 2 grants is cavatools17:17
lkclyour work can CONTINUE under the CAVATOOLS grant17:17
lkclwhich does NOT repeat NOT end in mid-october17:17
ghostmansdAssuming this task. What happens to the budget?17:17
lkclbut 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 cavatools17:18
lkclthat one is for one of the 6 grants17:18
lkclit *has* to be done before mid-october17:18
ghostmansdYes, this is my point.17:18
lkcltherefore things like working on pagereader are a serious distraction17:18
ghostmansdIf it's not done, the money will have to be allocated from cavatools.17:18
lkclyes, precisely.17:19
lkclwhich puts pressure on everyone else, financially, because EUR 50,000 will not go a long way between 4-5 people17:19
lkclso the more that is done before mid-october, the more money for everyone else17:19
lkcl"nice-to-have" *has* to take a back seat at the moment17:20
ghostmansd[m]OK, then we're on the same page17:21
ghostmansd[m]I'll update the regex17:22
ghostmansd[m]And fix the broken entries with spaces17:22
lkclok :)17:23
lkclwhilst we've been talking i've done popcnt already17:23
ghostmansdlkcl, speaking of "static" operands, e.g. Rc=1, Oe=1, etc.17:36
ghostmansdShould these be separated by comma or by space17:36
ghostmansde.g. `* addo.  RT,RA,RB (OE=1 Rc=1)`17:37
lkclspace. no change to those19:06
lkcl(actually anything in brackets is completely ignored)19:06
ghostmansd> (actually anything in brackets is completely ignored)19:08
ghostmansdno longer :-)19:08
ghostmansdor should I say, never more?19:08
ghostmansdQuoth the Raven “Nevermore!"19:09
ghostmansdCan it be that there are only "static" operands?19:16
ghostmansdThat is, no user-provided operands on input/output, but only Rc/OE19:16
ghostmansdlkcl, done19:43
ghostmansd+bpermd, cdtbcd, cbcdtd19:44
ghostmansdThe code seems to be simplified compared to original version. I now check all components separately.19:44
ghostmansdpagereader branch19:45
ghostmansdI checked pywriter and pagereader, both seem to work.19:45
lkclok brilliant, let me run some tests....20:11
ghostmansdcf also dis branch20:12
ghostmansdI think we finally handled Rc and Oe properly20:13
ghostmansdSo basically the only missing bit for scalar disassembler, I think, are dynamic operands20:13
lkclyou mean pseudo-operations? like "beq" is.. something like... "bc 20," or something?20:16
lkclthose are completely off the list, i don't want to go anywhere near them20:17
lkclouch. loadavg 21 running tests. can't do browser at same time20:18
ghostmansdnope, I mean the disassembler and the operands20:22
ghostmansdto encode/decode, we must know the operands ranges20:22
lkcloh you mean what was discussed yesterday?20:23
ghostmansdhow would I :-)20:24
*** dhill[m] <dhill[m]!~dhilldecr@2001:470:69fc:105::1:64d9> has joined #libre-soc20:25
lkclbranches with LK=1 do not have their own csv line in microwatt because microwatt tackles LK=1 explicitly inside the pipelines20:26
*** dhill[m] <dhill[m]!~dhilldecr@2001:470:69fc:105::1:64d9> has left #libre-soc20:27
lkclLK=1 is bit 31, like Rc=120:27
lkclso just like you get "." on the end and that means Rc=120:27
lkclyou also get "l" on the end and that means LK=120:28
lkclbut you do *not* get a separate csv line for "add."20:28
lkclyou just get, "add"20:28
lkcland likewise you do *not* get a separate csv line for "bcctrl"20:28
lkclyou just get, "bcctr"20:28
ghostmansdWell, I think we should be ready for such tricks now20:31
ghostmansdI got scalar disassembler working20:32
ghostmansdAt least for these two instructions I checked :-)20:32
lkclok all good in pagereader branch. rebased and pushed20:37
*** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC20:45
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC20:46
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC20:55
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC20:55
*** josuah <josuah!~irc@> has quit IRC20:55
*** yambo <yambo!~yambo@> has quit IRC20:55
*** ckie <ckie!~ckie@user/cookie> has quit IRC20:55
*** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has quit IRC20:55
*** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC20:55
*** mx08 <mx08!~mx08@user/mx08> has quit IRC20:55
*** kanzure <kanzure!~kanzure@user/kanzure> has quit IRC20:55
*** rsc <rsc!~robert@fedora/rsc> has quit IRC20:55
*** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC20:55
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc20:56
*** josuah <josuah!~irc@> has joined #libre-soc20:56
*** yambo <yambo!~yambo@> has joined #libre-soc20:56
*** ckie <ckie!~ckie@user/cookie> has joined #libre-soc20:56
*** lkcl <lkcl!lkcl@freebnc.bnc4you.xyz> has joined #libre-soc20:56
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc20:56
*** rsc <rsc!~robert@fedora/rsc> has joined #libre-soc20:56
*** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc20:56
*** kanzure <kanzure!~kanzure@user/kanzure> has joined #libre-soc20:56
*** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc20:56
*** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc20:56
*** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has quit IRC20:57
*** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has quit IRC20:57
*** openpowerbot <openpowerbot!~openpower@94-226-188-34.access.telenet.be> has joined #libre-soc20:58
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC20:59
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has quit IRC20:59
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has quit IRC20:59
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC20:59
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc21:00
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC21:02
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc21:02
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has quit IRC21:03
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC21:20
*** Veera[m] <Veera[m]!~veerakuma@2001:470:69fc:105::de08> has joined #libre-soc21:27
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc21:32
*** tinybronca[m] <tinybronca[m]!~tinybronc@2001:470:69fc:105::2:1af6> has joined #libre-soc21:58
*** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc22:31
*** sadoon[m] <sadoon[m]!~sadoonunr@2001:470:69fc:105::1:f0fa> has joined #libre-soc23:17
*** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc23:20
*** jevinskie[m] <jevinskie[m]!~jevinskie@2001:470:69fc:105::bb3> has joined #libre-soc23:25

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!