D/Objective-C 64bit

[Michel Fortin]

On 2014-03-12 19:02:10 +0000, Iain Buclaw <ibuclaw at gdcproject.org> said:

> From my POV, I wouldn't want to support the ABI of a language that GCC
> itself doesn't support.  So code compiled by GNU ObjC should be
> compatible with extern(ObjC) code generated by GDC - even if it isn't
> compatible with Clang ObjC.  But then, I'd be surprised if it wasn't
> compatible.

It all comes to how you integrate the thing with GCC. My guess is that 
you have three choices:

1. ignore Objective-C support: don't define DMD_OBJC in the code and 
the compiler will complain whenever it sees extern(Objective-C)

2. translate the calls to the DMD backend creating the various sections 
and segments to equivalent calls for creating sections and segments in 
GCC

3. replace the codegen for Objective-C data structures by what's 
already implemented in GCC for Objective-C

This last option will support whatever ABI GCC has support for. That's 
probably the way to go if you want to make sure ABIs are compatible. 
All the Objective-C ABI DMD knows about is implemented in objc.c, so 
what you have to do is to rewrite objc.c to call the GCC equivalent 
implementation, probably getting rid of most of the code in there.


> NeXT:
> NSConstantString
> objc_getClass
> objc_getMetaClass
> objc_msgSend
> objc_msgSendSuper
> 
> GNU:
> NXConstantString
> objc_get_class
> objc_get_meta_class
> objc_msg_lookup
> objc_msg_lookup_super
> 
> Some which greps for s(n)printf also show:
> 
> NeXT:
> ".objc_class_name_%s"
> ".objc_category_name_%s_%s"
> 
> GNU:
> "__objc_class_name_%s"
> "__objc_category_name_%s_%s"
> 
> 
> Most others look the same?  Maybe you'll be able to find out more with
> this information.

My understanding is that the differences are pretty trivial. But 
regardless, we probably don't have to care about them if you can hook 
directly to the GCC Objective-C codegen.


-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca