TP3/shell/tests/fixtures/expected.tsv

# Expected results for tests/fixtures/*.pas  -  one line per fixture:
#
#   <fixture-basename>	OK	<code>	<data>
#   <fixture-basename>	ERR	<tp3-error-no>	<relative-pos>
#
# Both the verdict AND the numbers are asserted by run_compile_tests.sh, so a
# regression in the *reported error position* fails the suite just like a
# regression in the generated code.  That matters: error positions were once
# silently wrong (a multi-character string literal swallowed the rest of the
# source, so every later error pointed at end-of-file), and nothing caught it
# because the old harness only printed the position for a human to squint at.
#
# Re-baseline deliberately, never to make a red test go green: if a fixture's
# expectation has to change because the compiler legitimately improved, change
# it in the same commit as the fix and say why in the message.
#
# ERR 102 = ENoLib, the original's "not implemented" path.  The remaining ERR
# rows are unimplemented features, not parser bugs:
#   t14       'array [..] of <type>' DECLARES and its constant-index element
#             access works now (CALC Stage 8): `b[1] := 2' stores TWO bytes, not
#             the whole ten-byte array, because a constant subscript folds
#             (index - lower bound) * element size into the address and the
#             expression carries the ELEMENT's width.  data=15 = b (10) + a (2)
#             ... plus the temporaries; the row moved ERR->OK when the width
#             landed.
#   t25       a string literal used where a 16-bit word is wanted
#   uierror   deliberate syntax error, pinned by the editor UI test
#
# The nine control-flow fixtures (t08 t09 t10 t11 t12 t13 t15 t27 t28) were
# re-baselined upward when they were rewritten to PRINT their result, so each
# has a .out file and is executed under qemu (run_com_exec.py) as well as
# compiled here.  Before that they assigned to a variable and fell off the end:
# they asserted that the compiler produced bytes, and nothing about behaviour.
# t13 also gained a second procedure, which is why it is bigger than the sum of
# its parts.  t08's data went 6 -> 7 because a CHAR variable joined the INTEGER.
#
# t02 t03 t05 t17 used to be ERR 102 as well: a multi-character literal was
# rejected because writeln had no string support.  They compile now, via the
# inline-string path (CALL wrtinl, then <length><chars> in the code stream -
# TPSRC8 pwrinlin / TPSRC4 xwrtinl), so their rows changed from ERR to OK and
# their code sizes went up by the literal's own bytes.
#
# RE-BASELINED for v-TP3-8086-LOWERING, when conditional branches and SETcc
# stopped being 386-only.  Nine rows moved, every one of them UPWARD, and every
# one of them by exactly the number of conditional sites in that fixture:
#
#   +1 per site.  A branch was 4 bytes (0F 8x rel16) and is now 5 (7x 03,
#   then the 3-byte EJMP).  A comparison VALUE was 5 bytes (0F 9x rel8, then
#   MOV AH,0) and is now 6 (B8 01 00, 7x 01, DEC AX).  So the deltas are
#   t09 +6 = 3 values + 3 branches, t10 +4 = 2+2, t11 +2 = 0+2,
#   t12 +4 = 2+2, t15 +2 = 1+1, t22 +2 = 0+2, t30 +1 = 0+1, t32 +3 = 1+2,
#   t33 +13 = 13 values.
#
# That arithmetic was CHECKED, not assumed: the site counts were counted out of
# the linked images (the same CMP AX,CX and CMP AX,0000 anchors and the same
# 7x 03 E9 shape that check_8086.py uses) and each row was only written after
# its delta matched its count.  Data sizes did not move at all.  The bytes
# themselves are pinned by check_8086.py, and the BEHAVIOUR is pinned by
# run_com_exec.py -- this row only says how big the code is.
#
# RE-BASELINED when the runtime was wired into the code buffer.  Every OK row
# changed by exactly +3 code and -256 data, and both numbers are correct:
#
#   +3 code  the prologue now emits MOV AX,<header offset> before
#            CALL TU_InitMem, because InitMem takes the header offset in a
#            register (B8 lo hi) rather than on the stack.  Previously the
#            prologue called offset 8, which is the hdrMax word - it only
#            "worked" because the runtime was not in the image at all.
#
#   -256 data  DataBytes() used to return dc, the ABSOLUTE end of the data
#            area, not a size.  dc started at 100H, so every program reported
#            256 more than it allocated - 260 for a program whose only data is
#            the two @@T1/@@T2 scratch words.  The field is documented as
#            "emitted data size in bytes", so 4 is the true size and 260 was
#            the bug.  It is a real correction, not a fit-to-the-test change:
#            the 6-byte rows are the fixtures that declare one global.
#
# ADDED for the BP displacement fix.  These two fixtures are the first with
# any frame access at all -- every earlier fixture put its variables in the
# DATA segment, addressed absolutely, so the whole [BP+off] path had zero
# coverage and a truncation there was invisible.
#
#   t27_localvar  five LOCAL variables, assigned and read back.  Locals are
#                 allocated downward from 0FFFEh and each access now costs 4
#                 bytes (mod=10 + disp16) where it cost 3 (disp8), so its code
#                 size reflects the fix rather than predating it.  Both
#                 encodings address the same place; only the rule for choosing
#                 between them changed.
#   t28_farparam  70 declared parameters; the call passes 16, which is the
#                 argument cap at the call site.  Under TP3's frame rule the
#                 LAST declared parameter is the one at BP+4, so p8 lands at
#                 BP+128 and p1 at BP+142 - the first offsets a disp8 cannot
#                 represent, since 80h is -128 and not +128.  Under the old
#                 code these two reads came from the wrong side of BP.  This
#                 fixture tests the ENCODING; it is executed too, but its .out
#                 carries only the deterministic sum of the two slots the
#                 sixteen pushed arguments land in (p55 + p70), never the
#                 stack garbage that p1..p54 read.  Do not read it as a claim
#                 that a 70-argument call works.
#
# RE-BASELINED for the case-label fix, and this is the one re-baseline in this
# file that is a CORRECTION rather than a new feature.  EmMovAxSp used to emit
#
#     8B 44 24 00      MOV AX,[SP]          <- 386 encoding, SIB byte
#
# which is 4 bytes.  [SP] is not encodable on the 8086 at all: mod=00/rm=100
# is [SI], and the SIB byte that 8B 44 needs did not exist until the 386.  The
# bytes were well formed, so every byte-level check passed, and fcml and qemu
# both DECODED it - as MOV AX,[SI+0x24h], because that is what it is.  Every
# CASE label test therefore loaded a garbage address, every comparison failed,
# and a case statement fell straight past its body.  It now emits
#
#     58 50            POP AX ; PUSH AX     <- 2 bytes
#
# which is observationally a peek.  t22 has two labels, so its code is exactly
# 4 bytes smaller: 96 -> 92.  The number moving is the point - the old size was
# the size of a wrong encoding, and a case fixture that is not executed cannot
# tell you that from its size alone.  t22 is executed (tests/run_com_exec.py).
#
# ADDED t29_readln: the first fixture that reads.  It needs the CHAR class to
# exist at all - see the note on TChar in Compiler.mod - so 7 data bytes where
# t19 has 4 (n is 2, c is 1, and the two are 2-byte aligned, so 4 + 2 + 1
# rounds up to 7) and 82 code bytes for the four runtime calls plus a literal
# char argument.  Its .out is compared byte for byte against qemu.
#
# RE-BASELINED for the procedure-skip jump.  t13, t27 and t28 gained exactly
# +3 code bytes: `E9 rel16`.  These are the only three fixtures that declare a
# PROCEDURE, and they are the only three rows that moved.
#
# The reason is a bug that only execution could find.  The declaration part is
# compiled BEFORE the main statement part, so a procedure's code lands between
# the program prologue and the main body - and nothing jumped over it.  A
# program with a procedure ran off the end of the prologue straight into the
# first procedure, which read its argument out of an uninitialised frame and
# returned to address 0000h.  t13_proc compiled, produced a plausible 53 bytes,
# and was never run, so the suite was green over a program that could not
# execute at all.
#
# The jump is emitted ONLY when a procedure or function is declared, which is
# why the other 27 OK rows did not move.  That condition is a lookahead over
# the source buffer, because the jump must be emitted before the declaration
# part but whether one is needed is only known after - see DeclaresProc in
# Compiler.mod for why the alternative (always emit it) was rejected.
#
#   t13_proc        53 -> 56
#   t27_localvar   122 -> 125
#   t28_farparam   123 -> 126
#   t31_procparam  66 -> 69
#
# t31_procparam is the fixture that proves the fix by running: it declares a
# procedure, calls it, and prints what the procedure wrote.  Before the fix it
# never halted at all.
#
# ADDED t30/t31/t32, all three now EXECUTED (not just compiled):
#
#   t30_forloop   `for i := 1 to 5 do s := s + i` printed 21, not 15.  The loop
#                 test was emitted AFTER the body, making it a post-test loop:
#                 the body ran a sixth time with i = 6.  The code size and the
#                 instruction bytes were both already correct - only the ORDER
#                 was wrong, and no byte-level check can observe an order.  The
#                 test now precedes the body, so 96 bytes both before and after
#                 this fix, which is the whole point: the number never moved and
#                 the behaviour did.
#   t31_procparam procedure + one parameter.  The non-termination above.
#   t32_forexit   `for` with `exit` in the body.  Two faults, both invisible to
#                 a size check: the loop's exits were patched to the position
#                 just past the body, which in a FOR is the STEP, so `exit`
#                 incremented the control variable and jumped back into the test
#                 - it did not exit; and the EXIT handler also emitted ADD SP,2
#                 while the loop's `done` label emitted it again, dropping four
#                 bytes off a stack that had two to give.  Exits are now patched
#                 at `done`, and the handler no longer touches the stack.
#   t33_cmpops   all six relational operators as VALUES, each with a true case,
#                 a false case and the equality boundary, plus one signed pair.
#                 Added while making the 8086 branch/compare lowering checkable:
#                 measuring which conditions the suite actually emitted showed
#                 that `=', `<>' and `<=' were never used in a comparison at all,
#                 because `writeln (a = b)` had no fixture.  Only `<', `>' and
#                 `>=' had coverage - and `>' vs `>=' had ALREADY been swapped
#                 once (bug 29), so a hole either side of the operators that
#                 were covered is the last place to leave one.  m := -1, n := -2
#                 makes the last line signed: unsigned, -1 > -2 is FALSE, so that
#                 one line is what tells SETG from a byte compare.
#
#   t36_argclobber eight lines of hand-derived output, added BEFORE the fix it
#                 covers: this row was written while the compiler still lost a
#                 computed argument, was proved red by running it, and its
#                 numbers did not move when the fix landed - the fix reorders
#                 bytes rather than adding them, so the same size came out of a
#                 different order.  A number that never moved and a behaviour
#                 that did is the same shape as t30 above.
#
#   t37_readbyte   added BEFORE the fix it covers, and its .out was derived by
#                 hand from the layout before the fix was written: `readln (b)'
#                 of a BYTE went through rdint, which stores a WORD - and the
#                 second byte of that word is the byte that FOLLOWS the
#                 variable, which in this fixture is `n'.  So `b' came out
#                 right and `n' was silently rewritten: 1000 appeared as 768
#                 (low byte zeroed) on line 1 and as 1023 (low byte set to
#                 FF) on line 2, which is what the pre-fix run printed, and
#                 what it was required to print before the fix was touched.
#                 Neither size here moved when the fix landed: rdint and
#                 rdbyte take the same argument the same way, so the dispatch
#                 chooses which entry answers without changing how long the
#                 call is.  The WIDTH of the store is asserted by execution
#                 (run_com_exec.py), not by this row - a size cannot see it.
#
#   t38_readbool   a boolean READ is refused, not misread.  TP3 errors 66
#                 ("I/O not allowed here", TPSRC8 prderrtp) and its runtime
#                 has no boolean reader at all - xrdreal, xrdchar, xrdint and
#                 xrdbyte exist; xrdbool does not.  This compiler used to
#                 accept it and dispatch to rdbool, which stores a WORD into
#                 the one-byte variable - the same overflow t37 pins for a
#                 byte, unobserved only because no fixture read a boolean.
#                 The position is the ')' after b: IoCall has parsed the
#                 whole argument, and the atom parser's Skip() has run, so the
#                 parser stands on the delimiter when IoCall dispatches on
#                 the variable's class.
#
#   t39_strvar     the first fixture with a STRING VARIABLE, and the first
#                 declared type bigger than a word that is not an error: `var
#                 s : string [10]' is 11 bytes - a length byte and ten
#                 characters, the layout TPSRC8's `string' type gives a
#                 variable (`INC BX / MOV varsize,BX', so n+1) - and DefVar's
#                 `size > 2' catch-all (still the answer for an ARRAY at its
#                 point of use) now exempts TString.  Assignment is a literal
#                 copied byte by byte: TPSRC8 asn2 sends a string through
#                 estcpl's string arm, `MOV CL,max_len ; CALL strstore', and
#                 this reproduces its observable result, truncation included.
#                 writeln(s)/write(s) route to a new runtime entry, wrstr
#                 (TPSRC4 xwrtstr without its field-width formatting), which
#                 prints the length byte's worth of characters and nothing for
#                 an empty string.  A global AND a local string are exercised,
#                 so the absolute and the [BP+off] address paths both have
#                 coverage, and the .out is compared byte for byte under qemu
#                 and Exec86.  t40_readln and t41_strassign extend the same
#                 ground: readln(s)/read(s) routes to a new runtime entry,
#                 rdstr (TPSRC4 xrdstr), which stops at CR/LF/^Z and truncates
#                 to the destination size, leaving the terminator pending for
#                 the readln wrapper; and `s := t' for two string variables
#                 routes to strstore (TPSRC2), pushed as both addresses (the
#                 literal path above is a compile-time copy of the same
#                 operation).  Still refused: s [i] indexing - ENoLib.
#
#                 t39's code size moved 215 -> 217 with the local-frame fix
#                 that t40 forced.  Locals used to take the PRE-decrement
#                 locFree as their base, so a local string started at BP-2 and
#                 its characters ran UP through BP, the saved BP and the return
#                 address: `readln(s)' into a local s stored "hello" over its
#                 own caller's return address and the program jumped into the
#                 string.  Locals are now top-anchored (base placed so the last
#                 byte lands on the top free byte), which leaves every INTEGER
#                 local byte-for-byte where it was (-2, -4, ...) but moves a
#                 string local down: t's base is now BP-6, and two of its byte
#                 stores that used to wrap to [BP+0]/[BP+1] and fit the disp8
#                 form are now disp16 - two bytes, hence 217.  See t40.

t01_minimal	OK	29	4
t02_writeln	OK	38	4
t03_inline_comment	OK	38	4
t04_var	OK	48	6
t05_own_line_comment	OK	38	4
t06_two_args	OK	52	4
t07_big	OK	102	6
t08_const	OK	76	7
t09_if	OK	195	6
t10_while	OK	151	6
t11_for	OK	144	6
t12_repeat	OK	137	6
t13_proc	OK	126	6
t14_types	OK	41	15
t15_label	OK	90	6
t16_str1	OK	42	4
t17_two_str	OK	45	4
t18_writeln_bare	OK	32	4
t19_int1	OK	42	4
t20_str3	OK	62	4
t21_mixed	OK	62	4
t22_case	OK	94	6
t23_str_empty	OK	36	4
t24_str_quote	OK	41	4
t25_str_as_value	ERR	102	48
t26_str_mixed_args	OK	58	4
t27_localvar	OK	256	6
t28_farparam	OK	153	8
t29_readln	OK	82	7
t30_forloop	OK	97	8
t31_procparam	OK	69	6
t32_forexit	OK	138	8
t33_cmpops	OK	404	12
t34_arith	OK	448	8
t35_not	OK	224	7
t36_argclobber	OK	492	12
t37_readbyte	OK	139	7
t38_readbool	ERR	66	659
t39_strvar	OK	217	15
t40_readln	OK	163	15
t41_strassign	OK	263	51
#   t42_multidecl   multi-name declarations in both spellings: `var a, b, c :
#                   integer', `procedure add3 (x, y, z : integer)' and
#                   `procedure mix (u, v : integer ; w : integer)' (TP3's
#                   grammar: names joined by ',', groups by ';'), plus the
#                   older `p : integer, q : integer' form.  data=12 is the four
#                   2-byte globals a,b,c,d plus the two @@T temporaries; the
#                   .out proves each name landed on its own slot.
t42_multidecl	OK	304	12
uierror	ERR	41	331
#   t43_codewindow  a program whose code exceeds the 4 KiB window between the
#                   end of the runtime and the data base (runtime + 1000h).  It
#                   must be REPORTED as TP3 error 98 (memory overflow); before
#                   Ebyte was bounded by dataBase it overran its own data and
#                   produced a corrupt image with no diagnostic.  Each of the 20
#                   writeln cases below embeds 240 bytes inline (wrtinl), so the
#                   overflow lands inside one of them at pos 4978.
t43_codewindow	ERR	98	4978
#   t44_strindex    s[i] read and write on a string, as a CHAR.  A STRING is a
#                   length byte at s[0] then the characters, so s[i] is the one
#                   byte at off+i; a constant index folds into boff exactly as
#                   an array's would, and r.cls drops to TChar so LoadAtom,
#                   Assignment and IoCall all treat it as one byte.  Only a
#                   constant index is accepted (a variable index is ENoLib, as
#                   it already was for an array).  data=16 is the global
#                   string[10] (11 bytes), the char c (1) and two @@T temps.
#                   The fix also had to drop ParseAtom's `r.boff := 0` after
#                   ParseVar, which had been discarding every subscript.
t44_strindex	OK	258	16
#   t45_strindex_read  readln (s[i]) reads one character into position i; the
#                   reader classifies by arg.cls (TChar for an indexed string)
#                   and pushes off+boff.  data=15 is the global string[10]
#                   (11 bytes) plus two @@T temps.  t45_strindex_read.in feeds
#                   'X' then 'Y'.
t45_strindex_read	OK	134	15
#   t46_strindex_var  s[i] with a VARIABLE index, both directions and in both
#                   registers.  ParseSub used to accept a constant only (ENoLib
#                   otherwise, exactly as for an array), because off+i is a
#                   run-time value; now it evaluates the index, then puts the
#                   element's address in DI (LEA DI,[base] / ADD DI,AX), and
#                   r.kind drops to 5 so LoadAtom reads [DI] and Assignment
#                   PUSHes DI across its right-hand side.  This fixture was red
#                   (ERR 102) before that.  It covers a global string, a LOCAL
#                   string (the 8D BE disp16 LEA form), a computed index (i+1),
#                   a subscript as a procedure argument, and `g[i] := h[j]`
#                   where BOTH sides are indexed - the case that proves the
#                   destination is saved across the source.  data=31 is g and h
#                   (string[10] = 11 each), i and j (4), c (1), and the two @@T
#                   temporaries (4).
t46_strindex_var	OK	578	31
#   t47_strindex_var_read  readln (g[i]) with a variable i.  The reader needs
#                   the computed address, not a folded off+boff, so IoCall
#                   pushes DI (57) instead of LEA AX,[off] in that case.
#                   data=15 is the global string[8] (9 bytes) plus i (2) and the
#                   two @@T temporaries (4).  t47_strindex_var_read.in feeds
#                   'X' into g[3] then 'Y' into g[6].
t47_strindex_var_read	OK	188	15
#   t48_strcmp             string = <> < <= > >=, both operands string
#                   VARIABLES, i.e. string-vs-string (a string SUBSCRIPT s[i] is
#                   a CHAR, so s[i] = c would be a scalar compare).  Five
#                   blocks, and each block weights the six operators
#                   1,2,4,8,16,32 for =,<>,<,<=,>,>= so the printed sum says
#                   exactly which ones held: 41 equal, 14 left < right, 50 left
#                   > right.  The weighting is not decoration: with a plain +1
#                   every unequal pair sums to 3, because exactly two of the
#                   four ordering tests hold, so 3,3,3,3 was reported while
#                   every ordering comparison was INVERTED.  The last block
#                   sets b := '' - the empty string - which drives cmpstr's
#                   min(len)=0 arm.  code=1905 is 5*6 branch compares plus the
#                   6 value compares of the final writeln; data=24 is a and b
#                   (string[8] = 9 each), n (2), and the two @@T temporaries (4).
t48_strcmp	OK	1905	24
#   t49_strcmp_lit         the same operators with a string LITERAL in one or
#                   both positions.  A literal has no storage and the image
#                   carries no initialised data, so PushStrAddr emits it inline
#                   in the code stream (JMP over <len><chars>, then the LEA that
#                   is its address); this pins that path.  Block 3 has both
#                   operands literal, including '' on both sides; the last line
#                   takes the empty literal's relation as a VALUE.  data=15 is s
#                   (string[8] = 9), n (2), and the two @@T temporaries (4).
t49_strcmp_lit	OK	1006	15
#   t50_strcmp_type        s = 'a' where s is a string: a one-character literal
#                   is a CHAR constant in ISO Modula-2, not a string, so this
#                   mixes TString with TScalar and ParseCmp rejects it.  (''
#                   does NOT: the zero-length string is a string, which is why
#                   t49 may compare against it.)  Pins the new mixed-operand
#                   guard; ETypeErr at the comparison.
t50_strcmp_type	ERR	56	600
#   t51_strcat             string concatenation, `a + b', where its result can
#                   go: a writeln argument, an assignment source, and then an
#                   operand again.  The pairings are var+var, literal+var,
#                   var+literal, var+char and char+var - every shape a string
#                   operand admits except two CHARs, which t53 rejects.  data=
#                   1842 is a,b,c (string[12] = 13 each), ch (1), the seven
#                   scratches (7*256), the three CHAR operands ('!', and ch in
#                   a+ch and in ch+a) at 2 bytes each, and the two @@T
#                   temporaries (4).
t51_strcat	OK	537	1842
#   t52_strcat_nest        nested concatenations - left-associative, so `a+b+'!''
#                   is two occurrences and two scratches - plus a concatenation
#                   as a comparison operand and a string ELEMENT as the left
#                   operand of `+'.  data=1574 is a,b (13 each), the six
#                   scratches (6*256), the four CHAR operands ('!', '<', '>',
#                   a[2]) at 2 bytes each, and the two @@T temporaries (4).
t52_strcat_nest	OK	501	1574
#   t53_strcat_type        `'a' + 'b'': two CHARs under `+' is a type error.  A
#                   CHAR is a string operand, so `'a' + b' concatenates; BOTH
#                   operands being CHARs, with no STRING on either side, is the
#                   rejection.  This is the one shape the BinOpEmit hook used
#                   to miss - it tested for a STRING operand only, so two CHARs
#                   fell through to integer addition and silently produced
#                   CHR(195).  ETypeErr at the `+' (pos is where the token
#                   after the right operand starts, as t50's is).
t53_strcat_type	ERR	56	663
#   t54_strcat_strnum       s + 1: a STRING operand makes `+' concatenation,
#                   and both operands must then be strings or CHARs; a number
#                   is neither.  ETypeErr at the `+'.
t54_strcat_strnum	ERR	56	463
#   t55_strcat_overflow    128 characters read into a `string' and then
#                   `s := s + s' asks for 256, past the 255 the scratch can
#                   hold: TP3's xconcat raises "string too long" (error 16),
#                   and the runtime leaves through INT 21h AH=4Ch with AL=16.
#                   The program therefore exits 16 - pinned by
#                   t55_strcat_overflow.exit, which is what turns "it stopped"
#                   into "it overflowed".  The .out stops at `read', before the
#                   `after' a truncating implementation would have printed.
#                   data=516 is s (the default string = 256), one scratch
#                   (256), and the two @@T temporaries (4).
t55_strcat_overflow	OK	126	516
#   t56_include            {$I t56_include.inc} - the include is expanded
#                   before parsing (ExpandIncludes), so FromInclude, which
#                   exists only in the .inc, is a real symbol here.  The .inc
#                   also carries a star-paren comment holding the text {$I} on
#                   purpose: the scanner has to read that as comment text, not
#                   as a directive, or the program breaks.  code=56 data=4 (the
#                   two @@T temporaries); the .out is `7', which is the
#                   INCLUDED procedure actually running, so this is not just
#                   "the name resolved".
t56_include	OK	56	4
#   t57_include_missing    {$I t57_this_file_does_not_exist.inc}: an include
#                   that cannot be opened is TP3 error 90 ("File not found",
#                   TPSRC10 cdincl errb) AT THE DIRECTIVE - not a silent
#                   swallow, which is exactly the bug this stage closes.
t57_include_missing	ERR	90	29
#   t58_include_nest       t58_include_a.inc contains a second {$I}.  TP3
#                   permits only one level of include (error 96, "Illegal
#                   nesting of include files", TPSRC10 cdincl), so the nested
#                   directive is refused rather than expanded.  The position is
#                   inside the spliced text, i.e. in expanded-buffer
#                   coordinates.
t58_include_nest	ERR	96	43
#   t59_typedconst         `FXMax : Char = 'G'' - CALC.PAS:111, the first CALC
#                   rung.  Scalar typed constants fold to an immediate but
#                   carry the DECLARED class, so `write (FXMax)' uses the char
#                   writer and prints G; a plain `X = 'G'' is TScalar and would
#                   print 71.  Integer and Boolean take the same path; Boolean
#                   also needs RdConst to read TRUE/FALSE, which it now does.
#                   A structured typed constant (set/array) is still ENoLib -
#                   it needs initialised storage this compiler lacks.
t59_typedconst	OK	65	4
#   t60_charcaret          `^M' and `#27' - CALC.PAS:113 is `EofLine = ^M'.  Both
#                   are unquoted CHARACTER constants, so ParseAtom must accept
#                   them as literals (not only RdConst in a declaration), or
#                   `write (^M)' would not compile.  The .out begins with the raw
#                   bytes 0D 1B, which is the proof they are characters and not
#                   the text "13"/"27"; the last two lines check the values
#                   (EofLine = ^M, Esc = 27).
t60_charcaret	OK	75	4
#   t61_setconst           `Numbers : set of Char = ['0'..'9']' - CALC.PAS:114.
#                   TP3's HYBRID set layout (coeur-tp-ocr 4.7.2): only the whole
#                   bytes covering the base range are stored, element e is bit
#                   (e MOD 8) of byte ((e DIV 8) - (base DIV 8)), high byte
#                   last.  A set cannot fold to a word, so its bytes go in the
#                   code stream behind a JMP (as string literals do) and the
#                   name becomes addressable; no `seg cs' is needed because a
#                   .COM's DS covers the code segment.  `in' with a compile-time
#                   element is answered at COMPILE time (TPSRC2 xsetin: AH > 255
#                   -> FALSE, else test the bit).  The .out is TRUE FALSE TRUE
#                   TRUE - the constant, an inline literal, and a two-range
#                   literal.  data=4 is the @@T temporaries; the set's 32 bytes
#                   are in the code stream, not the data area.
t61_setconst	OK	183	4
#   t62_enum               `Attributes = (Constant, Formula, Txt, ...)' -
#                   CALC.PAS:120.  Each enumerator is a constant holding its
#                   ordinal position; the TYPE is one byte and carries its
#                   bounds 0..n-1, which sizes `set of Attributes' to ONE byte
#                   (vs 32 for `set of Char').  A named constant may now be a
#                   set element (RdConst resolved identifiers), which is what
#                   `[Constant, Formula]' needs.  .out TRUE FALSE TRUE FALSE.
t62_enum	OK	187	5
#   t63_record             `CellRec = record ... end' - CALC.PAS:126.  Fields
#                   are non-compacted and juxtaposed; CellRec is 1 (set of
#                   Attributes) + 71 (String[70]) + 6 (Real) + 1 + 1 (two
#                   0..20 subranges: both bounds in 0..255 -> ONE byte) = 80.
#                   data=84 = 80 + the two @@T temporaries, so this row pins
#                   the layout to the byte.  Subrange sizing is part of it.
#                   Field SELECTION is still a loud error (the next increment).
t63_record	OK	57	84
#   t64_arrays             the 2-D array TYPE and an array TYPED CONSTANT -
#                   CALC.PAS:133 and :137.  Ranges are row-major, last fastest,
#                   both kept in an ArrRec the symbol points at.  Sheet is
#                   7*21*80 = 11760; XPOS is 7*2 = 14 and, like a set, its
#                   bytes are CODE-RESIDENT (behind a JMP) because an array
#                   constant cannot fold - so data=11764 is Sheet + the two
#                   @@T temporaries, with XPOS in the code stream.  Compile
#                   only: the image is ~16 KB and the exec harness's boot
#                   sector reads 8 KB (see the layout/execution stage).
t64_arrays	OK	67	11764
#   t65_array_access       array ELEMENT and record FIELD access - the width
#                   matters.  `v[1] := 11' folds (1 - 1) * 2 into the address
#                   and writes TWO bytes; `v[3] := v[1] + v[2]' reads two and
#                   writes a third; `r.A := 5' adds the field's offset and takes
#                   its width.  .out is 33 then 12, so a wrong scaling, a wrong
#                   lower-bound subtraction or a wrong store width all show up.
#                   data=16 = v (8) + r (4) + the two @@T temporaries.
t65_array_access	OK	101	16