This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Vector Extensions in GCC
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Subject: Re: Vector Extensions in GCC
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Thu, 12 Jul 2001 00:44:51 -0700
- cc: Stan Shebs <shebs at apple dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
> Do you have something more concrete? Over a third of the C front end is
> now common code used also by C++, a lot more than in 2.95, and a lot more
> is sufficiently similar that it ought to be shared, which is some sort of
> incremental merge but hardly likely to yield a single front end in a
> reasonable amount of time. What about Objective-C?
We are in discussions with people about doing this work, including
Objective-C. If that works out, it will happen in time measurable in
quarters. If not, then it will just remain my pipe-dream.
> Do you have an example of how templates would be used to implement one of
> the <tgmath.h> functions?
I forget the exact <tgmat.h> syntax/semantics, but here's what I had in
mind.
template <typename T> T acos (T);
template <> double acos(double d) { return cos (d); }
template <> float acos(float f) { return cosf (f); }
template <> long double acos(long double l) { return cosl (l); }
If you built up this representation internally, things would just
work. Using templates is a little cheesy here -- overloading would
work well. But, if you had an algorithm that you wanted to encode
(for example, an algorithm for computing `acos', independent of the
precision), then you could omit the specializations, and just
let the compiler instantiate the generic method for the appropriate
types.
For example:
template <typename T> T fmax (T t1, T t2)
{ return t1 ? t2 : t1 : t2; }
I am not sure what the right semantics are if `t1' and `t2' do
not have the same type. You might still need specializations to
handle all the arithmetic promotions, etc.
So, you could be right that overloading is more what you want.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com