prometeu-studio/discussion/lessons/DSC-0062-multi-frontend-pvm-neutrality/LSN-0061-pbx-runtime-boundary.md

id	ticket	title	created	tags
LSN-0061	multi-frontend-pvm-neutrality	PBX is the language-neutral runtime boundary	2026-09-18	vm-arch runtime pvm pbx compiler multi-frontend

PBX is the language-neutral runtime boundary

Original Problem

PBS was the first implemented frontend, so its name still appeared in a few common compiler specification titles. That editorial residue made it easier to misread the architecture as if PBS owned bytecode, IRVM, or the PVM execution model.

The implementation was already mostly neutral: the compiler emitted PBX, the runtime loaded PBX, and the common backend did not import PBS frontend packages. The real risk was future drift. In particular, IRVM could be mistaken for a runtime input, PBS\0 could be confused with the executable magic, and duplicated VM-architecture documents could silently become competing authorities.

Consolidated Decision

The executable pipeline is:

language frontend -> IRBackend -> IRVM -> PBX -> loader/verifier -> PVM

IRBackend, IRVM, optimization, and PBX emission are compiler-owned. IRVM is an internal compiler representation and never crosses the runtime boundary. PBX is the only executable artifact consumed by the runtime.

The runtime repository owns PBX binary layout, Core ISA, loader behavior, verification, and PVM execution. Studio owns the common compiler transformations that produce conforming PBX. Studio copies of VM-architecture documents are mirrors, not independent authorities.

PBS names a language, frontend, stdlib, and explicitly language-specific integration. It does not name the executable format, magic, ISA, ABI, program image, or runtime type. The canonical persisted artifact is program.pbx, and its binary magic is PBX\0.

Final Implementation

The common compiler specifications now identify bytecode/PBX and IRVM optimization as language-neutral surfaces. They explicitly state that IRVM is internal to the compiler and that PBX is the compiler/runtime boundary. Existing PBS references were retained where they describe legitimate frontend-specific publication or metadata behavior.

Studio's copies of ARCHITECTURE.md, ISA_CORE.md, and INTRINSICS.csv were synchronized with the runtime repository. A mirror policy now identifies the runtime repository as canonical and provides byte-for-byte comparison commands.

Existing Studio tests already proved two important invariants:

• BytecodeModule serializes the exact PBX\0 header;
• common backend contracts neither import nor publicly expose PBS frontend types.

Runtime conformance was strengthened in three focused places:

• the bytecode invalid-magic regression now explicitly proves that legacy PBS\0 is rejected;
• the PVM initialization regression now creates a BytecodeModule directly, serializes it, loads and verifies it, prepares the boot call, and executes it through HALT without any frontend;
• a quality check inspects the prometeu-bytecode and prometeu-vm manifests and rejects dependencies whose identities belong to compiler or frontend layers.

No production VM behavior, ISA, ABI, or binary format changed.

Examples

Language-specific work stops before the common backend:

PBS AST and semantic model
  -> PBS lowering
  -> neutral IRBackend data
  -> common IRVM lowering and optimization
  -> PBX\0

A future frontend follows the same boundary:

FutureLanguage AST and semantic model
  -> FutureLanguage lowering
  -> neutral IRBackend data
  -> the same common IRVM and PBX stages

The runtime sees the same PBX contract in both cases. It does not receive a languageId, source extension, AST object, IRVM object, or frontend service.

Pitfalls and Anti-Patterns

• Do not expose IRVM as a convenient runtime protocol. It is optimized for compiler transformations, not binary compatibility or runtime loading.
• Do not rename PBX concepts after the first frontend. PBS\0 is invalid even when PBS produced the program.
• Do not globally ban the word PBS from runtime documentation. PBS is a valid guest-language example; guards should inspect dependencies, public types, and format identities instead of raw text.
• Do not duplicate tests when an existing guard proves the entire invariant. Extend coverage only for the missing distinction, such as explicit PBS\0 rejection.
• Do not let a documentation mirror become a second authority. Synchronize it against runtime or replace it with an explicit reference.
• Loading a PBX image is not the same as beginning execution. The PVM boot test must prepare the published boot call before running the instruction budget.

References

• docs/specs/compiler/15. Bytecode and PBX Mapping Specification.md
• docs/specs/compiler/20. IRBackend to IRVM Lowering Specification.md
• docs/specs/compiler/21. IRVM Optimization Pipeline Specification.md
• docs/vm-arch/README.md
• prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/backend/bytecode/BytecodeModule.java
• prometeu-compiler/prometeu-build-pipeline/src/test/java/p/studio/compiler/specs/CommonBackendArchitectureTest.java
• Runtime: crates/console/prometeu-bytecode/src/model.rs
• Runtime: crates/console/prometeu-vm/src/virtual_machine.rs
• Runtime: crates/dev/prometeu-quality-checks/tests/pvm_frontend_neutrality.rs

Takeaways

• PBX is the stable, language-neutral executable boundary.
• IRVM stays private to the compiler pipeline.
• Runtime authority and compiler authority are complementary, not competing.
• Small dependency and artifact tests are enough to protect this boundary without introducing a plugin platform or a second language.