<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 12pt; font-family: Verdana,Geneva,sans-serif'>
<p>Yes, that would allow 90909090H as desired.</p>
<p>However it will also allow e.g. calling DWORD(4294000000), which will actually behave as DWORD(-967296), not desirable.</p>
<p>I believe fixing this means passing a flag through from the parser with the constant value to mark it as sourced from a hex literal. </p>
<p>But it's not just about fixing the code location you show.</p>
<p>You would also want to support </p>
<p> myint32 := 90909090H</p>
<p>and indeed</p>
<p> myint32 := 90000000H + 900000H + 9000H + 90H</p>
<p>(where some of those may be CONSTs)</p>
<p>And this means passing the flag on through the constant evaluation. It makes for a large and ugly change.</p>
<p>---</p>
<p>Re 'why would hex constants be desirable' - A very common modern usage is the ARGB representation of colour - HTML and CSS contains plenty of HEX colour representations, and industry sources such as Pantone specify web colours in hex.</p>
<p>-- Dave.</p>
<p>On 2020-04-28 00:51, Arthur Yefimov wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<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> </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> </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> </div>
<div>Let me know if this makes sense.</div>
</div>
<br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">--<br /> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br /> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" target="_blank" rel="noopener noreferrer">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a></div>
</blockquote>
</body></html>