Wednesday, 2022-06-01

programmerjakewell, i just discovered that doesn't limit CI minutes to only 400 if your project is public, instead it limits it to 50000min/mo ... I won't have to worry about running out when trying to get nmigen ci to work then!01:38
programmerjakemore specifically it counts one minute of public project ci usage as 0.008 minutes of usage in its accounting01:39
openpowerbot[mattermost] <lkcl> nice03:13
lkclprogrammerjake, the issue with ValueCastable is that its co-existence with UserValue destroys the possibility of establishing the highest (leaf-node) inheritance chain for the up-casting function11:23
lkclValueCastable was *specifically* and intentionally designed by whitequark *not* to derive from Value11:24
lkclthat completely destroys all and any possibility of using isinstance(Value) as well as python class-derivative-chain detection functions normally expected of an up-casting system11:24
lkclif you can think of a solution to that then we're good11:25
lkclotherwise, ValueCastable has to go11:25
lkclfor AST-overrides it is absolutely critical that there be absolutely no difference of any kind in any way shape or form of the API11:33
lkclduplication of the AST API would be a catastrophic mistake with massively-damaging implications.11:34
lkcland is completely and utterly unnecessary11:34
lkclduplication also becomes a third party maintenance nightmare.11:35
lkclif there is ever any additions or changes to the API (extremely unlikely but not outside of the realm of possibility)11:35
lkcl*or* of changes *internally* to the interface that *uses* (much more likely) then the third party user has a serious problem11:36
lkcltheir "copy" of - which was never in any way shape or form necessary in the first place - becomes hopelessly out of date11:36
lkclor, worse, they are forced into the situation of either updating their third party module, or choosing to use an older version of nmigen until such time as they can schedule an update to their third party module11:37
lkclwith care and attention11:37
lkclwe can make it possible for them to pass in *ONE FUNCTION* - the Casting function - and uses that **ONE** function to perform the required job of casting anything within the Module() to that type11:38
lkclthat's literally all it takes to make it possible to use in a generic way11:39
lkcli meant in all of the above. contains Module()11:39
lkclsorry about that11:39
ghostmansd[m]lkcl, we don't support Idx_1_2 yet, right?12:39
ghostmansd[m]That said, if we'd have supported it... this would require another cr_in and sv_cr_in field, right?12:40
ghostmansd[m]That is, we'd have had cr_in1 and cr_in2, as well as sv_cr_in1 and sv_cr_in2.12:41
ghostmansd[m]cr_in1 would be SVP64_CR_IN1_SEL_BA12:42
ghostmansd[m]cr_in2 would be SVP64_CR_IN2_SEL_BB12:43
ghostmansd[m]And enum of values for cr_in2 could be only either SVP64_CR_IN2_SEL_NONE or SVP64_CR_IN2_SEL_BB.12:44
ghostmansd[m]I'd actually prefer the code not to handle this idx_1_2 specifically, to be honest, so I'm thinking of teaching the sv_binutils generator (and only it) to consider this. Thoughts?12:45
ghostmansd[m]Also, SVP64_SV_EXTRA_NONE at either sv_in1/sv_out/sv_cr_in/etc. can only happen if the operand we're looking at is not present, right? That is, if corresponding in1/out/cr_in/etc. is also marked as NONE, and there's no operand (e.g. insn has 1 out and 2 in operands, and does not affect CRs, in3 would be None, so is sv_in3).12:49
ghostmansd[m]lkcl, another question. There're some insns  (attn, attn., b, bc, dcbf, eieio, etc.), which have sv_eype == SVEtype.NONE. How to deal with these? The code regarding extras handling in is, at best, somewhat sophisticated.13:36
ghostmansd[m]*sv_etype, sorry13:36
lkclghostmansd[m], moornin13:40
lkclIdx_1_2... trying to work out what that refers to13:41
lkclfound it...13:41
openpowerbot[mattermost] <lkcl>;a=blob;f=src/openpower/decoder/;h=e7c83002456cbd598735caef95eb97471e17443d;hb=38cf1167de852cba8548cfd366cd8ded76b7a2ba#l15013:43
openpowerbot[mattermost] <lkcl> correct: there's currently no SVP64 instructions added which use CRs, but there's room in the spec to do so13:44
openpowerbot[mattermost] <lkcl> which i have to actually implement first, along with unit tests13:44
openpowerbot[mattermost] <lkcl> it'll be covered underrrrr....
openpowerbot[mattermost] <lkcl> but please don't attempt adding that yet, as i need to get it into first, PowerDecoder2, ISACaller simulator, and unit tests.13:45
openpowerbot[mattermost] <lkcl> attn dcbf, eieio, all of these are *not* Vectorised. at all13:46
openpowerbot[mattermost] <lkcl> b and bc will *become* Vectorised... later... again, like cr_ops, there is a page for them
openpowerbot[mattermost] <lkcl> but generally if something has an sv_type of NONE it means "completely ignore it"13:47
openpowerbot[mattermost] <lkcl> like13:47
openpowerbot[mattermost] <lkcl> how can you Vectorise mtmsr?13:47
openpowerbot[mattermost] <lkcl> move to global (single) MSR register13:47
openpowerbot[mattermost] <lkcl> there's just conceptually no way in hell that can be Vectorised.13:47
openpowerbot[mattermost] <lkcl> therefore there's neverrrr going to be an SVP64 variant of mtmsr13:48
openpowerbot[mattermost] <lkcl> therefore binutils should very specifically ignore it and under no circumstances allow sv.mtmsr to be accepted as a valid instruction.13:48
openpowerbot[mattermost] <lkcl> as in: attempting to use non-vectorisable sv.attn or sv.dcbf or sv.eieio should raise a syntax error13:49
* lkcl pokes openpowerbot13:50
lkclpoking bot again to check connection13:53
ghostmansd[m]lkcl, OK, sounds perfectly reasonable13:59
ghostmansd[m]And also was my impression :-)13:59
ghostmansd[m]So, I'll raise an error whenever etype is marked as none13:59
lkclyes please, that's really important.14:06
ghostmansd[m]I thought a bit more. I won't simply generate such entries in C code, that'd be the best.14:25
ghostmansd[m]And, as such, we won't have sv_etype == NONE at all in C.14:26
ghostmansd[m]I suggest dropping entries with Idx_1_2 as well, since we don't support those.14:26
ghostmansd[m]This will simplify the C code, dropping entities which we don't support yet, or won't support ever.14:28
lkclthen of course they won't get into the svp64-opc.c tables, makes sense14:59
octaviuslkcl, is there a particular json file I should use for developing the pinmux? I generated the "microtest", should I use the "litex_pinpads.json"?16:21
lkcloctavius: use the class which should already be set up to handle that16:58
lkcl1 sec16:58
lkclwhich is in,,,17:00
lkcluse that function17:01
lkclstrictly speaking that function should be moved entirely into the pinmux module17:01
lkclyou need to *really* watch out for dependencies there.17:02
lkclpinmux the library *must* not import anything from any other libre-soc library.17:02
ghostmansd[m]lkcl, it took more time than I wanted and perhaps is somewhat dirty, but I got the result I wanted :-)19:20
ghostmansd[m]No more SVP64_SV_ETYPE_NONE and SVP64_SV_EXTRA_IDX_1_219:22
ghostmansd[m]Those insns which are ETYPE_NONE are either not supported yet or not vectorised at all19:22
ghostmansd[m]Those which have EXTRA_IDX_1_2 should first be implemented and likely the code around should be refactored to reflect its two-input-cr nature19:23
ghostmansd[m]I also find sv_ prefix redundant, that is, svp64_sv_etype is somewhat tautological, compared to svp64_etype. I'm going to change it as well.19:24
ghostmansd[m]I really cleaned up a lot of things in process of remapping instructions. Way more straightforward commits. Still more ahead.19:26
lkclghostmansd[m], nice. yes the idea was to have some sort of categorisation not just used for one specific purpose20:28
lkclof course gets into specialisation20:28
lkclyou noticed i also added.. what was it...20:29
lkclthe mode column makes all the bullshit "if insn.startswith("ld")" all go away20:30
lkclbecause you can use "if mode == 'LDST'"20:30
lkclstrictly speaking if mode is NONE then that is actually the correct/canonical way to detect non-vectorised20:31
lkclnot Etype, at all (!)20:31
ghostmansd[m]Ah, cool20:32
ghostmansd[m]I actually missed it: I filter-out fields unknown to sv_binutils20:33
ghostmansd[m]I'll check it, thanks for tip20:33
lkcli only added it like 2 weeks ago :)20:33
lkclironically at the moment it is basically doing the "if insn.startswith("ld") blah blah" back in sv_analysis.py20:34
lkclbut to stop people from having to duplicate that bullshit i added the extra column20:34
ghostmansd[m]The recent commits in sv_binutils was about hour ago I think :-)20:35
lkclthe last thing we need is a massive list of "if this instruction it's this type, if that instruction it's the other"20:35
lkcldang a month ago already20:35
lkclokaay so that's why you'd suddenly be seeing IDX_1_2 because i added qualification of crops as mode="CROP"20:36
lkclwhich, hm, temporarily, you will need to filter out, oh well20:37
lkcland bc as well.20:37
lkclthe only two that have been put into code, unit tests, etc. etc., are mode=NORMAL and mode=LDST20:38
ghostmansd[m]I think I've always seen IDX_1_2, because, well, I generate it from SVEXTRA enum :-)20:58
ghostmansd[m]Anyway, I'll dig into mode field, I guess it'll be useful20:58
octaviusOpenPOWER meeting in 10min21:50
lkclmarkos meeting?22:04
lkclare you free?22:04
ghostmansdI miss the meeting again, since the whole family around is asleep :-)22:19
ghostmansdAnyway, I have good news22:19
ghostmansdThis... an identical listing for both binutils and svp64.py22:20
ghostmansdhere's what we have for now with binutils:

Generated by 2.17.1 by Marius Gedminas - find it at!