• Result type of BYTE expressions

    From rugxulo@gmail.com@21:1/5 to August Karlstrom on Mon Oct 23 16:07:23 2017
    Hi,

    On Sunday, October 22, 2017 at 2:13:19 AM UTC-5, August Karlstrom wrote:

    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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From August Karlstrom@21:1/5 to rugxulo@gmail.com on Tue Oct 24 09:32:35 2017
    On 2017-10-24 01:07, rugxulo@gmail.com wrote:
    Hi,

    On Sunday, October 22, 2017 at 2:13:19 AM UTC-5, August Karlstrom wrote:

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cfbsoftware@gmail.com@21:1/5 to August Karlstrom on Tue Oct 24 04:14:12 2017
    On Sunday, October 22, 2017 at 5:43:19 PM UTC+10:30, August Karlstrom wrote:
    On 2017-10-21 19:33, August Karlstrom wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Diego Sardina@21:1/5 to cfbso...@gmail.com on Tue Oct 24 10:00:00 2017
    On Tuesday, October 24, 2017 at 1:14:13 PM UTC+2, cfbso...@gmail.com wrote:

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


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


    --
    Diego Sardina

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dsar@eml.cc@21:1/5 to August Karlstrom on Tue Oct 24 10:06:44 2017
    On Tuesday, October 24, 2017 at 9:32:36 AM UTC+2, August Karlstrom wrote:

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cfbsoftware@gmail.com@21:1/5 to Diego Sardina on Tue Oct 24 13:47:09 2017
    On Wednesday, October 25, 2017 at 3:30:00 AM UTC+10:30, Diego Sardina wrote:
    On Tuesday, October 24, 2017 at 1:14:13 PM UTC+2, cfbso...@gmail.com wrote:

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


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


    The issue here is overflow detection not type safety.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From August Karlstrom@21:1/5 to cfbsoftware@gmail.com on Wed Oct 25 10:05:52 2017
    On 2017-10-24 13:14, cfbsoftware@gmail.com wrote:
    On Sunday, October 22, 2017 at 5:43:19 PM UTC+10:30, August Karlstrom wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Diego Sardina@21:1/5 to cfbso...@gmail.com on Wed Oct 25 02:43:22 2017
    On Tuesday, October 24, 2017 at 10:47:10 PM UTC+2, cfbso...@gmail.com wrote:


    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.


    On Wednesday, October 25, 2017 at 10:05:52 AM UTC+2, August Karlstrom wrote:

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cfbsoftware@gmail.com@21:1/5 to Diego Sardina on Wed Oct 25 03:37:37 2017
    On Wednesday, October 25, 2017 at 8:13:23 PM UTC+10:30, Diego Sardina wrote:

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Diego Sardina@21:1/5 to cfbso...@gmail.com on Wed Oct 25 03:46:35 2017
    On Wednesday, October 25, 2017 at 12:37:38 PM UTC+2, cfbso...@gmail.com wrote:

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cfbsoftware@gmail.com@21:1/5 to August Karlstrom on Wed Oct 25 03:31:57 2017
    On Wednesday, October 25, 2017 at 6:35:52 PM UTC+10:30, August Karlstrom wrote:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From August Karlstrom@21:1/5 to cfbsoftware@gmail.com on Wed Oct 25 12:52:12 2017
    On 2017-10-25 12:31, cfbsoftware@gmail.com wrote:
    On Wednesday, October 25, 2017 at 6:35:52 PM UTC+10:30, August Karlstrom wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From August Karlstrom@21:1/5 to Diego Sardina on Wed Oct 25 12:54:18 2017
    On 2017-10-25 12:46, Diego Sardina wrote:
    On Wednesday, October 25, 2017 at 12:37:38 PM UTC+2, cfbso...@gmail.com wrote:

    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."

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


    -- August

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From August Karlstrom@21:1/5 to cfbsoftware@gmail.com on Wed Oct 25 14:00:24 2017
    On 2017-10-25 13:16, cfbsoftware@gmail.com wrote:
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cfbsoftware@gmail.com@21:1/5 to August Karlstrom on Wed Oct 25 04:16:38 2017
    On Wednesday, October 25, 2017 at 9:22:13 PM UTC+10:30, August Karlstrom wrote:


    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cfbsoftware@gmail.com@21:1/5 to August Karlstrom on Wed Oct 25 05:17:14 2017
    On Wednesday, October 25, 2017 at 10:30:25 PM UTC+10:30, August Karlstrom wrote:

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From August Karlstrom@21:1/5 to cfbsoftware@gmail.com on Wed Oct 25 14:58:12 2017
    On 2017-10-25 14:17, cfbsoftware@gmail.com wrote:
    On Wednesday, October 25, 2017 at 10:30:25 PM UTC+10:30, August Karlstrom wrote:

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From August Karlstrom@21:1/5 to August Karlstrom on Wed Oct 25 15:00:30 2017
    On 2017-10-25 14:58, August Karlstrom wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cfbsoftware@gmail.com@21:1/5 to August Karlstrom on Wed Oct 25 19:28:01 2017
    On Wednesday, October 25, 2017 at 11:28:13 PM UTC+10:30, August Karlstrom wrote:

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cfbsoftware@gmail.com@21:1/5 to August Karlstrom on Wed Oct 25 19:29:56 2017
    On Wednesday, October 25, 2017 at 11:28:13 PM UTC+10:30, August Karlstrom wrote:

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)