This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Function Argument Question


Michael Meissner wrote:

>
> Not necessarily.  The compiler on many machines receives the first n arguments
> in registers and not on the stack.  Some machines reserve space on the stack to
> store these arguments, and some do not, in which case it stores the argument at
> some location in the stack frame.  Also for char/short/float arguments if a
> prototype was not in scope the compiler receives the argument as the widened
> type and then converts it to the narrowed type, and stores it some place on the
> stack.
>

Yup, but I found the extension  for a function attribute:

void func(...) __attribute__ ((regparm(0)));

which is supposed to make it not pass any args in registers..


>
> So your only portable alternatives is to:
>
>    1)   Do a giant switch statement within the scripting language, that covers
>         every single combination of arguments passed, and call the function
>         that way.
>
>    2)   Encode the arguments into a giant text string and pass a single char *,
>         decoding in your function.
>

Hmm... I like number 2....  No way on number 1.. I've seen the more than 10 ways a
function can return, pass, etc....


>
> Other solutions that come to mind that involve some amount of non-portable
> code:
>
>    1)   Build a module that knows the argument layout as a shared library and
>         have the scripting language ldopen it to do the transfer.  This assumes
>         your scripting language supports shared libraries and provides a way
>         for C code to access its arguments.
>

Yeah, but my problem is I want this to be generic enough....


>
>    2)   Build a structure containing all of the data and pass it's address to
>         the function.  This assumes you know the structure layout of the
>         machine (which is different for different machines).
>

Thought of this.. I may end up doing it after all if what I'm doing now starts to
cause too many problems...


>
> In general, the marshalling and demarshalling of arguments tends to be the
> Achilles heel of any mixed language (or RPC) system.
>

Yup... I realize this....  I wish there were an exension that would make functions
behave to some (probably non existant) IEEE standard for inter-language
infacing...

Something like:

__common_call__ void foo(int a, float b, char c);

    Would mean.... pass all arguments in left-to-right order in a contiguous
section of memory.. where the arguments are aligned to the value specified in the
first 16bits interpreted as an unsigned 16bit integer... And space for the return
value appears at the end (or beginning) of that contiguous memory.. And it is the
responsibility of the caller to cleanup... etc
    Or something like that..   And if all languages has this extension in some
form a utopia would for and all homelessness and poverty would cease...... ;)

    Anyway, what I'm doing now is using __builtin_apply(...)  from within my
script interpreter to call the C function.... I looked around in the gcc code
enough to know that the first part of the void * argument contains the address
where the arguments should start (order of args I'm still not quite sure of)...  I
haven't played with return value yet and make just required them to be returned in
an argument...
    But, what I have is working for now....   I looked around and there doesn't
seem to be any documentation on the structure of what __builtin_apply_args
returns...  This would probably help me...




Thank for the response...
    -- Davy






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]