ChanServ changed the topic of #freedesktop to: https://www.freedesktop.org infrastructure and online services || for questions about freedesktop.org projects, please see each project's contact || for discussions about specifications, please use https://gitlab.freedesktop.org/xdg or xdg@lists.freedesktop.org
<karolherbst>
not really sure how to deal with this
<karolherbst>
I could make the forms templates on their own, but then each ALU instruction needs to declare all of those
<karolherbst>
also.. they kind of overwrite stuff of the "base" but I guess I could move more into the overrides
<karolherbst>
(e.g. MOD1 and MOD2)
<karolherbst>
but also not quite sure how that all works out with actual encoding
<karolherbst>
any thoughts?
<robclark>
karolherbst: are all these different forms common to all the instructions that would extend #alu-instruction? You could just put MOD1/MOD2/etc in the various different overrides that they apply to, right? I guess for example MOD1 is n/a to FORM==2, right? (You could use a <derived> field to give it a default value like zero, if needed)
<karolherbst>
robclark: correct
<karolherbst>
but MOD1 is available in MODE 2
<robclark>
Ok, yeah, then I think I'd just move them (other than FORM itself and whatever else is common to all the cases) into the different overrides
<karolherbst>
it just applies for SRC2 then
<karolherbst>
form 2-4 are swapped 5-7 modes
<karolherbst>
uhm...
<karolherbst>
2/3 are swapped 4/5
<karolherbst>
same encoding, but SRC1 and SRC2 are exchanged
<karolherbst>
robclark: what I am only curious about is, that "encode" tags are not valid inside overrides, are they?
<karolherbst>
the other annoying part is why I need _PAD, because if I have patterns and overwrite them with fields inside an override, I get "dontcare bits found" thingies
<robclark>
no, or at least I haven't needed that before (encode in override)
<karolherbst>
I think you can also only have 7 or 8 overrides :D
<karolherbst>
getting some weird crashes having that many
<robclark>
hmm, I don't think there should be any limit
<karolherbst>
didn't debug, but I get "nvir-disasm: ../src/compiler/isaspec/decode.c:268: pop_scope: Assertion `scope->state->scope == scope' failed."
<robclark>
oh, I think it is probably expr_stack?
<robclark>
in struct decode_state?
<robclark>
maybe somehow you are exceeding that?
<robclark>
hmm push_expr() could perhaps use an assert
<karolherbst>
maybe?
<karolherbst>
yeah, bumped that to 16 and it's fixed
<karolherbst>
anyway.. kind of feels like we might want a different solution... but...fiddling with isaspec looks like something where I could break stuff easily :)
<karolherbst>
but I suspect we might want something like encoding specializations or something... dunno
<karolherbst>
let me move everything into the overrides and see how that looks/feels like
<robclark>
when I get a chance I'll make some unit tests for isaspec.. we do have *some* indirect testing in CI in that we have ir3 tests that exercise encode and decode, so it at least should be obvious in CI if you break anything too badly
<karolherbst>
I might also need to rework some of the displaying bits, because I think trying to get 1:1 matching output with nvidias dissassembler might allow for some nice testing
<karolherbst>
they often auto hide things, so that's the annoying bit
<robclark>
you could make a field display empty string by splitting it into a bitset which itself has an <override>.. perhaps that is one way to deal with that. For sure we used diffing to previous decode as a way of testing during conversion to isaspec and there were special cases and instruction aliases and such
<robclark>
(like mov/mova/cov, etc)
<karolherbst>
robclark: I need derived inside overrides :)
<karolherbst>
or I just do displays for each override...
<karolherbst>
but then that sucks for 2 vs 3 src alus
<robclark>
both of those are options, you can use <derived> anywhere you can use <field>
<karolherbst>
that PAD0/PAD1 stuff is... annoying, but I guess better than nothing
<robclark>
seems reasonable.. is PADn just dontcare that you don't want to warn about?
<karolherbst>
correct
<karolherbst>
it warns about them even when overriding patterns :/
<karolherbst>
if having neither, it complains about not set bits
<robclark>
I suppose we could relax <assert> to allow dontcare (x) bits, maybe that would be cleaner if you don't want to assert that they are 1 or 0
<robclark>
anyways, I guess PADn works for now
<karolherbst>
well.. they are dontcare if not used by a form though
<karolherbst>
but it feels like we might want to extend isaspec somehow, but can't really come up with something which is clean enough, without duplicating things too much
<karolherbst>
mhhh
<robclark>
I mean, isaspec wants to make sure all bits are accounted for in all permutations of an instruction, to ensure that something didn't get missed.. <assert> is one way to account for bits that aren't used in some <field> for some particular <overide>.. it kinda sounds like you want something like that, but less strict ;-)
<karolherbst>
maybe have a form list instead of overrides, which is like a switch
<karolherbst>
and then isaspec can look at all cases to figure out bits
<karolherbst>
so if a bit is provided in all cases, the "base" doesn't need it to be set
<robclark>
right.. that is already the case (or at least should be)
<karolherbst>
yeah... just not if you rely on overrides :/
<robclark>
well, the part outside of all of the <override> is like the "default:" case in aswitch
<karolherbst>
sure
<robclark>
I guess it doesn't realize that the overrides you have setup cover all the possible values of {FORM}
<karolherbst>
yeah
<emersion>
this is #freedesktop, not #dri-devel, fwiw
<karolherbst>
ahhh crap :D
<karolherbst>
moving over then
progandy has quit [Ping timeout: 480 seconds]
progandy has joined #freedesktop
Rainer_Bielefeld_away has quit [Remote host closed the connection]
progandy has quit [Ping timeout: 480 seconds]
progandy has joined #freedesktop
ximion has joined #freedesktop
garrison has joined #freedesktop
i-garrison has quit [Read error: Connection reset by peer]