WRITE statements for INTEGER numbers in yaHALMAT

[rburkey2005]

Ryer p. 8-3 tells us that integers are always left-padded so as to print the number of characters needed for the largest number of a given precision. In the case of Intermetrics HAL/S, INTEGER is a 32-bit value, so all integers are padded to 11 characters (including allowance for a minus sign) when printed. So 1 would print as 1. INTEGER DOUBLE would be even more.

[Zaneham]

Still figuring out GitHub. But I've fixed these — integers now left-pad to 11 characters per spec.

[rburkey2005]

@Zaneham Okay, this is getting a bit ridiculous. I'm beginning to wonder if the people who wrote those old documents even know how the stuff worked at all. I think I mentioned the other day that there is a guy, Don Schmidt, working on both an AP101S linker and an emulator. Well, today I got my hands on it for the first time, and compiled/linked/ran the ubiquitous HELLO.hal using it. Here's the output:

THE BEGINNING 
     1 HELLO, WORLD! 
           2 RON BURKEY SAYS ISN'T THIS FUN? 
           4 RON BURKEY SAYS ISN'T THIS FUN? 
           6 RON BURKEY SAYS ISN'T THIS FUN? 
           8 RON BURKEY SAYS ISN'T THIS FUN? 
     2 HELLO, WORLD! 
           2 RON BURKEY SAYS ISN'T THIS FUN? 
           4 RON BURKEY SAYS ISN'T THIS FUN? 
           6 RON BURKEY SAYS ISN'T THIS FUN? 
           8 RON BURKEY SAYS ISN'T THIS FUN? 
     3 HELLO, WORLD! 
           2 RON BURKEY SAYS ISN'T THIS FUN? 
           4 RON BURKEY SAYS ISN'T THIS FUN? 
           6 RON BURKEY SAYS ISN'T THIS FUN? 
           8 RON BURKEY SAYS ISN'T THIS FUN? 
     4 HELLO, WORLD! 
           2 RON BURKEY SAYS ISN'T THIS FUN? 
           4 RON BURKEY SAYS ISN'T THIS FUN? 
           6 RON BURKEY SAYS ISN'T THIS FUN? 
           8 RON BURKEY SAYS ISN'T THIS FUN? 
     5 HELLO, WORLD! 
           2 RON BURKEY SAYS ISN'T THIS FUN? 
           4 RON BURKEY SAYS ISN'T THIS FUN? 
           6 RON BURKEY SAYS ISN'T THIS FUN? 
           8 RON BURKEY SAYS ISN'T THIS FUN? 

Notice that the integer field width is 6, not 11. And there aren't 5 spaces between fields!

Then I went through and changed the datatypes of I and J in HELLO.hal from INTEGER to INTEGER DOUBLE. No difference! And you know what? The HALMAT files produced are identical in either case!

Summary:

• It's may be a mistake to switch to 11-character fields for integers.
• Or to change the width of the blank separators.
• You may not be able to distinguish between single-and double precision, at least not with HELLO.hal.

I'll have to coordinate with Don. Or there may even be a bug in the compiler.

Are you open to a 3-way discussion about this with him and me? I'll have to inquire with him, of course.

[rburkey2005]

The problem with using HELLO.hal to distinguish differences between single-precision and double-precision print formats is that when you have multiple items in a WRITE statement, they're all shmooshed together into a single string and the precision data is lost. You have to print a single variable in each WRITE statement to see the differences. Here's a new test program for it, which I call FIELDWIDTH.hal:

 FIELDWIDTH: PROGRAM;
    DECLARE N1 INTEGER INITIAL(1234), N2 INTEGER DOUBLE INITIAL(567);
    DECLARE X0 SCALAR INITIAL(0.0), X1 SCALAR INITIAL(1.0);
    DECLARE SCALAR DOUBLE, X2 INITIAL(0.0), X3 INITIAL(2.0);
    DECLARE C CHARACTER(200);
    WRITE(6) '123456789012345678901234567890123456789012345678901234567890123456
 789012345678901234567890';
    WRITE(6) N1;
    WRITE(6) N2;
    WRITE(6) X0;
    WRITE(6) X1;
    WRITE(6) X2;
    WRITE(6) X3;
    WRITE(6) 'A string',N1, N2, X0, X1, X2, X3;
    WRITE(6) 'A string' || N1 || N2 || X0 || X1 || X2 || X3;
    C = '12345678901234567890123456789012345678901234567890123456789012345678901
 2345678901234567890';
    WRITE(6) C;
    C = N1;
    WRITE(6) C;
    C = N2;
    WRITE(6) C;
    C = X0;
    WRITE(6) C;
    C = X1;
    WRITE(6) C;
    C = X2;
    WRITE(6) C;
    C = X3;
    WRITE(6) C;
    WRITE(6) '123456789012345678901234567890123456789012345678901234567890123456
 789012345678901234567890';
    WRITE(6) '';
 CLOSE FIELDWIDTH;

(Be careful to compile without the SRN compiler option.)

Here's the result in yaHALMAT:

123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
       1234
        567
 0.0
 1.0000000E+00
 0.0
 2.0000000E+00
A string       1234        567 0.0 1.0000000E+00 0.0 2.0000000E+00
A string12345670102
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890






123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
�

versus the result in the AP-101S emulator:

123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 
  1234 
   567 
 0.0          
 1.000000E+00 
 0.0                   
 2.000000000000000E+00 
A string   1234    567  0.0           1.000000E+00  0.0                    2.000000000000000E+00 
A string123456756 0.0         1.0000000E+00 1 0.0                  2.0000000000000000E+00 
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 
1234 
567 
56 0.0         
 1.0000000E+00 
 1 0.0                  
 2.0000000000000000E+00 
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 

What a lot of observations can be drawn from this simple example! I'm tempted to make a huge list, but I'll avoid that temptation for now. I'll merely note that if we're to trust the AP-101S emulator, we'd infer that:

• Both INTEGER and INTEGER DOUBLE are printed in 6-character fields, but in automatic conversions to CHARACTER there is no extra padding.
• 0.0 is indeed printed as " 0.0", but it is right-padded to the full SCALAR or SCALAR DOUBLE field width both for printing and for automatic conversions to CHARACTER.

Plus, are you aware that newlines are emitted before lines rather than after them? That may explain why the AP-101S emulator has a blank line at the top which yaHALMAT doesn't, while yaHALMAT has a goofy unprintable character at the end that the AP-101S emulator does not.

Beyond that, the crystal ball gets a little murkier. And even those conclusions aren't fully clear.

[Zaneham]

Are you open to a 3-way discussion about this with him and me? I'll have to inquire with him, of course.

Yes no problem! Send him my email

Also going to reopen the issue for tracking

[rburkey2005]

@Zaneham I now realize something that likely affects not only this issue, but probably also issues #10, #11, #14, and #17, namely that these issues cannot be addressed without detailed knowledge of the symbol table — which is not embedded in the HALMAT itself —, but that yaHALMAT is likely not yet accessing the symbol table.

Some of what I will have to say below belongs in Halmat.pdf. I'll refrain from any detailed suggestions concerning that.

In the original HAL/S compiler, the symbol table remained in System/360 memory from one pass of the compiler to the next, so that each compiler pass that created, optimized, or used the HALMAT had direct access to the symbol table. In the modern version of the compiler, HALSFC, an image of the memory model is communicated among the compiler passes instead as files. While yaHALMAT in principle loads this memory image — it's yaHALMAT's --common F command-line option, where F is COMMON0.out.bin.gz (for halmat.bin) or COMMON2.out.bin.gz (for optmat.bin) —, I doubt that it can be accessing the symbol table, since it has no knowledge of where in memory the symbol table resides. I think that yaHALMAT uses these files only to get character-string data.

You may recall that my initial suggestion had been not to load these binary memory images, but to instead load the files COMMON0.out or COMMON2.out, which are human-friendly representations of so-called COMMON memory and of the areas of memory used to store character-string data, but that I quickly changed my mind before you had the chance to implement that approach. I think I was wrong.

In so far as the literal data alone is concerned, of course if that's working then there's no theoretical need to replace COMMONx.out.bin.gz by COMMONx.out. Why fix something that's working, right? But if you need to load and parse COMMONx.out anyway just for the symbol-table info, why load two files rather than just one? It's a judgement call. If you did want to switch completely to COMMONx.out, however, recall that the explanation for how to do so is in the description of the now-closed issue #1.

As far as accessing the symbol table in COMMONx.out is concerned, the file is arranged in a series of blocks whose functionality is determined by the 1st character of each line. The initial lines beginning with '@' or '+' (or other characters) can be discarded until reaching the first line beginning with '/'. That's where the symbol table begins.

Each line consists of tab-delimited fields. Each symbol in the table consists of a block of lines, as follows:

• Fields of the first line of a symbol entry in the symbol table:
  1. "/"
  2. "SYMuTAB"
  3. Symbol number (0, 1, 2, 3, ...). These numbers are how a SYT word in the HALMAT references the symbol
  4. "BASED"
  5. Info about the symbol that's may not be of any use ... time will tell.
• Fields of subsequent lines of the symbol entry:
  1. "."
  2. "SYM_xxxx", where xxxx indicates the particular type of information about the symbol which is being conveyed. Here are some of the ones that at the moment I think are relevant:
     • "SYM_NAME", name of the symbol
     • "SYM_FLAGS", secondary attributes of the symbol provided as a set of bit-flags, such as whether it is single- or double-precision. More on the interpretations of these flags below.
     • "SYM_TYPE", i.e., the datatype (CHARACTER vs INTEGER vs SCALAR vs etc.). More on the interpretations of this below.
  3. "0", I think.
  4. Datatype of the next field (5). Always(?) "FIXED" (hexadecimal string), "BIT" (also a hexadecimal string), or "CHARACTER" (quoted character string).
  5. The value of "SYM_xxxx".

The first line beginning with "/" but not "SYMuTAB" is the end of the symbol table.

For example, consider this symbol-table entry:

/       SYMuTAB 2       BASED   (blank)
.       SYM_NAME        0       CHARACTER       'LONG'
.       SYM_ADDR        0       FIXED   00000000
.       SYM_FLAGS       0       FIXED   00808208
.       XTNT    0       FIXED   00000000
.       SYM_XREF        0       BIT     0002
.       SYM_LENGTH      0       BIT     0000
.       SYM_ARRAY       0       BIT     0000
.       SYM_PTR 0       BIT     0000
.       SYM_LINK1       0       BIT     0000
.       SYM_LINK2       0       BIT     0000
.       SYM_NEST        0       BIT     01
.       SYM_SCOPE       0       BIT     01
.       SYM_CLASS       0       BIT     01
.       SYM_LOCK#       0       BIT     00
.       SYM_TYPE        0       BIT     05
.       SYM_FLAGS2      0       BIT     00

It says that symbol 2 has the name LONG, that it is of type SCALAR (SYM_TYPE=05), and that it has secondary attributes SINGLE ALIGNED STATIC (SYM_FLAGS=00808208).

Regarding interpretation of SYM_TYPE: The possible values come from this list, which may or may not be complete, in the original HAL/S compiler source-code file PASS1.PROCS/##DRIVER.xpl:

   DECLARE BIT_TYPE       LITERALLY '1',                                        00150900
      CHAR_TYPE      LITERALLY '2',                                             00151000
      MAT_TYPE       LITERALLY '3',                                             00151100
      VEC_TYPE       LITERALLY '4',                                             00151200
      SCALAR_TYPE    LITERALLY '5',                                             00151300
      INT_TYPE       LITERALLY '6',                                             00151400
      IORS_TYPE      LITERALLY '8',                                             00151600
      EVENT_TYPE     LITERALLY '9',                                             00151700
      MAJ_STRUC      LITERALLY '10',                                            00151800
      ANY_TYPE       LITERALLY '11',                                            00151900
                                                                                00152000
      TEMPL_NAME     LITERALLY '"3E"',                                          00152100
      STMT_LABEL     LITERALLY '"42"',                                          00152400
      UNSPEC_LABEL   LITERALLY '"43"',                                          00152500
      IND_CALL_LAB   LITERALLY '"45"',                                          00152700
      CALLED_LABEL   LITERALLY '"46"',                                          00152800
      PROC_LABEL     LITERALLY '"47"',                                          00152900
      TASK_LABEL     LITERALLY '"48"',                                          00153000
      PROG_LABEL     LITERALLY '"49"',                                          00153100
      COMPOOL_LABEL  LITERALLY '"4A"',                                          00153200
      EQUATE_LABEL   LITERALLY '"4B"';                                          00153300

In so far as interpretation of SYM_FLAGS is concerned, the flags come in part from the FLAG_MASK array in PASS1.PROCS/SYTDUMP.xpl. I say "in part", because once you eliminate all of those flags, there are some left over. Whether any of those are relevant for our purposes, I do not yet know.

      DECLARE FLAG_MASK(19) FIXED INITIAL(0,                                    00620500
         "00800000",     /* SINGLE      */                                      00620600
         "00400000",    /* DOUBLE      */                                       00620700
         "08000000",    /* TEMPORARY  */                                        00620800
         "04000000",    /* RIGID  (AS MODIFIED IN CHECK_AND_ENTER) */           00620900
         "00000004",     /* DENSE       */                                      00621000
         "00000008",     /* ALIGNED     */                                      00621100
         "00000020",     /* ASSIGN      */                                      00621200
         "00000400",     /* INPUT       */                                      00621300
         "00000100",     /* AUTOMATIC   */                                      00621400
         "00000200",     /* STATIC      */                                      00621500
         "00000800",     /* INITIAL     */                                      00621600
         "00001000",     /* CONSTANT    */                                      00621700
         "00010000",     /* ACCESS      */                                      00621800
         "00000002",     /* REENTRANT   */                                      00621900
         "00080000",     /* EXCLUSIVE   */                                      00622000
         "00100000",     /*  EXTERNAL   */                                      00622100
         "00000080",     /*  REMOTE  */                                         00622200
         "02000000");    /*  INCLUDED_REMOTE */    /* DR108643 */               00622300

[rburkey2005]

@Zaneham I was looking into the material in the preceding comment as part of a debugging effort on a problem I'm having with the HAL/S compiler, and as part of that I greatly expanded the capabilities of my unHALMAT.py script to parse HALMAT files. The improved script might conceivably be of use to you. Things to note if you want to try it:

• unHALMAT.py was previously in a different directory, but has been moved to match the PATH recommendations in the installation instructions, so if you use it, make sure you invoke the right copy.
• It now requires unLitfile.py as a module, and unLitfile.py itself has been greatly modified so that it can be used as a module.

Here's a sample command for using it:

unHALMAT.py --colorize --listing2=listing2.txt --litfile=litfile0.bin --memory=COMMON0.out.bin.gz --common=COMMON0.out  halmat.bin | less -R

(Note that --listing2 requires HALSFC to have been run with LISTING2 among its --parms=... options.) Basically, the command pulls in a source-code listing so that it can intermix HAL/S source code with the parsed HALMAT, pulls in the literal file so that it can show the values of literals, and pulls in the COMMON file so that it can give information about symbols in the symbol table. The --colorize switch adds ANSI escape sequences for colorizing, while the -R switch for the optional less does the same.

Here's an excerpt from the output, so you can judge if it's worth your while. It doesn't do all the justice it could do, because the actual output is colorized and the clip below probably isn't, but it'll give you a pretty good idea.

7200 bytes read from halmat.bin
RECORD 0
  HALMAT 0 (005, Start of HALMAT block): PXRC(1) 00 0 0
  HALMAT 1       99 00 00(  0) 00 00 00 01 00 00   (Matching XREC is at HALMAT 153)
  HALMAT 2 (02B, Start of PROGRAM definition): MDEF(1) 00 0 0
  HALMAT 3        1 00 01(SYT) 00 00 00 01 00 00   (Symbol 1: CORNERS, PROGRAM LABEL)
  HALMAT 4 (004, HAL/S statement marker): SMRK(1) 00 1 0
  HALMAT 5        1 00 00(  0) 00 00 01 01 00 01   (HAL/S statement 1)

      1 M|                                                                                
      1 M|  CORNERS: PROGRAM;                                                             
      1 M|     DECLARE SCALAR,                                                            

  HALMAT 6 (004, HAL/S statement marker): SMRK(1) 00 1 0
  HALMAT 7        2 00 00(  0) 00 00 00 01 00 00   (HAL/S statement 2)

      2 M|                LONG, SHORT, ALPHA;                                             
      2 M|     DECLARE VECTOR(2),                                                         

  HALMAT 8 (004, HAL/S statement marker): SMRK(1) 00 1 0
  HALMAT 9        3 00 00(  0) 00 00 00 01 00 00   (HAL/S statement 3)

      3 M|                AB, BC, CD, DA;                                                 
      3 M|     DO WHILE TRUE;                                                             

  HALMAT 10 (031, End of DECLAREs): EDCL(0) 01 1 0
  HALMAT 11 (00E, Start of DO WHILE/UNTIL block): DTST(1) 00 1 0
  HALMAT 12       1 00 02(INL) 00 00 00 01 00 00   (Bookkeeping label #1)
  HALMAT 13 (720, Test BIT true): BTRU(1) 00 0 0
  HALMAT 14       2 00 05(LIT) 00 00 00 01 00 00   (Literal 2: BIT 1)
  HALMAT 15 (016, Next WHILE/UNTIL iteration or exit): CTST(1) 00 0 0
  HALMAT 16       D 00 03(VAC) 00 00 00 01 00 00   (Result from operation at HALMAT 13)
  HALMAT 17 (004, HAL/S statement marker): SMRK(1) 00 1 0
  HALMAT 18       4 00 00(  0) 00 00 01 01 00 01   (HAL/S statement 4)

      4 M|        WRITE(6) 'Enter long side, short side, angle (radians), ',              

  HALMAT 19 (025, Start of argument list): XXST(1) 00 1 0
  HALMAT 20       2 00 06(IMD) 00 00 00 01 00 00   (Immediate integer data 2=0x2)
  HALMAT 21 (027, Argument): XXAR(1) 00 1 0
  HALMAT 22       4 02 05(LIT) 00 00 00 01 00 00   (Literal 4: CHARACTER 'Enter long side, short side, angle (radians), ')
  HALMAT 23 (027, Argument): XXAR(1) 00 1 0
  HALMAT 24       5 02 05(LIT) 00 00 00 01 00 00   (Literal 5: CHARACTER 'or else -1; to exit:')
  HALMAT 25 (021, WRITE statement): WRIT(1) 00 0 0
  HALMAT 26       6 00 06(IMD) 00 00 00 01 00 00   (Immediate integer data 6=0x6)
  HALMAT 27 (026, End of argument list): XXND(0) 00 0 0
  HALMAT 28 (004, HAL/S statement marker): SMRK(1) 00 1 0
  HALMAT 29       5 00 00(  0) 00 00 01 01 00 01   (HAL/S statement 5)

      5 M|                 'or else -1; to exit:';                                        
      5 M|        READ(5) LONG, SHORT, ALPHA;    
    ...                                         

[rburkey2005]

After some consideration, I realize that most of the new command-line options for unHALMAT.py should actually just be defaults. Nor is there any need for using the LISTING2 compiler option with HALSFC with these new defaults. So if you grab the latest unHALMAT.py (and HALSFC) from the repository as of now, you can use unHALMAT.py more easily, like one of the following exemplars,

unHALMAT.py [--colorize] halmat.bin
unHALMAT.py [--colorize] optmat.bin

But make no mistake, COMMONx.out is still needed to get access to the symbol table, it's just that in unHALMAT.py it's now the default, so you don't have to see it happening.