<html xmlns:v="urn:schemas-microsoft-com:vml" 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;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","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
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:269433419;
        mso-list-type:hybrid;
        mso-list-template-ids:-1389868582 201916433 201916441 201916443 201916431 201916441 201916443 201916431 201916441 201916443;}
@list l0:level1
        {mso-level-text:"%1\)";
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
ol
        {margin-bottom:0cm;}
ul
        {margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>A few years ago I was included in a private email discussion. I take the liberty of reproducing part of it here as I believe the concepts are crucial to this discussion. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>The following statement had been made:  <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>“I like this new version of Oberon's type rules. They are simpler to understand and if the audience <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>wants more details, he can always read the source code of ORP.Mod.”<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>Wirth’s response was as follows (verbatim apart from a couple of spelling typos that I corrected):<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>------------------------------------------------------------------------<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>NO, NO!<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>He should look only at the Oberon-Report. This is the definitive document. But never the compiler! Oberon-Users do not have access to the compiler source.<br><br>The very idea of a high-level language was that it must not be defined with reference to a computer (or compiler), but be clearly defined as an abstract machine, the language report. I am afraid that this notion got lost over the past decades, where in case of doubt one does not analyze the situation, but simply, due to interactive usage, try and try again.  Also, the  "open source" is a terrible promoter of deserting this most useful idea. Another consequence is that "everyone" creates his own compiler (language?) version, compromising the very idea of a common language serving communication.<br><br>Please do not consider my compiler as the definition of Oberon, and in case of doubt read the Report. It is the privilege of a report to leave certain constructs undefined. In this case a user should simply avoid using the (undefined) feature.</span><span style='font-size:13.5pt'><br></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>------------------------------------------------------------------------<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>Chris Burrows<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>CFB Software<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'><a href="https://www.astrobe.com">https://www.astrobe.com</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> Jörg [mailto:joerg.straube@iaeth.ch] <br><b>Sent:</b> Sunday, 26 April 2020 9:42 PM<br><b>To:</b> chris@cfbsoftware.com; ETH Oberon and related systems<br><b>Subject:</b> Re: [Oberon] Negative integer literals in Oberon<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Agreed<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The report is not always 100% clear. If this happens, I try to find other sources to get the intention of the construct. My preferred sources are other NW publications, like his compiler source and his RISC architecture.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Looking at these facts<o:p></o:p></p></div><div><div><p class=MsoNormal>a) NW introduced byte addressing mode in RISC-3<o:p></o:p></p></div><div><p class=MsoNormal>b) BYTE are the integers between 0 and 255<o:p></o:p></p></div><div><p class=MsoNormal>c) The type BYTE is compatible with the type INTEGER, and vice-versa.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Led to the (perhaps wrong) conclusion that assignments to BYTE are mapped to the byte addressing mode of the processor. The byte addressing mode works MOD 256 by definition.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>There are basically two cases you have to consider<o:p></o:p></p></div><div><p class=MsoNormal>Firstly: b := expression; (* store*)<o:p></o:p></p></div><div><p class=MsoNormal>The expression on the righthand side can be any integer value. c) tells us that I can store any value into b. And b) tells us that the as a result of this assignment to byte b, b is between 0..255. The compiler source tells us, that the intention of this assigment case was, to just map the assignment to the „store byte“ instruction, that works MOD 256 by definition<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Secondly: i := f(b) (* load *)<o:p></o:p></p></div><div><p class=MsoNormal>Whenever we use a byte value on the righthand side as part of an expression, b) tells us that the value to be taken shall be interpreted as 0..255. And c) tells us that a byte value is allowed to be assigned to an integer variable.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>br Jörg<o:p></o:p></p></div><div><p class=MsoNormal><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-bottom:12.0pt'>Am 26.04.2020 um 12:53 schrieb Chris Burrows <<a href="mailto:chris@cfbsoftware.com">chris@cfbsoftware.com</a>>:<o:p></o:p></p></blockquote></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal><span style='font-family:"Tahoma","sans-serif"'></span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'> </span><o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> Joerg [<a href="mailto:joerg.straube@iaeth.ch">mailto:joerg.straube@iaeth.ch</a>] <br><b>Sent:</b> Sunday, 26 April 2020 5:55 PM<br><b>To:</b> ETH Oberon and related systems<br><b>Cc:</b> <a href="mailto:chris@cfbsoftware.com">chris@cfbsoftware.com</a><br><b>Subject:</b> Re: [Oberon] Negative integer literals in Oberon</span><o:p></o:p></p></div></div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Chris<o:p></o:p></p><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>1)<span style='font:7.0pt "Times New Roman"'>    </span></span><![endif]>b := i;  is allowed, right?<o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>Yes – but the value of i must be in the range 0..255 for the result to be predictable.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoListParagraph style='text-indent:-18.0pt;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>2)<span style='font:7.0pt "Times New Roman"'>    </span></span><![endif]>b := i; does not generate a range check, right?<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>Not necessarily. An implementer is not required to generate a range check, but equally they are not prohibited from generating a range check either.</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p></div><div><p class=MsoNormal>3) i := 511; b := i; <o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>If 3) doesn’t generate a range check, but you want to be compliant to the report, you implement the assignment as b := i MOD 256;<o:p></o:p></p></div><div><p class=MsoNormal>as any value MOD 256 is between 0..255.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>The behaviour is not specified in the report so there is no question of compliance or non-compliance. Hence, the resulting value of b is undefined / unpredictable. Any programmer who assumes a particular result in that case is making a mistake. However, the implementer of the compiler is not required by the report to alert him to that mistake - but he can do if he wants to. </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>If the programmer is competent there is no problem because he can write his code in such a way that he gets the answer that he want. If he expects values of i to be outside the range 0..255 and he wants b to be equal to i MOD 256 then he should explicitly code it as:</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>b := i MOD 256</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>then there is no doubt about what the result will be no matter what the compiler implementer has decided to do..</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal>br<o:p></o:p></p></div><div><div><div><p class=MsoNormal>Jörg<o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-bottom:12.0pt'> <o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-bottom:12.0pt'>Am 26.04.2020 um 09:28 schrieb <a href="mailto:dave@brownsmeet.com">dave@brownsmeet.com</a>:<o:p></o:p></p></blockquote></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal><span style='font-family:"Tahoma","sans-serif"'></span> <o:p></o:p></p><p>((Lapsed) VOC maintainer here.)<o:p></o:p></p><p>In both VOC and Oberon 2013, integer literals are parsed in the symbol parser (VOC :OPS.Mod or 2013:ORS.MOD) and stored in the symbol table as signed integer values.<o:p></o:p></p><p>Later, during expression compilation, their size is determined by the magnitude of their signed integer value.<o:p></o:p></p><p>The difference between Oberon 2013 and VOC is the largest integer type, which is 32 bit on Oberon 2013 and 64 bit in VOC.<o:p></o:p></p><p>The special handling that allows a hex literal with top bit set to be treated as a signed value happens at the time the literal is parsed as a symbol independent of what context it is being used in. (Consider e.g. 'CONST mask = 90909090H' - CONST parsing does not know whether this constant will be used in a 64 bit, 32 bit, 16bit or other context.)<o:p></o:p></p><p>VOC and Oberon 2013 do both allow the hex special case top bit set parsing behaviour, the difference being the integer literal size.<o:p></o:p></p><p>Thus VOC accepts myint64 := 9090909090909090H because 9090909090909090H is parsed as a negative 64 bit signed integer.<o:p></o:p></p><p>But VOC does not accept myint32 := 90909090H because 90909090H is parsed as a positive 64 bit signed integer. <o:p></o:p></p><p>VOC has no way to parse 90909090H as a negative 32 bit signed integer.<o:p></o:p></p><p> - I did wonder about adding a further suffix letter to indicate the intended size, but I couldn't satisfy myself that any solution was simple enough to be easy to understand.<o:p></o:p></p><p> - Note that this is independent of VOC's -Ox compatibility setting: that sets the default INTEGER size, not integer literal size - integer literals always support the largest available integer size which is SYSTEM.INT64 aka HUGEINT.)<o:p></o:p></p><p>-- Dave<o:p></o:p></p><p> <o:p></o:p></p><p>On 2020-04-25 22:52, Chris Burrows 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-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>It all depends on what size (i.e. number of bits) INTEGER is defined as on the system you are using as to what range of numbers are valid INTEGERs. Since 2011, the range of INTEGER values is no longer defined in the Language Report; it is implementation-dependent. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>In the Project Oberon (2013) RISC5 compiler, INTEGER is 32 bit so 90909090H is a valid INTEGER. Maybe you used the default (-O2) option in VOC? If so, INTEGER is 16 bit so 90909090H would be too large. Make sure you are compiling with the VOC –OC option instead if you want INTEGER to be treated as a 32 bit quantity.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>Note that 9090H would be a negative number on a 16-bit INTEGER system but a positive number on a 32-bit INTEGER system.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>Regards,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>Chris Burrows</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'>CFB Software</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'><a href="https://www.astrobe.com">https://www.astrobe.com</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;mso-fareast-language:EN-US'> </span><o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><strong><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>From:</span></strong><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> Oberon [<a href="mailto:oberon-bounces@lists.inf.ethz.ch">mailto:oberon-bounces@lists.inf.ethz.ch</a>] <strong><span style='font-family:"Calibri","sans-serif"'>On Behalf Of </span></strong>Arthur Yefimov<br><strong><span style='font-family:"Calibri","sans-serif"'>Sent:</span></strong> Sunday, 26 April 2020 12:38 AM<br><strong><span style='font-family:"Calibri","sans-serif"'>To:</span></strong> <a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a><br><strong><span style='font-family:"Calibri","sans-serif"'>Subject:</span></strong> [Oberon] Negative integer literals in Oberon</span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>While developing the compiler[1], we got a question<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>whether it is possible to write the following:<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>PROCEDURE DWord(n: INTEGER);<br>...<br>DWord (90909090H)<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br>(where INTEGER is 32-bit).<br><br>Some compilers give an error (i.e. VOC), while this works in the<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Project Oberon (2013) compiler. This would turn out to be quite convenient,<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>because the purpose of DWord in our code was to write 4 bytes to the file<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>given as INTEGER (using little-endian byte order).<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>DWord has the following implementation (module Generator[2]):<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br>PROCEDURE DWord (n: INTEGER);<br>BEGIN<br>  Files.Write (r, CHR (n MOD 100H));<br>  Files.Write (r, CHR (n DIV 100H MOD 100H));<br>  Files.Write (r, CHR (n DIV 10000H MOD 100H));<br>  Files.Write (r, CHR (n DIV 1000000H))<br>END DWord;<br><br>The Oberon language report does not indicate that literal 90909090H<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>should be considered an error if INTEGER has 32 bits.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br>In this experiment, an online RISC emulator[3] was used.<o:p></o:p></p></div></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>References:<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[1] <a href="https://github.com/kekcleader/oberon" target="_blank">https://github.com/kekcleader/oberon</a><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[2] <a href="https://github.com/kekcleader/oberon/blob/master/Mod/Generator.Mod" target="_blank">https://github.com/kekcleader/oberon/blob/master/Mod/Generator.Mod</a><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[3] <a href="http://schierlm.github.io/OberonEmulator/emu-wasm.html?image=FullDiskImage&width=1024&height=768" target="_blank">http://schierlm.github.io/OberonEmulator/emu-wasm.html?image=FullDiskImage&width=1024&height=768</a><o:p></o:p></p></div></div></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></span><o:p></o:p></p></div></blockquote><p class=MsoNormal>--<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">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><o:p></o:p></p></div></blockquote></div></div><p class=MsoNormal>--<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">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><o:p></o:p></p></div></blockquote></div></div></div></div></body></html>