* [OpenRISC] Fpu tininess @ 2020-03-20 7:21 Stafford Horne 2020-03-21 13:06 ` Andrey Bacherov 0 siblings, 1 reply; 5+ messages in thread From: Stafford Horne @ 2020-03-20 7:21 UTC (permalink / raw) To: openrisc 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> ^ permalink raw reply [flat|nested] 5+ messages in thread
* [OpenRISC] Fpu tininess 2020-03-20 7:21 [OpenRISC] Fpu tininess Stafford Horne @ 2020-03-21 13:06 ` Andrey Bacherov 2020-03-22 0:58 ` Stafford Horne 0 siblings, 1 reply; 5+ messages in thread From: Andrey Bacherov @ 2020-03-21 13:06 UTC (permalink / raw) To: openrisc 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* [OpenRISC] Fpu tininess 2020-03-21 13:06 ` Andrey Bacherov @ 2020-03-22 0:58 ` Stafford Horne 2020-07-25 11:13 ` Andrey Bacherov 0 siblings, 1 reply; 5+ messages in thread From: Stafford Horne @ 2020-03-22 0:58 UTC (permalink / raw) To: openrisc 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 > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* [OpenRISC] Fpu tininess 2020-03-22 0:58 ` Stafford Horne @ 2020-07-25 11:13 ` Andrey Bacherov 2020-07-26 13:15 ` Stafford Horne 0 siblings, 1 reply; 5+ messages in thread From: Andrey Bacherov @ 2020-07-25 11:13 UTC (permalink / raw) To: openrisc 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [OpenRISC] Fpu tininess 2020-07-25 11:13 ` Andrey Bacherov @ 2020-07-26 13:15 ` Stafford Horne 0 siblings, 0 replies; 5+ messages in thread From: Stafford Horne @ 2020-07-26 13:15 UTC (permalink / raw) To: openrisc 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-07-26 13:15 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-20 7:21 [OpenRISC] Fpu tininess Stafford Horne 2020-03-21 13:06 ` Andrey Bacherov 2020-03-22 0:58 ` Stafford Horne 2020-07-25 11:13 ` Andrey Bacherov 2020-07-26 13:15 ` Stafford Horne
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.