Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expression type information during elaboration #111

Open
AtomCrafty opened this issue Feb 10, 2024 · 2 comments
Open

Expression type information during elaboration #111

AtomCrafty opened this issue Feb 10, 2024 · 2 comments
Assignees

Comments

@AtomCrafty
Copy link
Contributor

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.

@AtomCrafty AtomCrafty self-assigned this Feb 10, 2024
@eyck
Copy link
Contributor

eyck commented Feb 11, 2024

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
Copy link
Contributor Author

AtomCrafty commented Feb 11, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants