Specify type rules for comparison operators

Minres / CoreDSL

Xtext project to parse CoreDSL files

Apache License 2.0

14 stars 2 forks source link

Specify type rules for comparison operators #13

Closed jopperm closed 2 years ago

jopperm commented 2 years ago

Is it ok to compare operands with different types? Is 3'd0 == 4'd0?

jopperm commented 2 years ago

@atomcrafty I'll ultimately write the (textual) specification for this, but as you are currently working on the type validator anyways, can you please make a suggestion for how to handle the comparison operators?

AtomCrafty commented 2 years ago

I would probably allow all comparisons of numeric types, they should always be well-defined. The back-end would then need to find the smallest type that can represent all values from both types.

For example signed<3> and unsigned<5> would combine to signed<6>.

jopperm commented 2 years ago

Makes sense!

Random thoughts for future reference:

We certainly don't want to complicate simple situations like if (rd != 0) to if (rd != (unsigned<5>) 0).
6'd42 would not be equal to 6'sd42, even if they represent the same bit pattern, as their common type is actually signed<7>, in which the values differ in their MSB. (Related: #14)

AtomCrafty commented 2 years ago

About the first point: The correct type for the literal 0 would be unsigned<0>, that way it would implicitly convert to signed<1>, and unsigned<1> (aka bool).

In general, a non-verilog integer literal without a size suffix should have the smallest type able to fit its value.

0 → unsigned<0>     -0 → unsigned<0>
1 → unsigned<1>     -1 → signed<1>
2 → unsigned<2>     -2 → signed<2>
3 → unsigned<2>     -3 → signed<3>
4 → unsigned<3>     -4 → signed<3>
5 → unsigned<3>     -5 → signed<4>
and so on

About the second point: 6'sd42 has to be the least legible way of writing -22 I've ever seen. I guess we only allow that because Verilog does?

jopperm commented 2 years ago

6'sd42 has to be the least legible way of writing -22 I've ever seen. I guess we only allow that because Verilog does?

Haha, yes, I don't expect humans to use this.

In general, a non-verilog integer literal without a size suffix should have the smallest type able to fit its value.

I think zero-width types would be weird and counterintuitive. For example, someValue :: 0 would then be a no-op.

For the others, I'm unsure if we should exploit the asymmetry of the two's complement format. My current plan was to have no negative literals at all, and instead define the unary minus operator with a type signature of unsigned<n> -> signed<n+1>. I guess we have to come up and consider a few more examples in which either choice would make a difference.

jopperm commented 2 years ago

Updated spec in https://github.com/Minres/CoreDSL/wiki/_compare/c043e5be6dabdad820378c083875695b07bb68d0.