STRUCTURE operation problem

[rburkey2005]

I haven't exhaustively tested STRUCTURE operations, but had occasion to compile some test code involving STRUCTURE's, and as long as I had done that already anyway I decided to run the resulting HALMAT in yaHALMAT, where it failed. Here's the test code:

    TEST: PROGRAM;
        STRUCTURE A:
            1 B INTEGER,
            1 C SCALAR,
            1 D,
                2 E INTEGER,
                2 F SCALAR;
        DECLARE A A-STRUCTURE;
        C = 55.3;
        E = 12;
        WRITE(6) C, E;
    CLOSE TEST;

What this should print out when run in yaHALMAT is something like

 5.5300000E+01              12

but what it actually prints out is

 0.0          0

Explanatory note: What this code tests is that under a certain narrow range of circumstances, it's allowed in HAL/S to refer to fields in a STRUCTURE simply by their field names — C and E in the above example — without having to use their full dotted references (A.C and A.D.E). If you instead use the less-confusing alternative test program that has the full dotted references,

    TEST: PROGRAM;
        STRUCTURE A:
            1 B INTEGER,
            1 C SCALAR,
            1 D,
                2 E INTEGER,
                2 F SCALAR;
        DECLARE A A-STRUCTURE;
        A.C = 55.3;
        A.D.E = 12;
        WRITE(6) A.C, A.D.E;
    CLOSE TEST;

the compiler produces the same HALMAT files, the same compiler reports, and of course, yaHALMAT prints out the same thing.

[Zaneham]

Thank you for the test case, this is very helpful. The fact that both the short name form (C, E) and the full dotted form (A.C, A.D.E) produce the same HALMAT and the same wrong result narrows it down to how yaHALMAT resolves symbol table entries for STRUCTURE fields.

I suspect the issue is that the emulator resolves the field name to a symbol table index but does not account for the offset of the field within the structure's data layout. So when you write to A.C and then read A.C, the write goes to the right place but the read comes back as the base of the structure (which is zeroed) rather than the offset where C actually lives.

I will trace through the DSUB/TSUB handling in class 0 to confirm. The structure definition opcodes (STRI/SLRI/ELRI/ETRI in class 8) set up the layout but I need to check whether the field offsets are being tracked properly at runtime.