You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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'shff has bit pattern 11111111 and value -1
8'haa has bit pattern 10101010 and value 170
The operation 8'shff ^ 8'haa should result in a signed 8-bit number with bit pattern 01010101 and 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.
The text was updated successfully, but these errors were encountered:
I do not understand the issue with your example. If I do a logical operation on 2 operands the result has the size of the larger of the 2 operands. Where do the infinite leading ones come from?
Values internally are stored as big integers, hence the first operand (-1) has infinite leading ones. If we had type information that wouldn't be an issue since we'd know to just use the last 8 digits.
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'shff
has bit pattern11111111
and value -18'haa
has bit pattern10101010
and value 1708'shff ^ 8'haa
should result in a signed 8-bit number with bit pattern01010101
and value 85It'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.
The text was updated successfully, but these errors were encountered: