<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.E-MailFormatvorlage19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body lang=DE-CH link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'>Dave<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'>To forbid this “undesired” case, the Oberon-07 compiler parses hex literals and decimal literals differently.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'>For decimal literals the allowed range is 0 .. 2.1 billion.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'>For hexadecimal literals the allowed range is 0 to 4.2 billion. The compiler internally maps the range of 2.1 .. 4.2 to -2.1 .. 0 <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'>br<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'>Jörg<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span style='font-size:12.0pt;color:black'>Von: </span></b><span style='font-size:12.0pt;color:black'>Oberon <oberon-bounces@lists.inf.ethz.ch> im Auftrag von <dave@brownsmeet.com><br><b>Antworten an: </b>ETH Oberon and related systems <oberon@lists.inf.ethz.ch><br><b>Datum: </b>Dienstag, 28. April 2020 um 11:09<br><b>An: </b>ETH Oberon and related systems <oberon@lists.inf.ethz.ch><br><b>Cc: </b>Arthur Yefimov <artur.efimov@gmail.com><br><b>Betreff: </b>Re: [Oberon] Negative integer literals in Oberon (dave@brownsmeet.com)<o:p></o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p>Yes, that would allow 90909090H as desired.<o:p></o:p></p><p>However it will also allow e.g. calling DWORD(4294000000), which will actually behave as DWORD(-967296), not desirable.<o:p></o:p></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. <o:p></o:p></p><p>But it's not just about fixing the code location you show.<o:p></o:p></p><p>You would also want to support  <o:p></o:p></p><p>   myint32 := 90909090H<o:p></o:p></p><p>and indeed<o:p></o:p></p><p>  myint32 := 90000000H + 900000H + 9000H + 90H<o:p></o:p></p><p>(where some of those may be CONSTs)<o:p></o:p></p><p>And this means passing the flag on through the constant evaluation. It makes for a large and ugly change.<o:p></o:p></p><p>---<o:p></o: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.<o:p></o:p></p><p>-- Dave.<o:p></o:p></p><p>On 2020-04-28 00:51, Arthur Yefimov wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #1010FF 1.5pt;padding:0cm 0cm 0cm 5.0pt;margin-left:0cm;margin-right:0cm'><div><p class=MsoNormal>> 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. <o:p></o:p></p><div><div><p class=MsoNormal><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.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>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).<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>The value 90909090H is a constant, so<o:p></o:p></p></div><div><p class=MsoNormal>it's (x.mode = Const) & (x.type.form = Int64).<o:p></o:p></p></div><div><p class=MsoNormal>And the corresponding formal parameter is<o:p></o:p></p></div><div><p class=MsoNormal>(par.class = Var) & (par.type.form = Int32).<o:p></o:p></p></div><div><p class=MsoNormal>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?<o:p></o:p></p></div></div><div><p class=MsoNormal>IF (x.mode = Const) & (par.type.form = Int32) &<o:p></o:p></p></div><div><p class=MsoNormal>    (x.type.form = Int64) & (x.val >= 0) &<o:p></o:p></p></div><div><p class=MsoNormal>    (x.val < 100000000H)<o:p></o:p></p></div><div><p class=MsoNormal>THEN x.type.form := Int32<o:p></o:p></p></div><div><p class=MsoNormal>END<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>Let me know if this makes sense.<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><span style='font-family:"Courier New"'>--<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">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><o:p></o:p></span></p></div></blockquote><p class=MsoNormal>-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon <o:p></o:p></p></div></body></html>