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>