TP3/CALC-COMPILE.md

CALC-COMPILE — make the TP3 compiler accept and compile CALC.PAS

The goal of this line of work is narrow and stated as a verdict:

shell/compiletest returns OK for Resources/TP3/CALC.PAS, and CmdCompile writes a .COM.

It is deliberately not the same goal as CALC-PORT.md (porting MicroCalc to native GNU Modula-2 on top of Term.mod). That is a separate piece of work and a separate session; nothing here changes it, and nothing here depends on it.

Everything below is measured against the tree at tag v-TP3-INTERRUPT-RESTORE (2ae00d1) unless it is marked inferred or unknown.

---

0. Scope decisions, fixed before any code

1. Target the TURBO.COM dialect, i.e. the 6-byte binary REAL. CALC.PAS says so itself: it will not build with TURBO-87.COM without an 8087, and its help text notes that "Sqrt, Sin and friends are not implemented in the BCD compiler". So this is a TURBO.COM program and REAL is the 6-byte format of RESUME-TP3.md §2 ("REAL (6 octets)"), not the 10-byte BCD variant. Implement exactly one real format.

2. Compile first, run second. The gate is the compiler's verdict, not a working spreadsheet. A construct may be incomplete only if it is loudly incomplete (Err (ENoLib)); it may never be accepted and mis-compiled. This project has already shipped that bug once. One of the two cases below is now closed (Stage 2); the other is not:

   • var parameters are silently accepted and passed by value — ProcFunc drops the var (DropB (MatchKey (tok)), comment "VAR parameter recorded as value in this milestone"); writeln (g) after q (g) prints 7, not 42. Ten CALC routines take var parameters.
   • {$I CALC.INC} was silently swallowed as a comment, so CALC.PAS without its include compiled green (program p; {$I part.inc} begin halt end. → OK code=32 data=4, part.inc never opened). Closed at Stage 2: the include is expanded before parsing and an unopenable file is error 90, not a comment.

The var-parameter case is still open and must be closed by implementation, or by an explicit Err until it is (Stage 10).

1. One fixture and one ratchet per step. Every stage lands with a fixture that is provably red before and green after, plus a move of the ratchet (§1). Nothing is "done" on the strength of a compile that a human eyeballed.

---

1. The measuring device: the CALC ladder

A 1,763-line program (182 + 1,581 lines) that stops on the 111th line gives no sense of progress unless "how far did we get" is a number in a test. Make it one.

Implemented (Stage 1, 2026-10-19) — tests/fixtures/calc_ladder.tsv plus tests/calc_ladder.sh, run by run_all.sh as CALC ladder. Each row names a program and gives the exact verdict in the same shape as tests/fixtures/expected.tsv:

CALC.PAS   ERR   <errno>   <pos>

The script stages a copy of the named program — and of the companions that sit beside it, so CALC.INC is already there for Stage 2 — into tmp/calc_ladder/, runs the freshly built compiler on it, and compares. It does not build the compiler itself: it calls tests/run_compile_tests.sh --build-only, which is the one recipe that freshness-checks compiletest, so the ladder cannot become the second staleness test that drifts from the first.

The copy is deliberate: the include (Stage 2) resolves relative to the including file, so CALC.INC has to be beside CALC.PAS in the staged tree, and the row then measures the compiler rather than an edit-in-place of Resources/TP3. It is not a fixture in tests/fixtures/*.pas (which would enter the compile/COM/exec matrices and need a second copy of CALC.PAS kept in sync).

Each stage updates the row; the row may only move forward. Two traps are written next to the file itself:

• pos is not a file offset. LoadFile collapses CRLF and lone LF to a single CR, so pos indexes the normalised buffer. CALC.PAS is 11,241 bytes on disk and 11,059 bytes normalised; the reported pos 7791 is file byte 7901. Every expected value in the ladder must be computed in normalised coordinates. Once {$I} lands, the buffer is CALC.PAS with the directive replaced by CALC.INC, so all downstream positions shift again — which is exactly why this must be a computed number, not a remembered one.
• Nobody edits the ladder row without editing the fixture in the same commit, per the repo's re-baselining rule.

Current rung (measured today, normalised position):

position	blocker
10350	procedure Center(S : AnyString) — a string value parameter, INSIDE CALC.INC

Rungs behind it (now passed):

was	blocker	done by
7791	FXMax : Char = 'G' — scalar typed constant	Stage 4 (scalar)
7791	EofLine = ^M — caret character constant	Stage 3
7972	Numbers : set of Char = ['0'..'9'] — set typed constant	sets, increment 1
8098	Attributes = (Constant,…) — enum; and SetOfAttri = Set of Attributes	Stage 5 (enums)
8362	CellRec = record … end — record type	Stage 7 (record types)
8705	Cells = array['A'..'G',1..FYMax], Sheet : Cells, XPOS : array[…] = (…)	Stage 8 (declarations)
9202	MCFile : file of CellRec — the file type, the whole var block, and the {$I} expansion	Stage 13 (file types)

Rungs ahead:

position	blocker
10350	a string value parameter, then the rest of CALC.INC: file operations, indexing, with, pointers, var params, reals, string builtins, CRT, recursion

Corrections the measurements force, worth stating plainly because the stage list below was written before them:

• The include (Stage 2) does not move the rung. It is at normalised 9404, past the stop, so Stages 3-4 had to happen before the include is ever reached.
• 7791 → 8036 in one stage was optimistic. CALC.PAS:114, Numbers : set of Char = ['0'..'9'], is a typed constant whose type is a set, and it comes before the enumeration at 8036. Sets had to go first, and now they have — the compiler stops at 8098, on the enumeration. The measured ladder is the authority; the stage numbering below is the original plan, not the dependency order.

---

2. The census — what CALC actually needs

Counts are from CALC.PAS + CALC.INC with comments and string literals stripped.

2.1 Type and language constructs

construct	where	status today
{$I CALC.INC}	CALC.PAS:150	done (Stage 2) — expanded before parsing; t56/t57/t58
typed constants (X : T = v) — scalar	CALC.PAS:111	done (Stage 4) — declared class kept; t59_typedconst
typed constants — set	CALC.PAS:114	done (sets, increment 1) — code-resident bytes; t61_setconst
typed constants — array	CALC.PAS:137; CALC.INC:777	ERR 102 — needs initialised storage
lexical ^M, #nn	CALC.PAS:113	done (Stage 3) — t60_charcaret
enum type (Constant,Formula,…)	CALC.PAS:120	done (Stage 5) — ordinals; bounds carried; t62_enum
subrange types 'A'..'G', 0..20, string[70]	CALC.PAS:117,119,130	OK
set of Char / set of <subrange>	CALC.PAS:114	type + sizing done (hybrid bytes)
set of <enum>	CALC.PAS:121,127	sizing done (enum bounds → 1 byte for Attributes)
set constructor [a..b, c], in (compile-time)	t61_setconst	done — folding only
set in (run-time), +, *, =/<>, assignment, set variables	47 × in, 6 × + [, 2 × *	ENoLib — next sets increment
record + field select Sheet[FX,FY].CellStatus	CALC.PAS:126	type done (Stage 7) — CellRec = 80 bytes; field SELECT is next
with	13 sites	after field selection
2-D array array['A'..'G',1..FYMax] of CellRec	CALC.PAS:133	type + variable done (Stage 8) — Sheet = 11760
array typed constant XPOS : array[…] of Integer = (…)	CALC.PAS:137	done (Stage 8) — code-resident
array element access b[i] (constant index), r.f	t14, t65	done — width on the expression
array element access with a VARIABLE index Sheet[fx,fy], with	13 with sites	ENoLib — scaled addressing next
array indexed by an enum type	CALC.INC:773,927	ERR 41
pointers ^Pages, New, Dispose	CALC.INC:579,587,639,690	ERR 41
var parameters	10 routines, 14 occurrences (e.g. CALC.INC:765,979,995,1036)	silently by value
self-recursion	Fact — Fact := I * Fact(I - 1), CALC.INC:747,754	ERR 1 at the (
mutual recursion via forward	Expression fwd CALC.INC:742 ↔ Factor calls it at 820,932	forward parses; definition untested
forward definition repeating only the name	CALC.INC:1036 (params commented out)	to check
nested procedures / functions	DisplayMessage in Help; Fact/Factor in Evaluate	parses OK
local type/const/var sections in a nested function	CALC.INC:767-778	ERR 41/ERR 102
case labels ^E, ^X, ^J, #27, comma lists	CALC.PAS:169, CALC.INC:91,1200,1567	comma lists/^X/# unknown
file of CellRec, text	CALC.PAS:144, CALC.INC:582	types done (Stage 13) — operations next
lexical #27 and ^M char constants	many	ERR 41 at the #/^
write/writeln/read with a leading file argument	CALC.INC:562,625	not implemented

Not used by CALC, so explicitly not needed: downto, goto, absolute, shr/shl, packed, Pos, Concat, Round, Trunc, Frac, Ord.

2.2 Identifiers used but not declared in the source

This is the exact builtin surface. strPool/strOff/strLen are compiler tables, so this list is also the KProc/KFunc work list.

category	builtins (count in CALC)
present today	write 41, writeln 5, read 15, readln 1, halt 1
strings	length 19, copy 5, delete 3, insert 1, str 3, val 5
ordinal	chr 5, upcase 12, succ 5, pred 1
reals	ln 5, exp 3, abs 3, sqrt 2, sqr 1, sin 1, cos 1, arctan 1, int 1, str/val above
heap	new 1, dispose 1
files	assign 5, reset 3, rewrite 2, close 4, endoffile 5, ioresult 1
CRT	gotoxy 25, lowvideo 16, normvideo 16, clreol 10, clrscr 6, keypressed 3, delay 1, kbd (8 × Read(Kbd,Ch))
directives	{$I CALC.INC} (include), {$I-}/{$I+} (2), {$A-} (1, harmless/ignored)

Also needed by name for the declarations to resolve: predefined types integer, char, boolean, real, string, text, file, and the predefined constants true/false (both work today).

---

3. Structural blocker: the memory layout is inverted

This is not a feature; it is a hard prerequisite. CALC's code is 16,560 bytes (§3.1, measured) and this port refuses to emit more than 4,096. It has to be settled as one of the first things, not "before the fifth stage" — until it moves, every later stage can only be developed on fixtures a fraction of CALC's size, and the ladder cannot advance past the first few rungs.

What this port does today. pc starts at rtSz (773) and dataBase := rtSz + 1000H (4869). Code occupies [rtSz, dataBase) and data occupies [dataBase, …). The data sits above the code, so the enforced limit is code ≤ 4 KiB, reported as TP3 error 98 by Ebyte and pinned by t43_codewindow (v-TP3-CODEWINDOW). MaxCode is 24,000, so the buffer is not the constraint — dataBase is.

What the original does. TPSRC7:81-82:

	MOV	pc,#$2D7C	;PC: start of code
	MOV	dc,#$0240	;DC: start of file list

pc (the code position) starts at $2D7C = 11,644 and dc (the data counter, TPSRC7:1286-1287, vardef2 uses AX := dc as the global's offset) starts at $0240 = 576. That is the opposite orientation: data low and growing up, code above it and growing up. Inferred consequence: in the original the binding limit is data running into the code base, not code running into the data. That is consistent with the original having a runtime measured in hundreds of bytes while reserving ~11 KiB between $0240 and $2D7C.

Why CALC makes this binding. Measured data budget:

item	bytes
Sheet : array['A'..'G',1..21] of CellRec, 147 cells × 80	11,760
CellRec = set of Attributes 1 + String[70] 71 + Real 6 + DEC,FW 1+1	80
XPOS : array['A'..'G'] of Integer = (…) (typed const)	14
Line : string[100], FileName : string[70]	101 + 71
Help.Buffer : ^Pages with Pages = array[0..200] of string[80], New (Buffer) (CALC.INC:579,587,639)	201 × 81 = 16,281 on the heap

So ≈ 12 KiB of globals plus ≈ 16.3 KiB of heap, on top of code and stack, in one 64 KiB segment. MaxCode = 24,000 gives code room; the layout is what has to change.

This question is now closed — see §3.1, which measures the original's output directly. What remains open is which of the two candidate fixes below to implement, and that is a decision for the session that does the work, not an unknown.

Method: read the .COM write path in TPSRC7 from copyrt and the cdptr/cdbegpt/cdfoff handling through the MOV AX,dc at TPSRC7:1286, and cross-check against RESUME-TP3.md §3.1 (program skeleton) and §3.4. Resources/turbopascal3source/TP3/ is the ground truth by project rule; when the book and the disassembly disagree, the disassembly wins. Do not decide this from our dataBase constant and a plausible story.

The two candidate fixes, for reference, once the question is closed:

• Match the original: data at a fixed low base (dataBase := rtSz), code at a fixed higher base, code unbounded above. Cheap, faithful, one orientation change — but wastes the gap and needs a real data-window number.
• Dynamic data base: emit global addresses as fixups and resolve them once the final code size is known (FixUp kinds already exist on the Runtime side, .def comment "FixUp, kind 2"). More correct, more invasive: every emitter that bakes a DS offset has to register it.

Either way t43_codewindow and the Ebyte check must be re-baselined deliberately in the same commit as the change, with the reason in the message.

Cross-check worth making while you are in there: the original's global overflow raises $62 = 98 ("Memory overflow", TPSRC7:1286-1288), which is the same number our Ebyte uses, but CALC.PAS's own banner warns about "Compiler Overflow - Error #99". If 98 and 99 are two different limits — data into code vs. something else — the banner is telling us which one CALC hits and which one the 'C' (.COM) workaround moves. That is cheap evidence and it bears directly on the fix.

3.1 Reference measurements (resolved 2026-10-17)

Compiled on a real DOS (dosemu) with the original TURBO.COM, from a directory holding CALC.PAS, CALC.INC and CALC.HLP, using the .COM destination (O, C, Q, C, Q) exactly as CALC.PAS's banner instructs. A six-line HELLO program was compiled the same way as the baseline. The two artifacts are sitting in Resources/TP3/ for analysis and are deliberately not committed — they are derived from the proprietary TURBO.COM; the recipe above regenerates them, and the numbers are what this document keeps.

The compiler's own statistics line:

	HELLO	CALC
lines	6	1,763
code	0005 paragraphs = 80 B	040B paragraphs = 16,560 B
code free	0D26 par = 53,856 B	0920 par = 23,360 B
data	0002 paragraphs = 32 B	02F0 paragraphs = 12,032 B
data free	0FD9 par = 64,912 B	0CEB par = 52,400 B
stack min / max	16,384 B / 655,360 B	16,384 B / 655,360 B
.COM file	11,410 B	27,901 B

Image layout (both files share it):

• File offset 0 is a 3-byte entry jump E9 4A 2C → address 0x2D4D (= file 0x2C4D; the .COM offset-to-address bias is 0x100, the same constant as this port's LoadBias). So the fixed TP3 runtime is file [0, 0x2C4D) = 11,341 bytes, identical in both programs.
• At 0x2D4D: call TU_PARAGRAPHS, then the 20-byte program header (options 0006, cs 0813, ds 11D7, …), then mov bp,sp, call TU_TAILLE_CODE, the code-size word (0x4092 for CALC = 16,530, i.e. the reported 16,560 minus the 30 bytes of preamble), the SAUT_PRINCIPAL address (0x2D6D in both), and jmp PRINCIPAL.
• Typed constants live in the code stream, exactly as RESUME-TP3.md §3.14 says. Located byte-for-byte in CALC.COM: FXMax = 'G' (47) at 0x2D70; Numbers : set of Char = ['0'..'9'] as 32 bytes with FF 03 in bytes 6-7; XPOS as the seven words 03 00 0E 00 19 00 24 00 2F 00 3A 00 44 00 at 0x2D91; and StandardfunctionNames (the nested function's string[6] array) as length-prefixed 'ABS', 'SQRT', … around 0x4700.

Consequences for this port:

1. Q1 is answered. The original keeps the data area below the program code, so the binding limit is data running into the code base — the exact opposite of this port, whose dataBase := rtSz + 1000H caps code at 4 KiB. CALC's code is 16,560 bytes, so the port cannot emit it at all today; this is a hard prerequisite, not a nice-to-have.
2. MaxCode = 24,000 is not the binding constraint. 16,560 + 773 (our runtime) = 17,333, comfortably inside 24,000. It is dataBase alone that must move, and the fix has to be an orientation/layout change rather than a bigger buffer — which is what t43_codewindow was built to police.
3. The §3 data budget is confirmed, not inferred. Reported data is 12,032 B against a computed 11,760 B for Sheet alone (147 × 80 B CellRec), so the 80-byte CellRec sizing is right and the rest (Line, FileName, the file variables, scalars) accounts for ~272 B.
4. TP3's memory model has code and data in separate address spaces (cs 0x0813 vs ds 0x11D7 in the header, and separate "free" figures). A .COM collapses them to one segment, so we have to choose one contiguous layout; the measurements bound what we must allow: ≥ 16,560 B of code and ≥ 12,032 B of data, with 16,384 B of stack and a heap large enough for Pages (16,281 B, §3).
5. The runtime is 11,341 bytes in the original. Ours is 773 B. Not needed for this goal, but it explains where the original's fixed pc := $2D7C / dc := $0240 came from, and why TPSRC7:81-82 looks the way it does.

Feasibility, now checkable. A .COM is one 64 KiB segment holding [runtime][code][data], with the heap growing up and the stack growing down out of what is left. Using the measured figures:

	runtime	+ code	+ data	left for heap+stack	after Pages (16,281 B)
original	11,341	16,560	12,032	25,603	9,322 for stack
this port	773	16,560	12,032	36,171	19,890 for stack

So the goal is arithmetically reachable, and the original proves it is reachable with 10,568 bytes less room than we have — our runtime is that much smaller. There is no capacity reason to doubt the layout fix; the only question is which of the two orientations to implement. The same table shows MaxCode = 24,000 is fine with 7,440 to spare, and that TextLimit's 488 bytes of slack (§5) is the one genuinely tight number in the whole budget.

Still open from this experiment: whether memory-mode compilation of CALC reports "Compiler Overflow #99" as the banner warns. That is one more run of TURBO (step 1 of the banner, R instead of the .COM path) and it is the only remaining piece of the 98-vs-99 evidence.

Not resolved by these measurements: the meaning of the two header words after ds (the book calls them code and globales; they read 730/39 for HELLO and 1760/789 for CALC, which match neither the reported code/data nor each other). They are not the code and data sizes, so the book's field list should not be trusted here — the statistics line and the file layout above are the authoritative numbers.

---

4. Ordered stages

There are two parallel tracks, and it is worth being explicit that they are parallel:

• The ladder track (Stages 1-15) is front-end work. It advances the error position in CALC and needs no memory-layout change to be developed or verified — every feature can be exercised on a fixture far smaller than 4 KiB of code.
• The layout track (Stage 16, §3) is the only thing that stops the compiler from emitting the whole program once the front end accepts it. It does not block the ladder, but it is a hard prerequisite for the goal as stated, and it changes dataBase/t43_codewindow — so it belongs to one commit of its own, with the re-baselining reasoned in the message.

Ordering rule within the ladder: cheapest-and-most-independent first, then the ladder order (each stage removes the blocker the previous one exposed).

Session state — where to resume

Last touched 2026-10-19. Stages 1-4 are landed — the measuring device, the {$I} include, the lexical character constants, and the scalar typed constant. The ladder row now sits on sets.

• HEAD ce7e8cd (the plan) plus the Stage 1, 2 and (this one) 3+4 commits. Nothing pushed; origin/master is behind.
• Stage 1 (the ratchet) is landed: tests/fixtures/calc_ladder.tsv + tests/calc_ladder.sh, wired into run_all.sh as CALC ladder. The row was proved red first and may only move forward; it has moved once: ERR 1 7791 → ERR 102 7972.
• Stage 2 ({$I file}) is landed. ExpandIncludes resolves includes as a pre-pass (not in Skip, because DeclaresProc's lookahead rewinds srcPos), Compiler.SetSource gives the compiler the source path so an include resolves beside its including file, and the errors are TP3's own: 90 file-not-found, 96 illegal nesting. Fixtures t56_include (OK, and its .out proves the included procedure runs), t57_include_missing (ERR 90), t58_include_nest (ERR 96). TextBuf.InsertStr is the new bulk, capacity-checked paste.
• Stage 3 (^X/#nn) and Stage 4 (scalar typed constants) are landed. RdConst reads ^M and #nn, ParseAtom accepts them as literals, and DefConst accepts name : Type = value for a scalar type and keeps the declared class. Fixtures t60_charcaret and t59_typedconst. The scalar typed-constant red proof is the interesting one: dropping the class keeps the compile matrix green at the same OK 65 4 and only execution sees 71 for 'G'.
• Sets, increment 1, are landed — the hybrid type, the constructor, set typed constants, and compile-time in. Fixture t61_setconst (.out TRUE FALSE TRUE TRUE), and the storage decision is recorded in Stage 6: a typed constant's bytes are emitted in the code stream behind a jmp (as string literals already are), addressable through DS because a .COM has one segment — no seg cs, which is the single divergence from the original. Still ENoLib: run-time in, set variables, +/*/=/<>, assignment.
• Enumerations are landed (Stage 5) — ordinals 0..n-1, one-byte type, bounds carried so set of Attributes sizes to one byte. Fixture t62_enum. RdConst now resolves a named constant, which set literals and case labels need.
• Array TYPES, array VARIABLES and array TYPED CONSTANTS are landed (Stage 8, declarations half) — multi-range array types with row-major sizing stored in an ArrRec (Sheet = 11760), globals of array type, and XPOS : array[…] of Integer = (…) emitted code-resident like a set. Fixture t64_arrays (compile-only: its ~16 KB image is past the exec harness's 8 KB boot-sector read). t14 re-baselined: the array DECLARES now; the refusal moved to element access.
• File TYPES are landed (Stage 13, first half). text and file of T; a file variable is our control block (FileVarSize = 4). Fixture t66_files. This is the step that carried the compiler inside CALC.INC: the whole var block passed and the {$I} expanded, so the rung jumped from 9202 to 10350, where the first blocker is a string VALUE parameter in a nested procedure. File OPERATIONS (Assign/Reset/…, read/write with a file argument) are the next increment and are loud until then.
• The ladder now stops at ERR 102 at 10350 — procedure Center(S : AnyString) in CALC.INC, a value parameter wider than a word.
• One surprise on resuming: the working tree was found holding the nonvacuity script's frame-rule mutation of shell/Compiler.mod (the locFree := 0FFFEH / pre-decrement-base revert), i.e. a mutation from a tests/nonvacuity.sh run that the trap did not restore — presumably killed before the restore. It was reverted with git checkout -- shell/Compiler.mod before anything was measured. Worth knowing: the mutation's whole shape is byte-for-byte the same for INTEGER locals, so the compile matrix would have been green and only t40_readln (and later CALC) would have noticed.
• Verified baseline, run on this commit: ./tests/run_all.sh → OVERALL: ALL PASS, compile matrix 67/67, CALC ladder 1/1 at ERR 102 10350, 58 .COM linked and 56 executed under both qemu and Exec86 (t64_arrays is compile-only: its image is past the 8 KB boot-sector read).
• tests/nonvacuity.sh: re-run after this commit's cases (the set membership bit among them); see the commit message for the count. It is not in the default run_all.sh and must be run manually after touching any check.
• Still present and deliberately untracked: Resources/TP3/CALC.COM and Resources/TP3/HELLO.COM, the two reference binaries used for §3.1. They are derived from the proprietary TURBO.COM; do not stage them. The recipe and the numbers are in §3.1, which is what this document keeps.
• Corpus for later, already in the tree (untracked): Sources/Dezip/ holds 5,887 files, of which 4,919 are .PAS — plus 122 .EXE, 53 .OBJ, 26 .TPU and a SWAG collection (swag9702, swag9708, swag-pascal-master, …). Sources/ is a user directory and is never staged; it is here as test material only. Two things it enables, neither of which this plan currently has:
  1. A population metric — how far does the compiler get across thousands of real programs, not one. That is a far stronger regression signal than the CALC ladder alone, and it would have caught bug classes that a single hand-written fixture cannot.
  2. Dialect triage — not all of it is TP3. Expect TP1/TP2/TP4, DOS interrupt units, and units (.TPU) this compiler has no linker for. Any batch driver must report "rejected" as a result, not as a failure, or the corpus will look like a catastrophe rather than a baseline. Do this after the ladder, not before: measure the baseline once, so later stages can be shown to move it. A first pass needs a batch driver that feeds compiletest a file list (it already reads filenames from stdin, one per line) and tallies (verdict, errno) — cheap, and it turns the corpus into a number the moment it exists.
• Cheap evidence still missing (Q6): one memory-mode run of TURBO in dosemu to see whether CALC reports "Compiler Overflow #99" as its banner warns. The .COM path succeeds; the memory path was never tried.
• The one decision not to defer past the first sitting: which candidate fix to implement for §3 — match the original's orientation, or a dynamic data base with fixups. Everything else in the stages below is mechanical.

Next session

The next rung is an ENUM. The ladder stops at ERR 41 8098 on Attributes = (Constant, Formula, Txt, OverWritten, Locked, Calculated): a type whose definition is a parenthesised list of identifiers, which ParseType has no arm for. Land the enumeration type next (Stage 5), then the set-over-enum lines at CALC.PAS:121,127 follow immediately, and the rest of the set operations (run-time in, set variables, +/*/=/assignment) alongside.

The storage decision that sets needed is settled and recorded (Stage 6): a typed constant's bytes live in the code stream behind a jmp, addressable through DS; no seg cs, because a .COM is one segment. That is the same decision the enum-indexed array of strings (CALC.INC:767-778) and XPOS will use, so it does not need re-litigating.

Stage 1 — the ratchet (§1). DONE. tests/calc_ladder.tsv + tests/calc_ladder.sh, wired into run_all.sh; proved red against 7792 before it was set to 7791. It also resolved Q4 in favour of staging copies in tmp/calc_ladder/ rather than teaching the compile matrix about companion files.

Stage 2 — {$I file} include. DONE.

Implemented as a pre-pass, not in Skip, and that is the one design point worth recording. Skip is called by lookahead routines (DeclaresProc, PeekKw, KwAhead) that save and restore srcPos; splicing inside Skip runs once during the lookahead and again for real, and the second pass sees the first splice's text and reports error 96 (and a splice grows the buffer, which a rewind cannot undo). So ExpandIncludes resolves every include in one forward scan before parsing, and the parser — including DeclaresProc's scan for a PROCEDURE keyword, which must see a procedure that lives only in the include — sees one finished buffer. The scan recognises what the lexer does (a quoted literal, then star-paren comments, then brace comments, then a brace directive), so {$I} written inside a comment stays inert (t56 depends on it).

• {$I <name>} is spliced at the directive (buffer grows, srcLen updated) in the expanded-buffer coordinates the ladder already measures in; {$I+} / {$I-} remain the I/O-check toggle (dirs.chk, CALC.INC:396,399).
• Path resolved against the including file's directory — the compiler now gets the source path through Compiler.SetSource, called by the three loaders. Extension defaults to .PAS when absent (TPSRC10 kpasext).
• An unopenable file is error 90 ("File not found", TPSRC10 cdincl errb) at the directive; a nested include is error 96 ("Illegal nesting of include files", TPSRC10 cdincl). Both measured, not assumed.
• {$A-} is in fact a real TP3 directive (TPSRC10:783, Absolute code) that TP3 accepts and this port ignores; the "not a TP3 directive" note was wrong. The rule that mattered is kept: an include can never fall through to the comment path.
• Fixtures: t56_include (+t56_include.inc, red 41 → green OK, and its .out proves the included procedure runs), t57_include_missing (red OK → ERR 90), t58_include_nest (+t58_include_a.inc, red OK → ERR 96). Q4 resolved: the compile matrix needs no companion-file notion, because the .inc simply sits beside the .pas in tests/fixtures/ and the include resolves there.
• The ladder does not move at this stage. CALC.PAS's include is at normalised 9404, and the compiler stops at 7791 — the typed constant of Stage 4 — so the include is never reached for CALC.PAS yet. Stage 2 is pinned by t56/t57/t58 until Stage 4 lets the compiler get to it; the rung moving is a Stage 4 event.

Stage 3 — lexical #nn and ^X character constants. DONE.

RdConst reads ^M (the upper-cased character minus 64, so ^@ = 0 and ^[ = 27) and #nn (decimal, via RdIntConst, so #$FF works too). ParseAtom's literal test had to admit ^ and # as well, or write (^M) in an expression would still be a syntax error — only a declaration goes through RdConst. Both spellings are marked as characters, so they are written by the char writer. EofLine = ^M (CALC.PAS:113) now parses. Fixture t60_charcaret (red: ERR 41 at the ^M in write → green; its .out starts with the raw bytes 0D 1B, which is what proves they are characters and not the text "13"/"27").

Stage 4 — typed constants: the SCALAR form is DONE; structured is deferred.

DefConst takes the name : Type = value spelling (TPSRC7's constant reader) and, for a scalar type, records the declared class on the symbol. Because the value still folds to an immediate, that is the whole payoff: FXMax : Char = 'G' becomes a TChar constant holding 71, so write (FXMax) prints G rather than 71. Integer and Boolean take the same path, which also pulled in RdConst reading TRUE/FALSE (it could not before). Fixture t59_typedconst — and its red proof is worth noting: dropping the class (cls := typCls → cls := cls) leaves the compile matrix GREEN at the same OK 65 4 and only execution sees 7142 where G42 belongs.

What is not done, deliberately, is a typed constant of a structured type:

• A set (Numbers : set of Char = ['0'..'9'], CALC.PAS:114) or an array (XPOS : array['A'..'G'] of Integer = (…), 137) is an initialised value with a layout. This compiler has no initialised data — InitMem zeroes the data area — so accepting one and discarding the initialiser would be exactly the silent mis-compile §0.2 forbids. DefConst refuses a type bigger than a word with ENoLib, and that is where the ladder now stops: ERR 102 at 7972.
• So the plan's 7791 → 8036 was optimistic: sets (Stage 6) must be laid out before the enumeration at 8036 can be reached. The enum-indexed array of strings in a nested function (CALC.INC:767-778) needs the same storage decision, on top of sets, arrays and string[n] — it is the hardest single item in this plan and belongs to its own write-up, not this one.
• The original keeps typed constants in the code stream, reached with seg cs, with the program jumping over them (RESUME-TP3.md §3.14); the decision between that and an init block copied at startup is still open, and is now the first thing the set/array typed-constant work must settle.

Then, in ladder order

Stage 5 — enumerations. DONE.

Attributes = (Constant,Formula,Txt,OverWritten,Locked,Calculated). Each enumerator becomes a constant holding its ordinal position (0..n-1); the TYPE is one byte (TP3 uses one below 256 values, RESUME-TP3.md §2) and carries its bounds 0..n-1 in the symbol, which is what set of Attributes sizes its base from — one byte, against 32 for set of Char. ParseType grew the ( arm, SymEntry grew lo/hi, and RdConst now resolves a NAMED constant, so [Constant, Formula] and (soon) case labels over enumerators work. Succ/Pred over enums are a later milestone (they are the standard-function milestone's job, not the type's). Fixture t62_enum. Ladder: 8098 → 8362 (the enum AND SetOfAttri = Set of Attributes).

Stage 6 — sets. Increment 1 DONE; the rest is the next milestone.

Done:

• Type sizing — TP3's hybrid 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. set of Char is 32 bytes, set of 12..17 is 2. elem carries the origin (a multiple of 8).
• The constructor [a..b, c], and [].
• Set typed constants — Numbers : set of Char = ['0'..'9'].
• Compile-time in — a constant element against a set whose bytes are in the image, answered as TPSRC2 xsetin does (AH > 255 → FALSE, else test the bit). Fixture t61_setconst, .out TRUE FALSE TRUE TRUE.
• The storage decision the plan demanded, and it is the original's own: a typed constant's bytes are emitted in the code stream behind a jmp, exactly as string literals already are, and the name becomes addressable. The divergence from RESUME-TP3.md §3.14 is one line: the original had separate code and data segments and therefore prefixed seg cs; a .COM has one segment, so DS already covers the code area and no prefix is needed. The bytes are ordinary RAM, so a typed constant stays assignable, as TP3's static typed constants are.

Still to do (all currently ENoLib, none of them silently accepted):

• Run-time in — a variable element or a set variable. The bit arithmetic is the same, but it must be emitted, not folded.
• Set variables — a 32-byte local/global (DefVar still refuses size > 2 for a non-string) and their layout in the frame.
• + union, * intersection, =/<>, assignment, [] in context.
• set of <enum> — needs the enum base first (the current rung).

Reference note: Resources/COMPIL4/ (Wirth's Pascal-P4, P.PAS + P41..P48) was added as a cross-check. It is a different design — a fixed setsize = 8-byte bitset over 0..sethigh (63), with in as a built-in runtime opcode — so it informs the algorithms but not the representation. TP3's hybrid bytes remain the ground truth here, per the repo rule. Ladder: 8060 → 8237 (now 8098 → the enum).

Stage 7 — records. Record TYPES done; field selection is the next increment.

Done: the record … end arm of ParseType. Fields are non-compacted and juxtaposed (RESUME-TP3.md §2); each name in an a, b : T group is its own field at the running offset. Fields live in a table of their own (FldRec, keyed per record) because a field name is scoped to its record, not global. A type carries its field range in SymEntry.fldFirst/fldLast. CellRec comes out at exactly 80 bytes, which is what §3 measured Sheet against, so the layout is pinned by t63_record's data=84. This also required subrange sizing: 0..20 is one byte (both bounds in 0..255, RESUME-TP3.md §2), not the two this compiler used to give it.

Not yet: field selection (c.DEC, Sheet[FX,FY].CellStatus) and with. A field access needs the expression record to carry a width (a field's size is not its variable's), which is a small ERes change plus the addressing; today it is a loud error, not a wrong address. Records as array elements come with the 2-D array in Stage 8 — Sheet[FX,FY].CellStatus is both.

Stage 8 — arrays at their point of use. Declarations DONE; element access next.

Done: multi-range array types (array['A'..'G',1..FYMax] of T), row-major with the last index varying fastest (RESUME-TP3.md §2); the shape is kept in an ArrRec (n, lo[], hi[], elem) and the symbol points at it (SymEntry.arrIdx), so indexing has everything it needs. Array variables (global, and of any size) are laid out, and array typed constants (XPOS : array['A'..'G'] of Integer = (…)) are accepted: their bytes are emitted code-resident, exactly like a set, each element little-endian. Sheet is 11760 bytes and XPOS's 14 bytes are in the code stream, which is why t64_arrays's data=11764 is Sheet plus the two @@T temporaries. t14 is re-baselined: the array declares now, and the refusal moved from the declaration (pos 83) to the subscript (pos 109).

Element and field access are DONE for constant indices. An expression now carries its own WIDTH (ERes.sz, via VarSize), because an element's size is not its array's: a constant subscript folds (index - lower bound) * element size into the address and hands the element's size and class to the store, and r.f adds the field's offset and takes the field's size and class. The width is threaded through LoadAtom, Assignment and IoCall, and Statmnt (which builds an assignment target directly, not through ParseVar) had to set it too

• that omission is what the first cut got wrong. Fixture t65_array_access (v[1] := 11, v[3] := v[1] + v[2], r.A, r.B; .out 33 then 12), and t14 is re-baselined from ERR 102 109 to OK 41 15.

Not yet: a VARIABLE index (Sheet[FX,FY], XPOS[Ch], b[i]) - scaled run-time addressing, including the second dimension - which is a loud ENoLib today, and with. Both wait on the same scaled-addressing work.

Two consequences for the harness, both now recorded:

• check_8086 clause F had to narrow. It asserted "this region sweeps clean, therefore it is pure code, therefore no 0F". A code-resident set or array constant breaks that premise - the data can decode cleanly and then present an 0F that is a data byte. Fixtures that emit code-resident constants are now listed in CODE_RESIDENT_CONST and clause F is skipped for them; the runtime sweep (the backbone) and the execution oracles still cover the emitted instructions.
• The execution harness reads 8192 bytes. tests/exec/bootcom.s reads 16 sectors, and t64_arrays's image is already ~16 KB - so it is compile-only, and CALC's measured .COM is 27,901 bytes. Running CALC therefore needs the boot sector's read raised as well as the layout change; both are on the execution path.

Stage 9 — pointers and the heap. ^T (4 bytes, offset then segment), New/Dispose, Buffer^[i] read/write, Buffer^[0] := st (assignment to a string through a pointer). The heap must hold ≥ 16,281 bytes for Pages, which is a §3 budget item, not a detail.

Stage 10 — var parameters, by reference. RESUME-TP3.md §3.11: the caller pushes SEG then OFFSET (4 bytes), the callee reads LES DI,[BP+off], and ret imm frees 2 bytes per value parameter and 4 per var parameter. Ten CALC routines need it (14 occurrences). Also remove the silent by-value acceptance in ProcFunc in this same commit — until the SEG:OFF push exists, var must Err, not quietly pass by value.

Stage 11 — real, 6-byte. The largest single item, and the one to plan in its own write-up.

• storage (declaring a real variable is ERR 102 today), literals (0.0, 1.0, 34.0, 1.5, exponentials).
• + - * / and the six comparisons over the 6-byte format.
• and/or on the results (e.g. (I > 0.0) and (I < 34.0)).
• integer↔real conversions.
• Str/Val with widths and decimals (CALC's display and input path).
• ln, exp, abs, sqrt, sqr, sin, cos, arctan, int.
• a recursive real function with a by-value real parameter is the natural end-to-end test: Fact (CALC.INC:747), Fact := I * Fact (I - 1) (754).
• Runtime: nothing real-related exists in the 20 current RT_Entry selectors. TU_* equivalents are in TPSRC1/TPSRC2.

Stage 12 — the string builtins. length, copy, delete, insert, str, val, plus named string constants (const s = 'abc' is ERR 102 today) and string-typed-constant arrays. Also revisit the data cost: each + currently reserves a fresh 256-byte global scratch (NewScratchStr), which for CALC's concat sites buys ~2 KiB of the budget in §3 — it needs to be sized to the operand, or reused.

Stage 13 — files. Types DONE; operations next.

Done: text and file of T. A file variable is our own control block (FileVarSize = 4: the DOS handle word and a mode word), because this runtime does unbuffered INT 21h I/O where TP3 keeps a 128-byte buffer inside the variable - a recorded divergence. file of T parses its element type so the RECORD size a Read/Write must move is known. Fixture t66_files; this let the whole var block pass and the {$I CALC.INC} expand, which is why the ladder moved from 9202 to 10350 - inside the include.

Not yet, and loud (unknown identifier): Assign, Reset, Rewrite, Close, EndOfFile, IoResult, and read/write with a leading file argument (writeln (MCFile, Line), Readln (H, Buffer^[count])). These need runtime entries doing INT 21h open/create/read/write/close, with text-mode newline and ^Z semantics (RESUME-TP3.md §2). {$I-}/{$I+} (Stage 2) already gate the checking that IoResult reports.

Stage 14 — the CRT identifiers. GotoXY (25), LowVideo/NormVideo (16 + 16), ClrEol (10), ClrScr (6), KeyPressed (3), Delay (1), Read (Kbd, Ch). There is no unit system, so these become builtins with runtime entries: GotoXY and ClrEol from the cursor position, video attributes, a Delay busy loop, KeyPressed/Kbd from INT 16h. A compiling CALC needs them to resolve; a running CALC needs them to be right, which is a later question and explicitly not this goal.

Stage 15 — recursion, forward, nesting. Two distinct shapes, both in Evaluate:

• Direct self-recursion, Fact: Fact := I * Fact (I - 1) (CALC.INC:747,754). The name must be visible inside its own body.
• Mutual recursion through forward: Expression is declared function Expression(var ExpressionCh : Char): Real; forward; at CALC.INC:742 and defined at 1036 — with the parameter list commented out, function Expression{(var ExpressionCh : Char):Real;forward}; — while Factor calls it two ways (CALC.INC:820,932). So the definition may repeat only the name and must inherit the forward's parameters, result type and level; keep the var-ness intact (Stage 10).

Today a self-call is ERR 1 at the ( (proved with a probe). Grouping a callee's parameters must agree with Stage 10's 2-vs-4-byte accounting, so land this after parameters — or land the symbol-visibility half first and gate the rest.

Stage 16 — the layout (§3, the layout track). Re-orient the image so the compiler can emit 16,560 B of code and hold 12,032 B of data (both measured, §3.1), choosing between the two candidate fixes in §3 and re-baselining t43_codewindow in the same commit. This is the only stage that blocks the goal rather than the ladder. Then capacity (§5), which follows from it: TextLimit is 488 bytes from overflowing and should rise with the include stage.

---

5. Capacity — the numbers that will bite

limit	value	CALC needs	verdict
TextLimit (source buffer)	62,903	CALC.PAS + CALC.INC, normalised = 62,415	488 bytes of slack
MaxCode	24,000	16,560 B (measured, §3.1)	enough in itself; dataBase's 4,096 B window is the blocker (§3)
code window (dataBase − rtSz)	4,096	≥ 16,560	must change orientation (§3)
data area	unbounded past dc	12,032 B (measured, §3.1)	must be able to hold it under/over the code
stack	16,384 min / 655,360 max	16,384 min	matches the original's minstk/maxstk
MaxSym	3,000	47 routines + locals + params	inferred OK, verify
strOff/strLen	[0..255]	57 distinct string literals (67 occurrences)	OK
strPool	4,096 chars	≤ 69 bytes each	OK
heap	hdrHeap = dc to the stack	16,281 for Pages	must be checked in §3's budget
data scratch per +	256 bytes/site	~9 sites	trim (Stage 12)

The TextLimit number is the sharpest: a 62 KB program in a 62,903-byte buffer is not a design, it is luck. Raising TextLimit (and the buf array in TextBuf.mod) costs only compiler memory and should happen in the same commit as the include, because the include is what consumes the slack.

---

6. Open questions, each with a method

• Q1 — RESOLVED (§3.1). The data area sits below the program code; the binding limit is data running into the code base, and this port has it the other way round. Remaining as a decision, not an unknown: implement "match the original" or "dynamic data base", and re-baseline t43_codewindow in the same commit.
• Q2. Is {$A-} really a no-op for TURBO.COM? Check TPSRC for an A directive before treating it as ignorable.
• Q3. Pages = array[0..200] of string[80] — confirm the element size is 81 and that New (Buffer) gets 16,281 contiguous bytes from the heap the way TP3's New does.
• Q4 — RESOLVED (Stage 1). run_compile_tests.sh/CompileTest.mod still have no fixture-with-companion-file notion, and they do not need one: the ladder is a small dedicated script (tests/calc_ladder.sh) that stages CALC.PAS and CALC.INC as copies in tmp/calc_ladder/. That is also what makes the Stage 2 include resolve, since it opens the .inc relative to the including file.
• Q5. Are range/index checks on by default for TURBO.COM? CALC sets neither {$R} nor {$V}; if the default is on, TU_RANGE_CHECK and TU_INDEX_CHECK are on the critical path for every index in CALC, not an optional hardening. RESUME-TP3.md §4 (compiler options) is the place to check.
• Q6 (cheap, one run in dosemu). Does memory-mode compilation of CALC report "Compiler Overflow #99" as CALC.PAS's banner warns? The .COM path succeeds (§3.1); the memory path is the only untested claim about which limit bites. Banner step 1 (R) is all it takes.
• Q7. What the two header words after ds actually mean. They read 730/39 for HELLO and 1760/789 for CALC, matching neither the reported code/data sizes nor each other, so RESUME-TP3.md §3.1's field list is unreliable there. Only matters if we adopt the original's header shape; until then the statistics line and the file layout are authoritative (§3.1).

---

7. What not to do

• Do not "support" a construct by parsing it and emitting nothing. That is the var-parameter bug and the {$I} bug, and both were green.
• Do not raise dataBase/MaxCode and call §3 solved; the orientation is the question, and t43_codewindow exists precisely to catch a silently corrupt image.
• Do not implement BCD reals, Pos, Concat, Round, Trunc or goto for this goal. CALC uses none of them.
• Do not let this plan absorb CALC-PORT.md. Same program, different target, different session.

---

8. Pointers

• SUMMARY.md — current state, the fixture tables, "Next steps".
• RESUME-TP3.md — §2 types and layouts, §3.1 skeleton, §3.4 assignment, §3.11 parameters (the SEG:OFF push), §3.14 typed constants, §4 options.
• TP3-COMPILER.md — what the compiler does today and why.
• Resources/turbopascal3source/TP3/TPSRC1-10 — the ground truth.
• Resources/coeur-tp-ocr/coeur-tp-03-d.txt §4.7 — sets explained: the hybrid byte layout this port implements (4.7.2) and the memory order (4.7.3).
• Resources/COMPIL4/ — Wirth's Pascal-P4 (P.PAS, P41..P48), added as a cross-check. Its sets are a fixed 8-byte bitset over 0..63 with in as a runtime opcode, so it informs the algorithm, not the representation.
• Resources/TP3/CALC.PAS, CALC.INC, CALC.HLP — the target.
• shell/tests/probe/README.md — read before touching any emitter.