Preprocessor arithmetic

Preprocessor arithmetic

[Neil Booth]

Can someone explain to me what is wrong with CPP's arithmetic (as
referred to on the web page)?

All arithmetic in CPP is done in HOST_WIDEST_INT.  My understanding is
that this is the widest integer that GCC can support on the host;
which is usually twice the processor's native widest integer (itself
being HOST_WIDE_INT).

If I don't have it right so far, please correct me.

The standard defines intmax_t and uintmax_t as the "greatest width
integer types"; capable of representing any value of any (un)signed
type.  Preprocessor arithmetic should be done in these types.

These types seem to be the same thing to me.  What am I missing?

Neil.

Re: Preprocessor arithmetic

[Richard Henderson]

On Mon, Nov 13, 2000 at 11:41:00PM +0000, Neil Booth wrote:
> These types seem to be the same thing to me.  What am I missing?

Host vs target intmax_t.


r~

Re: Preprocessor arithmetic

[Zack Weinberg]

On Mon, Nov 13, 2000 at 11:41:00PM +0000, Neil Booth wrote:
> Can someone explain to me what is wrong with CPP's arithmetic (as
> referred to on the web page)?
> 
> All arithmetic in CPP is done in HOST_WIDEST_INT.  My understanding is
> that this is the widest integer that GCC can support on the host;
> which is usually twice the processor's native widest integer (itself
> being HOST_WIDE_INT).
> 
> If I don't have it right so far, please correct me.
> 
> The standard defines intmax_t and uintmax_t as the "greatest width
> integer types"; capable of representing any value of any (un)signed
> type.  Preprocessor arithmetic should be done in these types.
> 
> These types seem to be the same thing to me.  What am I missing?

Host versus target.  [u]intmax_t is the _target_'s largest integer
type.  HOST_WIDEST_INT is the host's.  They aren't necessarily the
same thing.

It's only an issue when cross-compiling from or to a machine with an
unusual definition of either type - I think all commonly used machines
these days have both be 64bit.  But it's still a concern.

zw

Re: Preprocessor arithmetic

[Neil Booth]

Zack Weinberg wrote:-

> Host versus target.  [u]intmax_t is the _target_'s largest integer
> type.  HOST_WIDEST_INT is the host's.  They aren't necessarily the
> same thing.
> 
> It's only an issue when cross-compiling from or to a machine with an
> unusual definition of either type - I think all commonly used machines
> these days have both be 64bit.  But it's still a concern.

It sounds non-trivial to fix in the case where the target is wider.
Or are we only worried about cases where target < host, which is
easier?  I imagine it wouldn't be too hard to get that case correct
now.

Neil.

Re: Preprocessor arithmetic

[Zack Weinberg]

On Tue, Nov 14, 2000 at 07:30:20AM +0000, Neil Booth wrote:
> Zack Weinberg wrote:-
> 
> > Host versus target.  [u]intmax_t is the _target_'s largest integer
> > type.  HOST_WIDEST_INT is the host's.  They aren't necessarily the
> > same thing.
> > 
> > It's only an issue when cross-compiling from or to a machine with an
> > unusual definition of either type - I think all commonly used machines
> > these days have both be 64bit.  But it's still a concern.
> 
> It sounds non-trivial to fix in the case where the target is wider.
> Or are we only worried about cases where target < host, which is
> easier?  I imagine it wouldn't be too hard to get that case correct
> now.

Either.  Think about cross-compiling from a 32-bit machine to a brand
new shiny 128-bit chip.  Okay, this is less likely than cross-
compiling from a 32-bit machine to an embedded 16- or 8-bit chip, but
no less wrong.

zw

Re: Preprocessor arithmetic

[Neil Booth]

Zack Weinberg wrote:-

> Either.  Think about cross-compiling from a 32-bit machine to a brand
> new shiny 128-bit chip.  Okay, this is less likely than cross-
> compiling from a 32-bit machine to an embedded 16- or 8-bit chip, but
> no less wrong.

Right.  In other words, we require arbitrary precision integer
arithmetic.  My understanding is that not even the compiler proper
does this.

What's the long term goal in this area?  To write a library to handle
such arithmetic, and use it in cpp and the front ends?

Neil.

Re: Preprocessor arithmetic

[Zack Weinberg]

On Wed, Nov 15, 2000 at 07:43:06AM +0000, Neil Booth wrote:
> Zack Weinberg wrote:-
> 
> > Either.  Think about cross-compiling from a 32-bit machine to a brand
> > new shiny 128-bit chip.  Okay, this is less likely than cross-
> > compiling from a 32-bit machine to an embedded 16- or 8-bit chip, but
> > no less wrong.
> 
> Right.  In other words, we require arbitrary precision integer
> arithmetic.  My understanding is that not even the compiler proper
> does this.

The compiler proper has support for up to 2*HOST_WIDE_INT integer
arithmetic (actually operating on tree nodes).  I think.

> What's the long term goal in this area?  To write a library to handle
> such arithmetic, and use it in cpp and the front ends?

Hm, g95 presently uses libgmp for integer and floating point
arithmetic simulation.  It might not be a bad idea to scrap what we
have and use libgmp everywhere - particularly the floating point
emulator.

zw

Re: Preprocessor arithmetic

[Michael Meissner]

On Wed, Nov 15, 2000 at 12:22:54AM -0800, Zack Weinberg wrote:
> On Wed, Nov 15, 2000 at 07:43:06AM +0000, Neil Booth wrote:
> > Zack Weinberg wrote:-
> > 
> > > Either.  Think about cross-compiling from a 32-bit machine to a brand
> > > new shiny 128-bit chip.  Okay, this is less likely than cross-
> > > compiling from a 32-bit machine to an embedded 16- or 8-bit chip, but
> > > no less wrong.
> > 
> > Right.  In other words, we require arbitrary precision integer
> > arithmetic.  My understanding is that not even the compiler proper
> > does this.
> 
> The compiler proper has support for up to 2*HOST_WIDE_INT integer
> arithmetic (actually operating on tree nodes).  I think.
> 
> > What's the long term goal in this area?  To write a library to handle
> > such arithmetic, and use it in cpp and the front ends?
> 
> Hm, g95 presently uses libgmp for integer and floating point
> arithmetic simulation.  It might not be a bad idea to scrap what we
> have and use libgmp everywhere - particularly the floating point
> emulator.

It depends which floating point emulator you are talking about.  The one in
real.c, certainly.  The one in config/fp-bit.c, I would say not at this time,
since AFAIK, gmp doesn't have the libgcc exception to allow users to link it
in.  Also, we would have to fold gmp into libgcc.a.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: Preprocessor arithmetic

[Zack Weinberg]

On Wed, Nov 15, 2000 at 03:49:40AM -0500, Michael Meissner wrote:
> On Wed, Nov 15, 2000 at 12:22:54AM -0800, Zack Weinberg wrote:
> > 
> > Hm, g95 presently uses libgmp for integer and floating point
> > arithmetic simulation.  It might not be a bad idea to scrap what we
> > have and use libgmp everywhere - particularly the floating point
> > emulator.
> 
> It depends which floating point emulator you are talking about.  The one in
> real.c, certainly.  The one in config/fp-bit.c, I would say not at this time,
> since AFAIK, gmp doesn't have the libgcc exception to allow users to link it
> in.  Also, we would have to fold gmp into libgcc.a.

I was talking about real.c.

I dimly remember someone offering us a complete replacement for
fp-bit.c, which got ignored by the mailing list.  I may have
hallucinated this - casual search of the archive doesn't show it.  If
it happened, it would've been in early 1999.

zw

Re: Preprocessor arithmetic

[Hans-Peter Nilsson]

> Date: Wed, 15 Nov 2000 01:01:49 -0800
> From: "Zack Weinberg" <zackw@Stanford.EDU>

> I dimly remember someone offering us a complete replacement for
> fp-bit.c, which got ignored by the mailing list.  I may have
> hallucinated this - casual search of the archive doesn't show it.  If
> it happened, it would've been in early 1999.

A search for "tege floating point" turned up this as #1:

<URL: http://gcc.gnu.org/ml/gcc/1999-07n/msg00553.html >

Would be nice if fp-bit was replaced.  It is 3 times slower than
the (older, less correct) floatlib.c for CRIS.

What were the issues with that new library?  Is there any reason
why it isn't used, besides common inertia and lack of time to
check it?  I haven't tried it, though, but I take Tege's word
for it (until I get time to test it).

brgds, H-P

Re: Preprocessor arithmetic

[Joern Rennecke]

> Hm, g95 presently uses libgmp for integer and floating point
> arithmetic simulation.  It might not be a bad idea to scrap what we
> have and use libgmp everywhere - particularly the floating point
> emulator.

I think that doing tree and rtl arithmetic (e.g. for fold-const.c, (g)cse.c
and combine.c) with gmp would slow the compiler down.

Re: Preprocessor arithmetic

[Richard Henderson]

On Wed, Nov 15, 2000 at 05:34:56PM +0000, Joern Rennecke wrote:
> I think that doing tree and rtl arithmetic (e.g. for fold-const.c, (g)cse.c
> and combine.c) with gmp would slow the compiler down.

On the other hand, it would allow the compiler to function
at all in cases where more than two host words are needed.



r~

Re: Preprocessor arithmetic

[Joern Rennecke]

> On the other hand, it would allow the compiler to function
> at all in cases where more than two host words are needed.

Well, we could autoconf it on the host word size being larger than
2 * HOST_WIDE_INT.

Re: Preprocessor arithmetic

[Richard Henderson]

On Wed, Nov 15, 2000 at 08:28:58PM +0000, Joern Rennecke wrote:
> Well, we could autoconf it on the host word size being larger than
> 2 * HOST_WIDE_INT.

Certainly.  Not something to worry about now though.


r~

Re: Preprocessor arithmetic

[Jim Wilson]

In article < 20001115010149.J8418@wolery.stanford.edu > you write:
>I dimly remember someone offering us a complete replacement for
>fp-bit.c, which got ignored by the mailing list.

http://gcc.gnu.org/ml/gcc/1999-07n/msg00553.html

Jim

Re: Preprocessor arithmetic

[Mark Mitchell]

>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:

    Richard> On the other hand, it would allow the compiler to
    Richard> function at all in cases where more than two host words
    Richard> are needed.

Yes.  I've been thinking about this for years, off an on.

EDG's compiler uses arbitrary numbers of host words, and that really
is necessary.  There are 32-bit chips without 64-bit data types, that
need to cross compile to 64-bit chips with 128-bit data types.
Whether we use gmp, or roll a small library of our own, we need this
functionality.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Preprocessor arithmetic

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

> EDG's compiler uses arbitrary numbers of host words, and that really
> is necessary.  There are 32-bit chips without 64-bit data types, that
> need to cross compile to 64-bit chips with 128-bit data types.
> Whether we use gmp, or roll a small library of our own, we need this
> functionality.

Do we really support cross-compiling from any chip for which we don't
support a 64-bit data type?  I can't think of any.

BFD will usually require a 64-bit data type when cross-compiling to a
64-bit chip, and this hasn't caused any trouble to date.  128-bit
types are more tricky, but IMHO it'd be not much more work to simply
implement a 128-bit type in those native 32-bit compilers, and more
useful, and would give a faster cpp.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Preprocessor arithmetic

[Mark Mitchell]

>>>>> "Geoff" == Geoff Keating <geoffk@geoffk.org> writes:

    Geoff> Mark Mitchell <mark@codesourcery.com> writes:

    >> EDG's compiler uses arbitrary numbers of host words, and that
    >> really is necessary.  There are 32-bit chips without 64-bit
    >> data types, that need to cross compile to 64-bit chips with
    >> 128-bit data types.  Whether we use gmp, or roll a small
    >> library of our own, we need this functionality.

    Geoff> Do we really support cross-compiling from any chip for
    Geoff> which we don't support a 64-bit data type?  I can't think
    Geoff> of any.

I don't know.

I do recally having trouble building cross-compilers from IA32 to IA64
due to issues with 128-bit types -- but of course IA32 does have a
64-bit type.

In general, however, there are operations that we punt on because of
our HOST_WIDE_INT pairs (like, for example, printing out large numbers
in error messages), and GMP would solve all of those problems for us
rather tidily.  It's possible that we could also make a version of GMP
that didn't allow *arbitrary* precision, but instead allowed just
enough.  The point is that there are routines in there to do all kinds
of useful stuff that otherwise we have to reinvent inside the
compiler.

It's hard to know what the performance issues will mean until we
measure...

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Preprocessor arithmetic

[Torbjorn Granlund]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

Joern Rennecke <amylaar@redhat.com> writes:

  > Hm, g95 presently uses libgmp for integer and floating point
  > arithmetic simulation.  It might not be a bad idea to scrap what we
  > have and use libgmp everywhere - particularly the floating point
  > emulator.
  
  I think that doing tree and rtl arithmetic (e.g. for fold-const.c, (g)cse.c
  and combine.c) with gmp would slow the compiler down.
  
Yes, using GMP, at least it high-level functions is not a good idea.
It is better to implement a little special library for fixed
precision.  After all, fixed precision is what the compiler really
needs.

Regarding using GMP's float functions instead of real.c, I'd vote
against that too.  GMP's floats are heavy weight, and only a new
experimental function calls supports true IEEE rounding.

But my ieeelib.c which I contributed years ago might be a starting
point for a fast real.c replacement.

--
Torbjörn
(GMP author)

Re: Preprocessor arithmetic

[Bill Wendling]

Also sprach Mark Mitchell:
} >>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:
} 
}     Richard> On the other hand, it would allow the compiler to
}     Richard> function at all in cases where more than two host words
}     Richard> are needed.
} 
} Yes.  I've been thinking about this for years, off an on.
} 
} EDG's compiler uses arbitrary numbers of host words, and that really
} is necessary.  There are 32-bit chips without 64-bit data types, that
} need to cross compile to 64-bit chips with 128-bit data types.
} Whether we use gmp, or roll a small library of our own, we need this
} functionality.
} 
Would it be possible to simply canibalize gmp for the parts we want
(skipping the rest) or is it that noone has any copious spare time left
:).

-- 
|| Bill Wendling			wendling@ncsa.uiuc.edu
|| Coding Simian

Re: Preprocessor arithmetic

[David Starner]

On Wed, Nov 15, 2000 at 12:22:54AM -0800, Zack Weinberg wrote:
> Hm, g95 presently uses libgmp for integer and floating point
> arithmetic simulation.  It might not be a bad idea to scrap what we
> have and use libgmp everywhere - particularly the floating point
> emulator.

GNAT uses some handwritten Ada code to handle it, which I think somebody
offer to port to C if it turned out that it was useful to more than
GNAT.

-- 
David Starner - dstarner98@aasaa.ofe.org
http://dvdeug.dhis.org
As centuries of pulp novels and late-night Christian broadcasting have taught 
us, anything we don't understand can be used for the purposes of Evil.
	-- Kenneth Hite, Suppressed Transmissions

Re: Preprocessor arithmetic

[Zack Weinberg]

On Wed, Nov 15, 2000 at 03:30:20PM +0100, Hans-Peter Nilsson wrote:
> > Date: Wed, 15 Nov 2000 01:01:49 -0800
> > From: "Zack Weinberg" <zackw@Stanford.EDU>
> 
> > I dimly remember someone offering us a complete replacement for
> > fp-bit.c, which got ignored by the mailing list.  I may have
> > hallucinated this - casual search of the archive doesn't show it.  If
> > it happened, it would've been in early 1999.
> 
> A search for "tege floating point" turned up this as #1:
> 
> <URL: http://gcc.gnu.org/ml/gcc/1999-07n/msg00553.html >
> 
> Would be nice if fp-bit was replaced.  It is 3 times slower than
> the (older, less correct) floatlib.c for CRIS.
> 
> What were the issues with that new library?  Is there any reason
> why it isn't used, besides common inertia and lack of time to
> check it?  I haven't tried it, though, but I take Tege's word
> for it (until I get time to test it).

Hard to say when no one said anything about it.  I imagine floating
point emulation isn't important to most developers, who work on chips
with hardware FPUs.

I'm prepared to take Tege's word for the functionality.  It'd need a
bit of work to fit into the current framework; fp-bit currently gets
split up with #ifdefs so that we get only one routine per object file,
and the embedded people won't want to lose that.  Shouldn't be hard
though.

As Tege suggested downthread, I think replacing real.c with ieeelib.c
might be interesting.  For one thing, if it were fast enough that we
could use it all the time, we could stop worrying about trapping
SIGFPE and attempting to recover.  And real.c is a crawling horror
anyway.

I'd like to see the code at least checked into the tree; then we can
convert over incrementally.

zw

Re: Preprocessor arithmetic

[William C. Cox]

On Wed, Nov 15, 2000 at 03:49:40AM -0500, Michael Meissner wrote:
> On Wed, Nov 15, 2000 at 12:22:54AM -0800, Zack Weinberg wrote:
> > 
> > Hm, g95 presently uses libgmp for integer and floating point
> > arithmetic simulation.  It might not be a bad idea to scrap what we
> > have and use libgmp everywhere - particularly the floating point
> > emulator.
> 
> It depends which floating point emulator you are talking about.  The one in
> real.c, certainly.  The one in config/fp-bit.c, I would say not at this time,
> since AFAIK, gmp doesn't have the libgcc exception to allow users to link it
> in.  Also, we would have to fold gmp into libgcc.a.

I was talking about real.c.

I dimly remember someone offering us a complete replacement for
fp-bit.c, which got ignored by the mailing list.  I may have
hallucinated this - casual search of the archive doesn't show it.  If
it happened, it would've been in early 1999.

Check with Torbjorn Granlund <tege@swox.ab>.  He wrote one
about 18 months ago...