February 05, 2014
On Wednesday, 5 February 2014 at 07:32:05 UTC, Dan Olson wrote:
>> Or maybe the next step is to rebuild phobos using the ldc/llc two phase
>> approach.
>
> Success building phobos this way and was able to writeln() to the Xcode
> console from iPhone 4.  Again, druntime rt_init() and D functions are
> called by the iOS app's C main (not using dmain2 main).
>
> In the process, I discovered that std.stdio was uninitialized because
> module constructors are not being called by rt_init().  Something in the
> runtime sections OSX code that does not work for iOS.  Oh, well, add to
> the todo list.  However, found I could manually initialize std.stdio
> with std_stdio_static_this().
>
> --- dfun.d ---
> import std.stdio;
>
> extern(C) void std_stdio_static_this();
>
> extern(C) int dfun()
> {
>     // static this in std.stdiobase isn't it called automatically? Need to
>     // figure it out.  In meantime, just do it!
>     std_stdio_static_this();
>
>     writeln("Hello phobos");
>     return 2014;
> }
>
> All the LEGO blocks are there in ldc to build a D toolchain for iOS.
> Over the next few weeks I will put up stuff on github along with a todo
> list.  I am not very good with Xcode so any thoughts on how to integrate
> would be nice.
>
> The tolist will look something like:
> - fix module ctors/dtors
> - version info for iOS (now using OSX && ARM, but not sure that makes
>    sense?  Use darwin && ARM?, or create new IOS version?)
> - exception support
> - thread support
> - tls support
> - run (and pass) unittests
> - figure out ldc codegen assertion errors for armv7/thumbv7 so can ditch
>    the ldc/llc 2-phase approach.
>
> that is enough for now.

Great to see such progress!
February 05, 2014
Hi Dan!

On Wednesday, 5 February 2014 at 07:32:05 UTC, Dan Olson wrote:
>
> The tolist will look something like:
> - fix module ctors/dtors
> - version info for iOS (now using OSX && ARM, but not sure that makes
>    sense?  Use darwin && ARM?, or create new IOS version?)
> - exception support
> - thread support
> - tls support
> - run (and pass) unittests
> - figure out ldc codegen assertion errors for armv7/thumbv7 so can ditch
>    the ldc/llc 2-phase approach.
>
> that is enough for now.

This really great work!!!!

I think the that modules ctors/dtors are not calles may be a side effect of not having the right version identifier. As soon as you know what version identifier you need, please let me know. I'll add it asap.

And if you still encounter ldc crashes, please report them. Even if I can't help on iOS right know I still can make sure that you have a stable environment.

Again, thanks for doing this!

Regards,
Kai
February 05, 2014
On 2014-02-05 08:32, Dan Olson wrote:

> Success building phobos this way and was able to writeln() to the Xcode
> console from iPhone 4.

That's great to hear :)

> Again, druntime rt_init() and D functions are called by the iOS app's C main (not using dmain2 main).
>
> In the process, I discovered that std.stdio was uninitialized because
> module constructors are not being called by rt_init().  Something in the
> runtime sections OSX code that does not work for iOS.  Oh, well, add to
> the todo list.  However, found I could manually initialize std.stdio
> with std_stdio_static_this().

To have to module constructors run you need to implement rt.sections correctly for iOS. You could most likely use rt.sections_osx for iOS.

> I am not very good with Xcode so any thoughts on how to integrate
> would be nice.

To integrate Xcode with LDC you would need to create a plugin for Xcode, which is not officially supported. This has already been done by Michel Fortin[1], but that was for Xcode 3. There are a couple of plugins for Xcode 4 out there to look at.

[1] http://michelf.ca/projects/d-for-xcode/

-- 
/Jacob Carlborg
February 05, 2014
Jacob Carlborg <doob@me.com> writes:

> To integrate Xcode with LDC you would need to create a plugin for Xcode, which is not officially supported. This has already been done by Michel Fortin[1], but that was for Xcode 3. There are a couple of plugins for Xcode 4 out there to look at.
>
> [1] http://michelf.ca/projects/d-for-xcode/

Ok, good reference.  It would also be nice to eventually try some Michel's and your D compiler modifications to directly interface with objc.  I have read about them elsewhere in the D newsgroups.

Thanks,
Dan
February 05, 2014
"Kai Nacke" <kai@redstar.de> writes:

> I think the that modules ctors/dtors are not calles may be a side effect of not having the right version identifier. As soon as you know what version identifier you need, please let me know. I'll add it asap.

Currently the verison(OSX) works in most places for iOS, or at least it compiles. Where I know there is a difference, I used nested version blocks by ARM. In the sections code, the existing version OSX code is being compiled without error, but does not work. I need to study it.

I am not sure on the proper version handling yet. Most versioned code will be identical for OSX and IOS, so maybe most places in druntime should use version(darwin), then nested OSX/IOS when there is a difference? Does that make sense?

> And if you still encounter ldc crashes, please report them. Even if I can't help on iOS right know I still can make sure that you have a stable environment.

Yeah, there are 3 flavors of assertion failures which I can write as issues.

-- 
Dan
February 05, 2014
"Szymon Gatner" <noemail@gmail.com> writes:

> Great to see such progress!

Yes, it is good when stuff just starts to work.  Only problem is when it cuts into sleep... :-)


February 05, 2014
On 2014-02-05 18:31, Dan Olson wrote:

> I am not sure on the proper version handling yet. Most versioned code
> will be identical for OSX and IOS, so maybe most places in druntime
> should use version(darwin), then nested OSX/IOS when there is a
> difference? Does that make sense?

Funny thing. When DMD was ported to OS X, "OSX" was added as a version identifier and "darwin" as a deprecated version identifier. "darwin" was already used by GDC, which was ported to OS X long before DMD.

-- 
/Jacob Carlborg
February 05, 2014
Le 05/02/2014 08:32, Dan Olson a écrit :
>> Or maybe the next step is to rebuild phobos using the ldc/llc two phase
>> approach.
>
> Success building phobos this way and was able to writeln() to the Xcode
> console from iPhone 4.  Again, druntime rt_init() and D functions are
> called by the iOS app's C main (not using dmain2 main).
>
> In the process, I discovered that std.stdio was uninitialized because
> module constructors are not being called by rt_init().  Something in the
> runtime sections OSX code that does not work for iOS.  Oh, well, add to
> the todo list.  However, found I could manually initialize std.stdio
> with std_stdio_static_this().
>
> --- dfun.d ---
> import std.stdio;
>
> extern(C) void std_stdio_static_this();
>
> extern(C) int dfun()
> {
>      // static this in std.stdiobase isn't it called automatically? Need to
>      // figure it out.  In meantime, just do it!
>      std_stdio_static_this();
>
>      writeln("Hello phobos");
>      return 2014;
> }
>
> All the LEGO blocks are there in ldc to build a D toolchain for iOS.
> Over the next few weeks I will put up stuff on github along with a todo
> list.  I am not very good with Xcode so any thoughts on how to integrate
> would be nice.
>
> The tolist will look something like:
> - fix module ctors/dtors
> - version info for iOS (now using OSX && ARM, but not sure that makes
>     sense?  Use darwin && ARM?, or create new IOS version?)
> - exception support
> - thread support
> - tls support
> - run (and pass) unittests
> - figure out ldc codegen assertion errors for armv7/thumbv7 so can ditch
>     the ldc/llc 2-phase approach.
>
> that is enough for now.
>
Really great news...

Thx for all your efforts.
February 06, 2014
On Wednesday, 5 February 2014 at 17:31:23 UTC, Dan Olson wrote:
> "Kai Nacke" <kai@redstar.de> writes:
>
>> I think the that modules ctors/dtors are not calles may be a side
>> effect of not having the right version identifier. As soon as you know
>> what version identifier you need, please let me know. I'll add it
>> asap.
>
> Currently the verison(OSX) works in most places for iOS, or at least it
> compiles. Where I know there is a difference, I used nested version
> blocks by ARM. In the sections code, the existing version OSX code is
> being compiled without error, but does not work. I need to study it.
>
> I am not sure on the proper version handling yet. Most versioned code
> will be identical for OSX and IOS, so maybe most places in druntime
> should use version(darwin), then nested OSX/IOS when there is a
> difference? Does that make sense?
That sounds like a reasonable approach.  Alternately, you could use X86/ARM, since OS X only runs on x86 now and iOS on ARM, which would be easier since those architecture keywords already exist, but perhaps not future-proof if Apple ever releases that ARM-based OS X laptop. ;) Darwin and iOS aren't in the predefined global versions in dmd's cond.c, so you might want to add them if you use those.
February 09, 2014
"Kai Nacke" <kai@redstar.de> writes:

> Hi Dan!
>
> On Wednesday, 5 February 2014 at 07:32:05 UTC, Dan Olson wrote:
>>
>> The to *do* list will look something like:
>> - fix module ctors/dtors
>
> I think the that modules ctors/dtors are not calles may be a side effect of not having the right version identifier. As soon as you know what version identifier you need, please let me know. I'll add it asap.

I figured out why static this() wasn't working.  I was calling rt_init()
in a __attribute__((constructor)) function.  But then I noticed that LDC
builds the ModuleReference list with global ctors too.  So odds were I
was calling rt_init() before all D modules were in the list.  Calling
rt_init() from C main solved it.