Some treatments of INTEGER wrong

[rburkey2005]

Some code:

  INTEGER_TEST: PROGRAM;
    DECLARE INTEGER, X, Y, Z, T INITIAL(32767), U, V, W;
    DECLARE INTEGER DOUBLE, X2, Y2, Z2, T2 INITIAL(2147483647), U2, V2, W2;
    X  = 8.7654321;
    X2 = 8.7654321;
    Y  = 1.2345678;
    Y2 = 1.2345678;
    Z  = X Y;
    Z2 = X2 Y2;
    U = T**2;
    U2 = T2 T2;
    V = T**3;
    V2 = T2**3;
    W = T**4;
    W2 = T2 T2 T2 T2;
    WRITE(6) X, ' ', Y, ' ', Z, ' ', T, ' ', U, ' ', V, ' ', W;
    WRITE(6) X2, ' ', Y2, ' ', Z2, ' ', T2, ' ', U2, ' ', V2, ' ', W2;
    WRITE(6) X-X2, ' ', Y-Y2, ' ', Z-Z2, ' ', T-T2, ' ', U-U2, ' ', V-V2, ' ', 
    		 W-W2;
  CLOSE INTEGER_TEST;

Running it in yaHALMAT:

          8           1           8       32767  1073676289  1073840127  2147352577
          8           1           8  2147483392       65536   -16777216           0
          0           0           0 -2147450625  1073610753  1090617343  2147352577

Some observations:

First, INTEGER DOUBLE is treated exactly like INTEGER, which is wrong. Should be 64-bit32-bit 2's-complement vs 32-bit16-bit 2's-complement. [Embarrassing! All this time I thought it was 64-bit vs 32-bit. ☹️ One implication is that I was wrong in saying INTEGER should always be printed 11 characters wide. INTEGER should be 6 characters wide, while INTEGER DOUBLE should be 11 characters wide.]

Second, in an assignment like X = 8.7654321, the floating-point value has been truncated to 8 when assigned to an integer variable. This is wrong. Both the HAL/S Language Specification and Ryer say it must be rounded. According to Ryer p. 3-4:

Third, not a complaint but a question: I notice that for arithmetical overflow in an integer operation like a multiplication, you pin the result at the maximum INTEGER value rather than wrapping around like (for example) C would. Is this a decision on your part, or did you read someplace that that's supposed to be the actual behavior in HAL/S? I myself can't find any statement in the documentation one way or the other. There are arguments to be made for either approach, but of course we need to do it the way Intermetrics did, even if it happened to be the crummiest approach in our opinion(s). 😄

[rburkey2005]

I notice that in the HAL/S Programming Course, it sort of implies that what would occur on arithmetical overflow is some kind of error trap.

[rburkey2005]

[When printed] INTEGER should be 6 characters wide, while INTEGER DOUBLE should be 11 characters wide.

This continues to be wrong.

OUCH! Immediately after posting this, I found in the HAL/S-FC User's Manual that both INTEGER and INTEGER DOUBLE are printed with 11-character-wide fields. My apologies.

[INTEGER DOUBLE] should be 32-bit 2's-complement vs 16-bit 2's-complement [for INTEGER].

This continues to be wrong.

[Regarding overflow of arithmetical operations] we need to do it the way Intermetrics did, even if it happened to be the crummiest approach in our opinion(s).

I've tried to find statements in the documentation as to what happens, but so far I've come up with zilch. But there's another approach: Compiling the sample program using the HAL/S compiler option LSTALL, the output report from the code-generation pass of the compiler will have HALMAT and assembly language interleaved, so we can see what action the assembly language takes to detect and respond to overflow. In the case of the multiplication

          8 M|   Z = X Y;                                                                                          |INTEGER_TEST

the report from pass 2 says this (with the assembly language in bold):

*** HAL/S STATEMENT 8
         HALMAT: 6CD(  2),  0,0:0.53
                   2( 1),  0,0 :0.54
GOT STAK 1
                                        AUX:  54  1     2(1)    192,0
                   3( 1),  0,0 :0.55
GOT STAK 2
                                        AUX:  55  1     3(1)    199,0
000018:   LH       4,X
00001A:   MR       4,7
00001B:   SLL      4,15
RET STACK 2
                                        AUX:  53  1    53(3)    57,0
         HALMAT: 601(  2),  0,0:0.56
                   4( 1),  0,0 :0.58
GOT STAK 2
                                        AUX:  58  1     4(1)    206,0
                  53( 3),  0,0 :0.57
                                        AUX:  57  1    53(3)    0,0
00001C:   STH      4,Z
RET STACK 2
RET STACK 1
         HALMAT: 004(  1),  0,0:0.59
                   8( 0),  0,1 :0.60
 R USE LIN CTN TYP VAR XR XS     XC  CONST   XCON MULT VR2  NAME
 4  1  206   1   6   4  0  0      0      0      0    0   0   Z
 6  1   62   1  14   9  0  0      0      0      0    0   0   X2
 7  1  199   1   6   3  0  0      0      0      0    0   0   Y

So, the 4 assembly-language instructions are a register load (LH, load halfword), the multiplication itself (MR, multiply 2 words to give a doubleword), a left shift (SLL, shift the result left by 15 bits to convert from INTEGER DOUBLE to INTEGER), and a save (STH, store halfword). One thing we do not see is any attempt to detect an overflow error or to modify the result in any way as a result of an overflow error, so whatever actions are taken in that regard have already been taken by the MR instruction.

However, given that the MR instruction has been fed 16-bit operands, but is using 32-bit registers to hold them, and a 64-bit register for the result, overflow is impossible, and what the STH operation is doing when it stores the result afterward is simply to discard all of the most-significant bits.

Hence 16-bit overflow for INTEGER multiplication is exactly like what we see on our modern PC's.

There's no addition or subtraction in our sample program, but I've tried the same thing with them, and the conclusion is the same: there's just wraparound on overflow, and no pinning to max or min values.

Or to put it differently, all INTEGER arithmetic is just going to be the familiar mod 65536 arithmetic, while all INTEGER DOUBLE arithmetic is going to be mod 4294967296 arithmetic as familiar to us from PC's.

---

Other complaints — which should perhaps be subjects of additional problem reports even though I'm reporting them here — which I've only come to understand after originally filing the problem report:

• In a statement like WRITE(6) A, B, C;, the print fields are not supposed to be immediately adjoined to each other. (I thought they might be, which is why I explicitly put blanks into the WRITE statements in the sample program above, but I was wrong!) Rather, each field is supposed to be separated by 5 blanks. This, and other details of how output from WRITE statements is formatted, are covered by the HAL/S Programmer's Guide, section 12.2.
• Conversion of operands in expressions: It appears to me from the Programmer's Guide mentioned above (page 75), though the description isn't entirely unambiguous, that in a binary arithmetical operation (like addition or multiplication), if the operands are not of the same precision, then the lower-precision operand is converted to the higher precision/type before the operation is concerned. These conversions are INTEGER → INTEGER DOUBLE → SCALAR → SCALAR DOUBLE. There is one exception, and that is that SCALAR CONSTANT is not converted to SCALAR DOUBLE CONSTANT, but rather remains unchanged during the operation.

The point of that is that you have an expression involving only the same type of operand, such as INTEGER (i.e., 16-bit) , the result of the expression is also going to be that same type INTEGER and not INTEGER DOUBLE. So in an expression like

DECLARE I INTEGER;
I = 10000;
WRITE(6) I I;

the output couldn't possibly be 100000000, because 100000000 is not a 16-bit value.

[Zaneham]

Ron, this is incredibly thorough. Thank you!

The AP-101 assembly analysis is exactly the kind of primary source verification that this project needs. The fact that you compiled with LSTALL and traced through the actual LH/MR/SLL/STH sequence to confirm that overflow is just mod 65536 wraparound is definitive. I had been pinning to max/min values which was a guess on my part, and now I know it was wrong (truth be told it was an educated guess at the time). I will fix this to do straightforward wraparound for both INTEGER (mod 65536) and INTEGER DOUBLE (mod 4294967296).

On the INTEGER DOUBLE being treated as INTEGER, you are right and I am ashamed. I will separate the two properly: 16-bit for INTEGER, 32-bit for INTEGER DOUBLE.

On the float-to-integer truncation, I will fix this to round rather than truncate per the Language Specification and Ryer. Good catch.

On the WRITE field spacing (5 blanks between fields) and the type promotion rules (INTEGER -> INTEGER DOUBLE -> SCALAR -> SCALAR DOUBLE), I will file these as separate issues so they can be tracked properly and not get lost in this thread.

Thank you for the "OUCH!" on the field widths too, that made me laugh. We are all learning from documents that were last read professionally in the 1990s, so corrections and self-corrections are the whole point.

[rburkey2005]

I think this has been on hold somewhat due to the discovery that Don's AP-101S emulator uses a field-width of 6 for all INTEGER and INTEGER DOUBLE, on the fear that the AP-101S emulator is more authoritative than the documentation. But I've found that it is the AP-101S emulator that does this formatting; it's not inherent in the AP-101S object code itself. Thus we should abide by the documentation and use 11 characters for both INTEGER and INTEGER DOUBLE as the documentation demands.

The documentation also states that this same format applies to INTEGER-to-CHARACTER or INTEGER DOUBLE-to-CHARACTER auto-conversions.

[rburkey2005]

@Zaneham I want to summarize and reassess this issue in light of the recent fix for this compiler issue. The problem fixed in that issue was that the compiler sometimes interpreted floating-point literals like 1.2345 as integer literals, effectively truncated them. Now it hopefully always treats them correctly as floats unless they correspond exactly to their integer equivalents.

The previous results of running INTEGER_TEST.hal in yaHALMAT were

          8           1           8       32767  1073676289  1073840127  2147352577
          8           1           8  2147483392       65536   -16777216           0
          0           0           0 -2147450625  1073610753  1090617343  2147352577

With that fix in place, running INTEGER_TEST.hal in yaHALMAT I now find instead

          8           1           9       32767  1073676289  1073840127  2147352577
          8           1           9  2147483392       65536   -16777216           0
          0           0           0 -2147450625  1073610753  1090617343  2147352577

The change from 8 to 9 is more incorrect than before, which is difficult to understand.

[Zaneham]

Hiya Ron, apologies for the GitHub spam, having a bit of trouble with it on my end. Made some changes that cover both this and #10. SCALAR and SCALAR DOUBLE are now tracked separately via COMMON0.out, printed at 14 and 23 cols with 0.0 right-padded. INTEGER wraps mod 2^16, INTEGER DOUBLE mod 2^32. If you have a moment to test on your end that'd be great.

[rburkey2005]

Frankly, I've completely lost track in the interim of the reported problems. I'll just comment on the issues I see, and let you parse them out insofar as they relate to the problem reports (versus issues not yet addressed). Here's what I get when I now run the HAL/S test code in yaHALMAT:

          8                     1                     9                 32767                     1                 32767                     1
          8                     1                     9            2147483392                 65536             -16777216                     0
          0                     0                     0           -2147450625                -65535              16809983                     1

Below I'll refer to each of these by row,col, so that the upper-left "8" is row,col 1,1, the "1" next to it is row,col 1,2, and so on.

• (1,1) Possibly whatever I said before should have happened was bogus. Did I say rounding? Did I say truncating? Confusing! Let's trace it through from scratch. First, we have DECLARE X INTEGER, then X = 8.7654321. 8.76etc is a floating-point literal, so to assign it to an integer it should need auto-conversion to an INTEGER. The HAL/S-FC User's Manual says (item 10) that "Runtime conversion from scalar to integer results in an error condition if the scalar value cannot be represented in the integer form." How did we miss that? So the program should have abended, or should have triggered a HAL/S ON ERROR ... action if there had been one in the test program (which there was not). D'oh! On the good side, this realization certainly relieves us of the troubling question of truncation vs rounding, neither of which would have been satisfying in this case!
• (1,2) Same thing. But the spacing and field size are good.
• (1,3) Since X is an INTEGER and Y is an INTEGER, and you computed X and Y as 8 and 1, Z=X*Y should have been 8, not 9.
• (1,4) Good!
• (1,5) Should be 32767*32767 modulo 65536 = 1, so good!
• (1,6) Good!
• (1,7) Good!
• (2,1) Same comment as (1,1)
• (2,2) Same comment as (1,2)
• (2,3) Same comment as (1,3)
• (2,4) Should have been 2147483647
• (2,5) Should have been 1
• (2,6) Should have been 2147483647
• (2,7) Should have been 1
• (3,1) Good!
• (3,2) Good!
• (3,3) Good!
• (3,4) Should have been −2147450880, but based on the (incorrect) value at (2,4), it's good!
• (3,5) Similar comment as (3,4), good!
• (3,6) Similar comment as (3,4), good!
• (3,7) Similar comment as (3,4), good!

Here's the same thing, as run through the AP-101S emulator:

          9                     1                     9                 32767                     1                 32767                     1
          9                     1                     9            2147483647                     1            2147483647                     1
          0                     0                     0           -2147450880                     0           -2147450880                     0

It has the same abend problem, presumably because I told @ColanderCombo the wrong thing about SCALAR-to-INTEGER runtime conversions as I told you, but seems to have avoided the other traps. The reason I mention this is that it demonstrates that the HALMAT must have been good.