Skip to content
hw.dev
hw.dev/signal/scaly-cortex-m-oracle-memory-gate-2026
SignalScaly

A Cortex-M Numeric Oracle Fits in 456 Bytes of Flash

Scaly makes generated numeric code prove its memory cost and forbidden dependencies before it reaches a Cortex-M microcontroller.

Thesis connection

A generated algorithm is easier to approve for a microcontroller when the build checks its memory budget and rejects hidden runtime dependencies.

#embedded#testing#tools#software
Read Original

Scaly can now build a generated numeric function and its sparse Jacobian, the matrix that describes how each output changes with each input, for bare-metal Cortex-M4F and M7 microcontrollers. The checked object occupies 456 bytes of flash and 4 bytes of static random-access memory (RAM). Its caller supplies another 320 bytes of workspace, 32 bytes of inputs, and 96 bytes of outputs.

The value is in the build gate around those numbers. Continuous integration checks both processor targets, rejects unexpected undefined symbols such as memory allocation, confirms that diagnostic printing disappears, and records flash and RAM use. A numerical comparison against NumPy checks the generated result, while an injected perturbation proves that the comparison can fail. This turns memory cost and runtime dependencies into reviewable properties of each generated artifact.

The project has not yet measured execution time on a microcontroller, so this proves fit and numerical agreement rather than field performance. An embedded team evaluating Scaly should add one board-level timing test with its real math library; that result will show whether the small object also meets the product's deadline.