This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
RE: PATCH: libffi vs. SPARC (again)
- From: Jeff Sturm <jsturm at one-point dot com>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: java-patches at gcc dot gnu dot org
- Date: Thu, 15 Nov 2001 23:51:15 -0500 (EST)
- Subject: RE: PATCH: libffi vs. SPARC (again)
On Wed, 14 Nov 2001, Boehm, Hans wrote:
> It doesn't look to me like the patch works for a big-endian 64-bit machine,
> e.g. sparc64?
Probably not. But it would never have really worked anyway.
I'd like to have tested sparc V9, but I'm having trouble building it on
the trunk.
> I'm also concerned that we're adding overhead on little-endian machines
> where it doesn't really matter. (My impression was that libffi always
> promoted to a word in the same sense that the C compiler promotes arguments,
> i.e. the real result is in the low order bits of the word. Is that not
> right?)
That's how I understand it. Little-endian does make things easier, but
also hides bugs.
> I suspect it would be hard for the compiler to deduce that this is
> all a no-op. It does seem ugly to distinguish based on endian-ness. But if
> we believe that this is time-critical code, I'd be inclined to do so.
Right now I'd prefer correct over fast. Eventually I think it could be
more efficient on all targets. Libffi knows about things like endianness,
so the best plan long-term may be adding e.g. some macros to libffi
that could make it more portable and efficient.
I'll look into revising this patch. Thank you Hans, Bryce and Tom for the
feedback.
Jeff