The pseudo C grammar has currently the following ambiguities:
Initializations and assignments are ambiguous. The manual sometimes types new variables sometimes not.
e.g. smt = Rss vs. size64u_t smt = Rss. Both are valid variable initialization in the manual.
Types like size8u_t can be interpreted as variable and not as type_specifier. This should be fixed somehow.
Statements like these:
((TLB[i] == 0) && (TLB[i] == Rs[26:20])) are interpreted either as
((TLB[i] == 0) && (TLB[i] == Rs[26:20])) - logical AND
or
((TLB[i] == 0) & (&(TLB[i] == Rs[26:20]))) - Bitwise AND with pointer (&) of (TLB[i] == Rs[26:20]). -> This is wrong.
Removing the unary & operator from the grammar fixes the problem. But this becomes a problem if the manual ever uses it.
The pseudo C grammar has currently the following ambiguities:
Initializations and assignments are ambiguous. The manual sometimes types new variables sometimes not. e.g.
smt = Rssvs.size64u_t smt = Rss. Both are valid variable initialization in the manual.Types like
size8u_tcan be interpreted asvariableand not astype_specifier. This should be fixed somehow.Statements like these:
((TLB[i] == 0) && (TLB[i] == Rs[26:20]))are interpreted either as((TLB[i] == 0) && (TLB[i] == Rs[26:20]))- logical AND or((TLB[i] == 0) & (&(TLB[i] == Rs[26:20])))- Bitwise AND with pointer (&) of(TLB[i] == Rs[26:20]). -> This is wrong. Removing the unary&operator from the grammar fixes the problem. But this becomes a problem if the manual ever uses it.