Open AtomCrafty opened 9 months ago
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.