[cfe-dev] Objective-C Code Generation

[fjahanian]

On Feb 24, 2008, at 5:28 AM, David Chisnall wrote:

> 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.

clang has several consumers that rely on integrity of ASTs to reflect  
the source language; pretty printer, dumper, rewriter are among them.  
In future there will be more. Lowering AST to its c equivalent will  
kill the abstraction needed by these consumers. It also makes  
objective-c code gen. runtime dependent as Darwin and Gnu runtimes  
have different rewuirements in many cases. Of course you can always  
write an AST-to-AST translator for objective-c code gen. only. But  
this will be just another Consumer and fits well with clang's  
architecture.

- Fariborz

>
>>> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev