On 3 December 2015 at 11:04, Józef Kucia <jkucia(a)codeweavers.com> wrote:
Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> --- This fixes infinite loop when dcl_immediateConstantBuffer is parsed.
Unfortunately, I had to reindent whole wined3d_sm4_opcode enum in order to make space for WINED3D_SM4_OP_DCL_IMMEDIATE_CONSTANT_BUFFER. I was also considering to use a shorter name: WINED3D_SM4_OP_DCL_IMMEDIATE_BUFFER. --- It's fine, if perhaps unfortunate. You could do something like WINED3D_SM4_OP_DCL_IMM_CB if we really want something shorter, but it's probably best to just follow the opcode name.
+ WINED3D_SM4_OP_MAX = 0x34, + WINED3D_SM4_OP_DCL_IMMEDIATE_CONSTANT_BUFFER = 0x35, + WINED3D_SM4_OP_MOV = 0x36, This is odd. I'd expect a DCL_ opcode to be in the > 0x58 range. Still, there's a hole there in the normal range, and "min" and "max" are also reversed compared to what you'd expect, so I suppose it's at least plausible.
opcode_token = *(*ptr)++; opcode = opcode_token & WINED3D_SM4_OPCODE_MASK; - len = ((opcode_token & WINED3D_SM4_INSTRUCTION_LENGTH_MASK) >> WINED3D_SM4_INSTRUCTION_LENGTH_SHIFT) - 1; + + if (opcode == WINED3D_SM4_OP_DCL_IMMEDIATE_CONSTANT_BUFFER) + len = *(*ptr) - 1; + else + len = ((opcode_token & WINED3D_SM4_INSTRUCTION_LENGTH_MASK) >> WINED3D_SM4_INSTRUCTION_LENGTH_SHIFT) - 1;
I don't think this is the right place to handle this. You should be able to handle this the same way as the other DCL_ opcodes. It should probably also have an entry in the opcode_info table. (Compare e.g. 6d948e1a8cdd8a9a5ae2b6124468275cbf13f2b8.)