Re: glue code ?

[James Henstridge <james daa com au>]

Alright, I will give you an example.

First of all, C calling conventions are pretty low level.  Generally
arguments are pushed onto a stack and that is it.  How those arguments are
interpreted is up to the function.  The function doesn't even know how
many arguments are passed to it (for instance, two ints usually take up
the same amount of stack space of a floating point number).

In interpreted languages, more information is known about the arguments
passed to the function.  For python, the arguments are packed into a tuple
(an immutable array of objects that knows how long it is).  If the
function call is implemented in C, it will have the C prototype
PyObject *function(PyObject *self, PyObject *args);

The args argument is the tuple I was talking about, and the return value
is passed to the python program.  Basically this function is a wrapper
that converts the interpreter's representation of arguments to the C
representation of arguments, then translates the return type to something
understandable by the interpreter.  This is necessary because there is no
way that the interpreter can know what arguments the C function requires
at runtime.

For compiled languages that use the standard C calling conventions, this
isn't a problem since they can get function definitions from headers at
compile time.

I hope this helps you understand why the glue code is necessary.

James Henstridge.

--
Email: james@daa.com.au
WWW:   http://www.daa.com.au/~james/


On Tue, 9 Feb 1999, boirie wrote:

> Well, if I understand, each object files share the same format whatever compiler
> it's been generated from.
> 
> 2nd guess (might be quite stupid) : interpreted languages have to deal with how to
> launch a process  based on shared objects libraries ; does this mean that the
> bindings (for interpreted languages) have to load processes from libraries, manage
> adress spaces and so on...?
> 
>     gregor
>