# Expected results for tests/fixtures/*.pas - one line per fixture: # # OK # ERR # # 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 ' at its point of use # t25 a string literal used where a 16-bit word is wanted # uierror deliberate syntax error, pinned by the editor UI test # # 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 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 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,
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. p63 lands at BP+128 and p70 # 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 and is never executed; do not read it as # a claim that a 70-argument call works. Its 123 bytes are # 1 more than t27's because the body is one ADD and one # store rather than five of each. 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 35 6 t09_if OK 67 6 t10_while OK 75 6 t11_for OK 69 6 t12_repeat OK 72 6 t13_proc OK 53 6 t14_types ERR 102 83 t15_label OK 38 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 96 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 122 6 t28_farparam OK 123 6 uierror ERR 41 331