HPPA FPU Specification? (FE_INEXACT raised by accident)
jda,
I've noticed that I cannot generate an underflow or overflow exception without also forcing an inexact exception on my PA 2.0 system. Are you familiar with this behaviour at all? I'm trying to straighten our fenv setup, and this is really the last crinkle.
Raising an overflow is done with "DBL_MAX + DBL_MAX", while the underflow is "DBL_MIN/3.0". Both raise FE_INEXACT aswell.
Cheers,
Carlos.
Quoted 4 lines
I've noticed that I cannot generate an underflow or overflow exception without also forcing an inexact exception on my PA 2.0 system. Are you familiar with this behaviour at all? I'm trying to straighten our fenv setup, and this is really the last crinkle.
I suggest looking at page 10-7. It describes the PA 2.0 behavior for this situation. I'm not an IEEE so I don't know offhand what it mandates.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Quoted 8 lines · John David Anglin
Quoted 4 lines
I've noticed that I cannot generate an underflow or overflow exception without also forcing an inexact exception on my PA 2.0 system. Are you familiar with this behaviour at all? I'm trying to straighten our fenv setup, and this is really the last crinkle.
I suggest looking at page 10-7. It describes the PA 2.0 behavior for this situation. I'm not an IEEE so I don't know offhand what it mandates.
Multiple exceptions per instruction is not the intended behaviour :) I need two numbers, that when added only overflow, not overflow and inexact. The same to be said for underflow. Perhaps I just need to dig more.
c.
Quoted 8 lines
Quoted 3 lines
I suggest looking at page 10-7. It describes the PA 2.0 behavior for this situation. I'm not an IEEE so I don't know offhand what it mandates.
Multiple exceptions per instruction is not the intended behaviour :) I need two numbers, that when added only overflow, not overflow and inexact. The same to be said for underflow. Perhaps I just need to dig more.
Well 10-7 talks explicitly about what happens when you get both exceptions on a single instruction. On the otherhand, the discussion of the inexact exception seems to imply that inexact should only occur in an overflow/underflow situation when an overflow/underflow exception doesn't occur. Possibly, the PA implementation is not consistent with IEEE mandated behavior, but I can't be sure.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Quoted 9 lines · John David Anglin
Quoted 8 lines
Quoted 3 lines
I suggest looking at page 10-7. It describes the PA 2.0 behavior for this situation. I'm not an IEEE so I don't know offhand what it mandates.
Multiple exceptions per instruction is not the intended behaviour :) I need two numbers, that when added only overflow, not overflow and inexact. The same to be said for underflow. Perhaps I just need to dig more.
Quoted 6 lines
Well 10-7 talks explicitly about what happens when you get both exceptions on a single instruction. On the otherhand, the discussion of the inexact exception seems to imply that inexact should only occur in an overflow/underflow situation when an overflow/underflow exception doesn't occur. Possibly, the PA implementation is not consistent with IEEE mandated behavior, but I can't be sure.
My reading of 10-7 and the equivalent sections in the PA 1.1 arch doc indicate that it _can_ happen outside of an overflow/underflow situation. It just so happens that it can also be coupled with underflow/overflow exceptions.
Does having them both at the same time violates the behaviour of "feraiseexcept" in the ISO C standard (especially in the case of underflow)? If feraiseexcept is called and only an underflow requested, but underflow and inexact are enabled, what then?
c.
Quoted 12 lines
Quoted 11 lines
Quoted 4 lines
Multiple exceptions per instruction is not the intended behaviour :) I need two numbers, that when added only overflow, not overflow and inexact. The same to be said for underflow. Perhaps I just need to dig more.
Well 10-7 talks explicitly about what happens when you get both exceptions on a single instruction. On the otherhand, the discussion of the inexact exception seems to imply that inexact should only occur in an overflow/underflow situation when an overflow/underflow exception doesn't occur. Possibly, the PA implementation is not consistent with IEEE mandated behavior, but I can't be sure.
Quoted 4 lines
My reading of 10-7 and the equivalent sections in the PA 1.1 arch doc indicate that it _can_ happen outside of an overflow/underflow situation. It just so happens that it can also be coupled with underflow/overflow exceptions.
I wasn't saying that inexact can't happen in other circumstances. I was wrong in including undeflow in the above and I mis-rembered the statement at the top of 10-11. It actually states that an inexact exception shall be signaled if an overflow occurs without an overflow trap.
Quoted 4 lines
Does having them both at the same time violates the behaviour of "feraiseexcept" in the ISO C standard (especially in the case of underflow)? If feraiseexcept is called and only an underflow requested, but underflow and inexact are enabled, what then?
Does this help? The standard says
"Whether the feraiseexcept function additionally raises the inexact exception whenever it raises the overflow or underflow exceptions is implementation defined."
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Quoted 10 lines
Quoted 4 lines
Does having them both at the same time violates the behaviour of "feraiseexcept" in the ISO C standard (especially in the case of underflow)? If feraiseexcept is called and only an underflow requested, but underflow and inexact are enabled, what then?
Does this help? The standard says
"Whether the feraiseexcept function additionally raises the inexact exception whenever it raises the overflow or underflow exceptions is implementation defined."
Also, in F.7.6.2,
"If the argument to the feraiseexcept function in <fenv.h> represents IEC 60559 valid coincident exceptions for atomic operations (namely overflow and inexact, or underflow and inexact) then overflow or underflow is raised before inexact."
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
[parisc-linux] fenv laid to rest, 50% done porting dbl-64 to ldbl-64, no testing yet.
Quoted 11 lines · John David Anglin
Quoted 10 lines
Quoted 4 lines
Does having them both at the same time violates the behaviour of "feraiseexcept" in the ISO C standard (especially in the case of underflow)? If feraiseexcept is called and only an underflow requested, but underflow and inexact are enabled, what then?
Does this help? The standard says
"Whether the feraiseexcept function additionally raises the inexact exception whenever it raises the overflow or underflow exceptions is implementation defined."
Quoted 6 lines
Also, in F.7.6.2,
"If the argument to the feraiseexcept function in <
fenv.h> represents IEC 60559 valid coincident exceptions for atomic operations (namely overflow and inexact, or underflow and inexact) then overflow or underflow is raised before inexact."
Yes, I have already taken this into account. Thanks for all the help with spec interpretation. I appreciate the feedback. We pass all the fenv tests in glibc, but still fail the long double support. I'm about 50% done porting dbl-64 to ldbl-64, might get done in the next few weeks. It would finally give us a functioning long double :)
c.
Re: [parisc-linux] fenv laid to rest, 50% done porting dbl-64 to ldbl-64, no testing yet.
Quoted 5 lines
Yes, I have already taken this into account. Thanks for all the help with spec interpretation. I appreciate the feedback. We pass all the fenv tests in glibc, but still fail the long double support. I'm about 50% done porting dbl-64 to ldbl-64, might get done in the next few weeks. It would finally give us a functioning long double :)
I think we should hold off on implementing this until we get a final decision from HP on whether they will release their quadlib or not.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: [parisc-linux] fenv laid to rest, 50% done porting dbl-64 to ldbl-64, no testing yet.
Quoted 8 lines · John David Anglin
Quoted 5 lines
Yes, I have already taken this into account. Thanks for all the help with spec interpretation. I appreciate the feedback. We pass all the fenv tests in glibc, but still fail the long double support. I'm about 50% done porting dbl-64 to ldbl-64, might get done in the next few weeks. It would finally give us a functioning long double :)
I think we should hold off on implementing this until we get a final decision from HP on whether they will release their quadlib or not.
Noted. I have reordered my hacking queue.
a- Generate new testing deb's for glibc
= Includes providing debian with a new .dpatch (1-2 days)
b- Fix _r_debug.r_map loader problems.
(Timeline unknown)
c- Finish light-weight kernel syscalls for atomic ops
(A few weeks)
d- Continue implementing ldbl-64 based on dbl-64.
= The first 50% was a "test the waters" patch. = It looks *very* feasible and easy to test. = Function renaming, rewriting, casting, and mangling. (A few weeks)
In parallel with my usual upstream pushes.
If HP gets up off their haunches before I get to "d-" then they win :), else I will continue my work on ldbl-64. I *will* hold-off on the release of such an implementation in favour of the 128-bit ldbl. I know full well that once we release the ldbl-64 it will become our ABI.
c.
Re: [parisc-linux] fenv laid to rest, 50% done porting dbl-64 to ldbl-64, no testing yet.
In reply to John David AnglinHi Dave,
Quoted 2 lines
I think we should hold off on implementing this until we get a final decision from HP on whether they will release their quadlib or not.
It's a long time we are awaiting this decision?
In the mean time, does it exists an URL where I can find spec?
Thanks in advance,
Joel
-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.
Re: [parisc-linux] fenv laid to rest, 50% done porting dbl-64 to ldbl-64, no testing yet.
Quoted 4 lines
Quoted 2 lines
I think we should hold off on implementing this until we get a final decision from HP on whether they will release their quadlib or not.
It's a long time we are awaiting this decision?
Yes.
Quoted 1 line
In the mean time, does it exists an URL where I can find spec?
The library implements the basic arithmetic operations for the long double type. I believe that you have to pay to get the spec from ANSI or IEC (ANSI/IEEE Std 754-1985 or IEC 60559). I don't have a copy but possibly you might find one with google. The HP library isn't publicly documented but it's pretty obvious what the routines do.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Quoted 10 lines
Quoted 4 lines
Does having them both at the same time violates the behaviour of "feraiseexcept" in the ISO C standard (especially in the case of underflow)? If feraiseexcept is called and only an underflow requested, but underflow and inexact are enabled, what then?
Does this help? The standard says
"Whether the feraiseexcept function additionally raises the inexact exception whenever it raises the overflow or underflow exceptions is implementation defined."
Ah! I must admit I missed that bit. It does help. It means that I can officially mark our 'fenv' as compliant and wash my hands clean of any worry :)
c.