[Openmcl-devel] GCC4-based interface translator available for testing

[Gary Byers]

There's a preliminary version of a GCC4-based interface translator
available in ftp://clozure.com/pub/testing/:

INSTALL-FFIGEN-darwinppc-gcc-4.0-20050326.txt   contains terse installation
						instructions
ffigen-bin-darwinppc-gcc-4.0-20050326.tar.gz	binaries for Darwin; Linux
						binaries should be available
						soon.
ffigen4-src-050408.tar.gz			"sources" (i.e., diffs and
						a Makefile.)

GCC-4.0 hasn't been officially released yet; this is based on a fairly
recent (March 26) snapshot.  "snapshot" archives are available from
gcc.gnu.org and its mirror sites.  I'll try to keep this fairly current
(at least until the final GCC-4.0 release.)

In the past, Apple has made sources to their own modified versions of
GCC available on www.opensource.apple.com.  I don't know whether the
"final" Apple GCC 4.0 release will differ from the final GNU release
in any significant way; if so, this should probably be synched with
that release as well.

The binaries will only run on OSX 10.3 or later; it's not clear to
me whether GCC 4 can be built on 10.2, and I didn't try.

There -may- be some issues related to internationalization of error
messages; that may also change when GCC 4 becomes a "final" release.

I've tested this -some-, and have found a few quirks and oddities but
(so far) no major problems.  Some of the quirks/oddities:

- some previous Apple GCC releases recognized __private_extern__ as
  a C storage class (or something triggered a C macro definition of
  that symbol.)  This construct is used in a few Apple header files;
  doing:

shell> h-to-ffi.sh -D__private_extern__=extern /path/to/header.h

  seems like a reasonable workaround (assuming that whatever the
  differences between "__private_extern__" and "extern" are, they're
  minor.)

- there seems to be some confusion in one of the files included by
  <math.h> about the correct prototype of the 'scalb' function.
  "scalb" is an intrinsic function in GCC 4.0, and the Panther
  header files provide a conflicting declaration.

- GCC 4.0 may have a different notion of how the "long double"
  type is implemented than previous versions did.

- this is based on the GCC ObjC frontend, so vanilla C files that
  reference type names like "Class" and "id" (and possibly the
  structure names "objc_class" and "objc_object") may confuse it.
  (Since most C system header files are intended to be included
  in ObjC headers/source, it's presumably rare for C headers to
  contain ObjC keywords.)

Except for the last quirk, these all seem to be issues that
C programmers might have to face.

One of the other goals in (finally!) starting to update this
translator is to write ObjC class and method information for ObjC
header files.  (Historically, about all that was incorporated into the
.ffi files produced from ObjC headers were the C types, records,
constants, and functions declared in those headers and a "template"
that described instances of each class as a C structure.)

For each ObjC class that this version of the translator sees, it produces
a form in the .ffi file that looks like:

(objc-class ("SOURCE-FILE" LINE-NUMBER)	; the source info isn't maintained
  "CLASS-NAME"
  (superclass "SUPERCLASS-NAME")  ; a string naming the superclass, or
                                  ; the literal VOID if the class has no
                                  ; superclass
  (template "TEMPLATE-NAME")      ; the structure tag of the "template"
  (IVAR*))                        ; 0 or more field definitions for
                                  ; each instance variable


For each ObjC instance method, the translator produces:

(objc-instance-method ("SOURCE-FILE" LINE-NUMBER) ; Real info this time!
  "METHOD-NAME"			 ; the selector string, may contain colons
  "CLASS-NAME"                   ; The class of the specialized argument
				 ; ("self")
  ("CATEGORY-NAME") | ()	 ; A list containing the name of the
				 ; category that defines this method, or
                                 ; an empty list
  (ARG*)                         ; Descriptions of the types of each
                                 ; argument (other than SELF/_CMD)
  RESULT-TYPE) 			 ; the method's result type

and likewise for ObjC class methods.

It's -possible- that this will need to be augmented some to deal with
methods defined via ObjC "protocols" (I'm not sure whether or not
those methods have been associated with classes by the time the translator
sees the class definition; if not, it may need to know what methods are
defined by what protocols and what protocols are adopted by what classes.)

Except for all of the stuff that I've forgotten about or never thought
of (that stuff is always a problem ...), this seems to basically work.
I haven't done much with Carbon yet (could be issues related to packed
legacy structures) and the ObjC info may need to be tweaked some, but
things seem to basically work.

So far, I haven't seen anything in the .ffi files that the FFI parser
in 0.14.3 doesn't understand.  (That may change when we start dealing
with 64-bit longs/pointers via the -m64 switch ...)

The "sources" (Makefile and patches) are also available via CVS, as
the module "ffigen4" in the repository "clozure.com:/usr/local/publiccvs".
That'd be:

shell> cvs -d :pserver:cvs at clozure.com:/usr/local/publiccvs login
(the anonymous CVS password is "cvs")

shell> cvs -d :pserver:cvs at clozure.com:/usr/local/publiccvs get ffigen4

If you want to work on this and want CVS write access, please let me know.
If you're able to test it and find bugs and problems other than those
mentioned above, please let me know that as well.