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>
1.7 KiB
Tasks
This file is current work. The repo is the sole task tracker (libavr guidance rule 20).
Open
Nothing.
Decided against
Both of these are measured, and both are recorded here rather than deleted so that the next person to measure them does not read a number as an opportunity and re-propose work the owner has already refused.
The millisecond clock stays 64 bits
Narrowing uptime::millis() and the three timestamps that hold its value from
uint64_t to uint32_t is 608 B of flash, 7.6 % of the image (8004 B down
to 7396), plus 16 B of RAM.
Refused, owner-stated: this board runs continuously and an uptime that
restarts every 49.7 days is not acceptable. That is what a 32-bit
millisecond counter wraps at, and the display is not the only cost - the
interval tests would have to become subtractions, since now - last >= interval survives a wrap where now >= last + interval does not, and
terminal.hpp's monitor tick is written the second way. The 64-bit counter is
what puts the wrap out of reach, which is the property being bought.
The 1 kHz tick keeps its 64-bit increment
The compare handler increments 64 bits, so it calls libgcc's __adddi3_s8, and
a call inside a signal handler decides the prologue - twelve push/pop pairs for
what the helper might clobber. Splitting the counter into two 32-bit halves
removes the call and keeps the full range, taking the handler from ~47
instructions to ~26 with the carry running once every 49.7 days.
Refused: it costs 66 B of flash to buy about 0.4 % of the CPU, and nothing here is timing-critical. It was only ever worth considering alongside the narrowing above, which is refused outright.