2009/7/20 Matteo Bruni matteo.mystral@gmail.com:
2009/7/20 Henri Verbeet hverbeet@gmail.com:
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).
They don't necessarily have to, the debug code only has to print what the parser read.
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.
I don't feel strongly about it, but it's probably less trouble in the long run.
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.
Which functions need special treatment? You can pass source arguments as an array + count, that's how they're stored in "struct instruction" anyway. All these callbacks really do is building an instruction and adding them to the array. You may not need a callback for that at all. Of course this will require some changes to the way the parser is setup.