Oberon 07: LONGREAL conversion

[frrrstfn]

Reading Oberon 07 report I see there are no function to convert from
LONGREAL to INTEGER and viceversa,
althougth they exist for REAL type (FLT, FLOOR).

May be because ARM compiler does not implement LONGREAL type?

[Chris Burrows]

Post by frrrstfn
Reading Oberon 07 report I see there are no function to convert from
LONGREAL to INTEGER and viceversa,
althougth they exist for REAL type (FLT, FLOOR).

There is also no REAL / LONGREAL type inclusion and EXP and PACK cannot be
used with LONGREALs either. Assuming that this is not just a simple
oversight, my interpretation of the Oberon-07 report is that specific
LONGREAL support in the *language* is restricted to:

Constant declarations (using the 'D' suffix)
Numeric operations (+ - / *)

That implies to me that any other functionality would have to be implemented
as a library module e.g. FPU, or additional SYSTEM extensions perhaps. Such
a module would include functions analogous to those which appear in typical
string / number conversion modules e.g. FPU.RealToLongReal,
FPU.LongRealToInt etc. to do the conversions. Typically, if the target
platform uses a floating-point coprocessor, the module might expose other
functionality available on the coprocessor.

The implementor of a system with LONGREAL support would then be responsible
for defining its behaviour to answer all of the tricky questions that the
language report conveniently avoids (e.g. what happens if LongRealToInt
overflows, what resolution is used for intermediate results of LONGREAL
operations on an 80-bit FPU, etc. etc.). I suspect this is one of those
issues that is descibed in the report's introduction as:

"What remains unsaid is mostly left so intentionally, either because it is
derivable from stated rules of the language, or *because it would
unnecessarily restrict the freedom of implementors*". (My asterisks)

Regards,
Chris Burrows
CFB Software

Astrobe: ARM Oberon-07 Development System
http://www.astrobe.com

[frrrstfn]

"make it simple as possible, but not simpler": sometimes I feel Wirth
made Oberon 07 report simpler.

function ASR (x, n)

x is of type INTEGER, n is an expression but no type specified.

Assuming is INTEGER because ASR(x, n) = x * 2^-n, shift right. Can be
n negative? If yes should the shift be on the left (as was in Oberon
ASH)?

The same for LSL and LSR.

function INC

INC(x, n) is ok if n is integer constant expression

I know that in an other paper Wirth says n must be 0 <= n < 256, why
not reporting it again?. It's not valid anymore?


Another point. Tested Astrobe: seems all ok except you can declare
constant 'overflow' value ;

CONST huge = 800000000000H; (* it's ok ? *)

[B. Kowarsch]

Post by frrrstfn
"make it simple as possible, but not simpler": sometimes I feel Wirth
made Oberon 07 report simpler.

It depends from whose viewpoint you are looking at this.

Prof. Wirth designed every one of his languages for a specific
purpose. He designed them as simple as possible but not any simpler
*for the specific purpose* that he designed the respective language
for.

You are probably looking at this from the viewpoint of your own
desired purpose. In other words you are saying "I feel Wirth made
Oberon-07 simpler than necessary *for my purpose*".

This may well be true, but Wirth did not design the language for your
purpose, he designed it for his own purpose. Very likely, you will be
able to use the language as-is anyway, but there is no guarantee that
it will match your requirements.

[Chris Burrows]

Post by frrrstfn
"make it simple as possible, but not simpler": sometimes I feel Wirth
made Oberon 07 report simpler.

Be careful what you wish for or unless you want an Oberon-07 report that
looks like the ISO Modula-2 Standard :(

Post by frrrstfn
function ASR (x, n)
x is of type INTEGER, n is an expression but no type specified.

I believe you can safely assume it is INTEGER. I can imagine no other
sensible interpretation.

Post by frrrstfn
Assuming is INTEGER because ASR(x, n) = x * 2^-n, shift right. Can be
n negative?

No.

Post by frrrstfn
If yes should the shift be on the left (as was in Oberon
ASH)?

N/A.

Post by frrrstfn
The same for LSL and LSR.

The same. No and N/A.

You could use other values but you should restrict yourself to using 1 <= n
<= 31 if you want to be guaranteed to get a result that you would expect.

Post by frrrstfn
INC(x, n) is ok if n is integer constant expression
I know that in an other paper Wirth says n must be 0 <= n < 256, why
not reporting it again?. It's not valid anymore?

The Oberon-07 *language* does not impose any restriction on the value of n.
The ARM *implementation* of Oberon-07 restricts the values to 0 <= n < 256.

Post by frrrstfn
Another point. Tested Astrobe: seems all ok except you can declare
constant 'overflow' value ;
CONST huge = 800000000000H; (* it's ok ? *)

Thank you for pointing that out. I'll update the documentation for the next
release to warn that no overflow checks are carried out on constant values.

[frrrstfn]

Post by Chris Burrows

Post by frrrstfn
"make it simple as possible, but not simpler": sometimes I feel Wirth
made Oberon 07 report simpler.

Be careful what you wish for or unless you want an Oberon-07 report that
looks like the ISO Modula-2 Standard :(

Post by frrrstfn
function ASR (x, n)
x is of type INTEGER, n is an expression but no type specified.

I believe you can safely assume it is INTEGER. I can imagine no other
sensible interpretation.

Post by frrrstfn
Assuming is INTEGER because ASR(x, n) = x * 2^-n, shift right. Can be
n negative?

No.

Post by frrrstfn
If yes should the shift be on the left (as was in Oberon
ASH)?

N/A.

Post by frrrstfn
The same for LSL and LSR.

The same. No and N/A.
You could use other values but you should restrict yourself to using 1 <= n
<= 31 if you want to be guaranteed to get a result that you would expect.

Post by frrrstfn
INC(x, n) is ok if n is integer constant expression
I know that in an other paper Wirth says n must be 0 <= n < 256, why
not reporting it again?. It's not valid anymore?

The Oberon-07 *language* does not impose any restriction on the value of n.
The ARM *implementation* of Oberon-07 restricts the values to 0 <= n < 256.

Post by frrrstfn
Another point. Tested Astrobe: seems all ok except you can declare
constant 'overflow' value ;
CONST huge = 800000000000H; (* it's ok ? *)

Thank you for pointing that out. I'll update the documentation for the next
release to warn that no overflow checks are carried out on constant values.

Thank you for the clarifications

Beaware that in Astrobe

ASR(x, -2), LSR(x, -2) and LSL(x, -2) are legal

[Chris Burrows]

Post by frrrstfn
Beaware that in Astrobe
ASR(x, -2), LSR(x, -2) and LSL(x, -2) are legal

Yes - as I said: "You could use other values but you should restrict
yourself to using 1 <= n <= 31 if you want to be guaranteed to get a result
that you would expect."

Chris.

[frrrstfn]

Post by Chris Burrows

Post by frrrstfn
Beaware that in Astrobe
ASR(x, -2),  LSR(x, -2) and LSL(x, -2) are legal

Yes - as I said: "You could use other values but you should restrict
yourself to using 1 <= n <= 31 if you want to be guaranteed to get a result
that you would expect."
Chris.

Many thanks for your time & help

[Chris Burrows]

Post by frrrstfn
Many thanks for your time & help

No problem - I appreciate your thoughtful questions. Keep them coming.

I've learnt much (and had a few surprises) while trying to answer them as
well! The surprises have been mainly due to unfounded expectations based on
my experience with Modula-2 and J & W Pascal.

I would be interested to see what sort of questions a newcomer to Oberon
would have if they had not been exposed to ANY other programming language.

Cheers,
Chris.

[Chris Burrows]

Post by Chris Burrows

Post by frrrstfn
Another point. Tested Astrobe: seems all ok except you can declare
constant 'overflow' value ;
CONST huge = 800000000000H; (* it's ok ? *)

Thank you for pointing that out. I'll update the documentation for the
next release to warn that no overflow checks are carried out on constant
values.

Update: It turns out it was just as easy to modify the compiler to detect
this error as it would have been to update the documentation ;-) A new
release of Astrobe with this fix and a few others and support for an
additional 8 microcontroller types from the LPC2xxx family should be
available in a week or so.

Regards,
Chris Burrows
CFB Software
Astrobe: ARM Oberon-07 Development System
http://www.astrobe.com