Tuesday, 2023-01-10

*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC01:35
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc02:07
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC02:16
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc02:39
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC02:48
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC03:06
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc03:41
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC03:58
*** Ritish <Ritish!~Ritish@> has joined #libre-soc04:15
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc04:25
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC04:59
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc05:04
lkclghostmansd, it's the only way to "redirect" to completely different pseudocode.05:07
lkclthe instruction quotes doesn't exist quotes05:07
lkcldoesn't have an authorised mnemonic05:08
lkclis not approved by the OPF ISA WG05:08
lkcland so on.05:08
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC05:09
lkclit has been explained by the Chair of the OPF ISA WG that post-increment was discussed (20+ years ago) extensively and DENIED05:18
lkclthe reason:05:18
lkclyou can always SUBTRACT the amount before going into a loop05:18
lkcland you end up re-adding it back on inside the loop05:18
lkcltherefore there will be STRONG RESISTANCE to adding a post-inc instruction named "ldup"05:19
lkclespecially when there is no 32-bit opcode space available to do so05:19
lkcla mnemonic - as you suggest - would "legitimise" the post-inc operation.05:20
lkclpeople would expect, "where is the 32-bit operation???"05:20
lkclthere isn't one05:20
lkcland there can NEVER be one.05:20
lkclbecause they are all MAJOR opcodes.05:20
lkclit would require SEVENTEEN major opcodes (probably more because of FP LD/ST)05:20
lkclthat's literally impossible05:21
lkclthe *only way* is to do it as a 64-bit operation05:21
lkclwe really really do not want to be burdened with the expectation:05:21
lkcl"sv.ldup? oh, there MUST be a ldup as well because that's the rules in SVP64"05:21
lkclthat would royally fuck things for us.05:21
lkclwhich is a "qualification" of "sv.ldu"05:22
lkclwhich in turn follows the rule "under absolutely no circumstances whatsoever is there a 64-bit SVP64 operation without a corresponding 32-bit scalar one"05:23
lkclwhereas "sv.ldu/pi" is avoiding the *implication* of a 32-bit "ldup" operation (which cannot exist. ever)05:24
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc05:39
*** ritish_ <ritish_!~Ritish@> has joined #libre-soc07:03
*** Ritish <Ritish!~Ritish@> has quit IRC07:03
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC07:26
*** ritish_ <ritish_!~Ritish@> has quit IRC07:42
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc08:01
programmerjakeyou could have post-inc load/st as 32-bit instructions without needing new major opcodes: just make the immediate smaller and have XO08:26
programmerjake8-bit immediate is big enough for most uses and leaves 8 bits of XO -- plenty08:27
programmerjakeif you need bigger immediates you're likely using the immediate as the lower half of an address and post-inc is inappropriate there, just use ld[u]08:30
programmerjake(inappropriate because the lower 16-bits of the address loaded from will be zero or PC, not because there's only 8-bits of immediate)08:31
programmerjakeneeding array indexing with a stride > 127 or < -128 is pretty uncommon08:32
*** Ritish <Ritish!~Ritish@> has joined #libre-soc08:33
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC09:12
*** octavius <octavius!~octavius@> has joined #libre-soc09:24
lkclprogrammerjake, absolutely no chance.10:24
lkcldo you not recall how badly attempting that went?10:25
lkcli mentioned it multiple times over the past eight+ months since attempting modification of the meaning of LD/ST instructions by utilising part of the immediate10:25
lkclplus as you well know that means modifying *the meaning of the scalar instruction as a scalar instruction*10:26
lkclthat would go down extremely badly with the OPF ISA WG and we would literally destroy our reputation and standing with them, irrevocably10:26
programmerjakeuuh, that'd be adding *new* instructions, not having the svp64 prefix *modify* existing instructions, so that experience *modifying* doesn't apply10:27
lkclno, no and no.10:27
lkclhave you forgotten that that is exactly and precisely what i did with the LD-ST-with-shift?10:27
lkcland how many times i repeated that it went extremely badly?10:27
lkcli am still tracking down the damage to the HDL and to openpower-isa to remove the unbelievably-complex modifications across the board10:28
programmerjakenote i'm not seriously proposing new post-inc ld/st ops, just pointing out that the objection that they need 17 major ops is invalid10:28
lkclover eight months later10:28
lkclit is.10:28
lkclplease think through why10:29
lkcland please do not argue otherwise10:29
lkcli leave it with you10:29
programmerjakeit seems entirely obvious to me that 17 major ops are unnecessary if the immediate of the *new* insns (not modifying existing ops) is 8-bit instead of 16-bit, allowing using an 8-bit XO, allowing taking up 1/256 as much encoding space as the existing ldu/stdu ops meaning we'd need 17/256 of a major opcode, not 1710:34
programmerjakein any case, it probably doesn't matter that much, so i'm fine dropping it10:35
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc10:39
*** octavius <octavius!~octavius@> has quit IRC10:50
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC11:13
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc11:44
*** Ritish <Ritish!~Ritish@> has quit IRC11:53
*** Guest6747 <Guest6747!~irc@> has quit IRC12:00
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC12:45
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc12:45
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC13:11
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc13:11
lkclyou are proposing the violation of the HARD RULE that UNDER ABSOLUTELY NO CIRCUMSTANCES are instructions proposed that are exclusive to the SVP64 space14:32
lkclit is a HARD AND ABSOLUTE REQUIREMENT that instructions added as 64-bit SVP64 ***ABSOLUTELY MUST*** have a corresponding scalar opcode14:32
programmerjakeuuh, i said 32-bit instruction, idk how you thought that meant svp64-only14:33
lkclwhere is the corresponding ***SCALAR*** instruction that has absolutely nothing to do with SVP64, in what you are proposing?14:33
lkcland where is it going?14:34
lkclin what opcode space?14:34
lkclok so you are discussing a *scalar* 32-bit instruction.14:34
programmerjakelkcl: yes14:34
lkclok so you are proposing DESTROYING ldu and other major opcodes in the *32-bit* space14:35
lkclby proposing that the ISA WG accept the REMOVAL of ldu, and all other major-opcode 32-bit instructions14:35
programmerjakeno, i said *new* instruction, not modifying/replacing existing instructions14:35
lkclso where is the opcode space coming from in the 32-bit EXT0nn space?14:35
lkclbear in mind that an absolutely massive *17 or greater* major opcodes are required14:36
lkclthat list is (incomplete):14:36
lkcl33 lwzu14:37
lkcl41 lhzu14:37
programmerjakeidk, i didn't get far enough to pick, and it takes 17/256ths of a major opcode, not 17 major opcodes14:37
lkcl49 lfsu14:37
lkcl35 lbzu14:37
lkcl43 hau14:37
lkcl51 lfdu14:37
lkcl37 stwu14:37
lkcl45 sthu14:37
lkcl53 wtfsu14:37
lkcl39 stbu14:37
lkcl55 stfdu14:37
lkcland in EXT058 and EXT062 there is ldu and stdu14:38
lkcli'm not going to put forward a proposal that has such a limited range in the immediate.14:39
lkcla limited range would be questioned as to its value, and we cannot take the risk14:40
programmerjakewell, think about it, when do you usually need post-increment? ...when indexing in an array in a for loop. usually array elements have size much less than 127 (few structs are that big).14:43
programmerjakein the rare case that the increment amount is > 127, just use ldu and one extra add insn before the loop14:44
programmerjakeor did you have other common use cases for post-inc that need large increments?14:45
programmerjakelooks like there's plenty of space in ext019, the XO field there is small enough (bits 28:31) that the immediate could be 12 bits (-2048 to 2047) and one box needed per each of 17 insns -- there's dozens free so how about picking XO 000--001-- and 001000000014:57
programmerjakewait, i miscalculated how many bits were available...15:00
programmerjakepowerisa v3.1b has the opcode table for ext19 incorrect afaict, they say xo is 28:31 yet have a 10-bit XO15:04
programmerjakethat threw me off15:08
programmerjakewell, in any case there's plenty of space. i won't worry about it.15:08
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC15:49
ghostmansdlkcl, sorry for the delay. Thanks for clarification on the instructions!17:15
ghostmansdI have a question regarding assembly for stuff like `sv.crand/ff=eq/m=r10 12,2,33`.17:19
ghostmansdThis is for 5-bit CRs, therefore it maps to CROpFF5RM.17:20
ghostmansdFor fail-first on 3-bit CRs, it's simple: we have a dedicated CR field in CROpFF3RM.17:21
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc17:23
*** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC17:23
*** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc17:23
ghostmansdlkcl, sorry for the delay. Thanks for clarification on the instructions!17:23
ghostmansdI have a question regarding assembly for stuff like `sv.crand/ff=eq/m=r10 12,2,33`.17:24
ghostmansdFor fail-first on 3-bit CRs, it's simple: we have a dedicated CR field in CROpFF3RM, so we simply set this field and also set `inv` field.17:24
ghostmansdHowever, crand is 5-bit CRs, and these map to CROpFF5RM.17:25
ghostmansdAnd, well, that one has only RC1 field, which makes it look like as if only RC1/~RC1 is possible.17:26
ghostmansdHowever, our tests check `sv.crand/ff=eq/m=r10 12,2,33`, and somehow it worked before.17:26
ghostmansdI found a strange comment in power_insn.py, added by you: `RC1: BaseRM[19] # cheat: set RC=1 based on ffirst mode being set`.17:27
ghostmansdBut I didn't manage to trace what happens there, and it'd be great if you could share how it works.17:27
ghostmansdWhich fields should I set? I see that RM.mode[0,1] are set to 0b01/0b11/0b10 depending on whether we use FF/PR/FF-for-CRs.17:30
ghostmansdI also see that non-CR-FF-or-PR also update .inv and .CR/.RC1 fields (the latter is chosen depending on Rc field).17:32
ghostmansdThe same logic for .inv + .CR can be applied to FF-for-3bit.17:32
ghostmansdBut I'm completely stuck with FF-for-5bit.17:32
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC18:20
ghostmansdI'm checking https://libre-soc.org/openpower/sv/cr_ops/, and there's no RC1 field at all.18:27
ghostmansdOK, I think I got how this "cheat" works: we only set RC1 field if we met RC1/~RC1, otherwise we assume ff is one of eq,lt,etc.18:50
lkclfrom 5-bit CRs, you take the CR Field number from the result operand.  crand BT, BA, BA, you take the CR *field* number from the top 3 bits of BT.19:19
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc19:24
markosdo we have a meeting today?19:28
markosshould be in 30min right?19:28
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc19:28
programmerjakeyes afaict19:42
ghostmansdlkcl, I still don't get how this magic with RC1 field works19:44
ghostmansdThis field, RC1, is not in the spec. Also, the comment explains nothing.19:46
ghostmansdFrom what I see in spec, this bit 19, should always be 1.19:46
ghostmansdAnd this does not clarify it too: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=c61e92833d696d46c50bf715c898b33a3100aa49;hb=refs/heads/master#l142919:48
ghostmansdBecause, again, I don't even see from the spec why do we even allow failfirst to be set, because the fields are not there in the spec.19:49
ghostmansdI see that BO_LSB occupies the same bit as SZ. And I could guess that we re-use SZ, DZ and INV for FF, but, again, there are no fields in the spec to speculate on that.19:56
lkclhang on give me a sec20:00
lkclhttps://libre-soc.org/openpower/sv/cr_ops/ - RC1 does not exist / apply20:00
lkclRC1 is *not* the same as "Rc=1"20:01
lkclRC1 is a special mode which *enables* Rc=1 for instructions which *do not* have a "." version20:01
lkclfor cr_ops (such as crand) there is *no point* even having an Rc=1 mode20:01
lkclbecause that means "write to CR0"20:01
lkcland of course you are *already* writing to a CR Field20:02
lkcl... specified by BT!20:02
lkcltherefore there is no RC1 mode for cr_ops20:02
lkclLogical Operations are usually the ones that have no "Rc" option20:02
lkcltherefore having the RC1 mode for them "makes sense"20:02
*** octavius <octavius!~octavius@> has joined #libre-soc20:03
lkclmeeting room's open if anyone's available20:06
markoswe're already there20:06
octaviusStill same room code?20:06
lkclsadoon[m], toshywoshy programmerjake octavius markos ghostmansd cesar jn20:06
lkclsplit meeting room i think20:06
gnucodeI'm working today.  And my boss is still here.  and we are busy.  can't call in today.21:27
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC21:29
*** octavius <octavius!~octavius@> has quit IRC21:58
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc22:16
*** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC22:18
lkclgnucode, ack. and and and :)23:51
lkcli've been on one of those trips23:55

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