Saturday, 2021-10-02

lkclcool.  the code itself needs docstrings, and feel free to then cross-ref the howto/tutorial in the code as well.00:05
lkclraise a bugreport for it, i'll add a budget00:05
lkclbtw you made a homepage on, right?00:05
lkclfound it00:06
kylelWill do00:49
ghostmansdXLEN = 6411:57
ghostmansdREG = lambda v: SelectableInt(v, XLEN)11:57
ghostmansdassert EXTS(REG(0xF0000A93), 32) == REG(0xFFFFFFFFF0000A93)11:57
ghostmansdassert EXTS(REG(0x0000F074), 16) == REG(0xFFFFFFFFFFFFF074)11:57
ghostmansdassert EXTS(REG(0x00000091),  8) == REG(0xFFFFFFFFFFFFFF91)11:57
ghostmansdlkcl: please confirm the following are correct wrt XLEN and extsb/extsh/extsw11:57
ghostmansdif yes, I suggest the following EXTS:11:57
ghostmansd    trunc_bits = min(value.bits, bits)11:57
ghostmansd    pad_bits = max(value.bits, bits)11:57
ghostmansd    return SelectableInt(exts(value.value, trunc_bits) & ((1 << pad_bits)-1), pad_bits)11:57
ghostmansddef EXTS(value, bits=256):11:57
lkclvalues get first truncated to the 2nd argument12:58
lkclfllowed only then by analysis and sign-extension12:58
lkclassert EXTS(REG(0xF0000A93), 32) == REG(0xFFFFFFFFF0000A93)12:58
lkclassert EXTS(REG(0x70000A93), 32) == REG(0x000000070000A93)12:59
lkclEXTS you have to be extremely careful with it.13:00
lkclall values returned from EXTS **MUST** return a length of 25613:01
lkclthis is crticically, critically important13:01
lkcl256 indicates "this length is unlimited"13:01
lkcl*ALL* of SelectableInt knows, "if the length is unlimited, you can safely set the length *to* the length of the inputs"13:02
lkclthus it is really not a good idea to change its behaviour13:03
lkclthis is why there are totally separate EXT64 and EXT128 functions13:03
lkclso no, please don't alter EXTS - it will completely break pretty much everything.13:04
ghostmansdlkcl: return SelectableInt(exts(value.value, bits) & ((1 << 256)-1), 256)?13:26
ghostmansdthe REG check is incorrect then, should be like this:13:26
lkclkylel, saw the bugreport, excellent -
ghostmansdassert EXTS(REG(0xF0000A93), 32) == SelectableInt(0xFFFFFFFFF0000A93, 256)13:27
lkclah then yes13:27
lkclwait... EXTS doesn't take an extra argument13:27
ghostmansdnow it takes: def EXTS(value, bits=256):13:27
lkcland shouldn't be made to13:27
ghostmansdwhy not?13:28
lkclno, that's really important that it *not* be modified that way13:28
ghostmansdwe must introduce another function then13:28
lkclbecause it's implicit13:28
lkclEXTS has to conform to the Power ISA spec13:28
lkclnow, *behind the scenes* it can go, "oh, i am operating under conditions of XLEN=32.  i should truncate things internally"13:29
lkclbut even there we have to take EXTREME caution13:29
ghostmansdso you mean we must, instead of `bits` argument, check self.XLEN?13:29
lkclbecause that could be a false assumption where a 128-bit partial result is handed to it13:29
ghostmansdif so, this can be arranged13:29
lkcl"what i suggest is just use EXTS((RA), 8)"13:30
lkcldamn that was a mistake13:30
lkcli'm in the middle of administrative tasks for the budgeting at the moment13:31
lkcli'm not quite adapting from "calculator mode" onto this.13:31
lkclgimme a sec13:31
ghostmansdwell yes, that's why EXTS got a new argument :-)13:31
ghostmansdno problem13:31
ghostmansdI assume you want this13:31
ghostmansdreturn SelectableInt(exts(value.value, self.XLEN) & ((1 << self.XLEN)-1), 256)13:31
ghostmansdoh no, wait13:32
ghostmansdreturn SelectableInt(exts(value.value, self.XLEN) & ((1 << 256)-1), 256)13:32
lkclthat was my initial thought, but even that is "damaging"13:32
lkclbecause the assumption of EXTS as it stands is that it can be passed *anything*, of *any* length13:32
lkcleven an intermediate results from e.g. a 64-bit multiply producing a 128-bit result13:33
lkclan assumption that it **MUST** truncate to XLEN would go:13:33
lkcl"oh, you had a 128-bit result? well, tough titty, i truncate everything to XLEN-bit before sign-extending, and XLEN=64 so i'm throwing away the top 64 bits"13:34
lkclmore to the point: i don't think EXTS even *needs* modifying13:34
lkclall inputs should have been already truncated to XLEN13:34
lkclall outputs *will* be post-analysed and truncated / sign-extended / saturated as a *separate* phase13:35
lkclthat's differerent13:35
lkclwhat XLCASTU does is a completely different matter13:35
ghostmansdit truncates/zero-extends to XLCASTU13:36
lkclbut should *not* be implemented internally using EXTS (forcing EXTS to be modified)13:36
lkclthat's explicit13:36
lkclbecause it *has* to be XLEN-aware13:36
ghostmansdlkcl, I must confess you make things more confusing :-)13:36
ghostmansdlet's wait for a moment till you have time13:36
lkclEXTS very very much does not.  it is defined - *defined* - as "taking its input, respecting its input's length, and performing sign-extension from that"13:37
lkclexamples. i need examples.13:37
lkcli can't think about this in the abstract without concrete examples13:37
lkclwhich really need to be done on a bugreport, not IRC13:37
lkclEXTS is one of those weird annoying functions where we had to conform to a nebulous *implicit* aspect of the Power ISA pseudocode / specification13:38
ghostmansdEXTS(XLCASTU(SelectableInt(0xF0000A93, 64))) == SelectableInt(value=0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000a93, bits=256)13:39
ghostmansdthis ^ is for XLEN=3213:40
lkclthat looks right13:40
ghostmansdon XLEN=64...13:40
ghostmansdEXTS(XLCASTU(SelectableInt(0xF0000A93, 64))) == SelectableInt(value=0xf0000a93, bits=256)13:41
ghostmansdstill OK?13:41
lkclshould be 0xf00000a93... yes13:41
ghostmansdnote that with these, pesudocode looks like...13:41
lkclXLCASTU should be where the explicit handling of XLEN is involved13:42
ghostmansdextsb: RA <- EXTS(XTRUNC(RS)), XLEN=813:42
ghostmansdextsb: RA <- EXTS(XTRUNC(RS)), XLEN=1613:42
ghostmansdextsw: RA <- EXTS(XTRUNC(RS)), XLEN=3213:42
* lkcl thinks13:42
lkclermm.... ermermerm...13:42
ghostmansdso there won't be explicit 8/16/3213:42
ghostmansdbut, instead, when we get to extsb, we already get there with XLEN=813:43
lkclthat clearly can't be the case13:43
ghostmansdand this affects XTRUNC13:43
lkclextsb clearly can't be exactly the same as extsw and extsh13:43
lkclit would have to be something like13:43
lkclextsb: RA <- EXTS(XTRUNC(RS, 8))13:43
lkclextsh: RA <- EXTS(XTRUNC(RS, 16))13:44
ghostmansdXTRUNC doesn't have explicit argument13:44
ghostmansdreturn SelectableInt(value.value, self.XLEN)13:44
ghostmansdthat you previously called XTRUNC13:44
lkclah ok13:44
lkclermmm... ermermerm...13:44
ghostmansdalso we have XLCASTS13:45
ghostmansdreturn SelectableInt(exts(value.value, self.XLEN), self.XLEN)13:45
ghostmansdalso w/o explicit arguments13:45
lkclok then it should be changed to have an explicit argument13:45
lkclspecifying the length13:45
lkclwhere that length is then truncated to max(length, self.XLEN)13:46
ghostmansdI suspect that we have a separate function then13:47
ghostmansdXL is implicitly XLEN13:47
ghostmansdXLCASTU -- cast to XLEN unsigned13:47
ghostmansdso it'll be the initial version of EXTS I posted, but named differently, that's what I suggest.13:48
lkcltck, tck, tck....13:48
* lkcl thinks13:48
lkclthis needs a table written out13:50
ghostmansddef EXTS_with_moo_powers(value, bits):13:50
ghostmansd        bits = max(bits, self.XLEN)13:50
ghostmansd        return SelectableInt(exts(value.value, bits) & ((1 << 256)-1), 256)13:50
lkclcan you write out a full table in the bugreport13:50
lkclwith extsb, extsh and extsw on the columns13:50
lkclXLEN=8/16/32/64 as the rows13:50
ghostmansdextsb: RA <- EXTS_moo(RB, 8)13:50
ghostmansdextsh: RA <- EXTS_moo(RB, 16)13:51
ghostmansdextsw: RA <- EXTS_moo(RB, 32)13:51
lkcland some example values as13:51
lkclghostmansd: this is too complex to do over IRC13:51
lkclit needs a wiki page13:51
lkclwith some examples - a full table13:51
ghostmansd> can you write out a full table in the bugreport13:51
ghostmansdOK will post to bugzilla13:51
ghostmansdI don't quite get what's complex here, but OK :-)13:52
lkcli can't cope with it without seeing everything at once, that's what13:52
lkclunless i can see *all* the potential combinations, i can't work out what needs to be done13:52
lkclit needs a wiki page13:52
lkclrather than going in the bugreport13:52
lkcl1 sec13:53
ghostmansdi'll create one13:53
lkcl or something13:53
lkclor better, under the svp64 page13:53
lkclsomething like that13:54
ghostmansdlkcl: I did it quickly, feel free to expand15:07
lkclghostmansd[m], i mean as a 2D table, not a 1D list15:38
lkcla 1D list the patterns are not clear15:38
lkclbecause the eye has to jump text and cannot spot vertical and horizontal patterns at the same time15:38
lkcluntil i've seen those examples laid out with the values (some signed, some unsigned), i'm literally unable to see the patterns which allow me to deduce how this needs to work15:40
lkclhere's how i did it for dynamic simd __eq__:15:41
lkcli was then able to write out some Karnaugh maps (32 of the damn things)15:42
lkclon paper (!)15:42
lkcland was able to mathematically reduce them down to an algorithm15:42
ghostmansd[m]What fields do you want? XLEN, sign, instruction?16:59
lkcli added 3 copies of a 2D table which has XLEN=64/32/16/8 across the columns and extsb/h/w across the rows17:47
lkclthat leaves placing several signed and unsigned values in the TODO value 1 TODO value 2 TODO value 317:47
lkclwhere for completeness - to see precisely what is going on - we need a full suite of unsigned values as well17:51
lkclthese actually could end up as the unit test values17:51
lkcli removed the pseudocode from the examples because it is misleading as to what is needed17:51
lkclthe tables should contain the *desired* values17:52
lkclnot the values that "happen to be calculated by an algorithm which may or may not produce the right answer(s), we don't know yet"17:52
ghostmansd[m]lkcl, ack18:02

Generated by 2.17.1 by Marius Gedminas - find it at!