SIMD-0391: Stake Program Float to Fixed-Point

[grod220]

Proposal to migrate floats in stake-interface to fixed point

[t-nelson]

firstly some basic stuff. i thought this was all documented in simd0001, but apparently that is not the case, so i'm going to elaborate here as a reference for foundation

simd's are intended to document protocol changes, not implementation changes. as such they should be written in a programming language and implementation agnostic way. imagine that you are sitting down to do a clean room implementation with only this document and knowledge of your intended target language. prefer prose. avoid code references where possible. where necessary, use pseudo code rather than a specific language

---

aside from the general corrections above and inline comments, a few things crossed my mind while reading this.

1. do we want to depend on native u128 support landing in upstream ebpf or should we have a contingency for wide/arbitrary integer arithmetic? if the latter, that would make sense as its own simd
2. i believe there are other instances of floating-point arithmetic in protocol, under consensus. would a generic "floating-point to fixed-point" migration simd be valuable to avoid needing to restate some of the details? we can just use that as a reference and stick to the specifics for each instance

[grod220]

Thanks for the review @t-nelson. Overhauled this SIMD to align with the the spirit of your feedback on being implementation agnostic.

do we want to depend on native u128 support landing in upstream ebpf or should we have a contingency for wide/arbitrary integer arithmetic?

This is currently in progress, but this SIMD should be on hold until the outcome of that work is merged or otherwise. Will provide an update when there is one. That said, the contingency would be to emulate u128 math using u64 limbs.

would a generic "floating-point to fixed-point" migration simd be valuable to avoid needing to restate some of the details

I'm not sure if that would reduce redundancy as the motivation is specific to an on-chain program wanting to be aligned with the upstream compiler reqs. Not sure if agave's motivations would be the same.