[Oberon] Negative integer literals in Oberon

[Jan de Kruyf]

>So to put the cat amongst the pigeons again :-)...

Yes very well said.😇 And all the birds are long ago in the highest tree
they could find.
And the cat sits licking itself in the sun: "It didn't happen anyway!"

So do I understand then that, to solve the multiple type size issue (which
is basically a hardware issue)
you propose sub-ranges (which are an aid to software development)??

I would not like to teach that to a 14 year old, Dave. My oldest son did
very well with the Wirth and Reiser book
at the time. It taught him reading and clear thinking. But this would have
been a bridge too far
because the primary concepts are fudged


On Sat, May 2, 2020 at 6:06 PM <dave at brownsmeet.com> wrote:

> While I agree on Oberon 2007+, this is not sufficient for original
> Oberon2 systems with SHORTINTs and (signed) BYTES. It's not an issue on
> Oberon2007+ because of the freer integer type compatibility rules.
>
> e.g. myshort := 0FFFFH
>
> doesn't work on multi-size oberon2 compilers because 65535 is bigger
> than MAX(SHORTINT) which is 32767.
>
> And using MOD to restrict the size doesn't work on such compilers
> because the size of the result of an arithmetic operation such as MOD
> that has a INTEGER parameters is INTEGER. There is no special case
> handling for MOD: the compiler doesn't look at the right hand argument,
> see if it is a constant, and work out how many bits that constant would
> require.
>
> (It could, but I don't know of any that do, and it's not covered in the
> language report, or in system specific documents that I have seen.)
>
> The more we discuss this the more I'm convinced that the compiler needs
> to be more sophisticated: rather than hex constants being rapidly
> treated as signed integers, they need a distinct intermediate
> representation that can be taken through the expression evaluation
> handling to the point where we can make a valid decision on whether they
> are an acceptable size.
>
> But - this is quite a lot of special case code for compilers that
> support multiple sizes of integer.
>
> And actually it is the support of multiple sizes of integer that is the
> real can of worms here, hex literal issues are just one issue.
>
> So to put the cat amongst the pigeons again :-), I have seen no better
> solution to multiple integer sizes than Wirth and Knudsen's original
> Pascal 6000 compiler (circa 1975) and its support for integer subranges.
>
> The BYTE/SHORTINT/INTEGER/LONGINT approach is for me the worst solution,
> it has neither the simplicity of a single INTEGER size, nor does it
> avoid the complexities of subranges, while at the same time introducing
> more special cases and limitations.
>
> Hey ho -- Dave.
>
>
> On 2020-05-02 16:12, Joerg wrote:
> > Dave
> >
> > For smaller values than the size of your CPU register it‘s not needed,
> > as you always can enfoce what you want by using normal INTEGER
> > arithmetic.
> >
> > b := FFH;
> > word16 := 0CAFEH;
> >
> > or to be absolutely sure (although not needed)
> >
> > b := FFH MOD 100H;
> > word16 := 0CAFEH MOD 10000H;
> >
> > All those literals are legal INTEGERs on a 32 CPU.
> >
> > But you can‘t use the same for values completely filling yor register
> > that are no valid INTEGERs anymore.
> >
> > i := 0CAFEBABEH;
> > is not going to work, as CAFEBABE needs more than 31 bit to be
> > represented as positive INTEGER.
> >
> > br
> > Jörg
> --
> 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/ce89e78b/attachment.html>