On 2014-03-12 08:06:47 +0000, "w0rp" <devw0rp@gmail.com> said:

> This is really awesome work. If you combined ARM support with Objective C support, it would mean you could write iOS programs in D without much frustration, and that would be a huge step forward. Objective C has a good runtime, but lacks templates and CTFE. Using CTFE for an iOS program could be very cool.
> 
> How do you plan to handle automatic reference counting? I imagine that's a hard part. When I was writing Objective C I remember having to write bridged casts so I could manually extend or limit object lifetime, but I never handled it from within a C library.

Well, there's three ways.

(a) The first one is to implement ARC for Objective-C objects, and to automatically add/remove roots to member variables when constructing/destroying Objective-C objects that were defined in D so the GC can those pointers.

(b) The second one is to not implement ARC and implement something in the GC so it can track Objective-C objects: retain them on first sight, release them once no longer connected to a root.

(c) The third one is to implement ARC as an alternative memory management scheme for D and bolt Objective-C object support on top of it.

I'd tend to go for (a) at first, as it's the simplest thing that can be done. But I fear always adding/removing roots will impact performance in a negative way. There's also the issue in (a) and (b) that if the last reference to an object is released from the GC thread the Objective-C object's destructor will be called in a different thread than what is expected which might cause some bugs. So we might want to implement (c) later on to have something more solid and deterministic.

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

On 2014-03-12 09:26:56 +0000, Iain Buclaw <ibuclaw@gdcproject.org> said:

> On 12 March 2014 07:10, Jacob Carlborg <doob@me.com> wrote:
>> Yeah, since Objective-C uses the C calling convention it's mostly about
>> outputting symbols and data to the object files.
> 
> In what ABI may I ask?  Your choices are:
> - Traditional (32bit) ABI without properties and Obj-C 2.0 additions
> - Traditional (32bit) ABI with properties and Obj-C 2.0 additions
> - Modern (64bit) ABI

I made the 32-bit legacy runtime support, Jacob added the 64-bit modern runtime support.

There's no support at this time for properties declarations in the ABI, but it doesn't really have much impact. As far as I'm aware, Objective-C 2.0 additions only include property declarations and attributes in the ABI.


> That can be mixed in with either:
> - GNU Runtime ABI
> - NeXT Runtime ABI

It's been tested with the Apple (NeXT) runtime only. In all honesty, I, and probably most people out there, don't care about the GNU runtime. Although probably the GCC guys do. Do you think it'd make it more difficult to merge GCC in the GCC project if it had support for Apple's runtime and not for the GNU one?

Also, is there a list of differences between the two runtimes somewhere?


> Each combination being incompatible with each other subtly different ways...

Which is why we have a test suite.


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

On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote:
> I just wanted to let everyone know that I have implemented D/Objective-C for 64bit. Everything that worked for 32bit should work, except for exceptions, which are not implemented yet.
>
> Objective-C on 64bit uses the modern runtime, which is also the same used on iOS. This means D/Objective-C should now be compatible with iOS as well, at least in theory.
>
> For those how don't know what D/Objective-C is. It is a language extension to D making it ABI compatible with Objective-C. This means it's possible to use Objective-C classes, methods, protocols (interfaces) and so on, directly just as it's currently possible to do with regular C functions.
>
> Here's a recap of what's implemented, both for 32 and 64bit unless otherwise noticed:
>
> * Classes
> * Subclasses
> * Instance and class methods
> * Protocols (interfaces)
> * Properties
> * Exceptions (only 32bit)
> * Selectors
> * Class references
> * String literals
> * Casts
>
> Some improvements that are really not part of Objective-C but are very convenient to have in D :
>
> * Constructors
> * Inheriting selectors
> * Automatically generated selectors
>
> On the other hand, here a list of what's not implemented yet:
>
> * Blocks (similar to delegates)
> * Categories (class extensions)
> * Any form of automatic memory management
> * Exceptions (64bit)
> * Vtable optimization (64bit)
>
> Objective-C exceptions on 64bit is implemented using the same mechanism as C++. I'm wondering if it would be possible for D (not just for this extension) to adapt this mechanism as well. This would make D compatible with both C++ and Objective-C exceptions on 64bit.
>
> A DIP is available here [1] and the latest implementation is available here [2].
>
> [1] http://wiki.dlang.org/DIP43
> [2] https://github.com/jacob-carlborg/dmd/tree/d-objc

Wow, this is fantastic! This and recent progress on iOS/ARM/LDC porting make me so happy :)

On Wednesday, 12 March 2014 at 12:14:23 UTC, Michel Fortin wrote:
> On 2014-03-12 09:26:56 +0000, Iain Buclaw <ibuclaw@gdcproject.org> said:
>
>> On 12 March 2014 07:10, Jacob Carlborg <doob@me.com> wrote:
>>> Yeah, since Objective-C uses the C calling convention it's mostly about
>>> outputting symbols and data to the object files.
>> 
>> In what ABI may I ask?  Your choices are:
>> - Traditional (32bit) ABI without properties and Obj-C 2.0 additions
>> - Traditional (32bit) ABI with properties and Obj-C 2.0 additions
>> - Modern (64bit) ABI
>
> I made the 32-bit legacy runtime support, Jacob added the 64-bit modern runtime support.
>
> There's no support at this time for properties declarations in the ABI, but it doesn't really have much impact. As far as I'm aware, Objective-C 2.0 additions only include property declarations and attributes in the ABI.
>
>
>> That can be mixed in with either:
>> - GNU Runtime ABI
>> - NeXT Runtime ABI
>
> It's been tested with the Apple (NeXT) runtime only. In all honesty, I, and probably most people out there, don't care about the GNU runtime. Although probably the GCC guys do. Do you think it'd make it more difficult to merge GCC in the GCC project if it had support for Apple's runtime and not for the GNU one?
>
> Also, is there a list of differences between the two runtimes somewhere?
>
>
>> Each combination being incompatible with each other subtly different ways...
>
> Which is why we have a test suite.

There is an outdated list here, http://wiki.gnustep.org/index.php/ObjC2_FAQ

I wouldn't care for GNUStep support.

Objective-C support in gcc is almost dead and GNUStep seems to have hardly changed since I used WindowMaker as my main window manager. Which was around 1999 - 2004!

--
Paulo

"w0rp" <devw0rp@gmail.com> writes:

> This is really awesome work. If you combined ARM support with Objective C support, it would mean you could write iOS programs in D without much frustration, and that would be a huge step forward. Objective C has a good runtime, but lacks templates and CTFE. Using CTFE for an iOS program could be very cool.

Just a plug that the LDC iOS work is coming along well.  D iOS programming may not be too far in the future.
-- 
Dan

"Szymon Gatner" <noemail@gmail.com> writes:

> Wow, this is fantastic! This and recent progress on iOS/ARM/LDC porting make me so happy :)

Yeah, it will be cool to combine this with the LDC iOS work.  I haven't posted progress lately.  I got Fibers working on an iPhone 4.  I found that GDC's thread.d already had ARM Fiber support so used it until it gets pulled into dmd.  It's really coming down to just a few fundumental things (cross compiling getting real "real" type, and supporting TLS).
-- 
Dan

On 3/12/14, 12:15 AM, Jacob Carlborg wrote:
> On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote:
>
>> Great. Jacob, what's your plan to take this forward? We're very
>> interested in merging this as part of the official D compiler.
>
> In theory I could create a pull request tonight. It depends on what
> state we need the language support to be in. As I said exceptions are
> missing on 64bit. But on the other hand when support for C++ was
> introduced in D it had very limited support.
>
> One idea is to merge the changes but wait with enabling the languages
> changes. The test machines could run the tests with the changes enabled.

I'll defer to domain experts on this one. Please advise.

Andrei

On 12 March 2014 12:14, Michel Fortin <michel.fortin@michelf.ca> wrote:
> On 2014-03-12 09:26:56 +0000, Iain Buclaw <ibuclaw@gdcproject.org> said:
>
>> On 12 March 2014 07:10, Jacob Carlborg <doob@me.com> wrote:
>>>
>>> Yeah, since Objective-C uses the C calling convention it's mostly about outputting symbols and data to the object files.
>>
>>
>> In what ABI may I ask?  Your choices are:
>> - Traditional (32bit) ABI without properties and Obj-C 2.0 additions
>> - Traditional (32bit) ABI with properties and Obj-C 2.0 additions
>> - Modern (64bit) ABI
>
>
> I made the 32-bit legacy runtime support, Jacob added the 64-bit modern runtime support.
>
> There's no support at this time for properties declarations in the ABI, but it doesn't really have much impact. As far as I'm aware, Objective-C 2.0 additions only include property declarations and attributes in the ABI.
>
>
>
>> That can be mixed in with either:
>> - GNU Runtime ABI
>> - NeXT Runtime ABI
>
>
> It's been tested with the Apple (NeXT) runtime only. In all honesty, I, and probably most people out there, don't care about the GNU runtime. Although probably the GCC guys do. Do you think it'd make it more difficult to merge GCC in the GCC project if it had support for Apple's runtime and not for the GNU one?
>

gobjc supports both, there's two ABI's for the NeXT - which I take to mean the difference between the difference between 32bit and 64bit.

It seems that (now I read up on it) the GNU runtime came about from decades back when NeXT was not open sourced by Apple.  From what I can gather, a move towards the modern ABI is the direction, but not considered production ready.

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


> Also, is there a list of differences between the two runtimes somewhere?
>

That's hard to say at an initial glance.  There's a handy hook system into each ABI to allow you to switch between versions easily.  The common differences I do however see are:

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.

On 2014-03-12 13:14, Michel Fortin wrote:

> I made the 32-bit legacy runtime support, Jacob added the 64-bit modern
> runtime support.
>
> There's no support at this time for properties declarations in the ABI,
> but it doesn't really have much impact. As far as I'm aware, Objective-C
> 2.0 additions only include property declarations and attributes in the ABI.

It is now :). I added support for properties. But as you say, I don't really know what they add.

-- 
/Jacob Carlborg

Am Wed, 12 Mar 2014 10:53:35 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 3/12/14, 12:15 AM, Jacob Carlborg wrote:
> > On Wednesday, 12 March 2014 at 01:45:38 UTC, Andrei Alexandrescu wrote:
> >
> >> Great. Jacob, what's your plan to take this forward? We're very interested in merging this as part of the official D compiler.
> >
> > In theory I could create a pull request tonight. It depends on what state we need the language support to be in. As I said exceptions are missing on 64bit. But on the other hand when support for C++ was introduced in D it had very limited support.
> >
> > One idea is to merge the changes but wait with enabling the languages changes. The test machines could run the tests with the changes enabled.
> 
> I'll defer to domain experts on this one. Please advise.
> 
> Andrei
> 
> 

We could also start a (better: the first) feature branch. http://wiki.dlang.org/Release_Process#Branching%20model