January 23, 2014
Jacob Carlborg <doob@me.com> writes:

> On 2014-01-23 06:34, Dan Olson wrote:
>
> I don't know why the wouldn't accept D since they accept applications built with C# and similar.

Once we get something simple with most of D runtime working, should submit and see what they think.

January 23, 2014
On 2014-01-23 09:11, Dan Olson wrote:

> Once we get something simple with most of D runtime working, should
> submit and see what they think.

It would probably be easier to send something to the Mac App Store. I'm wondering how similar the rules are.

-- 
/Jacob Carlborg
January 30, 2014
A small step, but over a big hurdle.  Ran D code + druntime on an iPhone.  Nothing fancy, but initialized runtime with rt_init() and did some dynamic array operations.  I include a snippet of silly D program I ran at end of post.

The big hurdle has been ldc assertion failures in backend/codegen phase. I have been studying llvm/clang code, but that takes time.  So I tried an experiment.

If ldc2 skips the backend phase, it can generate IR (option -output-ll) just fine for iOS target -mtriple=thumbv7-darwin.  Then question is, can we use llc to do the backend codegen?  Like this:

  ldc2 -output-ll   [target and compile options]
  llc -filetype=obj [similar target and compile options]

It works!  Could I compile all of druntime this way? Yes!  Will it run on an iPhone?  Yes again.

Still need to figure out the assertions but now have a work around so I can move on with getting more D stuff (classes, exceptions, threads, etc) working on iOS.

I also discovered that clang does a bunch of target munging, so -target armv7-apple-darwin becomes:

  clang -cc1 -triple thumbv7-apple-ios5.0.0 -target-cpu cortex-a8

in the compile phase.  What is good for clang must be good for ldc.  It does affect the register usage and probably the calling convention.

So when I edited druntime makefiles and used the two step build
(ldc2/llc), I used options:

ldc2 -mtriple=thumbv7-apple-ios5.0.0 -mcpu=cortex-a8 -disable-fp-elim -float-abi=soft
llc -mtriple=thumbv7-apple-ios5.0.0 -float-abi=soft -mcpu=cortex-a8 -disable-fp-elim -O3 -filetype=obj

Note: this is with llvm-svn trunk and ldc git HEAD with a small number of hacks in ldc tree just to get things going.

Following is some code I ran.  It is kicked off by calling dfun() from
the iOS app's main() C functions.

extern (C) int dfun()
{
    puts("Hello from dfun");
    foo("foo");
    return 2014;
}

struct Foo {
    this(int x, int y) {
        this.x = x;
        this.y = y;
        printf("Foo(%d, %d)\n", x, y);
    }
    ~this() {
        puts("~Foo");
    }
    int x, y;
}

void foo(string p)
{
    string s = "I am a D function: " ~ p;
    puts(s.ptr);

    auto f = Foo(1,42);

    printf("%d\n", f.x + f.y);

    int[] ar = [42];
    scope(exit) puts("done");

    foreach (i; 0..11) {
        printf("hello %d\n", i);
        ar ~= i;
    }

    foreach (i; ar) {
        printf("ar %d\n", i);
    }
}
January 31, 2014
On 2014-01-30 17:56, Dan Olson wrote:
> A small step, but over a big hurdle.  Ran D code + druntime on an
> iPhone.  Nothing fancy, but initialized runtime with rt_init() and did
> some dynamic array operations.  I include a snippet of silly D program I
> ran at end of post.

This is awesome. Have you tried any non C features, like classes yet?

Keep up to good work :)

-- 
/Jacob Carlborg
January 31, 2014
Jacob Carlborg <doob@me.com> writes:

> On 2014-01-30 17:56, Dan Olson wrote:
>> A small step, but over a big hurdle.  Ran D code + druntime on an iPhone.  Nothing fancy, but initialized runtime with rt_init() and did some dynamic array operations.  I include a snippet of silly D program I ran at end of post.
>
> This is awesome. Have you tried any non C features, like classes yet?
>
> Keep up to good work :)

Hi Jacob,

Yes, classes work.  So far everthing I have tried works except exceptions and threads which have some stubbed out support in druntime. And TLS is disabled too.  I am just stepping through druntime features. It may be time to figure out how to run the runtime unittests on iOS. Or maybe the next step is to rebuild phobos using the ldc/llc two phase approach.

Earlier I had thought classes were a problem because when I added one to my test code, I was hitting illegal instructions in places that used to work.  I thought there was some sort of codegen alignment problem.  I now think it was because I had breakpoints on assembly instructions and I can't leave them in after rebuilding my test app.

-- 
Dan
February 01, 2014
Hi Dan!

On Thursday, 30 January 2014 at 16:56:05 UTC, Dan Olson wrote:
>
> If ldc2 skips the backend phase, it can generate IR (option -output-ll)
> just fine for iOS target -mtriple=thumbv7-darwin.  Then question is, can
> we use llc to do the backend codegen?  Like this:
>
>   ldc2 -output-ll   [target and compile options]
>   llc -filetype=obj [similar target and compile options]
>
> It works!  Could I compile all of druntime this way? Yes!  Will it
> run on an iPhone?  Yes again.

This sounds like a great step forward! Congratulations!

I think I found the root cause why ldc crashes. I fixed it in the merge-2.064 branch. If you like to try it...

Regards,
Kai
February 01, 2014
"Kai Nacke" <kai@redstar.de> writes:

> I think I found the root cause why ldc crashes. I fixed it in the merge-2.064 branch. If you like to try it...
>
> Regards,
> Kai

Yes - I am would like to try it out this evening.
February 02, 2014
Dan Olson <zans.is.for.cans@yahoo.com> writes:

> "Kai Nacke" <kai@redstar.de> writes:
>
>> I think I found the root cause why ldc crashes. I fixed it in the merge-2.064 branch. If you like to try it...
>>
>> Regards,
>> Kai
>
> Yes - I am would like to try it out this evening.

Tried it and no more crashing (segv) :-)

Should I be using merge-2.064 branch instead of master
for my iOS porting fun?
-- 
Dan
February 03, 2014
On Sunday, 2 February 2014 at 09:31:24 UTC, Dan Olson wrote:
> Dan Olson <zans.is.for.cans@yahoo.com> writes:
>
>> "Kai Nacke" <kai@redstar.de> writes:
>>
>>> I think I found the root cause why ldc crashes. I fixed it in the
>>> merge-2.064 branch. If you like to try it...
>>>
>>> Regards,
>>> Kai
>>
>> Yes - I am would like to try it out this evening.
>
> Tried it and no more crashing (segv) :-)
>
> Should I be using merge-2.064 branch instead of master
> for my iOS porting fun?

Great. Yes, please do. I hope I can fix the last few bugs in this branch soon.

Regards,
Kai
February 05, 2014
> 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.
-- 
Dan