Skip to content

Expression type information during elaboration #111

@AtomCrafty

Description

@AtomCrafty

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions