Minres / CoreDSL

Xtext project to parse CoreDSL files
Apache License 2.0
14 stars 2 forks source link

Expression type information during elaboration #111

Open AtomCrafty opened 7 months ago

AtomCrafty commented 7 months ago

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:

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.

eyck commented 7 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?

AtomCrafty commented 6 months ago

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.