[libre-riscv-dev] IEEE754 FPU

[Luke Kenneth Casson Leighton]

On Monday, February 11, 2019, Aleksandar Kostovic <
alexandar.kostovic at gmail.com> wrote:

>
>
> I have to admit that this FPU has me thinking quite a bit. It's not as easy
> as I thought to wite Migen so that requires some time. It's much easier to
> build a simple ALU for integer stuff in a CPU than it is to build FPU.


Uh-huh :)  an  integer ALU can be written in, what... under 50 lines of
verilog, because verilog has support for basic integer operations, it is
almost just a case statement!

An FPU, we see the number splits in two parts (three including sign bit),
so scaling is needed, and, unlike integer ops, overflow occurs.

Imagine instead in verilog of being allowed to use *, you have to write
your own multiply pipeline.



> even the functions
> > like packToF32UI could potentially be blindly replicated with hardware
> > variants..
>
>
> For me it's not that easy. I am used to thinking of something from my head
> than implement it.


>
Yehyeh, that's the normal way. I am a bit abnormal / lazy.  I find some
code that is proven to work and has a strong userbase (lots of eyes, lots
of testing), find some really good unit tests, then plan a strategy to
convert it.

It is very odd because you are not necessarily actually knowing at a low
level how the code itself works. There is this really weird period, during
the translation phase, which feels like you just jumped across a chasm,
what am I doooiiiiiing :)

Then you get to run the first unit tests, it all works, yet you still don't
have a full understanding of the code! You just know it works, and can even
prove that.

Understanding comes much later, as exposure to the code and the tests begin
to sink in.

It is an approach that is not for everyone, I can however attest to it
saving absolutely vast amounts of time, literally an order of magnitude
over starting from scratch.

In the end it comes down to what *you* want to do. How do *you* want to
tackle it? Would you feel like you had learned something by using the
from-scratch method or another method?

Whatever you choose, I'm happy to support your choice.

Either way, I am thinking of setting up some stub classes and putting in
some ascii art diagrams representing the sign, mantissa and exponent, and
sort-of drawing out the FADD algorithm as best I can make it out, to see if
that helps at all.

What do you think of that idea?


>  This is a bit new to me but I am positive that we can do
> it. I haven't written any code yet cuz migen, but once i get it fully i
> will start the development. Now its just small examples until i figure it
> out (passing "self" to everything is a bit strange to a C/C++ guy).
>
>
"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.


i leave it up to you to decide? :)
>
>
> Not sure yet actually. There are a lot of stuff to figure out :)
>
> On another note - i apologize if i had been a bit inactive as i had to deal
> with some stuff in life, but i am actively thinking about this. So sorry
> for inactivity :)


Silence is the basis of activity.

Bram Cohen designed the entirety of bittorrent in his head, not talking to
anyone about it, then sat down and coded straight for 3 months.

Dr Stallman did something similar, except he was typing 2 fingers peck peck
for so long and so fast he ended up filling up the keyboard buffers on the
terminals he was using, and often had to wait for a minute for the machine
to catch up.

L



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