A little progress report. More to come later when I get something pushed to github.

I bought a returned Apple Watch yesterday at discount for $223.99 US and tried to see how much of D would work on it using my iOS fork of LDC. There were a few bumps, like dealing with embedded bitcode (a watchOS requirement). After 4-hours of baby steps, little D programs with incremental druntime support, I was able to download a huge watch app extension with all druntime and phobos unittests and run most of them alphabetically. Everything zipped along fine, only a std.math error, then mysteriously a exit after running std.parallelism test a long time. It was late for me so decided that was enough progress.

This means all of druntime worked and probably most of phobos.

The Apple Watch uses a new chip with armv7k, a different ABI, and different exception handling than iOS, so kinda surprised it worked as well as it did.  Of course much thanks goes to LLVM with recently added watchOS, tvOS support, and all the LDC contributors that have kept master building with the latest 3.8 LLVM.
-- 
Dan

On Monday, 28 December 2015 at 01:17:15 UTC, Dan Olson wrote:
> A little progress report. More to come later when I get something pushed to github.
>
> I bought a returned Apple Watch yesterday at discount for $223.99 US and tried to see how much of D would work on it using my iOS fork of LDC. There were a few bumps, like dealing with embedded bitcode (a watchOS requirement). After 4-hours of baby steps, little D programs with incremental druntime support, I was able to download a huge watch app extension with all druntime and phobos unittests and run most of them alphabetically. Everything zipped along fine, only a std.math error, then mysteriously a exit after running std.parallelism test a long time. It was late for me so decided that was enough progress.
>
> This means all of druntime worked and probably most of phobos.
>
> The Apple Watch uses a new chip with armv7k, a different ABI, and different exception handling than iOS, so kinda surprised it worked as well as it did.  Of course much thanks goes to LLVM with recently added watchOS, tvOS support, and all the LDC contributors that have kept master building with the latest 3.8 LLVM.

Heh, nice, thanks for keeping us up to date.

I don't understand how the bitcode requirement works on your own device: I thought that was for an Apple-submitted app that they then compiled to binary themselves?  Do you have to go through the same process even for test apps, ie no sideloading?  Or does the device itself take bitcode?

btw, Dan's iOS/tvOS/watchOS work will require these dmd/druntime github pulls to be reviewed and merged:

https://github.com/D-Programming-Language/dmd/pull/5231
https://github.com/D-Programming-Language/druntime/pull/1448

Joakim <dlang@joakim.fea.st> writes:
>
> I don't understand how the bitcode requirement works on your own device: I thought that was for an Apple-submitted app that they then compiled to binary themselves?  Do you have to go through the same process even for test apps, ie no sideloading?  Or does the device itself take bitcode?

This is all based on my experience and I don't know the full bitcode story.  I may state erroneous info below.

The device takes normal executables but there is a check to make sure that each object file has the appropriate bitcode sections. I think the linker does this, but did not check which tool in build chain spit out the error.

The bitcode is actually two new sections in every object file:

  .section __LLVM,__bitcode
  .section __LLVM,__cmdline

The __bitcode section seems to just be the LLVM IR for the object file
in the .bc binary format. Some sources say it is a xar archive but in my
investigation I used Apple's clang with -fembed-bitcode and inspected
the IR or ARM assembly to see these two sections. Extracting and using
llvm-dis on the __bitcode section gave back the containing module's
IR in human readable format. It exactly matches the LLVM IR for its
object file sans Apple's clang -fembed-bitcode.  So not sure when xar is
used yet.

The __cmdline section appears to be some of the clang options used to compile the bitcode.

The compile process becomes something like this:
1. Create IR for module as usual.
2. Generate the IR bitcode representation.
3. Add the two new sections, using bitcode from (2) as contents of
  __bitcode section and __cmdline options to compile it
4. Generate object from IR.

But not wanting to figure all that out now, I tried simpler things and discovered that at least for testing, these sections only need to be present and the contents don't seem to matter. So for now I skip 2 and just put a zero in each.

On implication of Apple requiring bitcode: if Apple is compiling the bitcode with their clang or llc, then it means using a modifed LLVM like I do to support thread-locals on watchOS, tvOS, or iOS is only good for side loading.  Probably going to have to work on plan B for thread-locals.
-- 
Dan

On Monday, 28 December 2015 at 08:45:46 UTC, Dan Olson wrote:
> Joakim <dlang@joakim.fea.st> writes:
>>
>> I don't understand how the bitcode requirement works on your own device: I thought that was for an Apple-submitted app that they then compiled to binary themselves?  Do you have to go through the same process even for test apps, ie no sideloading?  Or does the device itself take bitcode?
>
> This is all based on my experience and I don't know the full bitcode story.  I may state erroneous info below.
>
> The device takes normal executables but there is a check to make sure that each object file has the appropriate bitcode sections. I think the linker does this, but did not check which tool in build chain spit out the error.
>
> The bitcode is actually two new sections in every object file:
>
>   .section __LLVM,__bitcode
>   .section __LLVM,__cmdline
>
> The __bitcode section seems to just be the LLVM IR for the object file
> in the .bc binary format. Some sources say it is a xar archive but in my
> investigation I used Apple's clang with -fembed-bitcode and inspected
> the IR or ARM assembly to see these two sections. Extracting and using
> llvm-dis on the __bitcode section gave back the containing module's
> IR in human readable format. It exactly matches the LLVM IR for its
> object file sans Apple's clang -fembed-bitcode.  So not sure when xar is
> used yet.
>
> The __cmdline section appears to be some of the clang options used to compile the bitcode.
>
> The compile process becomes something like this:
> 1. Create IR for module as usual.
> 2. Generate the IR bitcode representation.
> 3. Add the two new sections, using bitcode from (2) as contents of
>   __bitcode section and __cmdline options to compile it
> 4. Generate object from IR.
>
> But not wanting to figure all that out now, I tried simpler things and discovered that at least for testing, these sections only need to be present and the contents don't seem to matter. So for now I skip 2 and just put a zero in each.

Thanks for the detailed answer; I'm sure this will now become the definitive answer online.  I've gone googling for technical info only to sometimes be directed back to a post in these D forums. :)

> On implication of Apple requiring bitcode: if Apple is compiling the bitcode with their clang or llc, then it means using a modifed LLVM like I do to support thread-locals on watchOS, tvOS, or iOS is only good for side loading.  Probably going to have to work on plan B for thread-locals.

Time to get emulated TLS for Mach-O into llvm, as one google engineer did with ELF for Android, which will be released in the upcoming llvm 3.8:

https://code.google.com/p/android/issues/detail?id=78122

On 2015-12-28 09:45, Dan Olson wrote:

> On implication of Apple requiring bitcode: if Apple is compiling the
> bitcode with their clang or llc, then it means using a modifed LLVM like
> I do to support thread-locals on watchOS, tvOS, or iOS is only good for
> side loading.  Probably going to have to work on plan B for
> thread-locals.

Would it be possible to bypass LLVM and do the thread local specific parts in LDC?

-- 
/Jacob Carlborg

Joakim <dlang@joakim.fea.st> writes:
>
> Thanks for the detailed answer; I'm sure this will now become the definitive answer online.  I've gone googling for technical info only to sometimes be directed back to a post in these D forums. :)

Me too!  Its very funny when that happens.

> Time to get emulated TLS for Mach-O into llvm, as one google engineer did with ELF for Android, which will be released in the upcoming llvm 3.8:
>
> https://code.google.com/p/android/issues/detail?id=78122

That is Plan B.1

Jacob Carlborg <doob@me.com> writes:
>
> Would it be possible to bypass LLVM and do the thread local specific parts in LDC?

That is Plan B.2

On 2015-12-28 20:02, Dan Olson wrote:

> That is Plan B.2

I'm working on implementing native TLS for OS X in DMD. I think I've figured out how everything works. Unless you already know how it works, I could tell you what I have figured out.

-- 
/Jacob Carlborg

Jacob Carlborg <doob@me.com> writes:

> On 2015-12-28 20:02, Dan Olson wrote:
>
>> That is Plan B.2
>
> I'm working on implementing native TLS for OS X in DMD. I think I've figured out how everything works. Unless you already know how it works, I could tell you what I have figured out.

I know some of it from hacking dyld for iOS, but not all.  How does this fit in with "Plan B.2"?

On 2015-12-30 08:02, Dan Olson wrote:

> I know some of it from hacking dyld for iOS, but not all.  How does this
> fit in with "Plan B.2"?

If you need to figure out how TLS works, I can give you some help, that's all I'm saying :)

-- 
/Jacob Carlborg