[cfe-dev] Objective-C Code Generation
csdavec at swansea.ac.uk
Sun Feb 24 05:28:27 PST 2008
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
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?
>> 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
@"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:
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.
More information about the cfe-dev