I think the LDC + iOS stuff it is working well enough that others might have fun with it too.  I made a fork of ldc/druntime on github and pushed up changes into branch ios-2.064.  It is based on ldc merge-2.064 branch.  You will find very few changes were needed to get this far.  It has been mostly a game of finding the right recipe and stubbing out missing functions for iOS.

What can you do with it?  Well, as far as I know, most of D 2.064 appears to work with the exception of exceptions (that came out nice) and thread locals.  I am sure there are many pits and holes to fall into though.

In general:
- TLS support not available so I disabled for now
- Threads "work", but there are unfinished pieces and a wumpus hiding
  here (e.g. not sure what gc will do when it triggers)
- You can throw exceptions, but they have a tragic ending
- debug info does not work and -g causes link warnings
- things are hardcoded for iOS in a few places, so this branch may not
  work as a native compiler).  For example, I had to hardcode real type
  as a 64-bit double (dmd uses host's long double type for real)

To compile the C portions of druntime/phobos, you will need an iPhone
SDK downloaded from Apple, which means you need to use OSX (mac) as
the host.  To actually run on hardware (iPhone 4 in my case) I signed up
as an iOS developer.  D objs and libs can then be added to an Xcode
project and run in the debugger.

Follow normal ldc build instructions on D wiki with some differences below.

http://wiki.dlang.org/Building_LDC_from_source.

Must use llvm-3.4 or newer.  I am confguring llvm with all targets enabled (llvm/configure with no options).

$ git clone --recursive https://github.com/smolt/ldc.git
$ mkdir thumb7-ios-ldc
$ cd thumb7-ios-ldc
$ cmake -DD_FLAGS='-w;-d;-mtriple=thumbv7-apple-ios5.0.0;-mcpu=cortex-a8;-disable-fp-elim;-float-abi=softfp;-vectorize-slp' -DD_FLAGS_DEBUG='' -DD_FLAGS_RELEASE='-Os;-release' -DTARGET_C_FLAGS='-target armv7-apple-darwin -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk' ../ldc
$ make

Then to compile a simple program with D as the main:

$ cat <<XYZZY >hello.d
import std.stdio;

void main()
{
    writeln("Hello from D");
}
XYZZY

$ thumb7-ios-ldc/bin/ldc2 -mtriple=thumbv7-apple-ios5.0.0 -disable-fp-elim -float-abi=softfp -Os -c hello.d

Make a simple (empty) Xcode project for iOS and remove the objc main.m (or disabled it).  Then add the resulting hello.o plus thumb7-ios-ldc-3.4/lib/libphobos-ldc-debug.a.  There are no debug symbols but at least asserts are enabled, which I think is a good thing in this new world.  Build and run.

Alternatively, you can use the objc main() and have it call an extern
(C) D function.  But remember to call rt_init() first thing.  You can do
it the objc main() as in:

int main()
{
   extern int rt_init();
   extern void someDfunc();
   if (rt_init()) {
      someDfunc();
   }

   ...

}

I hope it works for somebody besides me.  Thanks to everyone who helped so far.
-- 
Dan

Hi Dan!

On Friday, 14 February 2014 at 09:02:22 UTC, Dan Olson wrote:
> I think the LDC + iOS stuff it is working well enough that others might
> have fun with it too.  [...]
> I hope it works for somebody besides me.  Thanks to everyone who helped
> so far.

I am really impressed!!!!

Regards,
Kai

On 2014-02-14 10:02, Dan Olson wrote:
> I think the LDC + iOS stuff it is working well enough that others might
> have fun with it too.  I made a fork of ldc/druntime on github and
> pushed up changes into branch ios-2.064.  It is based on ldc merge-2.064
> branch.  You will find very few changes were needed to get this far.  It
> has been mostly a game of finding the right recipe and stubbing out
> missing functions for iOS.
>
> What can you do with it?  Well, as far as I know, most of D 2.064
> appears to work with the exception of exceptions (that came out nice)
> and thread locals.  I am sure there are many pits and holes to fall into
> though.
>
> In general:
> - TLS support not available so I disabled for now

If TLS is not natively supported, can it be emulated like DMD currently does on OS X?

> - Threads "work", but there are unfinished pieces and a wumpus hiding
>    here (e.g. not sure what gc will do when it triggers)
> - You can throw exceptions, but they have a tragic ending
> - debug info does not work and -g causes link warnings
> - things are hardcoded for iOS in a few places, so this branch may not
>    work as a native compiler).  For example, I had to hardcode real type
>    as a 64-bit double (dmd uses host's long double type for real)
>


> I hope it works for somebody besides me.  Thanks to everyone who helped
> so far.

This sounds great :)

-- 
/Jacob Carlborg

On Friday, 14 February 2014 at 19:58:45 UTC, Jacob Carlborg wrote:
> On 2014-02-14 10:02, Dan Olson wrote:
>> In general:
>> - TLS support not available so I disabled for now
>
> If TLS is not natively supported, can it be emulated like DMD currently does on OS X?
Yes, why can't you just use the TLS support in druntime's rt/sections_osx.d?  Is it that different on iOS?

Nice work, looking forward to checking it out when I try ARM on Android.

Jacob Carlborg <doob@me.com> writes:

> If TLS is not natively supported, can it be emulated like DMD currently does on OS X?

David talked about doing something like that.  BTW (and aside), does dmd still emulate tls on OSX?  If so, is someone planning to switch it to OSX's thread locals?

Jacob, it looks like you have been playing with D on Mac for awhile.  I searched D forums for iOS or Mac stuff and your name comes up.  I think as a next step (pun intended) it would be cool to try something you have done to interface D with the objc world.  For now, I am just creating C functions as needed to glue objc messages to D.

Also started playing some with the ObjC Runtime calls like

  objc_msgSend(obj, sel_registerName("release"))

to do stuff like

  [obj release];

That could go along way with some handy wrapper functions.  Then there is the project I think you mentioned to make D compiler directly support objc interfaces.  Would it be much work to fold it into the current compiler?

Anyway, looking forward to any tools or thoughts you have.  For now, exception handling seems the most useful missing feature.  So I am looking at that.
-- 
Dan

"Joakim" <joakim@airpost.net> writes:

> On Friday, 14 February 2014 at 19:58:45 UTC, Jacob Carlborg wrote:
>> If TLS is not natively supported, can it be emulated like DMD currently does on OS X?
> Yes, why can't you just use the TLS support in druntime's rt/sections_osx.d?  Is it that different on iOS?

Hi Joakim,

David suggested we could do that with ldc.  I think it is a good approach.

http://forum.dlang.org/thread/m2d2k79zsl.fsf@comcast.net?page=3#post-mailman.287.1389372405.15871.digitalmars-d-ldc:40puremagic.com

On 2014-02-15 07:44, Dan Olson wrote:

> David talked about doing something like that.  BTW (and aside), does dmd
> still emulate tls on OSX?

Yes, it still emulates. I think we need to decide if we are willing to remove the support for OS X 10.6.

I want to add that I think it's theoretically possible to implement the TLS support code located in the dynamic linker in druntime. This would allow us to move to native TLS on OS X 10.7 while still supporting 10.6, with the same code.

> If so, is someone planning to switch it to OSX's thread locals?

I would guess that's the plan, eventually. It's basically a requirement for making dynamic libraries work. It's the same as with everything else, someone needs to commit time to make it happen.

> Jacob, it looks like you have been playing with D on Mac for awhile.

I certainly have :)


> I searched D forums for iOS or Mac stuff and your name comes up.  I think
> as a next step (pun intended) it would be cool to try something you have
> done to interface D with the objc world.  For now, I am just creating C
> functions as needed to glue objc messages to D.
>
> Also started playing some with the ObjC Runtime calls like
>
>    objc_msgSend(obj, sel_registerName("release"))
>
> to do stuff like
>
>    [obj release];
>
> That could go along way with some handy wrapper functions.  Then there
> is the project I think you mentioned to make D compiler directly support
> objc interfaces.

I just have started to work on the 64bit support for D/Objective-C [1] (same runtime as iOS).

> Would it be much work to fold it into the current compiler?

Unfortunately yes. The 32bit version is currently very usable. It basically only missing support for categories and blocks. For the 64bit version only the most basic functionally like: calling instance methods, class methods and implementing Objective-C classes on the D side. What's missing in the 64bit version is:

* Categories
* Protocols (interfaces)
* Catching exceptions (I have a workaround for this that I think is working)
* Properties
* All that's missing in the 32bit version

Non of the version supports ARC.

Except from all the missing features it would most likely require quite a lot of work to get the code approved and merged. There are quite a lot of changes in most of the phases in the compiler. Adding new syntax to the language is a high barrier.

If you want to use D/Objective-C you can DStep [2] to create bindings.

> Anyway, looking forward to any tools or thoughts you have.  For now,
> exception handling seems the most useful missing feature.  So I am
> looking at that.

[1] https://github.com/jacob-carlborg/dmd/tree/d-objc-64
[2] https://github.com/jacob-carlborg/dstep

-- 
/Jacob Carlborg

On 15 Feb 2014, at 7:58, Dan Olson wrote:
> David suggested we could do that with ldc.  I think it is a good approach.
>
> http://forum.dlang.org/thread/m2d2k79zsl.fsf@comcast.net?page=3#post-mailman.287.1389372405.15871.digitalmars-d-ldc:40puremagic.com

The big question is how to best implement it, though.

From an LDC perspective, the best would be to add support for emitting the TLS variables into a bracketed section and inserting runtime calls to access them directly to LLVM; then none of the LDC code (resp. the generated LLVM IR) would actually have to change.

That might be too much work for this option to be feasible, though – I never really looked at how the various targets lower TLS accesses (besides Win32/MinGW, where I contributed a few small fixes).

I suppose the best way to go about this would simply be to ask for advice on llvm-dev, probably somebody can judge the involved trade-offs much better than I can.

David

On Saturday, 15 February 2014 at 15:13:07 UTC, David Nadlinger wrote:

> The big question is how to best implement it, though.
>
> From an LDC perspective, the best would be to add support for emitting the TLS variables into a bracketed section and inserting runtime calls to access them directly to LLVM; then none of the LDC code (resp. the generated LLVM IR) would actually have to change.

At least DMD had some problems with bracketed sections with the linker. DMD doesn't use bracketed sections anymore. Why do you need bracketed sections? At least OS X has API's available to access a specific sections. I would assume iOS also has does API's.

Would it be possible to output OS X native TLS for iOS? Does LLVM allow that? If that's possible we could experiment with adding the TLS code from the dynamic linker to druntime and see what happens. Theoretically it should work. It don't think the dynamic linker does anything that a regular application can't do.

--
/Jacob Carlborg

On 16 Feb 2014, at 13:43, Jacob Carlborg wrote:
> On Saturday, 15 February 2014 at 15:13:07 UTC, David Nadlinger wrote:
>> From an LDC perspective, the best would be to add support for emitting the TLS variables into a bracketed section and inserting runtime calls to access them directly to LLVM; then none of the LDC code (resp. the generated LLVM IR) would actually have to change.
>
> At least DMD had some problems with bracketed sections with the linker. DMD doesn't use bracketed sections anymore. Why do you need bracketed sections? At least OS X has API's available to access a specific sections.

Sorry, yes, I just intended to write "special section".

But as a side note, Darwin's dyld is more or less alone in offering that functionality. On other OSes, DMD still uses bracketed sections for various tasks.

> Would it be possible to output OS X native TLS for iOS? Does LLVM allow that? If that's possible we could experiment with adding the TLS code from the dynamic linker to druntime and see what happens. Theoretically it should work. It don't think the dynamic linker does anything that a regular application can't do.

I was thinking about that as well, yes. In theory, it should be possible to adapt the code in LLVM without too much of a hassle (I don't think there would be any problems with x86-specific relocations or so), but as I said, I haven't looked into how the TLS sections are emitted when writing to Mach-O at all.

Another thing to keep in mind would be that we probably can't use some of the APIs due to App Store restrictions…

David