Re: sparc vs lapack

[craig at jcb-sc dot com]

>craig@jcb-sc.com wrote:
>
>> >However, ISO C9X added all sorts of gnifty complex math functions,
>> >and so I have to fix the problem to pass the brand new glibc tests.
>>
>> Ah, indeed.  Might also be worth making sure we DTRT vis-a-vis the
>> C++ complex type, whatever that is -- does the ABI consider it a
>> complex type, or is it just a class that happens to be implemented
>> as a struct with two floats?
>
>It's a template class, _but_ its implementation is implementation-
>defined (imagine that :-). The standard only mandates the interface;
>an implementation can use a native complex type internally.

This adds a bit of clarity to my previously fuzzy feeling, or instinct,
that any ABI that requires implementation of a complex data type to be
handled differently from implementation of the "equivalent" C struct
is, well, broken by design.

Now, maybe if it very specifically requires this distinction for
*Fortran* COMPLEX, or otherwise enumerates the specific languages,
and limits that list to languages the implement COMPLEX as a built-in
type (i.e. one users, or system header files, don't create entirely out
of lower-level constructs), it isn't *entirely* broken...

...but it's less useful than one that leaves higher-level types like
complex up to the language designer in terms of how they're implemented,
so if the language designer (e.g. compiler) says "our complex data type
is implemented as a C struct", bingo, compatibility *across* several
languages like Fortran (g77, anyway, but most any other "real" compiler),
C, and (I guess) C++ with whatever its canonical libraries provides,
plus others.

But an ABI that just says "the complex single-precision data type gets
passed ..." and doesn't say "just like an aggregate containing two
single-precision values, the first being the real part and the second
being the imaginary part", and doesn't strictly define how one is to decide
whether, e.g., a *user-defined* data type that happens to look like that
aggregate is really what the ABI calls "complex", is too broken to use IMO.

I may be missing some important component to all this, e.g. an industry-
wide, language-wide agreement as to when to call a type "complex".

If not, barring some other degree of clarity, I suggest we consider
declaring that the GCC project *never* obeys an ABI's requirement for
how to deal with "complex" types as such -- it *always* chooses to
obey the requirements for the underlying implementation as chosen by
the language/library combination.

That way, we can explain that we think it's actually *important* that
code written in different languages be able to pass complex data around
to each other without necessarily having to be compiled in exotic ways,
assuming the complex types are encoded in the same way...even though
we certainly don't "solve" the overall cross-language "problem", as
Digital probably does.

(What makes me nervous about my suggestion is that Digital normally
does a bang-up job making their compilers and libraries, for different
languages and such, get along well, at least compared to my experiences
with some other vendors.  So I'm not sure how to reconcile my intuition
that the ABI's under discussion are broken with my experience that
Digital doesn't usually make such mistakes.  It's much easier to do so
if it wasn't Digital's mistake, but OSF's or similar, in favor of my
feeling that the ABI's are broken.  I'd certainly like to see an
explanation of why one language with a native complex type is forced
to not interoperate with another language whose complex type is built
up by the programmer using built-in constructs, to see if it makes any
sense.)

>> This is getting so complex!  ;-)
>
>Yes, it's about time we started thinking about a native
>quaternion type, to make things a bit less boring ...

Well, yes, that'd be funnier to me (I assume ;-) if I remembered what
"quaternion" means...

...but, more worrisome, just how would these ABI's handle a language
that implemented Kahan's idealize (but, apparently, quite implementable)
numerics, whose complex type was built out of a combination of the
built-in real and built-in, or built-up, *imaginary* type?

I don't really have enough cross-platform experience with ABI's, but
from what I've seen, they should limit themselves to describing how
the *machine* (and requisite *operating system*) types are to be passed
around.  Unless the ABI pertains to a system whose *underlying* components
(the OS plus the CPU architecture, aka the iron, itself) necessarily define
a complex type, it shouldn't mention it at all, is my feeling right now.

(Not that this viewpoint, even if based on correct reasoning, solves
everything.  There's still a need for agreement on how to *represent*
complex using the underlying types languages presumably already agree
about, for example.  Another example: a CPU architecture might define
no character type, and maybe it has no need for one at its OS level,
leading to languages choosing different representations for it using
the built-in types -- while the ABI could make language-specific
recommendations in cases like that, it shouldn't really mandate a
language-independent representation, as even C's `char *' and Fortran's
`CHARACTER*(*)' don't get along anyway.  But ABI's should not *add* to
the problem by extending themselves into areas where they're not needed;
at least with the character issue, the industry already understands the
problems there pretty well, while an ABI that makes the complex type
"special" introduces new problems the industry does not appear to already
have, or at least to understand that it has.)

        tq vm, (burley)