D3D shader assembler

[Henri Verbeet]

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.

> 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. 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.