Fixed Point Arithmetic

&gt; If you #include &lt;stdfix.h&gt;, you gain access to compiler-understood fixed-point data types. For example, you get access to type _Accum, which is a 16.15 fixed point <i>exactly</i> like the one that we&#x27;ve been considering above.<p>You can actually use _Accum without including stdfix.h, at least for compilers that conform the embedded extension to C (ISO&#x2F;IEC TR 18037 [1]). Stdfix.h just gives you a macro named `accum` among others; this approach has been used for any new C keyword since C99 (e.g. _Bool vs. stdbool.h, _Alignas vs. stdalign.h). The size of _Accum type is also not exactly defined (it can well be 4.27).<p>[1] <a href="http:&#x2F;&#x2F;www.open-std.org&#x2F;jtc1&#x2F;sc22&#x2F;wg14&#x2F;www&#x2F;docs&#x2F;n1169.pdf" rel="nofollow">http:&#x2F;&#x2F;www.open-std.org&#x2F;jtc1&#x2F;sc22&#x2F;wg14&#x2F;www&#x2F;docs&#x2F;n1169.pdf</a>

I know fixed point was very important back in the days when CPUs didn&#x27;t have dedicated floating point instructions. How important is it now, when most common CPUs have fast floating point operations? Is there still a performance win? Do games and similar software use them today?

Prepared as a lecture supplement for ECE 4760 (Digital System Design Using Microcontrollers) at Cornell.

Don&#x27;t use stdfix.h if you are doing this though. As soon as you need to change your headroom (even temporarily within an algorithm), it will be a pain. Just use the boring C90 types (possibly typedeffed to something else) and write the operators you need.

Fixed point was still normal instruction in mandatory classes when I was in school. It is a pity, but I feel like we stopped teaching it at some point.

Another advantage: the results of additions no longer depend on the operation order. Converting floats to such ints helped me remove nondeteminism from a large pipeline that did additions over large sets of numbers. It was annoying to trace diffs in the pipeline when we were making changes and wanted to see what the end results are.

I used fixed point for my game&#x27;s physics, because I wanted things to be deterministic across platforms and compilers (the game has a hidden &quot;solver&quot; which is used to tweak things a little bit to make the game more fun, but this involves rerunning simulations multiple times).

I used fixed-point for all the 3d code in The Virtual Reality Playhouse (1992). That was the last time I wrote any significant assembler code. Good times.

Fixed point is critical reading for a lot of FPGA work.

That would be easier with Forth :).

Whenever I hear &quot;fixed point arithmetic&quot;, it reminds me of the jittery graphics on PSX.<p>Can&#x27;t find a more official source than Reddit, but here goes:<p>&gt; It&#x27;s because the position of each polygon&#x27;s vertex (corner) is only calculated at a very low precision. Once the polygon moves (or the camera) the vertexes will stay at the same point, until they&#x27;re closer to the next and suddenly &quot;jump&quot; to the new position without transition. Newer graphics hardware could interpolate smoothly here with more in-between states (that&#x27;s where all the talk about &quot;floating point precision&quot; came from in graphics).<p>0. <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;gaming&#x2F;comments&#x2F;bkedc&#x2F;heres_a_question_why_do_3d_models_on_the_ps1_tend&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;gaming&#x2F;comments&#x2F;bkedc&#x2F;heres_a_quest...</a>

I&#x27;m using fixed point for real-time DSP on cortex-M. Faster than floating.<p>Using the CMSIS-DSP Q31 functions, in particular. On Rust `i32`s.