HLSL Grammar ... Tokens?
Hi,
I am currently working on a HLSL parser, and while the HLSL grammar can be found in the online reference I've got a few questions about the tokens to be used.
Especially, I couldn't figure out how T_TYPE_ID and T_NON_TYPE_ID should be defined.. I've got a few ideas that seem to work but would rather use the 'official' definition and not have mine break at some random point in the future.
Also, the assignment operator tokens aren't quite clear. The grammar lists quite a few possible assignment operators (<<=, >>=, *=, /=, +=, -=, %=, &=, |=, ^=) but i'm not quite clear how I should map these to the five tokens used in AssignmentExpr (T_OP_ME, T_OP_DE, T_OP_RE, T_OP_AE and T_OP_SE). Right now it doesn't really matter, but again I'd prefer to go with the 'official' way to do things for long term compatibility.
Regards,
-Stephan
[879 byte] By [
step] at [2007-12-23]
The T_TYPE_ID and T_NON_TYPE_ID tokens are like identifiers in C. The first is for identifiers that are types in scope created by typedef and the second is for any other identifier. So something like "typedef int foo; foo bar" would tokenize as "T_KW_TYPEDEF T_KW_INT T_NON_TYPE_ID ';' T_TYPE_ID T_NON_TYPE_ID".
As for the assignment operators, the names are aribitrary so you should just make up your own if they're confusing. I don't see any compatibility issue. The bitwise assigment operator tokens aren't used in the grammar, but should be treated as one erroneous token instead of two or three in case it matters somehow.
Okay.. thanks.. I guess the fact that the bitwise assignments aren't used was what threw me off...
The distinction between T_TYPE_ID and T_NON_TYPE_ID then is not lexical, but semantic. That certainly explains why I couldn't figure out how to define them in the tokenizer - because I can't, or at least wouldn't know how to do that in Coco/R.
A few minor modifications later my parser works like a charm!
Cheers, stephan
