Skip to content

as370: fold the libc370 corpus into the committed byte-identity comparison #23

Description

@mgrossmann

Problem

The committed byte-identity suite (as370/tests/run.sh + ref/) compares 13 samples (sample1-10, rs_badidx/goodidx). But the guarantee everyone cites — "736/736 (now 739) modules byte-identical to IFOX00" — comes from an ad-hoc external run, recorded only in prose (as370/README.md, docs/object-record-fidelity.md, CLAUDE.md). Nothing runnable enforces it.

That means a codegen change to as370 can silently regress the real corpus while make test stays green, because the 13 samples don't cover it. The 923-module scan done for #18 was a throwaway script, not a gate.

Fix (scope only, do not implement here)

Fold the libc370 corpus into the committed comparison so the claim is reproducible:

  • A harness that assembles every libc370 asm/ + src/**.s module with as370 and checks each object deck against a committed IFOX00 reference (deck content before the END-card IDR, per the existing byte-identity convention).
  • Reference decks: either commit them (sizeable) or generate on demand via the mvsMF path against a real IFOX00 and cache.
  • Wire it into a make test-corpus (kept separate from the fast make test, since it is large).

Why now

#18/#21 change codegen. Their gate is "make test + listref + the 923-scan stays 0". The scan is manual. This issue makes that gate permanent so the next codegen change can't quietly move the corpus.

Related: the crent370->libc370 rename issue (harness pointers), #18, #21.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions