On 3 December 2015 at 11:04, Józef Kucia jkucia@codeweavers.com wrote:
Signed-off-by: Józef Kucia jkucia@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.)