Inconsistency in Validation Framework

[EAlexJ]

The following statement is not allowed by the validator
extern char MEM[1 << XLEN] [[is_main_mem]];
Since << is not allowed in the "[..]" operator.
Fixing it by introducing a variable like so:

unsigned<XLEN+1> MEMSIZE = 1 << XLEN;
extern char MEM[MEMSIZE] [[is_main_mem]];

Does not work, since 'XLEN+1' is not allowed in the type declaration.

Creating a new variable like so:

unsigned int XLEN;
unsigned<33> XLENP = XLEN +1;

unsigned<XLENP> MEMSIZE = 1 << XLEN;
extern char MEM[MEMSIZE] [[is_main_mem]];

seems to be the only option, since casting in constant expressions like this is not allowed either:
unsigned int XLENP = (unsigned int)(XLEN +1);

This is counterintuitive, there should be no need for enlarged datatypes.

Casting in declarations should be allowed.
The best solution to the original problem is to allow the << Operator inside the extern array declaration.

Edit:
I have spoken too soon, the "Fix" unsigned<XLENP> MEMSIZE = 1 << XLEN; is also just a shift operation which after all is not allowed in any declarations.
This means shift operations are not usable at all in declarations.

[AtomCrafty]

You are right, none of the bitwise operators are currently supported in constant expressions.

If I recall correctly, we pushed it down the line due to some open questions regarding the semantics of the shift operator when used in constant expressions. Based on the the current type rules of the shift operator, expressions of the form 1 << n will always evaluate to zero for n != 0, because the result must always have type unsigned<1>.

Btw, you can use XLEN+1 in a type specifier, but it needs to be parenthesized like this, because otherwise the '>' would conflict with the greater than operator in the grammar: unsigned<(XLEN+1)>. Regarding the cast: I had previously made the proposal that type rules can be ignored for constant assignments, as long as the calculated value fits in the assignment target. It is currently tracked as #75.