[libre-riscv-dev] IEEE754 FPU

[Luke Kenneth Casson Leighton]

On Tuesday, February 12, 2019, Aleksandar Kostovic <
alexandar.kostovic at gmail.com> wrote:
>
>
> While that way of doing stuff saves time it wouldnt benefit any of us IMHO.
> Its better to actually understand something before doing it. That way we
> all can be on the same page when talking about something and have a mutual
> understanding. :)
>
>
Good point.


> It would be nice if you drew the algorithm simplifying the whole process. I
> would be very happy to see the simplification of floating point
> arithmetics.


Ok.


>
> "self" is the exact same thing in c++ as "this->"
> > It takes getting used to, that scope has to be explicit. It soon
> > disappears, you get used to it.
> > Also if you use the "with" trick, which you see in some of the nmigen
> > examples, the self.thing is only needed once.
> > I was very impressed with nmigen, the code looks way clearer and easier
> to
> > read than migen, if you use the "with" keyword.
>
> Now i am getting it. nMigen definitely looks fun but painful. Takes some
> time getting used to tho.


If you run a conversion to verilog every time, it helps.


>
> FPU is the most complex project i have been working on so it may take some
> time, but i hope it will be rewarding. FP arithmetics are complicated,
> however when i "get it", it will all make sense on how to implement it.


>From what I understand

The mantissa cannot have a zero in the MSB, so it is shifted up (exponent
adjusted simultaneously) so that eventually there *is* a one ine the MSB.
Then that top 1 is always removed (implicit).

0.00153e1 is not allowed, neither is 0.0153e0, however 0.153e-1 is ok. In
binary obviously.

For a calculation, the mantissa has to be shifted so that the exponents are
the same.

The the mantissas can be added (or multiplied etc).

The partial result will then potentially have zeros in it.

0.153e-1 - 0.152e-1 is 0.001e-1, and, again, the zero in the MSB is not
allowed, so normalisation has to be done.

Result: 0.1e-3

Add will potentially be the other way round. 0.153e-1 + 0.947e-1 results in
2.0e-1.  This needs to be normalised, it gets shifted *down*, to 0.2e0.

It gets slightly complicated when overflow needs to be detected. Adding a
NaN to a NaN etc. Also zero has to be expressed explicitly, luckily it is
synonymous with integer all zeros

That's basically what I understand so far. Will write out some ascii
diagrams of FADD.

L.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68