[libre-riscv-dev] IEEE754 FPU turning into ALU with Reservation Stations

Aleksandar Kostovic alexandar.kostovic at gmail.com
Thu Mar 14 16:18:05 GMT 2019


also i want you to get involved as well like for when we first did adder
the old way. with both of us working we done that very quickly and your
guidance helped a ton.

On Thu, Mar 14, 2019 at 5:06 PM Aleksandar Kostovic <
alexandar.kostovic at gmail.com> wrote:

> Ok i got it. Will take baby steps to ensure everything works. But the
> amount of code in add.py file is huge and its not the easiest to uderstand,
> so it might take some time...
>
> On Thu, Mar 14, 2019 at 6:48 AM Luke Kenneth Casson Leighton <
> lkcl at lkcl.net> wrote:
>
>> On Thu, Mar 14, 2019 at 3:19 AM Luke Kenneth Casson Leighton <
>> lkcl at lkcl.net>
>> wrote:
>>
>> let's work to get FPMul back up and running, first, ok?
>> >
>>
>>  gaah, finally, that was a pain in the ass.  i'd forgotten to add the
>> submodules to the fmul class:
>> +        m.submodules.of = of
>> +        m.submodules.a = a
>> +        m.submodules.b = b
>> +        m.submodules.z = z
>>
>> consequently all the logic in those modules wasn't being done:
>> is_denormalised and all the other tests were all failing.
>>
>> so, what i suggest, aleksander, is to *slowly* proceed in an *incremental*
>> fashion, keeping FMul running *at all times*.
>>
>> it's possible to run thousands to tens of thousands of unit tests to make
>> absolutely sure that even the smallest code change remains functional and
>> does not result in the wrong answers being generated.
>>
>> once you are "off that path" of generating the wrong answers all the time,
>> it is an absolute hellish nightmare to get back on track.  you have *no
>> idea* which *combination* of changes will happen, by total random chance,
>> to produce the right answer.
>>
>> i just spent about 2 hours debugging FMul, having to go back to git
>> checkout 1ad14, take screenshots of gtkwave, git checkout master, run the
>> (failing) test again, and compare the screenshot against the (failing)
>> gtkwave display in order to track down which function was failing.
>>
>> jacob: just to emphasise - again - *this is why unit tests are so
>> absolutely absolutely critical*.
>>
>> l.
>> _______________________________________________
>> libre-riscv-dev mailing list
>> libre-riscv-dev at lists.libre-riscv.org
>> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>>
>


More information about the libre-riscv-dev mailing list