<div dir="ltr">in other words you are saying that that integer constant then takes on a specific property, which is "cardinal".<div>Or to say it another way "it has a specific aspect".</div><div>In the same way Guy's C interface declarations have a specific aspect not found in regular procedure declarations.</div><div>And by the way on thinking about that issue : he might be right and I might have been wrong, </div><div>but that is a discussion for another day.</div><div>There is another place where one needs to assign a specific aspect: in the case of immutable addresses </div><div>of hardware, so the optimizer does not optimize them into oblivion.</div><div>Then there is a passed variable from the hw-interface layer, out of our control, that should be read only because </div><div>the hardware changes it all the time.</div><div><br></div><div>All this then makes me think that we should be able to clearly assign an abnormal aspect to certain entities </div><div>as is done in Ada.</div><div>CONST jim = 9999 WITH CARDINAL;</div><div><br></div><div>PROCEDURE Jerry (....) WITH "C";</div><div><br></div><div>VAR Jock : INTEGER WITH READONLY;</div><div><br></div><div>In this way It is clear that it does not belong to the regular language and you could compile with it or without it.</div><div><br></div><div>In any case this whole discussion points to a much deeper cultural problem in the Oberon community. </div><div>Let me do some more thinking about that before I shoot off my mouth. But for sure the present situation is </div><div>very debilitating.</div><div><br></div><div>j.</div><div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 2, 2020 at 2:27 PM Joerg <<a href="mailto:joerg.straube@iaeth.ch">joerg.straube@iaeth.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Jan<div><br></div><div>I first thought so as well. But re-introducing CARDINALs is not one of my favorites (and Chris‘ neither😊)</div><div><br></div><div>The question arises: where do we need those „CARDINALs“? In my point only in low level programming, HW drivers and cryptography.</div><div>Oberon declares quite some SYSTEM functions with INTEGER as parameters. Looking at the carefully, the semantic is not really INTEGERs in the pure sense. These low level functions know they are handling low level things and can interprete internally INTEGERs as CARDINALs. Eg the famous SYSTEM.GET(-64) knows that the INTEGER address -64 has to be taken at the top end of memory.</div><div><br></div><div>So, from the point on where you have a value in your register/variable, you can well live with INTEGER as type for it. Let‘s look at the problem how to get a value into a register. Setting a variable is the result of an arithmetic expression, a type conversion or a literal.</div><div>So the only point where you really need the „CARDINAL“ behaviour, is when stating constant literals in your code.</div><div><br></div><div>So instead of defining a whole new type (with all pros and cons) don’t you think the clarification of the value cast operator H is enough?</div><div><br><div dir="ltr"><div>Jörg</div></div><div dir="ltr"><br><blockquote type="cite">Am 02.05.2020 um 11:32 schrieb Jan de Kruyf <<a href="mailto:jan.de.kruyf@gmail.com" target="_blank">jan.de.kruyf@gmail.com</a>>:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto">So the thought experiment whether we can live without unsigned integers must be answered with a resounding "No".<div dir="auto"><br></div><div dir="auto">q. e. d. </div><div dir="auto"><br></div><div dir="auto">J. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 2 May 2020, 08:23 Jörg, <<a href="mailto:joerg.straube@iaeth.ch" target="_blank">joerg.straube@iaeth.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="DE-CH"><div><p><span lang="EN-US">I think the root cause of this discussion is that the Oberon language does not clearly define the semantic of the H suffix.<u></u><u></u></span></p><p><span lang="EN-US">Let me try to explain what I mean. In my point of view we have to differentiate two conceptionally different layers. Let me call it<u></u><u></u></span></p><ul style="margin-top:0cm" type="disc"><li style="color:red"><span lang="EN-US">the red Oberon layer, as defined by the Oberon report.<u></u><u></u></span></li><li><span lang="EN-US" style="color:rgb(0,112,192)">the blue implementation layer, as defined by the target CPU and the Oberon compiler.</span><span lang="EN-US"><u></u><u></u></span></li></ul><p><span lang="EN-US"><u></u> <u></u></span></p><p><span lang="EN-US">In the red Oberon layer you might write<u></u><u></u></span></p><p><span lang="EN-US" style="color:red">CONST<u></u><u></u></span></p><p style="text-indent:18pt"><span lang="EN-US" style="color:red">Int = -1869574000;<u></u><u></u></span></p><p style="text-indent:18pt"><span lang="EN-US" style="color:red">Real = -5.702072E-29;<u></u><u></u></span></p><p><span lang="EN-US">Let’s assume the compiler has a 32bit CPU as target. The CPU represents INTEGERs as two’s complement (that’s quite common but not a given) then the red Oberon value <span style="color:red">-1869574000 </span>is represented by the blue 32bit pattern <span style="color:rgb(0,112,192)">90909090</span>.<u></u><u></u></span></p><p><span lang="EN-US">If the floating point unit chooses to represent REALs as IEEE754 (that’s quite common but not a given) the red Oberon value <span style="color:red">-5.702072E-29 </span>is represented by the blue 32 bit pattern <span style="color:rgb(0,112,192)">90909090.<u></u><u></u></span></span></p><p><span lang="EN-US"><u></u> <u></u></span></p><p><span lang="EN-US">With these two layers in mind, the <b>H</b> suffix can have two totally different semantics<u></u><u></u></span></p><ol style="margin-top:0cm" start="1" type="a"><li><span lang="EN-US">is H purely working in the red Oberon layer and just be another notation to define an INTEGER?<br>Then, the decimal notation <span style="color:red">2425393296</span> and hex notation <span style="color:red">90909090H</span> are absolutely identical.<u></u><u></u></span></li><li><span lang="EN-US">Or does H do a type cast of the blue 32bit pattern <span style="color:rgb(0,112,192)">90909090</span> into a red INTEGER value <span style="color:red">-1869574000</span>?<u></u><u></u></span></li></ol><p><span lang="EN-US"><u></u> <u></u></span></p><p><span lang="EN-US">Looking at the Oberon-07 report the semantic of H looks more like a).<u></u><u></u></span></p><p><span lang="EN-US">NW’s Oberon-07 compiler behaves like b). Another hint that NW most probably had semantic b) in mind is the fact that a suffix R exists. 90909090R type casts the 32 bit pattern 90909090 into a REAL.<u></u><u></u></span></p><p><span lang="EN-US">The semantic of H should be better described in the Oberon report.<u></u><u></u></span></p><p><span lang="EN-US"><u></u> <u></u></span></p><p>br<u></u><u></u></p><p>Jörg<u></u><u></u></p><p><u></u> <u></u></p><p><span lang="DE">Am 01.05.20, 20:00 schrieb "Jörg" <<a href="mailto:joerg.straube@iaeth.ch" rel="noreferrer" target="_blank">joerg.straube@iaeth.ch</a>>:<u></u><u></u></span></p><p><span lang="DE"><u></u> <u></u></span></p><p><span lang="DE">    SHORT(90909090H) should generate an error, as 2.4 billion is big for a 32 bit integer.<u></u><u></u></span></p><p><span lang="DE">    Jörg<u></u><u></u></span></p><p><span lang="DE">    <u></u><u></u></span></p><p><span lang="DE">    > Am 01.05.2020 um 18:46 schrieb <a href="mailto:dave@brownsmeet.com" rel="noreferrer" target="_blank">dave@brownsmeet.com</a>:<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > Hi Oleg,<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > Re 1 - Personally I really dislike '90909090H - 100000000H' because it is more confusing to read than the alternatives.<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > Instead of SYSTEM.VAL(INTEGER, 90909090H) you may prefer SHORT(90909090H). It's a bit more concise, avoids the dependency on SYSTEM, and works whatever the 32 bit integer type is called (i.e. INTEGER or LONGINT).<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > (If you are adding support for LONGINT then you will almost certainly be adding support for SHORT() and LONG()).<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > ---<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > Re 2 - Yes, this fixes 32 bit hex literals. But it doesn't fix 16 or 8 bit hex literals. I think these should be considered too. It's also difficult to explain the use of the H vs L suffix - the description in the component pascal documentation is correct but very confusing.<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > ---<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > Re 3 - Yes, in this case (assuming you have added support for 64 bit integers) all arithmetic is 64 bit, and assignments to smaller int variables are simply clipped at the time they are stored. You don't need SHORT() or LONG().<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > If you do this I'd like to see a compilation option to do range checking at run time on every store to < 64 bits.<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > ---<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > Re 4 - Oberon already has casting under another name (type guard) for extended types - with the type name in  brackets following the variable name. Maybe keep the syntax similar.<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > -- Dave.<u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    > <u></u><u></u></span></p><p><span lang="DE">    >> On 2020-05-01 11:26, Oleg N. Cher wrote:<u></u><u></u></span></p><p><span lang="DE">    >> Dear Dave,<u></u><u></u></span></p><p><span lang="DE">    >> After all, the question: is the literal 90909090H considered 64-bit<u></u><u></u></span></p><p><span lang="DE">    >> unsigned or 32-bit signed? We have four solutions:<u></u><u></u></span></p><p><span lang="DE">    >> 1. Consider it as a 64-bit literal, by context. And if we need to<u></u><u></u></span></p><p><span lang="DE">    >> declare it as a 32-bit literal, we'll write it like this:<u></u><u></u></span></p><p><span lang="DE">    >>  myint := 90909090H - 100000000H;<u></u><u></u></span></p><p><span lang="DE">    >> If we don't like writing code this way, we'll write it differently:<u></u><u></u></span></p><p><span lang="DE">    >>  myint := SYSTEM.VAL(INTEGER, 90909090H);<u></u><u></u></span></p><p><span lang="DE">    >> , quite in the spirit of the Oberon paradigm. So, Artur, this is what<u></u><u></u></span></p><p><span lang="DE">    >> I suggest you do in your compiler.<u></u><u></u></span></p><p><span lang="DE">    >> 2. Consider it as a 32-bit literal. And for 64-bit use the postfix<u></u><u></u></span></p><p><span lang="DE">    >> modifier like 0FFFFFFFFL, as in Component Pascal. Ofront+ also<u></u><u></u></span></p><p><span lang="DE">    >> implements this option (in -C mode).<u></u><u></u></span></p><p><span lang="DE">    >> 3. Pretend that we have all integer literals of the same size. In this<u></u><u></u></span></p><p><span lang="DE">    >> case, all the hexadecimal digits allowed as a bitfield value of the<u></u><u></u></span></p><p><span lang="DE">    >> literal. This way is implemented in most Oberon-07 compilers, which is<u></u><u></u></span></p><p><span lang="DE">    >> justified by the lack of integer arithmetic of different bits in them.<u></u><u></u></span></p><p><span lang="DE">    >> (BYTE is a non-arithmeric type in Oberon-07, and its size does not<u></u><u></u></span></p><p><span lang="DE">    >> used in operations, always casted to INTEGER).<u></u><u></u></span></p><p><span lang="DE">    >> 4. Explicitly specifying the constant type, as there was in Turbo Pascal:<u></u><u></u></span></p><p><span lang="DE">    >> CONST MyConst = INTEGER(90909090H);<u></u><u></u></span></p><p><span lang="DE">    >> As in Active Oberon, Delphi and Turbo Pascal. But then it is necessary<u></u><u></u></span></p><p><span lang="DE">    >> to allow the same (note, non-system) casting in expressions - and<u></u><u></u></span></p><p><span lang="DE">    >> rushed.<u></u><u></u></span></p><p><span lang="DE">    >> I would suggest two ways. The non-system way:<u></u><u></u></span></p><p><span lang="DE">    >>  CONST MyConst = 90909090H - 100000000H;<u></u><u></u></span></p><p><span lang="DE">    >> This will be our payment for the fact that there are no unsigned types<u></u><u></u></span></p><p><span lang="DE">    >> in Oberon. This is a simplification that I think is very useful, but<u></u><u></u></span></p><p><span lang="DE">    >> has a cost. So now we have all integer constants as signed numbers.<u></u><u></u></span></p><p><span lang="DE">    >> And the system way. Ofront+ supports:<u></u><u></u></span></p><p><span lang="DE">    >>  myint := SYSTEM.VAL(INTEGER, 90909090H);<u></u><u></u></span></p><p><span lang="DE">    >> And in constants too:<u></u><u></u></span></p><p><span lang="DE">    >>  CONST MyConst = SYSTEM.VAL(INTEGER, 90909090H);<u></u><u></u></span></p><p><span lang="DE">    >> The disadvantage here is the compatibility problem, because old<u></u><u></u></span></p><p><span lang="DE">    >> sources may contain literals that rely on the size of 32 bits. But<u></u><u></u></span></p><p><span lang="DE">    >> this is mitigated by the fact that Ofront+ supports 5 Oberon dialects,<u></u><u></u></span></p><p><span lang="DE">    >> and we can choose any of it at our discretion.<u></u><u></u></span></p><p><span lang="DE">    > --<u></u><u></u></span></p><p><span lang="DE">    > <a href="mailto:Oberon@lists.inf.ethz.ch" rel="noreferrer" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<u></u><u></u></span></p><p><span lang="DE">    > <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><u></u><u></u></span></p><p><span lang="DE">    <u></u><u></u></span></p></div></div>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" rel="noreferrer" target="_blank">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" rel="noreferrer noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div>
<span>--</span><br><span><a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems</span><br><span><a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a></span><br></div></blockquote></div></div>--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">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" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div>