[libre-riscv-dev] IEEE754 FPU

[Aleksandar Kostovic]

>
> 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.

Yes thats what i am getting so far.

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?

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. :)

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.

"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.

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.

Interesting. Didnt know that

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.

On Mon, Feb 11, 2019 at 6:04 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> 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
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>