Re: PATCH: libffi vs. SPARC (again)

[Jeff Sturm <jsturm at one-point dot com>]

On 16 Nov 2001, Tom Tromey wrote:
> 
> Jeff> +      switch (rtype->type)
> Jeff> +	{
> Jeff> +	case FFI_TYPE_VOID:
> Jeff> +	  ffi_call (&cif, (void (*)()) meth->ncode, NULL, values);
> Jeff> +	  break;
> Jeff> [ ... ]
> 
> When I wrote JNI, I split _Jv_CallAnyMethodA into two pieces.  Before
> that it was a single function.  In order to avoid a switch like this,
> I used a local jvalue as the ffi_call return value in order to ensure
> proper size and alignment for any result.

That strategy is perfect for the function arguments.  It fails only on the
return type, and only on big-endian targets probably.  (I'm starting to
see why some call it "wrong endian" ;))

We could be seeing this again when we get around to supporting the
interpreter on sparc.  I haven't begun on that yet.

At the moment I'm attempting to test on sparc64, assuming it builds at
all.

Whatever we choose perhaps should also go on the 3.0 branch, which closes
at the end of November.

> In a perfect world we'd go through the library and rethink things like
> how we deal with signatures, and types, and the like.  We have lots of
> little bits of code that look similar but which are slightly different
> (reflection, the interpreter, JNI, the verifier, and the class code
> all have variants on the same stuff).  It isn't fatal, but it does get
> annoying.  I'm mostly to blame for this :-(.

That's not a fair criticism.  Some divergence is inevitable on any project
of this magnitude.  In fact XP teaches us not to be concerned with it...
don't overdesign, but build for today, refactor later.

The trouble with free software projects is that the refactoring never
seems to happen.  Volunteer time is limited and there is a disincentive to
submitting patches any larger than they have to be.  Just look how messy
other parts of gcc have gotten to be.

Jeff