| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 01:35 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 02:07 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 02:16 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 02:39 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 02:48 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 03:06 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 03:41 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 03:58 | |
| *** Ritish <Ritish!~Ritish@115.97.40.46> has joined #libre-soc | 04:15 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 04:25 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 04:59 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 05:04 | |
| lkcl | ghostmansd, it's the only way to "redirect" to completely different pseudocode. | 05:07 |
|---|---|---|
| lkcl | the instruction quotes doesn't exist quotes | 05:07 |
| lkcl | doesn't have an authorised mnemonic | 05:08 |
| lkcl | is not approved by the OPF ISA WG | 05:08 |
| lkcl | and so on. | 05:08 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 05:09 | |
| lkcl | it has been explained by the Chair of the OPF ISA WG that post-increment was discussed (20+ years ago) extensively and DENIED | 05:18 |
| lkcl | the reason: | 05:18 |
| lkcl | you can always SUBTRACT the amount before going into a loop | 05:18 |
| lkcl | and you end up re-adding it back on inside the loop | 05:18 |
| lkcl | therefore there will be STRONG RESISTANCE to adding a post-inc instruction named "ldup" | 05:19 |
| lkcl | especially when there is no 32-bit opcode space available to do so | 05:19 |
| lkcl | a mnemonic - as you suggest - would "legitimise" the post-inc operation. | 05:20 |
| lkcl | people would expect, "where is the 32-bit operation???" | 05:20 |
| lkcl | there isn't one | 05:20 |
| lkcl | and there can NEVER be one. | 05:20 |
| lkcl | because they are all MAJOR opcodes. | 05:20 |
| lkcl | it would require SEVENTEEN major opcodes (probably more because of FP LD/ST) | 05:20 |
| lkcl | that's literally impossible | 05:21 |
| lkcl | the *only way* is to do it as a 64-bit operation | 05:21 |
| lkcl | but | 05:21 |
| lkcl | we 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 |
| lkcl | that would royally fuck things for us. | 05:21 |
| lkcl | hence | 05:22 |
| lkcl | "sv.ldu/pi" | 05:22 |
| lkcl | which is a "qualification" of "sv.ldu" | 05:22 |
| lkcl | which 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 |
| lkcl | whereas "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-soc | 05:39 | |
| *** ritish_ <ritish_!~Ritish@115.97.226.10> has joined #libre-soc | 07:03 | |
| *** Ritish <Ritish!~Ritish@115.97.40.46> has quit IRC | 07:03 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 07:26 | |
| *** ritish_ <ritish_!~Ritish@115.97.226.10> has quit IRC | 07:42 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 08:01 | |
| programmerjake | you could have post-inc load/st as 32-bit instructions without needing new major opcodes: just make the immediate smaller and have XO | 08:26 |
| programmerjake | 8-bit immediate is big enough for most uses and leaves 8 bits of XO -- plenty | 08:27 |
| programmerjake | if 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 |
| programmerjake | needing array indexing with a stride > 127 or < -128 is pretty uncommon | 08:32 |
| *** Ritish <Ritish!~Ritish@115.97.226.10> has joined #libre-soc | 08:33 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 09:12 | |
| *** octavius <octavius!~octavius@92.40.170.16.threembb.co.uk> has joined #libre-soc | 09:24 | |
| lkcl | programmerjake, absolutely no chance. | 10:24 |
| lkcl | do you not recall how badly attempting that went? | 10:25 |
| lkcl | i mentioned it multiple times over the past eight+ months since attempting modification of the meaning of LD/ST instructions by utilising part of the immediate | 10:25 |
| lkcl | plus as you well know that means modifying *the meaning of the scalar instruction as a scalar instruction* | 10:26 |
| lkcl | that would go down extremely badly with the OPF ISA WG and we would literally destroy our reputation and standing with them, irrevocably | 10:26 |
| programmerjake | uuh, that'd be adding *new* instructions, not having the svp64 prefix *modify* existing instructions, so that experience *modifying* doesn't apply | 10:27 |
| lkcl | no, no and no. | 10:27 |
| lkcl | have you forgotten that that is exactly and precisely what i did with the LD-ST-with-shift? | 10:27 |
| lkcl | and how many times i repeated that it went extremely badly? | 10:27 |
| lkcl | i am still tracking down the damage to the HDL and to openpower-isa to remove the unbelievably-complex modifications across the board | 10:28 |
| programmerjake | note i'm not seriously proposing new post-inc ld/st ops, just pointing out that the objection that they need 17 major ops is invalid | 10:28 |
| lkcl | over eight months later | 10:28 |
| lkcl | it is. | 10:28 |
| lkcl | please think through why | 10:29 |
| lkcl | and please do not argue otherwise | 10:29 |
| lkcl | i leave it with you | 10:29 |
| programmerjake | it 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 17 | 10:34 |
| programmerjake | in any case, it probably doesn't matter that much, so i'm fine dropping it | 10:35 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 10:39 | |
| *** octavius <octavius!~octavius@92.40.170.16.threembb.co.uk> has quit IRC | 10:50 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 11:13 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 11:44 | |
| *** Ritish <Ritish!~Ritish@115.97.226.10> has quit IRC | 11:53 | |
| *** Guest6747 <Guest6747!~irc@46.23.94.12> has quit IRC | 12:00 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 12:45 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.235> has joined #libre-soc | 12:45 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.235> has quit IRC | 13:11 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.235> has joined #libre-soc | 13:11 | |
| lkcl | you are proposing the violation of the HARD RULE that UNDER ABSOLUTELY NO CIRCUMSTANCES are instructions proposed that are exclusive to the SVP64 space | 14:32 |
| lkcl | it is a HARD AND ABSOLUTE REQUIREMENT that instructions added as 64-bit SVP64 ***ABSOLUTELY MUST*** have a corresponding scalar opcode | 14:32 |
| programmerjake | uuh, i said 32-bit instruction, idk how you thought that meant svp64-only | 14:33 |
| lkcl | where is the corresponding ***SCALAR*** instruction that has absolutely nothing to do with SVP64, in what you are proposing? | 14:33 |
| lkcl | and where is it going? | 14:34 |
| lkcl | in what opcode space? | 14:34 |
| lkcl | ok so you are discussing a *scalar* 32-bit instruction. | 14:34 |
| programmerjake | lkcl: yes | 14:34 |
| lkcl | ok so you are proposing DESTROYING ldu and other major opcodes in the *32-bit* space | 14:35 |
| lkcl | by proposing that the ISA WG accept the REMOVAL of ldu, and all other major-opcode 32-bit instructions | 14:35 |
| programmerjake | no, i said *new* instruction, not modifying/replacing existing instructions | 14:35 |
| lkcl | ok | 14:35 |
| lkcl | so where is the opcode space coming from in the 32-bit EXT0nn space? | 14:35 |
| lkcl | bear in mind that an absolutely massive *17 or greater* major opcodes are required | 14:36 |
| lkcl | that list is (incomplete): | 14:36 |
| lkcl | pwzu | 14:36 |
| lkcl | 33 lwzu | 14:37 |
| lkcl | 41 lhzu | 14:37 |
| programmerjake | idk, i didn't get far enough to pick, and it takes 17/256ths of a major opcode, not 17 major opcodes | 14:37 |
| lkcl | 49 lfsu | 14:37 |
| lkcl | 35 lbzu | 14:37 |
| lkcl | 43 hau | 14:37 |
| lkcl | 51 lfdu | 14:37 |
| lkcl | 37 stwu | 14:37 |
| lkcl | 45 sthu | 14:37 |
| lkcl | 53 wtfsu | 14:37 |
| lkcl | 39 stbu | 14:37 |
| lkcl | 55 stfdu | 14:37 |
| lkcl | and in EXT058 and EXT062 there is ldu and stdu | 14:38 |
| lkcl | i'm not going to put forward a proposal that has such a limited range in the immediate. | 14:39 |
| lkcl | a limited range would be questioned as to its value, and we cannot take the risk | 14:40 |
| programmerjake | well, 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 |
| programmerjake | in the rare case that the increment amount is > 127, just use ldu and one extra add insn before the loop | 14:44 |
| programmerjake | or did you have other common use cases for post-inc that need large increments? | 14:45 |
| programmerjake | looks 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 0010000000 | 14:57 |
| programmerjake | wait, i miscalculated how many bits were available... | 15:00 |
| programmerjake | powerisa v3.1b has the opcode table for ext19 incorrect afaict, they say xo is 28:31 yet have a 10-bit XO | 15:04 |
| programmerjake | that threw me off | 15:08 |
| programmerjake | well, in any case there's plenty of space. i won't worry about it. | 15:08 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.42.235> has quit IRC | 15:49 | |
| ghostmansd | lkcl, sorry for the delay. Thanks for clarification on the instructions! | 17:15 |
| ghostmansd | I have a question regarding assembly for stuff like `sv.crand/ff=eq/m=r10 12,2,33`. | 17:19 |
| ghostmansd | This is for 5-bit CRs, therefore it maps to CROpFF5RM. | 17:20 |
| ghostmansd | For 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-soc | 17:23 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 17:23 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 17:23 | |
| ghostmansd | lkcl, sorry for the delay. Thanks for clarification on the instructions! | 17:23 |
| ghostmansd | I have a question regarding assembly for stuff like `sv.crand/ff=eq/m=r10 12,2,33`. | 17:24 |
| ghostmansd | For 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 |
| ghostmansd | However, crand is 5-bit CRs, and these map to CROpFF5RM. | 17:25 |
| ghostmansd | And, well, that one has only RC1 field, which makes it look like as if only RC1/~RC1 is possible. | 17:26 |
| ghostmansd | However, our tests check `sv.crand/ff=eq/m=r10 12,2,33`, and somehow it worked before. | 17:26 |
| ghostmansd | I 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 |
| ghostmansd | But I didn't manage to trace what happens there, and it'd be great if you could share how it works. | 17:27 |
| ghostmansd | Which 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 |
| ghostmansd | I 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 |
| ghostmansd | The same logic for .inv + .CR can be applied to FF-for-3bit. | 17:32 |
| ghostmansd | But 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 IRC | 18:20 | |
| ghostmansd | I'm checking https://libre-soc.org/openpower/sv/cr_ops/, and there's no RC1 field at all. | 18:27 |
| ghostmansd | OK, 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 |
| lkcl | from 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-soc | 19:24 | |
| markos | do we have a meeting today? | 19:28 |
| markos | should be in 30min right? | 19:28 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 19:28 | |
| programmerjake | yes afaict | 19:42 |
| ghostmansd | lkcl, I still don't get how this magic with RC1 field works | 19:44 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=4aa2fff95f8b8ac88762f6b1be58f5b1e0780e9e;hb=refs/heads/master#l1796 | 19:45 |
| ghostmansd | This field, RC1, is not in the spec. Also, the comment explains nothing. | 19:46 |
| ghostmansd | From what I see in spec, this bit 19, should always be 1. | 19:46 |
| ghostmansd | https://libre-soc.org/openpower/sv/cr_ops/ | 19:46 |
| ghostmansd | And 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#l1429 | 19:48 |
| ghostmansd | Because, 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 |
| ghostmansd | I 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 |
| lkcl | hang on give me a sec | 20:00 |
| lkcl | https://libre-soc.org/openpower/sv/cr_ops/ - RC1 does not exist / apply | 20:00 |
| lkcl | RC1 is *not* the same as "Rc=1" | 20:01 |
| lkcl | RC1 is a special mode which *enables* Rc=1 for instructions which *do not* have a "." version | 20:01 |
| lkcl | but | 20:01 |
| lkcl | for cr_ops (such as crand) there is *no point* even having an Rc=1 mode | 20:01 |
| lkcl | because that means "write to CR0" | 20:01 |
| lkcl | and of course you are *already* writing to a CR Field | 20:02 |
| lkcl | ... | 20:02 |
| lkcl | ... specified by BT! | 20:02 |
| lkcl | therefore there is no RC1 mode for cr_ops | 20:02 |
| lkcl | Logical Operations are usually the ones that have no "Rc" option | 20:02 |
| lkcl | therefore having the RC1 mode for them "makes sense" | 20:02 |
| *** octavius <octavius!~octavius@92.40.170.15.threembb.co.uk> has joined #libre-soc | 20:03 | |
| lkcl | meeting room's open if anyone's available | 20:06 |
| markos | we're already there | 20:06 |
| octavius | Still same room code? | 20:06 |
| lkcl | sadoon[m], toshywoshy programmerjake octavius markos ghostmansd cesar jn | 20:06 |
| lkcl | hmmm | 20:06 |
| lkcl | split meeting room i think | 20:06 |
| gnucode | I'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 IRC | 21:29 | |
| *** octavius <octavius!~octavius@92.40.170.15.threembb.co.uk> has quit IRC | 21:58 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 22:16 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 22:18 | |
| lkcl | gnucode, ack. and and and :) | 23:51 |
| lkcl | i've been on one of those trips | 23:55 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!