Re: [PATCH 5/5] d3dcompiler: Implement basic expressions parsing.

[Stefan Dösinger]

Am Montag, 16. Juli 2012, 20:39:23 schrieb Matteo Bruni:
> +    HLSL_IR_BINOP_MUL,
> ...
> +    HLSL_IR_BINOP_DOT,
> HLSL has 3 somewhat related multiplication operations: "*", "mul" and "dot". 
> Dot is fairly straightforward, but "*" and "mul" have subtle differences. I 
> recommend to write tests to find out the exact details, but as far as I 
> remember "float4 * float4" gives you a float4 with a component-wise 
> multiplication, whereas mul(float, float) returns a scalar like the dot 
> product. "float4x4 * float4" is an error, but mul(float4x4, float4) performs a 
> matrix-vector multiplication and returns a float4.
> +static struct hlsl_type *expr_common_type(struct hlsl_type *t1, struct
> hlsl_type *t2,
> +        struct source_location *loc)
> This type inference system might be a bit too limited, you have to take the 
> operation into account. e.g. a dot(float3, float4) returns a scalar and 
> crs(float4, float4) returns a float3.

[PATCH 5/5] d3dcompiler: Implement basic expressions parsing.

[Matteo Bruni]

2012/7/17 Stefan Dösinger <stefandoesinger(a)gmx.at>:
> Am Montag, 16. Juli 2012, 20:39:23 schrieb Matteo Bruni:
> > +    HLSL_IR_BINOP_MUL,
> > ...
> > +    HLSL_IR_BINOP_DOT,
> > HLSL has 3 somewhat related multiplication operations: "*", "mul" and "dot".
> > Dot is fairly straightforward, but "*" and "mul" have subtle differences. I
> > recommend to write tests to find out the exact details, but as far as I
> > remember "float4 * float4" gives you a float4 with a component-wise
> > multiplication, whereas mul(float, float) returns a scalar like the dot
> > product. "float4x4 * float4" is an error, but mul(float4x4, float4) performs a
> > matrix-vector multiplication and returns a float4.

Indeed this is not very clear, but with HLSL_IR_BINOP_MUL I mean the
translation of the "*" operator, while I'm planning to handle the
mul() intrinsic with some code translating that into a bunch of MULs,
ADDs and DOTs depending on the specific data types. mul() is
apparently documented quite okay in MSDN but I know I'll have to test
all of that anyway...
> > +static struct hlsl_type *expr_common_type(struct hlsl_type *t1, struct
> > hlsl_type *t2,
> > +        struct source_location *loc)
> > This type inference system might be a bit too limited, you have to take the
> > operation into account. e.g. a dot(float3, float4) returns a scalar and
> > crs(float4, float4) returns a float3.

Yeah, you're right, I'll need to take into account the operation in
some cases, I consider this as a first "approximation". However I was
planning to handle the "intrinsic function parameters / return value"
case you mention in a different way, i.e. by explicitly generating all
the intrinsic functions prototypes, with all the data type
combinations allowed, and letting the (currently missing) "overloaded
functions type checker/dispatcher" deal with the data types.

Not that I have written that code yet, so it may reveal to be a bad
idea in the end. Stay tuned...