You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Formalize platform abstraction: Memory Space + Execution Space model (RAJA/Kokkos pattern) #77
LLNL RAJA achieved 20x reduction in new-platform onboarding by investing in a formal platform abstraction. Sandia Kokkos models both execution space (where code runs) and memory space (where data lives) as first-class concepts. NASA cFS uses a similar PSP → OSAL → cFE layering.
Problem
Synth currently has linker scripts per target (STM32, nRF52840, generic) and synth-memory provides a portable memory abstraction for Zephyr/Linux/bare-metal. But there's no formal model of memory spaces (Flash vs SRAM vs TCM vs external RAM) or execution spaces (Cortex-M0/M4/M33/M55 capabilities).
Proposal
Formalize synth-memory into three explicit layers:
Status (issue-hygiene pass): backlog, platform-level. The Memory-Space/Execution-Space formalization (RAJA/Kokkos pattern) spans synth+kiln+meld; synth's slice of it (where compiled code may assume memory lives) is being settled concretely by the #237 native-pointer ABI rather than by an abstract model first. Once #237's contract is proven on-target, this issue is the right place to generalize it — until then it stays open as backlog, deliberately behind the concrete work.
Shipped in v0.49.0 (#810). PlatformSpaces::validate() now makes the Memory-Space + Execution-Space choice a machine-checked invariant: a bare-metal core requesting an OS-mapped space, or an FP-requiring space on an FPU-less core, is REJECTED (red-first). Bounded first increment of the formalization; the fuller model (more space classes, cross-check vs the linker geometry) can extend it as needs arise.
Activity
avrabe commentedon Jun 10, 2026
Status (issue-hygiene pass): backlog, platform-level. The Memory-Space/Execution-Space formalization (RAJA/Kokkos pattern) spans synth+kiln+meld; synth's slice of it (where compiled code may assume memory lives) is being settled concretely by the #237 native-pointer ABI rather than by an abstract model first. Once #237's contract is proven on-target, this issue is the right place to generalize it — until then it stays open as backlog, deliberately behind the concrete work.
feat(#77,#80): platform space-consistency invariant + P3 async error-…
chore(release): v0.49.0 — phase-2 frontier + falcon to zero (7-lane h…
avrabe commentedon Jul 17, 2026
Shipped in v0.49.0 (#810).
PlatformSpaces::validate()now makes the Memory-Space + Execution-Space choice a machine-checked invariant: a bare-metal core requesting an OS-mapped space, or an FP-requiring space on an FPU-less core, is REJECTED (red-first). Bounded first increment of the formalization; the fuller model (more space classes, cross-check vs the linker geometry) can extend it as needs arise.