# 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.