D3D shader assembler

[Matteo Bruni]

2009/7/20 Henri Verbeet <hverbeet at gmail.com>:
> 2009/7/20 Matteo Bruni <matteo.mystral at gmail.com>:
>> That function, in particular, should really be into asmparser.c and
>> not be visible from outside. Then the wine_dbg_sprintf() function
>> comes really handy in this situation, I didn't know it. Note also that
>> this debug_src function is used just to print trace info during asm
>> parsing, not to generate the intermediate representation or the
>> bytecode.
> Yeah, but you can treat the debug output just like another
> asmparser_backend. That would mean calling the parser twice when
> debugging, but that should be ok. You can do something similar on the
> bytecode writing side.

I'm not so persuaded on making another backend for debug messages, as
in this way the debug things would be separated from the processing
code, and could easily happen they don't perfectly match (by
mistakes).
If you don't feel strongly against, I prefer to just fix the debug_src
things as you suggested, without splitting the parsed_shader
infrastructure.

>
>> A question: do you have an idea how I could split this in separate
>> patches? I can think of separating the parser from the bytecode
>> writer, but doesn't seems to me that this would be a real improvement.
>> Adding some shader instructions handling each time (for ex. starting
>> with just shader model 1, then separate patches for the subsequent
>> versions) maybe is better, but the first patch won't be really simpler
>> than this, I believe, as it would be alike this patch but without a
>> bunch of cases/functions.
>>
> You could probably split it into a patch adding the basic framework
> and separate patches for each instruction. That also implies that you
> can wait with adding supporting functions like the various debug
> functions until they're used for the first time.

This needs some work but certainly can be done, and will be done when
finally sending the patches to wine-patches.

> Thinking about the
> basic design some more, it's not entirely clear to me why you've got
> separate asmparser_*() functions for each instruction though. They
> look largely similar, and I think the differences like e.g. number of
> source arguments could be handled by an appropriate lookup table.
>

While in principle this is right, as many functions are indeed very
similar, this won't be pretty practically, even excluding that some
instructions really need special treatment. The problem is that the
different asmparser_* functions have different signatures (0, 1, 2 or
3 src registers, comparison or not, etc). So the generic function
should accept all the parameter combinations used by them (leading to
a quite long function signature), most of them set to NULL in the
function invocation, or it should manage a variable number of
arguments.
Conversely, this is very much doable in the bytecode writer, as there
all the functions have already the same format; I can simply replace
the function pointers in the backends to make them point to a single
function (excluding the instructions that really need special
handling), and the function, using a lookup table or a switch, can
convert from the internal instruction opcode to the D3D one.