Unbalanced assignment compiler error: a subtle bit width inference with type resizing issue

[robstewart57]

I'm coming across a subtle bit width inference issue when compiling with Xronos, which I can solve by using a slightly less elegant var declaration. I may be encouraging an Orcc size inference pass, or I may be encouraging a Xronos inference pass, I suspect maybe the former.

Here's an example:

actor myActor () int (size = 16) In1, int (size = 16) In2 ==> int (size = 16) Out1 :
 myAction : action In1 : [x], In2 : [y]==> Out1 : [(x * 5) / y] end
end

The compilation error I get is:

failed to compile: UnbalancedAssignmentException, continuous assignment has mismatched bit sizes: divide(16)!=add/{add_u3984[16],add_u3984[16],add_u3984}(19)

My guess is the the expression (x * 5) has somewhere being upcast to something higher than a 16bit int, and Xronos doesn't know what to do with:

<16bit int> := <32bit int> / <16bit int>

I can solve this pulling out the output expression into a var declaration, letting me give the entire expression (x *5) / y an explicit bit width type, i.e.

actor myActor () int (size = 16) In1, int (size = 16) In2 ==> int (size = 16) Out1 :
 myAction : action In1 : [x], In2 : [y]==> Out1 : [z]
 var int(size=16) z = (x * 5) / y
 do
 end
end

And the compilation problem goes away. Because I'm generating this CAL code, and would like it written in the first way such that pattern matching on actions with no var declarations is simplified, it'd be great if I could express this action in the first way, and for type resizing to judge that the expression (x * 5) / y is 16 bit.

Do you consider this a bug in the type resizer Orcc transformation, or a Xronos bug, a feature, and/or something that could be rectified?

Thanks!

[endrix]

The division operation in Xronos is very limited, as I remember well I can support only 16 bit division. I need to dig to the code to see why the casting on the dividend is not applied.