The help text was thirteen help_row(N) calls and the dispatch thirteen
case N labels, both counting positions in a list defined elsewhere. A
command is now one row of name and summary; the summaries become a second
NUL-separated flash blob printed in a loop, and every case label is
command_index("name"), which does not compile for a name the list lacks.
The help column derives from the longest name, the dotted padding is one
helper for labels and help rows alike, and the ADC scale, the monitor
interval and the uptime units are named. Output is unchanged; the image
goes from 8004 B to 7838 B, both modes byte-identical. The 32-bit
narrowing in dev/tasks.md is re-measured against the new image.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
608 B of flash, 7.6 % of the image, and it is not available: this board runs
continuously and an uptime that restarts every 49.7 days is not acceptable,
which is what a 32-bit millisecond counter wraps at.
The tick split goes with it. It only ever made sense beside the narrowing, and
on its own it costs 66 B to buy about 0.4 % of a CPU nothing here is competing
for.
Both are recorded rather than deleted, and that is the point of the change: the
numbers are real and re-measurable, so someone will find 608 B again and read
it as an opportunity. What they need with it is the reason it was refused.
Docs only; five tests green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two findings from the flash sweep, both measured and neither taken, because
each is a decision rather than a defect.
Narrowing uptime::millis() and its three timestamps to 32 bits is 608 B, 7.6 %
of the image, and 16 B of RAM. The reason it is not a free win is not the
display: a 32-bit millisecond counter wraps every 49.7 days on a board that
runs continuously, and the interval tests would have to become subtractions,
since `now - last >= interval` survives a wrap where `now >= last + interval`
does not - which is how terminal.hpp's monitor tick is written today. The
64-bit counter is what puts the wrap out of reach, so this is a question about
a wrapping uptime display, and the answer decides 608 B.
The 1 kHz tick's own prologue is the smaller one. The handler increments 64
bits, so it calls __adddi3_s8, and a call in a signal handler decides the
prologue - twelve push/pop pairs for what the helper might clobber. Two 32-bit
halves remove the call and keep the range, taking the handler from ~47
instructions to ~26 with the carry running once every 49.7 days. Not taken
either: it costs 66 B of flash to buy about 0.4 % of the CPU, and nothing here
is timing-critical.
This repo had nowhere to record work, so it has a tracker now.
Docs only; the image is unchanged at 8004 B and the suite is green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
BlackMarkandClaude Opus 5.5