Wednesday, 2021-09-29

ghostmansd[m]Sorry, I should've written this not in form of bitwise operations, but rather via indexing08:40
ghostmansd[m]I meant, `sign = value[XLEN - 1]` is not OK in PPC, right?08:41
ghostmansd[m]Also, regarding repo push: I mean libreriscv repo08:41
programmerjakedepends on if your using bits numbered lsb0 (like nmigen and most software) or msb0 (openpower isa spec)08:52
ghostmansd[m]lkcl: Are XLCASTS/XLCASTU in XLEN branch OK?08:52
ghostmansd[m]programmerjake: yes, that's what I mean, thank you for putting it clear :-)08:53
programmerjakeif it's numbered lsb0, then that is the sign bit, if it's msb0, then that bit is actually equivalent to `value & 1`08:53
programmerjakeif your writing openpower isa spec pseudo-code, it uses msb008:54
programmerjakeafaict, the functions should be like:09:02
programmerjakedef XLCASTU(self, value):09:02
programmerjakedef XLCASTU(self, value):09:12
programmerjake    bits = min(self.XLEN, value.bits)09:12
programmerjake    return SelectableInt(value.value & ((1 << bits) - 1), self.XLEN)09:12
ghostmansdprogrammerjake: and XLCASTS should be the same but with sign extension?09:17
lkcl<ghostmansd[m]> I meant, `sign = value[XLEN - 1]` is not OK in PPC, right?09:18
ghostmansddef XLCASTS(x):09:18
ghostmansd        bits = min(value.bits, self.XLEN)09:18
ghostmansd        value = exts(value.value, bits)09:18
ghostmansd        return SelectableInt(value & ((1 << bits) - 1), self.XLEN)09:18
lkclthat's incorrect09:18
lkcl`sign = value[XLEN - 1]` ***is*** OK in PPC09:18
lkclit cannot be any other way09:18
lkclto be otherwise would be catastrophic and disastrous for any programs and compilers09:18
lkclprograms would be utterly non-portable to the Power ISA09:19
lkcltherefore, logically, we may deduce that it *has* to be exactly as for all and any other architecture that has 2's-complement integer arithmetic09:20
lkclghostmansd, haven't looked yet09:20
programmerjakewell, lkcl, you're forgetting that on ppc bits are numbered from 0 at the *msb* end to xlen -1 at the lsb end. the sign is still always at the *msb* end aka. bit 0 on ppc09:20
lkclahh yeah, that's a Power ISA spec issue09:21
lkclnot a hardware issue09:21
ghostmansd[m]Yes, I'm about specs09:21
lkclthe MSB is always where the sign-extension must occur09:21
lkclghostmansd[m], ok.09:21
lkclso yes, in IBM's totally-backwards LSB0-numbering, you want the bit numbered zero, aka the MSB, as the sign bit09:22
ghostmansd[m]Pushed fixedlogical changes and updated XLCASTS/XLCASTU09:22
lkclit looks like the only "damage" to the wiki git repository is a claim that this material is copyrighted (written) by you09:23
lkcloh wait09:24
lkclit still says "author me"09:24
lkclbut submitter you09:24
ghostmansd[m]Yes :-)09:24
lkclthat's ok09:24
programmerjakedef XLCASTS(self, value):09:24
programmerjake    return SelectableInt(exts(value.value, self.XLEN), self.XLEN)09:24
ghostmansd[m]But the commit tells that you've updated RFPs :-D09:24
ghostmansd[m]So I wondered if it's OK to do force-push to drop it09:25
programmerjakeexts already does the hard work for us09:25
lkclargh argh there's a rebase error on the server repo09:26
ghostmansd[m]programmerjake: thank you, pushed09:26
lkclok sorted09:29
programmerjakethe matrix bridge was borked for the last few minutes...09:30
lkclthe exts function does everything arithmetically, so you don't even need to know the numbering (LSB0 ordering)09:31
lkclthe only reason you ever need to know the LSB0 ordering is when trying to *directly* access bits09:32
lkclx = SelectableInt()09:32
lkclx = SelectableInt(8)09:32
lkclx[0] --> the *SEVENTH* bit of x09:32
lkclif you use SelectableInt in an *arithmetic* way, you *DO NOT* need to know that09:32
lkclat all09:32
programmerjakewell, how the XLCASTS function I posted uses exts, you can't even access bits using indexing, since it only gets a python int09:33
programmerjakein exts09:33
lkclSelectableInt behaves precisely and exactly like a standard 2's-complement arithmetic object09:33
ghostmansd    RA <- XLCASTS(RS & 0xFF)09:34
ghostmansd    RA <- XLCASTS(RS & 0xFFFF)09:35
lkclif both the value and the width received by exts are python ints, then it will actually behave exactly as expected.09:35
programmerjakesort-of...the constructor makes it act like a unsigned modular integer rather than a 2's complement modular integer09:35
ghostmansdextsb can also be written as `RA <- XLCASTS(RS[XLEN-8:XLEN-1])`09:35
lkcldue to the Liskov Substitution Principle it will work for both09:35
ghostmansdI'm not sure how to write extsh in the same fashion09:35
lkclahh yeah i forgot about that09:35
lkclgood catch, jacob09:36
* lkcl thinking09:37
ghostmansdchecking ./src/soc/fu/logical/test/test_pipe_caller.py09:38
ghostmansdok, forgot self...09:38
programmerjakeextsb: RT <- XLCASTS(EXTS64((RA))[56:63])09:40
programmerjakeextsh: RT <- XLCASTS(EXTS64((RA))[48:63])09:40
lkclwhat i suggest is just use EXTS((RA), 8)09:40
lkclwhat i suggest is just use EXTS((RA), 16)09:40
lkclwhat i suggest is just use EXTS((RA), 32)09:40
lkclfor extsb, extsh and extsw respectively09:40
lkcland we sort it out behind the scenes09:40
lkclget EXTS() to perform the [optionally] required truncation09:41
lkclit doesn't need spec changes09:41
lkcland the implementation details are hidden and do not need to be declared to OPF ISA WG09:42
programmerjakelkcl: that could totally work, except that the result of EXTS would be 8/16/32 bits for extsb/h/w rather than XLEN09:42
lkclother than a terse note, "EXTS must perform truncation if XLEN=8"09:42
lkclEXTS is implemented as setting the width to 256 to indicate "unlimited length"09:43
lkclwhich is then detected by subsequent operations and *replaced* with the length at which it is used09:43
programmerjakeah, ok, sounds good!09:44
lkcllong story behind that one09:44
lkclconsequently, when copying the result into the GPR, which will have a length set on it of 8, the truncation will automatically occur at that point09:44
programmerjakewait, can extsh have different src and dest xlen? elwidsrc and elwiddest?09:45
programmerjakeif so, we need to do sign extension when converting from xlensrc to 8/16/32, and sign extension again when converting to xlendest09:46
programmerjakeicr if we have two xlen09:46
lkcli'm hoping that the decision to "operate at maximum XLEN"09:47
lkclwill result in the source/dest XLEN *not* having to be exposed to the pseudocode09:48
lkclbut sorted out as a "pre-analysis phase" followed by "execute at one and only one XLEN" followed by "post-analysis and potential truncation phase"09:48
lkclif that algorithm's insufficient then sigh we have to bite the bullet and add an SLEN (source XLEN) and DLEN (dest XLEN)09:49
lkclwhich i reaaaallly would, obviously, greatly prefer not to do09:49
lkcltrying to explain it to the OPF ISA WG would be... fraught09:49
* lkcl afk, got up too early09:50
programmerjakek, though not everything will match user's expected/assumed semantics then09:50
programmerjaketoo sleepy to come up with any examples at the moment tho09:50
programmerjakebtw, today's my mom's actual bday, sunday was just the bday party09:52
programmerjakewell, i'm going to sleep, ttyl09:54
programmerjakegood luck with the xlen stuff ghostmansd!09:54
ghostmansd[m]lkcl: if you _really_ want to go with inheritance from ISACallerHelper, then you _have_ to call super().__init__() if you have custom __init__ in inherited class.12:31
ghostmansdThat's one of things we missed. The next one is that XLEN should also be transformed to self.XLEN, it seems.12:35
ghostmansdI frankly don't even know how it works now.12:35
ghostmansdAh, OK, likely via this big-neat self.namespace. OK, but it'd better if XLEN is prefixed with `self.` upon obtaining it.12:46
ghostmansdBecause, well, from helpers it _is_ self.XLEN.12:47
lkclghostmansd, ah whoops13:16
lkclyes, self.XLEN is the next thing13:17
lkclthe idea is that before each and every instruction is executed, self.XLEN must be set.13:17
ghostmansdI've already updated the parser13:18
ghostmansdAnd added super()13:18
ghostmansdAnd some other stuff13:18
ghostmansdin xlen branch13:18
ghostmansd11 failures in, including svp6413:18
ghostmansdMostly something related to selectable int13:18
ghostmansdI guess it has to do with self.XLEN, but haven't figured why it breaks yet.13:20
lkclok let me have a go13:25
lkclcan you attach an example stack trace or list precisely one and only one instruction that fails13:25
lkcl(so i don't have to run them all for 25 minutes)13:26
ghostmansd  File "/home/ghostmansd/src/openpower-isa/src/openpower/decoder/isa/", line 620, in op_divweu13:29
ghostmansd    if eq(divisor, [0] * self.XLEN):13:29
ghostmansd  File "/home/ghostmansd/src/openpower-isa/src/openpower/decoder/", line 143, in eq13:29
ghostmansd    return onebit(a == b)13:29
ghostmansd  File "/home/ghostmansd/src/openpower-isa/src/openpower/decoder/", line 413, in __eq__13:29
ghostmansd    assert False13:29
ghostmansdI guess that relates to the fact that we have 64 zeroes instead of 1 int :-)13:29
ghostmansdI think I've found the issue13:29
ghostmansdLuke, do you do some magic after XLEN is obtained from self.namespace?13:30
ghostmansdYou do convert it to selectable int, don't you?13:30
ghostmansdself.XLEN is a simple int, I guess this is where the issue comes from. Let me check.13:30
lkclthat sounds likely13:33
lkclah no13:33
lkclwrong file, doh13:33
lkclno, no magic13:33
lkclXLEN is set to 64 as an int in the self.namespace dict13:34
ghostmansdYes, but in the places you access self.namespace, don't you do magic?13:34
ghostmansdBecause [0]*64 is 64 zeroes13:35
lkclit doesn't actually involve *access* to self.namespace13:35
lkclthe dictionary *items* of self.namespace are merged into the globals() used by the function13:35
ghostmansdAnd, I suspect, [0]*SelectableInt(64) is 0b.....0 (i.e. 64 bits)13:35
ghostmansdOK, let me check whether conversion helps13:35
lkclwhich is a shockingly-bad hack but works13:35
lkclermmm.. ermermerm...13:36
lkclhold on13:36
lkcl[0]*self.XLEN should never have made it into the compiler output13:36
lkclit should have been identified *by the compiler* and *replaced* with13:36
ghostmansdOK, that's where we lost :-)13:37
lkclselectconcat(0, self.XLEN)13:37
ghostmansdI guess selectconcat only works with Name?...13:37
ghostmansdBecause in one of commits it became Attribute13:37
lkclnono, it's not selectconcat that's the problem13:37
ghostmansdthat is, when we see XLEN, we convert it into self.XLEN13:37
ghostmansdand do it via Name + Attribute combo13:38
lkclit's the compiler that outputs that function as a simple text string13:38
lkclthat sounds about right13:38
ghostmansdyes yes, I'm talking about compiler13:38
ghostmansdXLEN is no longer ast.Name13:43
ghostmansdBut an ast.Attribute13:43
lkclor, it's an ast.Attribute with an id "self"13:48
lkcland a value which is an ast.Name, where that ast.Name's id is "XLEN"13:48
lkclbtw you notice i drop a whole stack of tests into, right?13:49
lkclfeel free to add one "concat_test4 = [0]*self.XLEN"13:49
lkclactually i'll do that now...13:49
lkclactually, don't need to13:50
lkclit's concat_test313:50
lkclghostmansd, git pull.;a=commitdiff;h=be99ee688c680e0fc7b9ce81f53bcbe58250042913:51
lkclyou can back out setting XLEN to SelectableInt13:51
ghostmansdok will continue later on this14:16
lkclgot PartitionedSignal to test14:41
ghostmansdok, making the thing an attribute does work!20:33
ghostmansdexactly as I hoped :-)20:33 works on my side20:33
ghostmansd(w/o arguments, so svp64 is included)20:34
ghostmansdlet me know if I need more tests to check20:34
ghostmansdI suggest moving these into the master20:34
ghostmansdlkcl, ^20:34
ghostmansdlkcl, I merged these, since they didn't break any of tests21:14
mikolajwhi, checking if Matrix bridge works, can you read what I'm writing?21:34
mikolajwok, I see from the logs it works21:35
ghostmansd[m]Yes, it works :-)21:56
ghostmansd[m]I can see your messages, mikolajw21:56
lkclghostmansd[m], excellent, will do tomorrow. long day today22:41
lkcloo that's a lot :)22:41
lkclghostmansd[m], look at the constructor for SelectableInt.22:44
lkclit already performs "mask = (1<<bits)-1, self.value = value & mask"22:44
lkclso XCASTU has no need to repeat that22:44
ghostmansd[m]lkcl: let's be explicit :-)22:45
ghostmansd[m]After all, specs have no idea of selectable int22:45
lkcla comment would suffice22:45
lkclthe spec needs to be explicit22:45
ghostmansd[m]Ah, you mean the impl22:45
lkclthe implementation is up to us.22:45
ghostmansd[m]Not the call itself22:45
ghostmansd[m]Ok, will check tomorrow22:45
lkcla comment, def XLCASTU(self, value):22:45
ghostmansd[m]Too tired today22:45
lkcl    # SelectableInt already masks out the bits22:46
lkcli hear ya22:46
lkclme too. done for the day22:46
ghostmansd[m]I liked that task22:46
ghostmansd[m]Initially it seemed to be quite straightforward22:46
ghostmansd[m]But we did a lot in scope of it22:47
ghostmansd[m]Basically we affected the whole generation process22:47
ghostmansd[m]I'll simplify XLCASTU and proceed into extsb/extsh22:48
ghostmansd[m]What do we have left after these?22:48
ghostmansd[m]Also, any news from NLnet?22:49
ghostmansd[m]They gone silent :-)22:49
ghostmansd[m]IDK if you saw it in mailing list, but 3mdeb also got affected22:49
ghostmansd[m]Also I had to re-submit one of RFPs, hope it won't introduce more confusion22:51

Generated by 2.17.1 by Marius Gedminas - find it at!