| programmerjake | well, i just discovered that gitlab.com 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 |
|---|---|---|
| programmerjake | more specifically it counts one minute of public project ci usage as 0.008 minutes of usage in its accounting | 01:39 |
| openpowerbot | [mattermost] <lkcl> nice | 03:13 |
| lkcl | programmerjake, 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 function | 11:23 |
| lkcl | ValueCastable was *specifically* and intentionally designed by whitequark *not* to derive from Value | 11:24 |
| lkcl | that 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 system | 11:24 |
| lkcl | if you can think of a solution to that then we're good | 11:25 |
| lkcl | otherwise, ValueCastable has to go | 11:25 |
| lkcl | for AST-overrides it is absolutely critical that there be absolutely no difference of any kind in any way shape or form of the API | 11:33 |
| lkcl | duplication of the AST API would be a catastrophic mistake with massively-damaging implications. | 11:34 |
| lkcl | and is completely and utterly unnecessary | 11:34 |
| lkcl | duplication also becomes a third party maintenance nightmare. | 11:35 |
| lkcl | if there is ever any additions or changes to the ast.py API (extremely unlikely but not outside of the realm of possibility) | 11:35 |
| lkcl | *or* of changes *internally* to the interface that ast.py *uses* (much more likely) then the third party user has a serious problem | 11:36 |
| lkcl | their "copy" of ast.py - which was never in any way shape or form necessary in the first place - becomes hopelessly out of date | 11:36 |
| lkcl | or, 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 module | 11:37 |
| lkcl | or | 11:37 |
| lkcl | with care and attention | 11:37 |
| lkcl | we can make it possible for them to pass in *ONE FUNCTION* - the Casting function - and ast.py uses that **ONE** function to perform the required job of casting anything within the Module() to that type | 11:38 |
| lkcl | that's literally all it takes to make it possible to use dsl.py in a generic way | 11:39 |
| lkcl | damn | 11:39 |
| lkcl | i meant dsl.py in all of the above. dsl.py contains Module() | 11:39 |
| lkcl | sorry about that | 11: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_BA | 12:42 |
| ghostmansd[m] | cr_in2 would be SVP64_CR_IN2_SEL_BB | 12: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 svp64.py is, at best, somewhat sophisticated. | 13:36 |
| ghostmansd[m] | *sv_etype, sorry | 13:36 |
| lkcl | ghostmansd[m], moornin | 13:40 |
| lkcl | Idx_1_2... trying to work out what that refers to | 13:41 |
| lkcl | found it... | 13:41 |
| openpowerbot | [mattermost] <lkcl> https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_enums.py;h=e7c83002456cbd598735caef95eb97471e17443d;hb=38cf1167de852cba8548cfd366cd8ded76b7a2ba#l150 | 13:43 |
| openpowerbot | [mattermost] <lkcl> correct: there's currently no SVP64 instructions added which use CRs, but there's room in the spec to do so | 13:44 |
| openpowerbot | [mattermost] <lkcl> which i have to actually implement first, along with unit tests | 13:44 |
| openpowerbot | [mattermost] <lkcl> it'll be covered underrrrr.... https://libre-soc.org/openpower/sv/cr_ops/ | 13:45 |
| openpowerbot | [mattermost] <lkcl> but please don't attempt adding that yet, as i need to get it into svp64.py first, PowerDecoder2, ISACaller simulator, and unit tests. | 13:45 |
| openpowerbot | [mattermost] <lkcl> attn dcbf, eieio, all of these are *not* Vectorised. at all | 13:46 |
| openpowerbot | [mattermost] <lkcl> b and bc will *become* Vectorised... later... again, like cr_ops, there is a page for them https://libre-soc.org/openpower/sv/branches/ | 13:46 |
| openpowerbot | [mattermost] <lkcl> but generally if something has an sv_type of NONE it means "completely ignore it" | 13:47 |
| openpowerbot | [mattermost] <lkcl> like | 13:47 |
| openpowerbot | [mattermost] <lkcl> how can you Vectorise mtmsr? | 13:47 |
| openpowerbot | [mattermost] <lkcl> move to global (single) MSR register | 13: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 mtmsr | 13: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 error | 13:49 |
| * lkcl pokes openpowerbot | 13:50 | |
| lkcl | poking bot again to check connection | 13:53 |
| ghostmansd[m] | lkcl, OK, sounds perfectly reasonable | 13:59 |
| ghostmansd[m] | And also was my impression :-) | 13:59 |
| ghostmansd[m] | So, I'll raise an error whenever etype is marked as none | 13:59 |
| lkcl | yes 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 |
| lkcl | then of course they won't get into the svp64-opc.c tables, makes sense | 14:59 |
| octavius | lkcl, 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 |
| lkcl | octavius: use the class which should already be set up to handle that | 16:58 |
| lkcl | 1 sec | 16:58 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/debug/jtag.py;h=4b4f17a97d672c3f22b668008a1c058ac2500da6;hb=919ad8e3c110f5af0779d7e1d329736c245b56ae#l26 | 16:59 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simple/issuer.py;h=60948dcc51c7b576a0f23e0805b68f93ddcea65f;hb=919ad8e3c110f5af0779d7e1d329736c245b56ae#l217 | 17:00 |
| lkcl | get_pinspecs | 17:00 |
| lkcl | which is in,,, | 17:00 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simple/issuer.py;h=60948dcc51c7b576a0f23e0805b68f93ddcea65f;hb=919ad8e3c110f5af0779d7e1d329736c245b56ae#l44 | 17:00 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/config/pinouts.py;h=95129b1999e733b44c5f46c265d9b1c478c4a8f4;hb=919ad8e3c110f5af0779d7e1d329736c245b56ae#l59 | 17:01 |
| lkcl | there. | 17:01 |
| lkcl | use that function | 17:01 |
| lkcl | strictly speaking that function should be moved entirely into the pinmux module | 17:01 |
| lkcl | you need to *really* watch out for dependencies there. | 17:02 |
| lkcl | pinmux 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_2 | 19:22 |
| ghostmansd[m] | Those insns which are ETYPE_NONE are either not supported yet or not vectorised at all | 19: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 nature | 19: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 |
| lkcl | ghostmansd[m], nice. yes the idea was to have some sort of categorisation not just used for one specific purpose | 20:28 |
| lkcl | of course sv_bitmanip.py gets into specialisation | 20:28 |
| lkcl | you noticed i also added.. what was it... | 20:29 |
| lkcl | mode. | 20:30 |
| lkcl | the mode column makes all the bullshit "if insn.startswith("ld")" all go away | 20:30 |
| lkcl | because you can use "if mode == 'LDST'" | 20:30 |
| lkcl | strictly speaking if mode is NONE then that is actually the correct/canonical way to detect non-vectorised | 20:31 |
| lkcl | not Etype, at all (!) | 20:31 |
| ghostmansd[m] | Ah, cool | 20:32 |
| ghostmansd[m] | I actually missed it: I filter-out fields unknown to sv_binutils | 20:33 |
| ghostmansd[m] | I'll check it, thanks for tip | 20:33 |
| lkcl | i only added it like 2 weeks ago :) | 20:33 |
| lkcl | ironically at the moment it is basically doing the "if insn.startswith("ld") blah blah" back in sv_analysis.py | 20:34 |
| lkcl | but to stop people from having to duplicate that bullshit i added the extra column | 20:34 |
| ghostmansd[m] | The recent commits in sv_binutils was about hour ago I think :-) | 20:35 |
| lkcl | the 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 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=e4de47020542f6c01b43e8b90ba29ac7bcdafa0b | 20:35 |
| lkcl | dang a month ago already | 20:35 |
| lkcl | okaay so that's why you'd suddenly be seeing IDX_1_2 because i added qualification of crops as mode="CROP" | 20:36 |
| lkcl | which, hm, temporarily, you will need to filter out, oh well | 20:37 |
| lkcl | and bc as well. | 20:37 |
| lkcl | the only two that have been put into code, unit tests, etc. etc., are mode=NORMAL and mode=LDST | 20: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 useful | 20:58 |
| octavius | OpenPOWER meeting in 10min | 21:50 |
| lkcl | markos meeting? | 22:04 |
| lkcl | are you free? | 22:04 |
| ghostmansd | I miss the meeting again, since the whole family around is asleep :-) | 22:19 |
| ghostmansd | Anyway, I have good news | 22:19 |
| ghostmansd | This... https://pastebin.com/v6VP9xGM | 22:19 |
| ghostmansd | ...gives an identical listing for both binutils and svp64.py | 22:20 |
| ghostmansd | here's what we have for now with binutils: https://pastebin.com/v4Hd9V2R | 22:20 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!