Re: GMP compiled under MacOS/C++ wrap

[Hans Aberg]

At 13:02 +0200 2001/04/24, Torbjorn Granlund wrote:
>It is a stretch to call the G4 a 128-bit CPU.  It has SIMD
>instructions operation on 128-bit registers, but it is still a 32-bit
>CPU.

The new "titanium" power book has a G4 with a "velocity engine" which is
claimed to be 128-bit vectored into 4 32-bit words. The memory bus size
also seemed to be 64 or 128 bit, by some speed computations I made.

But I have been unable to find document giving the exact details.

>It is a different question what limb size we should use in GMP.  We
>need a C type that matches a limb, and that limits the choices.  I
>strongly doubt usign anything but 32 bits would be a god idea.

Is this necessary if you write assembler instructions for the basic math
operations?

>  - mpq_swap, mpf_swap are mentioned in the manual, but are not in the gmp.h
>  header.
>
>They seem to be there now.

Is there a later version than <ftp://ftp.gnu.org/pub/gnu/gmp/gmp-3.0.tar.gz>?

They are not in the gmp.h of that version.
>  - mpz_inp_binary
>    mpz_out_binary
>    mpf_ceil
>    mpf_floor
>    mpf_trunc
>  are in the gmp.h header, but have no definition.
>
>True for mpz_inp_binary and mpz_out_binary (now cleaned up), not true
>for the rest.  They are in mpf/integer.c.  Is click-my-icon compilers
>like CodeWarrior might not be capable of compiling a file several
>times?

Probably not. Another problem is that it scans the all sub-directories, so
that files with equal names cannot be compiled. Thus one must either change
the filenames or split up the project into sub-projects with their own
directories.

I will check on mpf/integer.c, and get back on it.

>  I suggest that you use the GNU C/C++ compiler.

This is a good idea, but GCC is not available under pre-MacOS X, except by
using Tenon Mach/UNIX, which I did a few years ago. That old GCC could not
compile my C++ code, so I switched to CodeWarrior because of that.
(MetroWerks is supposed to be owned by Motorola, so they perhaps pump a lot
of money into that company in order to boost the use of their CPU's.)

In general though, I merely report these problems; it is up to you to
decide what is relevant for your distribution. GNU has its own scope.

I think that GCC might lack a good IDE (integrated development
environment), so for that reason, people may still decide to use other
compilers.

For MacOS X, I am told that Apple has works on such an IDE, but it is still
way off. MacOS X does not have X-windows, but it can be obtained
independently.

But then the problem is still to get an IDE for GCC. -- I pointed this out
to RMS recently, though.

>  - When including gmp.h under C++, I ran into the problem that gmp.h defines
>  the keyword "inline" to empty.
>
>No, it does not.  But gmp-impl.h conditionally defines it to empty.
>Is that what you mean?

Yes. The lines gmp-impl.h
#if ! defined (__GNUC__)        /* FIXME: Test for C++ compilers here,
                                   __DECC understands __inline */
#define inline                  /* Empty */
#endif

>  Somehow you have to make sure that "inline"
>  is defined as normal when the header is finished reading, otherwise it
>  produces hard to understand link errors.
>
>I don't understand what you're trying to say here.

If one reads the lines above from a C++ compiler other than GCC, then
"inline" becomes empty, which screws up the subsequent code. Therefore,
before this file ends, you should have
#if ! defined (__GNUC__)        /* FIXME: Test for C++ compilers here,
                                   __DECC understands __inline */
#undef inline                   /* Empty */
#endif
at the end of the file.

Or perhaps use:

#if defined (__GNUC__)  /* FIXME: Test for C++ compilers here,
#define inline_ inline
#else
#define inline_        /* Empty */
#endif
and use inline_ instead of inline in your files.

Or, if you want to make it available on C compilers that can accept
"inline" make a macro:

#if defined (__GNUC__)
#define have_inline
#endif

#ifdef have_inline
#define inline_ inline
#else
#define inline_        /* Empty */
#endif

Then also other compilers that under C can accept "inline" can define it.
-- My compiler did not have any problems with it. Is "inline" a part of the
new C standard?

Or something.

>  - In gmp.h, I noticed the lines:
>    /* Really use `defined (__STDC__)' here; we want it to be true for Sun
>C */
>    #if defined (__STDC__) || defined (__cplusplus)
>  Note that under C++ (cf. C.1.9:1 in the C++ standard), __STDC__
>  implementation defined.
>
>What is your point here?

My impression from reading this comment was that you had put in
"defined(__cplusplus)" just in order to make it work for Sun C/C++ (but I
perhaps read it wrong). But it is normal to not have __STDC__ defined under
C++.

  Hans Aberg