-
Notifications
You must be signed in to change notification settings - Fork 4
Description
An issue I've been facing repeatedly is that constant expression evaluation is required during the elaboration phase, before any sort of expression type analysis is performed. This means the constant expression evaluation cannot take type information into account. We didn't fully consider the implications of this back then, and it's coming back to haunt us now.
The problem is that many of the important operators dictate that the operands must be implicitly cast to the operation's result type before it is applied, and the result truncated to the result type. Both of these steps are currently impossible to do since neither the operand types nor the result type is known to the expression evaluator.
Here is an example:
8'shffhas bit pattern11111111and value -18'haahas bit pattern10101010and value 170- The operation
8'shff ^ 8'haashould result in a signed 8-bit number with bit pattern01010101and value 85 - However, the expression will instead evaluate to -171, which has the same bit pattern, but with infinite leading ones
- The evaluator has no way of knowing that all of the leading digits have to be discarded since they don't fit into the result type
It's clear to me that accurate constant expression evaluation is only possible if the necessary type information is available. The elaborator in its current form is essentially a fixed point solver that will repeatedly attempt to calculate the types and values of architectural state elements, until either all have been determined or the remaining ones cyclically depend on each other. I'll need to rewrite parts of it in order to track expression type information.