RE: libffi: closures for sparc

["Boehm, Hans" <hans_boehm at hp dot com>]

I dug up a message I sent to a much smaller list about a year ago, and then never got around to doing much about.  It seems to me this leaves the sticky question about where the Java to/from raw conversion should be implemented, since it seems to have to know both about argument passing conventions and Java stacks.  Given a choice, I'd rather have libffi know about Java stacks then having libgcj know about parameter passing.  But if someone can think of a clean way to factor this ...

Hans

--------------------------------

I think conceptually there should be three versions of the interfaces:

1) The original "cooked" model in which argument lists are arrays of pointers.

2) The "raw" model, which should be entirely machine-specific.  On X86, this is the natural in-memory representation of the arguments.  On IA64, it should use the IA64 argument structure I defined, since the arguments are not normally in memory.  In general, it should eventually be the format used by ffi_closure_inner, on something like Alpha.  (It may be that the va_list format is the best choice here.  it seems to be used on Alpha.)  The representation should be opaque to a machine-independent client.  There should be a portable way to convert it to a "cooked" argument list.

Unfortunately, so far this was defined to use the X86 argument representation on all architectures.  Fortunately, I'm not convinced this interface is currently used on anything other than X86, for which it wouldn't change.  (In the short run, I'll only change it for Itanium.)

3) The "java" model, in which arguments are represented as on a JVM stack.  This happens to coincide with (2) for X86, which I think started this confusion.  On X86, this should just be an alias for (2).  On other architectures, there is currently a generic implementation based on (1), which is fine for now, though basing it on (2) in the future would probably make things run faster.

Doing this cleanly would get rid of some ifdefs from libjava.  I think it would make Mozilla happy.  It might also make it possible for someone to actually understand the libffi interface. I would probably change it in unison with libjava to facilitate some renaming (ffi_java_raw -> ffi_java), which shouldn't break any other clients.

But I'd like to run this past Anthony before investing more time.  I'd be undoing some other peoples earlier design decisions (which I suspect were really nondecisions).


> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> Sent: Wednesday, July 17, 2002 2:34 PM
> To: Kresten Krab Thorup
> Cc: gcc-patches@gcc.gnu.org; java-patches@gcc.gnu.org
> Subject: Re: libffi: closures for sparc
> 
> 
> On Wed, 17 Jul 2002, Kresten Krab Thorup wrote:
> > I'm out of the loop now, but it should be known that the 
> "raw" api was
> > thought as an optimized version of the general ffi api 
> which would make
> > sense exactly on architectures where the interpreter's 
> stack (i.e. the
> > union of jint, jchar, etc.) is very similar to the layout 
> of arguments
> > in the host environment's ABI.  As such, it is indeed ugly; 
> and relies
> > on all kinds of assumptions...
> 
> I remember the discussion... the x86 interpreter is efficient 
> because of
> the raw API, which I believe is a good thing, portable or not.
> 
> The plain closure API is fairly portable but realistically is too much
> overhead for an efficient bytecode interpreter.  This may be 
> one of those
> areas we abandon portability.
> 
> Specifically for java_raw_api.c, I'm tempted to pull that layer into
> libgcj where it can operate directly on _Jv_word and perhaps use a
> simpler, more direct interface into libffi.  Perhaps loading argument
> registers directly from the java stack.  But I haven't thought this
> through yet.
> 
> Good to hear from you, Kresten.
> 
> Jeff
>