Result type of BYTE expressions

[August Karlstrom]

As far as I understand, in Oberon-07 the types INTEGER and BYTE are
expression compatible. But is the result of an arithmetic operation with
at least one BYTE operand always INTEGER?

-- August

[August Karlstrom]

Post by August Karlstrom
As far as I understand, in Oberon-07 the types INTEGER and BYTE are
expression compatible. But is the result of an arithmetic operation with
at least one BYTE operand always INTEGER?

For instance, what is the output from this module?

MODULE M;

IMPORT Out;

VAR
a, b: BYTE;

BEGIN
a := 255;
b := 1;
Out.Int(a + b, 0);
Out.Ln
END M.

Does the calculation overflow or not?


-- August

[r***@gmail.com]

Hi,

Post by August Karlstrom
For instance, what is the output from this module?
Does the calculation overflow or not?

Why don't you try it? What compilers do you use?

Oxford Oberon 3.0.7 (Win32) "obc -07" says "256" here (Win7 64-bit).

[August Karlstrom]

Post by r***@gmail.com
Hi,

Post by August Karlstrom
For instance, what is the output from this module?
Does the calculation overflow or not?

Why don't you try it? What compilers do you use?
Oxford Oberon 3.0.7 (Win32) "obc -07" says "256" here (Win7 64-bit).

If two compilers differ, how do we know which one is correct and which
is not?


-- August

[d***@eml.cc]

Post by August Karlstrom
If two compilers differ, how do we know which one is correct and which
is not?

I don't think you can grasp something with all those undefined behaviours.


--
Diego Sardina

[c***@gmail.com]

Post by August Karlstrom

Post by August Karlstrom
As far as I understand, in Oberon-07 the types INTEGER and BYTE are
expression compatible. But is the result of an arithmetic operation with
at least one BYTE operand always INTEGER?

For instance, what is the output from this module?
MODULE M;
IMPORT Out;
VAR
a, b: BYTE;
BEGIN
a := 255;
b := 1;
Out.Int(a + b, 0);
Out.Ln
END M.
Does the calculation overflow or not?

If you have to ask the question then you should avoid writing code like this. It would be just as risky as writing:

FOR a := 1 TO 255 DO ...

The primary purpose of the BYTE type is to save on storage space or to transfer information to / from BYTE-oriented systems. Use INTEGERs for integer-sized calculations.

Regards,
Chris Burrows
CFB Software
http://www.astrobe.com

[Diego Sardina]

Risky? Type-safe languages were invented for this reason.


--
Diego Sardina

[c***@gmail.com]

Post by Diego Sardina
Risky? Type-safe languages were invented for this reason.

The issue here is overflow detection not type safety.

[August Karlstrom]

Post by c***@gmail.com

Post by August Karlstrom
MODULE M;
IMPORT Out;
VAR
a, b: BYTE;
BEGIN
a := 255;
b := 1;
Out.Int(a + b, 0);
Out.Ln
END M.
Does the calculation overflow or not?

If you have to ask the question then you should avoid writing code like this.

So you claim that for an expression containing a BYTE variable the
result type is undefined?


-- August

[Diego Sardina]

Post by c***@gmail.com

Post by Diego Sardina
Risky? Type-safe languages were invented for this reason.

The issue here is overflow detection not type safety.

A type safe language helps the programmer to avoid unexpected results and unexpected behaviours related to memory and arithmetic problems.

I expect that a type safe language helps me to detect that 255 + 1 = 0 since this is an unexpected result. Then I change the code to protect the program from a problem like this or enlarge the type for that arithmetic operation because I need larger values.

Post by c***@gmail.com
So you claim that for an expression containing a BYTE variable the
result type is undefined?

From the report: "The type of the result is that operand's type which includes the other operand's type."

The type of the result is BYTE. OBC gives a wrong result because 256 is not of type BYTE (maybe it does calculation as INTEGER).



--
Diego Sardina

[c***@gmail.com]

Post by Diego Sardina
From the report: "The type of the result is that operand's type which includes the other operand's type."

Which section of the report is that? I'm looking at Revision 1.10.2013 / 3.5.2016 and cannot see that statement.

[Diego Sardina]

Post by c***@gmail.com
Which section of the report is that? I'm looking at Revision 1.10.2013 / 3.5.2016 and cannot see that statement.

Sorry, I clicked the old Oberon report by mistake.

Oberon-07 report says in 8.2.2. Arithmetic operators:

"Both operands must be of the same type, which is also the type of the result."



--
Diego Sardina

[August Karlstrom]

Post by Diego Sardina

Post by c***@gmail.com
Which section of the report is that? I'm looking at Revision 1.10.2013 / 3.5.2016 and cannot see that statement.

Sorry, I clicked the old Oberon report by mistake.
"Both operands must be of the same type, which is also the type of the result."

But this is obviously not true if one of the operands is of type INTEGER
and the other of type BYTE.


-- August

[c***@gmail.com]

Post by August Karlstrom
So you claim that for an expression containing a BYTE variable the
result type is undefined?

No. I'm saying that if *you*, as a programmer, are not convinced what the result should be then you should use a different approach that you are certain of. I see no good reason to use BYTE variables in calculations that expect INTEGER results.

[August Karlstrom]

Post by c***@gmail.com

Post by August Karlstrom
So you claim that for an expression containing a BYTE variable the
result type is undefined?

No. I'm saying that if *you*, as a programmer, are not convinced what the result should be then you should use a different approach that you are certain of. I see no good reason to use BYTE variables in calculations that expect INTEGER results.

My question is not about arithmetic overflow. What I want to know is if
a + b is of type BYTE or INTEGER if a and b is of type BYTE.


-- August

[c***@gmail.com]

Post by August Karlstrom
My question is not about arithmetic overflow. What I want to know is if
a + b is of type BYTE or INTEGER if a and b is of type BYTE.

Type differences are not relevant in this example. e.g. consider this on a system where INTEGER is a 32-bit quantity:

VAR
i1, i2, i3: INTEGER;

i1 := ‭2147483647‬;
i2 := ‭2147483645‬;
i3 := 10;

is i1 + i2 an INTEGER?

Now i1 + i3 - i2 = 12, but would you code it like that if you knew what the potential ranges of the values of the variables would be? I hope not.

For this particular case you should write the expression as e.g. i1 - i2 + i3.

What this illustrates is that you should not make any assumptions about intermediate values of expressions when the behaviour is not explicitly stated and there is potential for overflow.

[August Karlstrom]

Post by c***@gmail.com
VAR
i1, i2, i3: INTEGER;
i1 := ‭2147483647‬;
i2 := ‭2147483645‬;
i3 := 10;
is i1 + i2 an INTEGER?

Of course the expression i1 + i2 has type INTEGER. Arithmetic overflow
has nothing to do with this fact.

Post by c***@gmail.com
What this illustrates is that you should not make any assumptions about intermediate values of expressions when the behaviour is not explicitly stated and there is potential for overflow.

But then what you essentially say I that the the type of a + b is
undefined (or better "unspecified") if a and b is of type BYTE.


-- August

[c***@gmail.com]

Post by August Karlstrom
Of course the expression i1 + i2 has type INTEGER. Arithmetic overflow
has nothing to do with this fact.

If it is 'of course' why then do you doubt that b1 + b2 has type BYTE? What does it matter what type it is if you don't care about overflow?

[August Karlstrom]

Post by c***@gmail.com

Post by August Karlstrom
Of course the expression i1 + i2 has type INTEGER. Arithmetic overflow
has nothing to do with this fact.

If it is 'of course' why then do you doubt that b1 + b2 has type BYTE? What does it matter what type it is if you don't care about overflow?

Because it could be the case that BYTE variables in expressions are
implicitly converted to INTEGER. In fact, someone made that claim on the
ETH Oberon mailing list. In my world the type of an expression is
determined by the type of its operands, not its value.


-- August

[August Karlstrom]

Post by August Karlstrom
In my world the type of an expression is
determined by the type of its operands, not its value.

I meant "not their values".


-- August

[c***@gmail.com]

Post by August Karlstrom
Because it could be the case that BYTE variables in expressions are
implicitly converted to INTEGER. In fact, someone made that claim on the
ETH Oberon mailing list. In my world the type of an expression is
determined by the type of its operands, not its value.

They were probably referring to the way the language *has* been implemented, not the way it *must* be implemented, on a particular. e.g. the RISC5 architecture that the Project Oberon OS runs on uses 32-bit registers exclusively for add, subtract etc. operations. 8-bit quantities are only involved for load and store operations (transfer of between registers and RAM). The report intentionally does not prevent the language from being implemented efficiently on such an architecture.

[c***@gmail.com]

Post by August Karlstrom
Because it could be the case that BYTE variables in expressions are
implicitly converted to INTEGER. In fact, someone made that claim on the
ETH Oberon mailing list. In my world the type of an expression is
determined by the type of its operands, not its value.

They were probably referring to the way the language *has* been implemented, not the way it *must* be implemented, on a particular architecture. e.g. the RISC5 architecture that the Project Oberon OS runs on uses 32-bit registers exclusively for add, subtract etc. operations. 8-bit quantities are only involved for load and store operations (transfer of data between registers and RAM). The report intentionally does not prevent the language from being implemented efficiently on such an architecture.