GCC/ObjC enhancements, comments requested

[Ovidiu Predescu]

On Sat, 7 Feb 1998 20:17:34, Scott Christley wrote:

> So the proposal is to add three builtin functions.
>
> This function is given a type string and pointers to two buffers where it
> will store its output.  The function will traverse through the type string
> and for each argument store a 0 (zero), if the argument is passed in a
> register, or a 1 (one), if the argument is passed on the stack, into
> buffer; if the argument is passed on the stack then the stack size will be
> stored into sizes.  The type string uses the encoding characters as
> defined by the ObjC runtime library; the first character representing the
> return value with the additional characters representing the arguments.
>
> void
> builtin_allocation(char *types, int *buffer, int *sizes);
>
> This function is given a type string and returns the type information in
> internal GCC format.
>
> tree
> builtin_convert_type(char *types);
>
> This function is similar to the existing builtin_apply function except
> that it has two additional argument; one which contains type information,
> in internal GCC format, for the arguments and return value, and the other
> which is a two element array that points to register/stack allocation
> information.
>
> static rtx
> builtin_perform (rtx function, rtx arguments, rtx argsize, tree types, int
> *allocation[2]);

When you speek about builtin functions you should remember that these  
functions are either generated by the compiler or available in libgcc at  
runtime.

The above three functions cannot be implemented as builtin functions because  
none of the internal structures of GCC are available in the compiled  
programs (there are no tree or rtx objects available in libgcc or libobjc).  
These functions cannot be generated by compiler or included in a runtime  
library without taking a lot of GCC's internal knowledge.

If you thought at these functions as being part of the compiler itself, then  
they don't make sense because the compiler doesn't have to deal with the  
incomplete type specification encoded by Objective-C type strings.

The way I originally saw this runtime construction of a call is to make GCC  
generate this knowledge and implement generic functions in a runtime library  
(libgcc or libobjc) that uses that knowledge to build the call. The public  
API though should be in my opinion written entirely in C, not use any ObjC  
specific classes, so that C programs can use it. In addition the type  
encoding used by this API should not use the plain ObjC type encoding because  
it lacks a lot of type information from the original C type, though it can  
be a good starting point.

--
Ovidiu Predescu <ovidiu@net-community.com> (NeXTMail, MIME)
http://www.net-community.com/Users/~ovidiu