Repository navigation
Make verified portable x64 the canonical CLI path - #19
Draft
Papishushi wants to merge 1 commit into
Draft
Papishushi wants to merge 1 commit into
Papishushi wants to merge 1 commit into
Conversation
| internal string? PortableModulePath { get; set; } | ||
| internal bool EmitMetadata { get; set; } = true; | ||
| internal bool PortableX64 { get; set; } = true; | ||
| internal bool PortableX64Requested { get; set; } |
Not up to standards ⛔🔴 Issues
|
| Category | Results |
|---|---|
| BestPractice | 1 medium 1 minor |
🟢 Metrics 283 complexity · 2 duplication
Metric Results Complexity 283 Duplication 2
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
Papishushi
changed the base branch from
main
to
feat/semantic-binary-verifier-v0
October 15, 2026 14:28
Papishushi
changed the base branch from
feat/semantic-binary-verifier-v0
to
main
October 15, 2026 17:06
Papishushi
changed the base branch from
main
to
feat/semantic-binary-verifier-v0
October 15, 2026 17:06
Papishushi
changed the base branch from
feat/semantic-binary-verifier-v0
to
main
October 15, 2026 17:09
Papishushi
changed the base branch from
main
to
feat/semantic-binary-verifier-v0
October 15, 2026 17:09
Papishushi
changed the base branch from
feat/semantic-binary-verifier-v0
to
main
October 15, 2026 17:37
Papishushi
changed the base branch from
main
to
feat/semantic-binary-verifier-v0
October 15, 2026 17:38
Papishushi
added this pull request to stack #13
October 15, 2026 19:34
Papishushi
force-pushed
the
feat/canonical-portable-x64-cli-v0
branch
from
October 15, 2026 21:44
a8622ec to
0194d1b
Compare
| @@ -1,3 +1,6 @@ | |||
| [assembly: System.CLSCompliant(true)] | |||
Papishushi
force-pushed
the
feat/canonical-portable-x64-cli-v0
branch
from
October 15, 2026 21:54
0194d1b to
82c8714
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Makes verified indexed UBCM the canonical/default x64 compilation route and migrates the existing Linux module/isolation consumers onto that boundary without silent fallback to direct source -> x64 codegen.
This PR remains stacked on #18 (
feat/semantic-binary-verifier-v0).Canonical CLI route
Invoking
ubytec <source.ubc>now usesPortableSourceX64Pipelineby default.--portable-x64remains a compatibility alias.--legacy-source-x64is the only explicit opt-in to the deprecated direct source -> x64 path, and conflicting pipeline flags fail deterministically.--portable-modulepersists the exact UBCM bytes consumed by native code generation.Portable library ABI
Library exports no longer require source names inside
PortableX64Backend. The backend remains index-only (ubytec_binary_*). After verification,PortableSystemVLibraryAbiderives System V thunks from the verified UBCM export table.--host-export Function=ubytec_host_symbolis now portable: the requested export is inserted before UBCM serialization, verified with the module, then bound to native ABI only after the verifier boundary.Structured control and tail calls
Indexed executable v0 normalizes structured source control into portable
LOOP/IF/BREAK/ENDoperations and the x64 backend validates scope transitions and balanced function scopes.--tail-callsis also supported by the canonical x64 route.PortableX64TailCallOptimizeroperates only on verified indexed CALL + RETURN pairs and compatible UBCM signatures. It remains explicit because frame reuse changes physical frame lifetime.Other source-backend optimization switches remain legacy-only until they have portable/backend contracts.
Runtime services and module contracts
ModuleInvoke,HostReadandHostWriteare represented as reservedubytec.runtimeimports inside UBCM. Post-verification binding maps their ImportIndex labels to the supervisor bridges; the core backend never resolves source aliases.Source
import/exportdeclarations retain their loader-facing aliases and grant-slot metadata in the critical UBCMContractManifest.PortableX64ModuleContractAbiparses that verified manifest, cross-checks it against the verified ImportIndex/ExportIndex tables, emits the native.ubytec_contractsection and generates the correspondingubytec_bridge_call,ubytec_bridge_manyandubytec_host_contract_*adapters. The manifest describes slots/contracts only; authority grants remain supervisor-owned.Isolation migration exercised by this PR
The Isolation integration now runs through the canonical portable path rather than depending implicitly on the legacy source backend. The current head passes the complete
Isolation mechanism prototypesworkflow, including:LoanRead/LoanWriteFull productionization of the capability/isolation runtime remains the next dedicated PR; this PR only ensures the canonical UBCM -> x64 route can carry and execute the existing contracts faithfully.
Legacy compatibility
Direct source -> x64 compilation remains temporarily available behind
--legacy-source-x64. There is no implicit fallback from the portable route when a feature is unsupported.