refactor(simd): Phase 4 — extract scalar backend to src/simd_scalar.rs#174
Merged
Conversation
Phase 4 of the integration plan in `.claude/knowledge/
simd-dispatch-architecture.md`.
simd.rs shrinks from 1956 → 685 LoC by lifting the inline 1271-line
`pub(crate) mod scalar { ... }` block (impl_float_type! / impl_int_type!
macros + 11 type instantiations + 30+ extra impl blocks for U8x64 /
I8x*/I16x* / U16x32 / I32x16 / I64x8 / F32x16 / F64x8 / U32x16 / U64x8)
out into its own file `src/simd_scalar.rs`. Declared from `simd.rs`
with `#[path = "simd_scalar.rs"] pub(crate) mod scalar;` so the
internal module name stays `scalar` — every `pub use scalar::{...}`
re-export in `simd.rs` continues to resolve unchanged.
Behavior is byte-identical. The file move is mechanical: zero semantic
edits, just outdented one level and wrapped with a module-level doc
comment explaining its role as the non-x86_64 fallback backend.
Why now: the dispatcher should read as a re-export catalog with cfg
arms, not 1.6k LoC of macro expansions. Future tweaks to the scalar
backend (TD-SIMD-5 in the architecture doc) now live in a file named
for what they are.
`use core::ops::{...}` import list was wrapped at a slightly different
column than rustfmt prefers (post-extraction reflow). One-line fmt diff.
AdaWorldAPI
force-pushed
the
claude/pr-x-phase4-scalar-honesty
branch
from
15945b6 to
e0c99a3
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
2 participants
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
Phase 4 of the integration plan in
.claude/knowledge/simd-dispatch-architecture.md.src/simd.rsshrinks from 1956 → 685 LoC by lifting the 1271-line inlinepub(crate) mod scalar { ... }block out into its own filesrc/simd_scalar.rs.The mod is declared from
simd.rswith#[path = "simd_scalar.rs"] pub(crate) mod scalar;so the internal module name staysscalarand everypub use scalar::{...}re-export keeps resolving unchanged.Behavior is byte-identical — zero semantic edits, just outdented one level and wrapped with a module-level doc comment explaining the file's role as the non-x86_64 fallback backend.
Why now
The dispatcher should read as a re-export catalog with cfg arms, not 1.6k LoC of macro expansions. Future tweaks to the scalar backend now live in a file named for what they are.
What moved
impl_float_type!/impl_int_type!macrosF32x16,F64x8,F32x8,F64x4,U8x64,I32x16,I64x8,U16x32,U32x16,U64x8, plus the I8/I16 set)U8x64byte ops (palette codec, nibble, byte scan),I32x16math,I64x8math,F32x16/F64x8bit casts,U16x32widen/pack,U32x16/U64x8shifts,U8x64×U8x64multiplyf32x16=F32x16, etc.)Test plan
cargo build --target=thumbv6m-none-eabi— non-x86 path resolves scalar mod via#[path]cargo buildon x86_64 —mod scalargated out, no impactGenerated by Claude Code