[parisc-linux] HPPA FPU Specification? (FE_INEXACT raised by accident)

[parisc-linux] HPPA FPU Specification? (FE_INEXACT raised by accident)

[Carlos O'Donell]

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.

[parisc-linux] Re: HPPA FPU Specification? (FE_INEXACT raised by accident)

[John David Anglin]

> 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: HPPA FPU Specification? (FE_INEXACT raised by accident)

[Carlos O'Donell]

On Sun, Oct 19, 2003 at 07:16:03PM -0400, John David Anglin wrote:
> > 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.

Re: [parisc-linux] Re: HPPA FPU Specification? (FE_INEXACT raised by accident)

[John David Anglin]

> > 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: HPPA FPU Specification? (FE_INEXACT raised by accident)

[Carlos O'Donell]

On Mon, Oct 20, 2003 at 11:30:34AM -0400, John David Anglin wrote:
> > > 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.

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.

Re: [parisc-linux] Re: HPPA FPU Specification? (FE_INEXACT raised by accident)

[John David Anglin]

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

> 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: HPPA FPU Specification? (FE_INEXACT raised by accident)

[John David Anglin]

> > 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] Re: HPPA FPU Specification? (FE_INEXACT raised by accident)

[Carlos O'Donell]

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

[parisc-linux] fenv laid to rest, 50% done porting dbl-64 to ldbl-64, no testing yet.

[Carlos O'Donell]

On Mon, Oct 20, 2003 at 12:56:10PM -0400, John David Anglin wrote:
> > > 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."

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.

[John David Anglin]

> 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
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.

[Carlos O'Donell]

On Mon, Oct 20, 2003 at 01:49:17PM -0400, John David Anglin wrote:
> > 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.

[Joel Soete]

Hi Dave,


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

http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] fenv laid to rest, 50% done porting dbl-64 to ldbl-64, no testing yet.

[John David Anglin]

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

> 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
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)