Jump to page: 1 2 3
Thread overview
Better watch out! D runs on watchOS!
Dec 28, 2015
Dan Olson
Dec 28, 2015
Joakim
Dec 28, 2015
Dan Olson
Dec 28, 2015
Joakim
Dec 28, 2015
Dan Olson
Dec 28, 2015
Jacob Carlborg
Dec 28, 2015
Dan Olson
Dec 29, 2015
Jacob Carlborg
Dec 30, 2015
Dan Olson
Dec 30, 2015
Jacob Carlborg
Dec 30, 2015
Dan Olson
Dec 31, 2015
Jacob Carlborg
Dec 31, 2015
Joakim
Dec 30, 2015
Dan Olson
Dec 30, 2015
Joakim
Dec 31, 2015
Dan Olson
Dec 31, 2015
Joakim
Jan 04, 2016
Dan Olson
Jan 04, 2016
Joakim
Jan 04, 2016
Dan Olson
Jan 04, 2016
Dan Olson
Jan 06, 2016
Dan Olson
Re: D runs on watchOS! and on Android Wear too!
Jan 05, 2016
Laeeth Isharc
Jan 06, 2016
Joakim
Jan 06, 2016
Dan Olson
Jan 07, 2016
Laeeth Isharc
Jan 07, 2016
Rory McGuire
December 27, 2015
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
December 28, 2015
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
December 28, 2015
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
December 28, 2015
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
December 28, 2015
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
December 28, 2015
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
December 28, 2015
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
December 29, 2015
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
December 29, 2015
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"?
December 30, 2015
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
« First   ‹ Prev
1 2 3