[OpenRISC] Fpu tininess

[OpenRISC] Fpu tininess

[Stafford Horne]

Hi Andrey,

Thanks for replying to the question about fusesoc.

I've been meaning to ask you a question about our fpu implementation.
Currently for glibc most  floating point math routines use 64-bit double
precision.  Anything not handled by the architecture is emulated.

I have written the emulation patches but the tests are having issues with
underflow flags being incorrectly set sometimes.

I have a hunch it may be due to my tininess setting.   Do you know what we
should set for:

_FP_TININESS_AFTER_ROUNDING

?

The glibc patch
https://github.com/openrisc/or1k-glibc/commit/4748177bdde92846974fc8ec523d212d6db74aa0

The gcc patch
https://github.com/stffrdhrn/gcc/commit/8e99e252edc130162b6d2d7bdef2180305389053
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20200320/457573eb/attachment.html>

[OpenRISC] Fpu tininess

[Andrey Bacherov]

Hello Stafford

ORK1 FPU implements tininess after rounding.

https://github.com/bandvig/or1k_testfloat/blob/994c84b8c11f3609772c318f8894ecbad860bd89/src/testfloat.c#L145

At least it should...

I must admit that I wasn't FP-guru while was implementing FP :). And I'm 
not FP-guru now. :). Perhaps I don't understand FP-standard clearly in 
all aspects. As a result "underflow flag" behavior doesn't meet standard 
completely. And I temporary blocked "underflow flag" behavior 
verification in my version of test_float tool:

https://github.com/bandvig/or1k_testfloat/blob/994c84b8c11f3609772c318f8894ecbad860bd89/src/milieu.h#L50

"Underflow flag" behavior correction is in my TODO list, but I'm not 
sure that I could pay enough attention for it.
BTW, it could be task for GSoC, if somebody would be ready to become a 
mentor.

WBR
Andrey


20.03.2020 10:21, Stafford Horne wrote:
> Hi Andrey,
> 
> Thanks for replying to the question about fusesoc.
> 
> I've been meaning to ask you a question about our fpu implementation.  
> Currently for glibc most  floating point math routines use 64-bit double 
> precision.  Anything not handled by the architecture is emulated.
> 
> I have written the emulation patches but the tests are having issues 
> with underflow flags being incorrectly set sometimes.
> 
> I have a hunch it may be due to my tininess setting.   Do you know what 
> we should set for:
> 
> _FP_TININESS_AFTER_ROUNDING
> 
> ?
> 
> The glibc patch
> https://github.com/openrisc/or1k-glibc/commit/4748177bdde92846974fc8ec523d212d6db74aa0
> 
> The gcc patch
> https://github.com/stffrdhrn/gcc/commit/8e99e252edc130162b6d2d7bdef2180305389053
> 
> _______________________________________________
> OpenRISC mailing list
> OpenRISC at lists.librecores.org
> https://lists.librecores.org/listinfo/openrisc
> 

[OpenRISC] Fpu tininess

[Stafford Horne]

On Sat, Mar 21, 2020 at 04:06:45PM +0300, Andrey Bacherov wrote:
> Hello Stafford
> 
> ORK1 FPU implements tininess after rounding.
> 
> https://github.com/bandvig/or1k_testfloat/blob/994c84b8c11f3609772c318f8894ecbad860bd89/src/testfloat.c#L145

Thanks, I also set glibc and gcc to emulate with tininess after rounding.
I just tried to run all the tests after switch tininess after rounding off as
well and get the same results.  Perhaps the issue with the underflow flag is not
related to the tininess setting.

Right now my tests are running completely on QEMU simulators.  I was able to track
one of the underflow issues to the software implementation of 'log' to me it
looked like an issue in the soft float implementation.

There are so many layers here, qemu float emulation, gcc float emulation glibc
floating point routines.  I have probably just have something wrong on one
layer,  but I wanted to be sure the simulation is inline with the hardware.


> At least it should...
> 
> I must admit that I wasn't FP-guru while was implementing FP :). And I'm not
> FP-guru now. :). Perhaps I don't understand FP-standard clearly in all
> aspects. As a result "underflow flag" behavior doesn't meet standard
> completely. And I temporary blocked "underflow flag" behavior verification
> in my version of test_float tool:
> 
> https://github.com/bandvig/or1k_testfloat/blob/994c84b8c11f3609772c318f8894ecbad860bd89/src/milieu.h#L50
> 
> "Underflow flag" behavior correction is in my TODO list, but I'm not sure
> that I could pay enough attention for it.
> BTW, it could be task for GSoC, if somebody would be ready to become a
> mentor.

Are your volunteering to mentor a student?  We can raise a project proposal
under the librecores GSoC program.

-Stafford

> WBR
> Andrey
> 
> 
> 20.03.2020 10:21, Stafford Horne wrote:
> > Hi Andrey,
> > 
> > Thanks for replying to the question about fusesoc.
> > 
> > I've been meaning to ask you a question about our fpu implementation.
> > Currently for glibc most  floating point math routines use 64-bit double
> > precision.  Anything not handled by the architecture is emulated.
> > 
> > I have written the emulation patches but the tests are having issues
> > with underflow flags being incorrectly set sometimes.
> > 
> > I have a hunch it may be due to my tininess setting.   Do you know what
> > we should set for:
> > 
> > _FP_TININESS_AFTER_ROUNDING
> > 
> > ?
> > 
> > The glibc patch
> > https://github.com/openrisc/or1k-glibc/commit/4748177bdde92846974fc8ec523d212d6db74aa0
> > 
> > The gcc patch
> > https://github.com/stffrdhrn/gcc/commit/8e99e252edc130162b6d2d7bdef2180305389053
> > 
> > _______________________________________________
> > OpenRISC mailing list
> > OpenRISC at lists.librecores.org
> > https://lists.librecores.org/listinfo/openrisc
> > 

[OpenRISC] Fpu tininess

[Andrey Bacherov]

Sorry for the very late reply, Stafford.

>>
>> ORK1 FPU implements tininess after rounding.
>>
>> https://github.com/bandvig/or1k_testfloat/blob/994c84b8c11f3609772c318f8894ecbad860bd89/src/testfloat.c#L145
> 
> Thanks, I also set glibc and gcc to emulate with tininess after rounding.
> I just tried to run all the tests after switch tininess after rounding off as
> well and get the same results.  Perhaps the issue with the underflow flag is not
> related to the tininess setting.
> 
> Right now my tests are running completely on QEMU simulators.  I was able to track
> one of the underflow issues to the software implementation of 'log' to me it
> looked like an issue in the soft float implementation.
> 
> There are so many layers here, qemu float emulation, gcc float emulation glibc
> floating point routines.  I have probably just have something wrong on one
> layer,  but I wanted to be sure the simulation is inline with the hardware.

I've re-implemented tininess detection and underflow flag behavior.
https://github.com/openrisc/or1k_marocchino/pull/20
Now FPU perform tininess detection BEFORE rounding because the approach 
looks simpler.
I verified the mods with TestFloat tool with unlocked underflow check.
As I wrote in the comment of the pull request I'm interested to have 
ability to run glibc FP-related tests on my Atlys board. Could you guide 
me which glibc and gcc sources would be better for that? From your forks 
or from upstream?
And how build and run glibc tests?

> Are your volunteering to mentor a student?  We can raise a project proposal
> under the librecores GSoC program.

I'm apologize, but supervising is definitely not for me.

WBR
Andrey

[OpenRISC] Fpu tininess

[Stafford Horne]

On Sat, Jul 25, 2020 at 02:13:14PM +0300, Andrey Bacherov wrote:
> Sorry for the very late reply, Stafford.
> 
> > > 
> > > ORK1 FPU implements tininess after rounding.
> > > 
> > > https://github.com/bandvig/or1k_testfloat/blob/994c84b8c11f3609772c318f8894ecbad860bd89/src/testfloat.c#L145
> > 
> > Thanks, I also set glibc and gcc to emulate with tininess after rounding.
> > I just tried to run all the tests after switch tininess after rounding off as
> > well and get the same results.  Perhaps the issue with the underflow flag is not
> > related to the tininess setting.
> > 
> > Right now my tests are running completely on QEMU simulators.  I was able to track
> > one of the underflow issues to the software implementation of 'log' to me it
> > looked like an issue in the soft float implementation.
> > 
> > There are so many layers here, qemu float emulation, gcc float emulation glibc
> > floating point routines.  I have probably just have something wrong on one
> > layer,  but I wanted to be sure the simulation is inline with the hardware.
> 
> I've re-implemented tininess detection and underflow flag behavior.
> https://github.com/openrisc/or1k_marocchino/pull/20
> Now FPU perform tininess detection BEFORE rounding because the approach
> looks simpler.
> I verified the mods with TestFloat tool with unlocked underflow check.
> As I wrote in the comment of the pull request I'm interested to have ability
> to run glibc FP-related tests on my Atlys board. Could you guide me which
> glibc and gcc sources would be better for that? From your forks or from
> upstream?
> And how build and run glibc tests?

Hi Andrey,

This is good news.  I have a few branches I use here:

 - GCC - https://github.com/stffrdhrn/gcc/tree/or1k-glibc-1
 - GLIBC - https://github.com/openrisc/or1k-glibc/tree/or1k-port-1
 - Building - https://github.com/stffrdhrn/or1k-utils/tree/master/glibc

I am currently working on revision 2 of the glibc patches but have gotten
sidetracked trying to fix from linux stability issues.

I don't really have any directions for doing the build and running on atlsys.
If you have built and run inux before it should be pretty staight forward.

Have a look at the scripts in or1k-utils/glibc:

 - The top level script for building everything is: glibc.build
 - I have also included things that the test depends on like setting up a chroot
   environment, installing bash, coreutils, dropbear ssh.
 - Next I have glibc.test for running tests

This is all not the "recommended" way for building and running tests, most
people would use something like buildroot.  Also, in glibc they have something
called "buildbot": https://sourceware.org/glibc/wiki/Buildbot and there is also
something in the glibc project called: scripts/build-many-glibcs.py which I
haven't figure out how to use yet.

> > Are your volunteering to mentor a student?  We can raise a project proposal
> > under the librecores GSoC program.
> 
> I'm apologize, but supervising is definitely not for me.

That's ok, I may miss it this year too.

-Stafford