Rm f64#1957
Conversation
Replace the live fee-warning percentage calculations with integer arithmetic and preformatted percentage strings. The warning threshold and the displayed rounded value stay the same, but the firmware no longer needs the runtime `f64` calculation path just to decide whether to show the high-fee warning text. The Bitcoin, Cardano and Ethereum flows now all reuse the same integer-based warning-percentage logic. Savings: 824 bytes
Add an integer `set_fraction()` progress path through the HAL and UI layers,
and switch the live Bitcoin-signing and Bluetooth-upgrade progress updates to
use it.
The progress bar ultimately renders whole pixels, so the C progress component
now stores the filled pixel width directly and computes it with integer math.
This keeps the visible behavior intact while removing the Rust-side soft-float
`f32` arithmetic path that was only used for progress updates.
In the final firmware image this drops the live
`compiler_builtins::float::{add,div,mul}::<f32>` helpers together with the
associated `__aeabi_fadd`, `__aeabi_fdiv`, and `__aeabi_fmul` wrappers.
Savings: 1488 bytes
Extend .ci/check-unwanted-symbols with additional checks for linked floating-point helpers in build/bin/firmware.elf. Keep the existing float formatting, strftime, and sha2::Sha512 checks, and add floating-point helper checks for the helpers removed by the integer fee and progress commits. The f64 check is intentionally scoped to comparison/conversion helpers because this branch still has some double arithmetic helpers pulled in by the existing C snprintf/newlib path.
|
very good! does removing the use of u128 also reduce size more? I suppose u128 is entirely software implemneted. |
Codex actually made an accounting error and the use of u128 undid the previous commit's gains. The code to replace it (adde as a wip commit) is quite ugly and harder to review. An alternative would be to use the same as ETH, which uses BigUint: It would be reusing existing clean code, but the big-int dep would have to be then enabled for BTC-only too, adding ~8kB to that binary (but saving bytes in the Multi binary as that one already uses big-ints). |
|
Do we have to support larger values than 2.1e15? (all satoshis that ever will be available?) |
BTC is not the only user of this function, Cardano does too. I split out the first easy commit (and CI check) to #1959 |
|
Have two functions then? In multi it is strictly better to use BigUints, so there it isn't a question. In BTC we only use 60% of the fw size so there it is more of a ideological question. |
2 participants
No description provided.