portable cdecl 'elliptic' function calls

portable cdecl 'elliptic' function calls

[Camm Maguire]

Greetings!  On 3 of the 11 Debian architectures (i386, m68k, and ia64),
the cdecl calling convention is available, making the following code
possible:

object
c_apply_n(object (*fn)(), int n, object *x)
{object res=Cnil;
#if 1
 object *stack;

 if (!(stack=alloca(n*sizeof(*stack))))
   FEerror("Cannot allocate stack for elliptic call", 0);
 memcpy(stack,x,n*sizeof(*stack));
 res=fn();

As one might guess, this is taken from GCL and is used to call C
functions with a runtime-determined number of arguments.  

I know that the portable way to do this is with a switch statement on
n, but this would always be something of a workaround, limiting the
argument list to some presumably large number, and taking up a fair
bit of space in the code.

My question is whether there is an alternative call analogous to the
one outlined above for the other 8 Debian architectures (arm,
mips(el), alpha, hppa, sparc, ppc, s390), giving an unlimited to
within system stack memory runtime-determined argument list to a C
function call on these platforms as well?

Advice much appreciated, 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: portable cdecl 'elliptic' function calls

[Fergus Henderson]

On 28-Jul-2003, Camm Maguire <camm@enhanced.com> wrote:
> object
> c_apply_n(object (*fn)(), int n, object *x)
> {object res=Cnil;
> #if 1
>  object *stack;
> 
>  if (!(stack=alloca(n*sizeof(*stack))))
>    FEerror("Cannot allocate stack for elliptic call", 0);
>  memcpy(stack,x,n*sizeof(*stack));
>  res=fn();

This code is extremely non-portable.

I suggest you try using libffi, which is included in the GCC sources.
See libffi/README.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: portable cdecl 'elliptic' function calls

[Camm Maguire]

Greetings, and thank you for this tip!  I now think I see how to do
this in GCL, and would like to build in dependency on libffi.  Is this
available on everyone's systems?  I'm assuming its packaged at least
everywhere gcc is available.  What about solaris, Mac OS X?

Take care,

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

> On 28-Jul-2003, Camm Maguire <camm@enhanced.com> wrote:
> > object
> > c_apply_n(object (*fn)(), int n, object *x)
> > {object res=Cnil;
> > #if 1
> >  object *stack;
> > 
> >  if (!(stack=alloca(n*sizeof(*stack))))
> >    FEerror("Cannot allocate stack for elliptic call", 0);
> >  memcpy(stack,x,n*sizeof(*stack));
> >  res=fn();
> 
> This code is extremely non-portable.
> 
> I suggest you try using libffi, which is included in the GCC sources.
> See libffi/README.
> 
> -- 
> Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
> The University of Melbourne         |  of excellence is a lethal habit"
> WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
> 
> 
> 

-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

RE: [Gcl-devel] Re: portable cdecl 'elliptic' function calls

[Mike Thomas]

Hi Camm.

It must be statically linked with gcc on Windows rather than being
standalone, assuming it's used there at all as it is absent from my Cygwin
and MinGW32 gcc lib directories.

The gcc source seems to imply it works on Windows but some docs I've read on
the web don't list Windows as a target platform for libffi.  (Never built
gcc so can't say which.)

Fergus, did you use it in the Cygwin port of Mercury?

Cheers

Mike Thomas



| -----Original Message-----
| From: gcl-devel-bounces+miketh=brisbane.paradigmgeo.com@gnu.org
| [mailto:gcl-devel-bounces+miketh=brisbane.paradigmgeo.com@gnu.org]On
| Behalf Of Camm Maguire
| Sent: Thursday, July 31, 2003 7:55 AM
| To: Fergus Henderson
| Cc: gcc@gcc.gnu.org; axiom-developer@nongnu.org;
| maxima@mail.ma.utexas.edu; acl2@lists.cc.utexas.edu; gcl-devel@gnu.org
| Subject: [Gcl-devel] Re: portable cdecl 'elliptic' function calls
|
|
| Greetings, and thank you for this tip!  I now think I see how to do
| this in GCL, and would like to build in dependency on libffi.  Is this
| available on everyone's systems?  I'm assuming its packaged at least
| everywhere gcc is available.  What about solaris, Mac OS X?
|
| Take care,
|
| Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
|
| > On 28-Jul-2003, Camm Maguire <camm@enhanced.com> wrote:
| > > object
| > > c_apply_n(object (*fn)(), int n, object *x)
| > > {object res=Cnil;
| > > #if 1
| > >  object *stack;
| > >
| > >  if (!(stack=alloca(n*sizeof(*stack))))
| > >    FEerror("Cannot allocate stack for elliptic call", 0);
| > >  memcpy(stack,x,n*sizeof(*stack));
| > >  res=fn();
| >
| > This code is extremely non-portable.
| >
| > I suggest you try using libffi, which is included in the GCC sources.
| > See libffi/README.
| >
| > --
| > Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known
| that the pursuit
| > The University of Melbourne         |  of excellence is a lethal habit"
| > WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of
| T. S. Garp.
| >
| >
| >
|
| --
| Camm Maguire			     			camm@enhanced.com
| ==========================================================================
| "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
|
|
| _______________________________________________
| Gcl-devel mailing list
| Gcl-devel@gnu.org
| http://mail.gnu.org/mailman/listinfo/gcl-devel
|
|

Re: [Gcl-devel] Re: portable cdecl 'elliptic' function calls

[Fergus Henderson]

On 31-Jul-2003, Mike Thomas <miketh@brisbane.paradigmgeo.com> wrote:
> Fergus, did you use it [libffi] in the Cygwin port of Mercury?

No.

Camm Maguire <camm@enhanced.com> wrote:

> | Greetings, and thank you for this tip!  I now think I see how to do
> | this in GCL, and would like to build in dependency on libffi.  Is this
> | available on everyone's systems?  I'm assuming its packaged at least
> | everywhere gcc is available.  What about solaris, Mac OS X?

You should not assume that libffi is implemented everywhere that gcc is
available.  The reason that libffi is included in the GCC distribution
is, I think, because it is used by the Java interpreter.  That is a lot
less widely ported than the GNU C compiler, I would imagine.

The libffi implementation is by its nature not portable;
its implementation depends on the platform's calling convention.
However, the interface is portable, and by using libffi,
the work of implementing this interface for a bunch of different
calling conventions can be shared between all the different
projects that need this functionality.

The difficulty of porting libffi to a different OS will depend on
whether that OS uses the same calling convention as one that libffi
already supports.  If so, as is the case with Cygwin, then it should
be very little work.  If not, it might be a lot of work.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: [Gcl-devel] Re: portable cdecl 'elliptic' function calls

[Tom Tromey]

>>>>> "Mike" == Mike Thomas <miketh@brisbane.paradigmgeo.com> writes:

Mike> The gcc source seems to imply it works on Windows but some docs
Mike> I've read on the web don't list Windows as a target platform for
Mike> libffi.  (Never built gcc so can't say which.)

libffi works fine on Windows.  You can easily find out where it works
by looking in gcc/libffi/configure.in.  There is a big case statement
that sets up the build for all the working platforms.

Things are a little different if you use the closure API.  Then you
have to look in gcc/libffi/include/ffi.h.in to see what platforms
define FFI_CLOSURES.

The "normal" API works on more platforms than the closure API.  I
think libffi works on all the Debian architectures except HPPA.
Nobody has ever done that port.

Tom

Re: [Gcl-devel] Re: portable cdecl 'elliptic' function calls

[Tom Tromey]

>>>>> "Mike" == Mike Thomas <miketh@brisbane.paradigmgeo.com> writes:

Mike> The gcc source seems to imply it works on Windows but some docs
Mike> I've read on the web don't list Windows as a target platform for
Mike> libffi.  (Never built gcc so can't say which.)

libffi works fine on Windows.  You can easily find out where it works
by looking in gcc/libffi/configure.in.  There is a big case statement
that sets up the build for all the working platforms.

Things are a little different if you use the closure API.  Then you
have to look in gcc/libffi/include/ffi.h.in to see what platforms
define FFI_CLOSURES.

The "normal" API works on more platforms than the closure API.  I
think libffi works on all the Debian architectures except HPPA.
Nobody has ever done that port.

Tom

Re: [Axiom-developer] portable cdecl 'elliptic' function calls

[Arthur Norman]

On Mon, 28 Jul 2003, Camm Maguire wrote:
> Greetings!  On 3 of the 11 Debian architectures (i386, m68k, and ia64),
> the cdecl calling convention is available...
> ...
> As one might guess, this is taken from GCL and is used to call C
> functions with a runtime-determined number of arguments.
>
> I know that the portable way to do this is with a switch statement on
> n, but this would always be something of a workaround, limiting the
> argument list to some presumably large number, and taking up a fair
> bit of space in the code.
>
In CSL/CCL what I do to support arbitrary arg counts involves that ugly
switch statement up to some fixed limit, but beyond that I do what is in
effect a source-code remapping so that args N, N+1, N+2,... get packed
into a regular Lisp vector and passed as one argument

Eg a call
   (f a1 a2 a3 a4 ... a20, a21, ...)
is mapped to
   (f a1 a2 a3 a4 ... (vector a20 a21 ...))
and a function definition
   (defun f (a1 ... a20 ...)
      ... a23 ...)
becomes
   (defun f (a1 ... vec-of-rest)
      ... (elt vec-of-rest 4) ...)
This clearly carries an overhead in performance in such cases but comes
closer to living within the C standard.

    Arthur