On 2014-03-12 20:02, Iain Buclaw wrote:

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

You previously listed three ABI's. It's the modern runtime for 64bit and the traditional for 32bit with with properties that are interesting. I don't know how much difference these properties do.

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

I'm not sure I understand. Do you want to support the NeXT or GNU runtime?

Clang is at least compatible with the Apple GCC. I don't know about FSF GCC.

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

One basically need to look at each single feature and see what differs.

-- 
/Jacob Carlborg

On 2014-03-12 17:53:35 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

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

If the compiler is going to be converted to the D language (how is that progressing?), it'd probably be better to merge before that, otherwise it'll be a lot of work to port all those changes.

The first question should about the review process. This patch touches a lot of things, so I wonder if Walter will be confortable reviewing it. Should different people review different parts? Here's a comparison view:

DMD:  94 changed files with 8,005 additions and 48 deletions.
https://github.com/jacob-carlborg/dmd/compare/d-objc

druntime:  10 changed files with 1,263 additions and 0 deletions.
https://github.com/jacob-carlborg/druntime/compare/d-objc

Most of the changes to the compiler are inside #if DMD_OBJC/#endif blocks. Changes outside of those blocks shouldn't affect the semantics or the binary output of existing code. So I think a review could be done in two steps:

1. Review changes outside of those #if DMD_OBJC blocks. Those are the most critical changes as they'll affect the next version of the compiler that'll ship (I'm assuming Objective-C features won't be turned on until they're more usable). This includes some changes in the lexer, but it shouldn't affect current D code. This review could exclude the two files objc.h/objc.c, since the makefile ignores them without the D_OBJC flag.

2. Maybe review things inside of those #if DMD_OBJC blocks. Those things won't affect the compiler unless compiled with the D_OBJC flag, so it's less critical to review them. Most of them are there to implement Objective-C semantics so you'll need to be somewhat familiar with Objective-C to judge whether they're correct or not. What should be checked is whether an error would make them affect non-Objective-C constructs when they're compiled in.

We also need to know what to do about the test suite. I made a separate test suite for D/Objective-C since those tests can only run on OS X and only with the compiler compiled with Objective-C support enabled. It could easily be merged with the main test suite, but the tests should be made conditional to whether the compiler is compiled with Objective-C or not.


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

On 2014-03-12 19:02:10 +0000, Iain Buclaw <ibuclaw@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@michelf.ca
http://michelf.ca

On 12 March 2014 19:29, Jacob Carlborg <doob@me.com> wrote:
> On 2014-03-12 20:02, Iain Buclaw wrote:
>
>> 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.
>
>
> You previously listed three ABI's. It's the modern runtime for 64bit and the traditional for 32bit with with properties that are interesting. I don't know how much difference these properties do.
>

Sorry, some context.  The two 32bit ABIs are part of the same source, I'd take them to be identical, with the exception that the second option supports features that are on-by-default in the 64bit ABI.


>
> I'm not sure I understand. Do you want to support the NeXT or GNU runtime?
>

As in, if I were to support NeXT.  I'd support the same as implemented by GNU ObjC.  I'd have to look up if there are incompatibilities between GCC > 4.3 and Clang on the ObjC side...

On 12 March 2014 19:36, Michel Fortin <michel.fortin@michelf.ca> wrote:
> On 2014-03-12 19:02:10 +0000, Iain Buclaw <ibuclaw@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.
>
>

Hooking to ObjC could be done, but requires patching GCC proper so that ObjC mangling becomes common code, not front-end specific.

On 12 March 2014 19:34, Michel Fortin <michel.fortin@michelf.ca> wrote:
> On 2014-03-12 17:53:35 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
>
>> 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.
>
>
> If the compiler is going to be converted to the D language (how is that progressing?), it'd probably be better to merge before that, otherwise it'll be a lot of work to port all those changes.
>

Daniel's DDMD conversion tool is on github, you could run it through that to get most of the legwork converted over I guess?

On 2014-03-12 20:34, Michel Fortin wrote:

> If the compiler is going to be converted to the D language (how is that
> progressing?), it'd probably be better to merge before that, otherwise
> it'll be a lot of work to port all those changes.

I think Daniel has said he as a working Linux compiler. He just need to create pull requests (and get them merged) for all changes his tool requires.

-- 
/Jacob Carlborg

On 2014-03-12 20:37, Iain Buclaw wrote:

> Sorry, some context.  The two 32bit ABIs are part of the same source,
> I'd take them to be identical, with the exception that the second
> option supports features that are on-by-default in the 64bit ABI.

I see.

> As in, if I were to support NeXT.  I'd support the same as implemented
> by GNU ObjC.  I'd have to look up if there are incompatibilities
> between GCC > 4.3 and Clang on the ObjC side...

Sounds reasonable.

-- 
/Jacob Carlborg

"Michel Fortin"  wrote in message news:lfqcs6$2su5$1@digitalmars.com...

> If the compiler is going to be converted to the D language (how is that progressing?), it'd probably be better to merge before that, otherwise it'll be a lot of work to port all those changes.

The converter can convert git master, compile it with git master, and pass the full test suite + phobos on linux32/linux64/win32.  If someone wants to give me access to an OSX box I'll get it working there too.

The main problem with these patches is their use of #if in places where D's version blocks don't work.  These will all need to be fixed before it is merged, as I've done for the rest of the frontend.

I'm happy to help anyone set up the converter - contact me here/by email/on github.

It should be as simple as
1. Build dmd master
2. git clone git@github.com:yebblies/magicport2.git
3. Fix paths if you have a different layout than I do
4. make 

"Jacob Carlborg"  wrote in message news:lfqf4t$2v1o$1@digitalmars.com...

> I think Daniel has said he as a working Linux compiler. He just need to create pull requests (and get them merged) for all changes his tool requires.

The changes to dmd's source are all done(!), it's now time to start putting the manually ported stuff into the main repo.