[cfe-dev] Objective-C Code Generation

David Chisnall csdavec at swansea.ac.uk
Sun Feb 24 05:28:27 PST 2008


Hi Chris,

On 23 Feb 2008, at 19:06, Chris Lattner wrote:

>> I imagine the easiest way of getting this working is to
>> transform the Objective-C AST into a pure-C AST with calls to the
>> relevant runtime libraries.
>
> This is the way that GCC works, but I don't think it is really the  
> best way.  I'd much rather have the clang codegen module directly  
> produce the LLVM IR for the constructs it needs.  I don't anticipate  
> that this will be a problem for metadata or other objc constructs.

I am not completely sure what would be gained by doing this.  Unlike C+ 
+, every Objective-C construct maps cleanly to a C construct.   
Objective-C objects are C structures, Objective-C message sends are C  
function calls (and methods are just C functions with their pointers  
added to the class structure), and so on.  If work has already been  
done to transform these C constructs into LLVM IR then it seems like  
there would be some significant code duplication to do the same for  
Objective-C.

I don't mind generating LLVM IR (I've already written code which  
generates code targeting the GNU runtime from GNU Lightning), but I'm  
not sure what the benefit would be.

>> Are there any existing hooks for inserting this abstraction layer?   
>> If
>> so, can someone point me in the right direction, and if not can
>> someone suggest a good place to put them?
>
> At this point, I'd suggest starting with the simple constructs (e.g.  
> the stand alone objc expressions like @"foo", add pointers to  
> interfaces, etc) and then move on the metadata.  If you do each  
> patch cleanly and incrementally I don't expect a big problem.  When  
> we start on codegen support for the next runtime, we can generalize  
> the code and figure out what abstractions are best on a case-by-case  
> basis.

@"foo" is actually decidedly non-trivial from a code-generation  
perspective.  It needs to be expanded to an object, which is a  
structure of the form:

{
	Class isa;
	char * c_string;
	unsigned int length;
}

Where the class pointed to by isa is determined at compile-time and  
resolved at runtime (both GNUstep and Cocoa define this as their own  
constant string representation (an NSString subclass).  It's hard to  
get something like this right until you have classes being generated  
correctly, which is probably where I'll start.

David



More information about the cfe-dev mailing list