<div dir="ltr">> I think the answer to Arthur's original question depends on whether his<br>> goal is a single integer size compiler, or whether there is an intent to<br>> add support for e.g. Oberon 2's SHORTINT and LONGINT.<br><br>At first we are going to support a single INTEGER type only. Then we will need to think if we also need to add any support for SHORTINT, LONGINT etc. (and may be even SYSTEM.INT32 etc.) But still I think it would be convenient to be able to pass 90909090H to a procedure that accepts a 32-bit INTEGER even though it would end up being a negative number. Anyway, inside the procedure we are dividing it by 100H, 10000H etc. to get the individual bytes.<div><div><br>> The crux of the issue from my point of view is that supporting 90909090H<br>> as a 32 bit integer parameter is easy for a compiler like Oberon 2013<br>> that supports a single INTEGER size, and not easy, or not possible for a<br>> compiler that supports OBERON 2's multiple integer sizes.</div><div><br></div><div>I may be wrong, but as long as we are only implementing this for constants, I have an idea of an easy solution for an Ofront-like compiler. Below I'll use some kind of pseudocode (let's suppose Int32 and Int64 are integer constants, i. e. 3 and 4).</div><div><br></div><div>The value 90909090H is a constant, so</div><div>it's (x.mode = Const) & (x.type.form = Int64).</div><div>And the corresponding formal parameter is</div><div>(par.class = Var) & (par.type.form = Int32).</div><div>As our item (x) is a constant, we also know it's value at compile-time. Why not to add a cascade of IF-statements like so?</div></div><div>IF (x.mode = Const) & (par.type.form = Int32) &</div><div>    (x.type.form = Int64) & (x.val >= 0) &</div><div>    (x.val < 100000000H)</div><div>THEN x.type.form := Int32</div><div>END</div><div><br></div><div>Let me know if this makes sense.</div></div>