[Openmcl-devel] Re: ffigen for GCC 3.4

[Gary Byers]

First of all, I seem to have missed Helmut Eller's announcement.  Belated
thanks to Helmut.

As regargs the problem below: the general idea is that primitive
built-in GCC types (integers and floats of various sizes/signedness)
should be recognized as primitive at the .ffi level.  (In order to
actually be able to -do- anything involving one of those types, lisp's
FFI has to also be aware of that type, but that's a separate issue.)
At this level, we want to ensure that "__int128_t" is recognized as a
primitive, built-in type (like "long unsigned int"), and not as
something defined by typedef.  As an example, an AltiVec-aware GCC may
consider "vector int" to be a primitive type; it's important that
FFIGEN recognize that type as primitive and emit references to that
type via a lisp-y name (VECTOR-INT, or something), even though OpenMCL's
FFI doesn't understand AltiVec.

If I understand correctly, I think that we want to add an entry for
"__int128_t" to FFIGEN's primitive type table.  (Since lisp won't
understand how to pass/return 128-bit integers around for a while,
it may not matter too much whether it fails because of an unknown
foreign type or a known but unsupported foreign type, but making
the type "known" on both sides of the translation process will
eventually allow it to be supported.)


On Sun, 15 Aug 2004, Cyrus Harmon wrote:

> openmcl-dev,
>
> I have tried to use the ffigen with some success, but I needed to do
> the following:
>
> *** ffi.c       Sun Aug 15 14:07:57 2004
> --- ../../ffigen-3.4.1/ffi.c    Tue Aug  3 07:48:48 2004
> ***************
> *** 162,168 ****
>      for (; map->gcc_name; ++map)
>        if (!strcmp (map->gcc_name, gcc_name))
>          return (char*)map->ffi_name;
> -   return 0;
>      fprintf (stderr, "Bug: couldn't find primitive name for %s\n",
> gcc_name);
>      abort ();
>    }
> --- 162,167 ----
> ***************
>
> to get it to work right. Otherwise, it complains about not being able
> to find the primitive for __int128_t (I think that's right). One
> difference is that I'm using the gcc-3.4.1 tarball not gcc-3.4.1-core.
> I had to disable gcj and this could be the source of the 128-bit
> weirdness. In any event, I thought you'd like to know. I'll keep
> plowing ahead and see if I can make this work all the way through for
> the stuff I'm working on.
>
> Thanks,
>
> Cyrus
>
>
> On Aug 4, 2004, at 12:49 AM, Helmut Eller wrote:
> > From: Helmut Eller <e9626484 at stud3.tuwien.ac.at>
> > Date: August 4, 2004 12:49:59 AM PDT
> > To: openmcl-devel at clozure.com
> > Subject: ffigen for GCC 3.4
> >
> >
> > Hello!
> >
> > I just wanted to say that I've ported ffigen to GCC 3.4.1.  There
> > where some bitfield related changes and I'm not sure if I did
> > everything 100% right.  Anyway, the patches can be found at:
> >
> >   http://stud3.tuwien.ac.at/~e9626484/ffigen-3.4.1.tgz
> >
> > Helmut.
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>