[Oberon] Negative integer literals in Oberon
Jan de Kruyf
jan.de.kruyf at gmail.com
Sat May 2 11:31:24 CEST 2020
So the thought experiment whether we can live without unsigned integers
must be answered with a resounding "No".
q. e. d.
J.
On Sat, 2 May 2020, 08:23 Jörg, <joerg.straube at iaeth.ch> wrote:
> I think the root cause of this discussion is that the Oberon language does
> not clearly define the semantic of the H suffix.
>
> 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
>
> - the red Oberon layer, as defined by the Oberon report.
> - the blue implementation layer, as defined by the target CPU and the
> Oberon compiler.
>
>
>
> In the red Oberon layer you might write
>
> CONST
>
> Int = -1869574000;
>
> Real = -5.702072E-29;
>
> 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 -1869574000 is represented by the blue 32bit pattern
> 90909090.
>
> If the floating point unit chooses to represent REALs as IEEE754 (that’s
> quite common but not a given) the red Oberon value -5.702072E-29 is
> represented by the blue 32 bit pattern 90909090.
>
>
>
> With these two layers in mind, the *H* suffix can have two totally
> different semantics
>
> 1. is H purely working in the red Oberon layer and just be another
> notation to define an INTEGER?
> Then, the decimal notation 2425393296 and hex notation 90909090H are
> absolutely identical.
> 2. Or does H do a type cast of the blue 32bit pattern 90909090 into a
> red INTEGER value -1869574000?
>
>
>
> Looking at the Oberon-07 report the semantic of H looks more like a).
>
> 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.
>
> The semantic of H should be better described in the Oberon report.
>
>
>
> br
>
> Jörg
>
>
>
> Am 01.05.20, 20:00 schrieb "Jörg" <joerg.straube at iaeth.ch>:
>
>
>
> SHORT(90909090H) should generate an error, as 2.4 billion is big for a
> 32 bit integer.
>
> Jörg
>
>
>
> > Am 01.05.2020 um 18:46 schrieb dave at brownsmeet.com:
>
> >
>
> > Hi Oleg,
>
> >
>
> > Re 1 - Personally I really dislike '90909090H - 100000000H' because
> it is more confusing to read than the alternatives.
>
> >
>
> > 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).
>
> >
>
> > (If you are adding support for LONGINT then you will almost
> certainly be adding support for SHORT() and LONG()).
>
> >
>
> > ---
>
> >
>
> > 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.
>
> >
>
> > ---
>
> >
>
> > 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().
>
> >
>
> > 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.
>
> >
>
> > ---
>
> >
>
> > 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.
>
> >
>
> >
>
> > -- Dave.
>
> >
>
> >
>
> >> On 2020-05-01 11:26, Oleg N. Cher wrote:
>
> >> Dear Dave,
>
> >> After all, the question: is the literal 90909090H considered 64-bit
>
> >> unsigned or 32-bit signed? We have four solutions:
>
> >> 1. Consider it as a 64-bit literal, by context. And if we need to
>
> >> declare it as a 32-bit literal, we'll write it like this:
>
> >> myint := 90909090H - 100000000H;
>
> >> If we don't like writing code this way, we'll write it differently:
>
> >> myint := SYSTEM.VAL(INTEGER, 90909090H);
>
> >> , quite in the spirit of the Oberon paradigm. So, Artur, this is
> what
>
> >> I suggest you do in your compiler.
>
> >> 2. Consider it as a 32-bit literal. And for 64-bit use the postfix
>
> >> modifier like 0FFFFFFFFL, as in Component Pascal. Ofront+ also
>
> >> implements this option (in -C mode).
>
> >> 3. Pretend that we have all integer literals of the same size. In
> this
>
> >> case, all the hexadecimal digits allowed as a bitfield value of the
>
> >> literal. This way is implemented in most Oberon-07 compilers, which
> is
>
> >> justified by the lack of integer arithmetic of different bits in
> them.
>
> >> (BYTE is a non-arithmeric type in Oberon-07, and its size does not
>
> >> used in operations, always casted to INTEGER).
>
> >> 4. Explicitly specifying the constant type, as there was in Turbo
> Pascal:
>
> >> CONST MyConst = INTEGER(90909090H);
>
> >> As in Active Oberon, Delphi and Turbo Pascal. But then it is
> necessary
>
> >> to allow the same (note, non-system) casting in expressions - and
>
> >> rushed.
>
> >> I would suggest two ways. The non-system way:
>
> >> CONST MyConst = 90909090H - 100000000H;
>
> >> This will be our payment for the fact that there are no unsigned
> types
>
> >> in Oberon. This is a simplification that I think is very useful, but
>
> >> has a cost. So now we have all integer constants as signed numbers.
>
> >> And the system way. Ofront+ supports:
>
> >> myint := SYSTEM.VAL(INTEGER, 90909090H);
>
> >> And in constants too:
>
> >> CONST MyConst = SYSTEM.VAL(INTEGER, 90909090H);
>
> >> The disadvantage here is the compatibility problem, because old
>
> >> sources may contain literals that rely on the size of 32 bits. But
>
> >> this is mitigated by the fact that Ofront+ supports 5 Oberon
> dialects,
>
> >> and we can choose any of it at our discretion.
>
> > --
>
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems
>
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200502/3b0b2df9/attachment.html>
More information about the Oberon
mailing list