February 05, 2012
wow, great news for my phone :)
I've read another blogpost about someone trying to achieve the same, had
something to do with "between ideals", I'll google it up if you need it.
he had a github repo with some "ugly hacks" to make druntime work for
android, maybe this can be looked into?

2012/2/5 Alex Rønne Petersen <xtzgzorex@gmail.com>

> On 02/05/2012 11:04 PM, Johannes Pfau wrote:
>
>> Am Sun, 5 Feb 2012 18:04:12 +0100
>> schrieb Johannes Pfau<nospam@example.com>:
>>
>>  I will probably need some more time to get this working...
>>>
>>>
>> I have some good news: http://www.mediafire.com/?**107we120sh3xx<http://www.mediafire.com/?107we120sh3xx>
>>
>> I fixed that problem and then the whole build worked fine. I'll post build instructions soon, but the binaries are ready. I only did a simple gdc -c test.d to check the compiler, but it seems to work.
>>
>> Linking against druntime fails, as it uses functions which are not available on Android (backtrace, signal stuff).
>>
>> I also built a simple hello world on linux (printf, no runtime) and ran it on my android phone, and it worked!
>>
>> In case you haven't used GDC without runtime before, a short introduction:
>>
>> * use gdc -nophoboslib to make gdc not link against phobos (and afaik,
>>   druntime)
>> * theres also -nostdlib in case you need it
>> * complex code may require -fno-section-anchors because of bug #120
>> * You'll get an error about a missing _Dmodule_ref symbol. That symbol
>>   is used by module constructors and not generated by gdc if
>>   -nophoboslib was passed. As long as you don't run the module
>>   constructors, you can add a fake _Dmodule_ref in a .c file:
>>
>> ------------
>> void* _Dmodule_ref;
>> ------------
>>
>> * The compiler defines version(Android)
>>
>> Here's my hello world:
>> ------------
>> version(Android)
>> {
>>     pragma(msg, "Hello Android!");
>> }
>>
>> extern(C)
>> {
>>     int printf(in char* format, ...);
>> }
>>
>> extern(C) void main()
>> {
>>     printf("Hello, %s!\n".ptr, "Android".ptr);
>> }
>> ------------
>>
>> compile the _Dmodule_ref into hack.o, then use
>> gdc -nophoboslib hello.d hack.o
>>
>
> Can we standardize that Android version identifier? Would be good to have it on dlang.org/version.html.
>
> --
> - Alex
>


February 06, 2012
On 6 February 2012 00:04, Johannes Pfau <nospam@example.com> wrote:

> Am Sun, 5 Feb 2012 18:04:12 +0100
> schrieb Johannes Pfau <nospam@example.com>:
>
> > I will probably need some more time to get this working...
> >
>
> I have some good news: http://www.mediafire.com/?107we120sh3xx
>
> I fixed that problem and then the whole build worked fine. I'll post build instructions soon, but the binaries are ready. I only did a simple gdc -c test.d to check the compiler, but it seems to work.
>
> Linking against druntime fails, as it uses functions which are not available on Android (backtrace, signal stuff).
>
> I also built a simple hello world on linux (printf, no runtime) and ran it on my android phone, and it worked!
>
> In case you haven't used GDC without runtime before, a short introduction:
>
> * use gdc -nophoboslib to make gdc not link against phobos (and afaik,
>  druntime)
> * theres also -nostdlib in case you need it
> * complex code may require -fno-section-anchors because of bug #120
> * You'll get an error about a missing _Dmodule_ref symbol. That symbol
>  is used by module constructors and not generated by gdc if
>  -nophoboslib was passed. As long as you don't run the module
>  constructors, you can add a fake _Dmodule_ref in a .c file:
>
> ------------
> void* _Dmodule_ref;
> ------------
>
> * The compiler defines version(Android)
>
> Here's my hello world:
> ------------
> version(Android)
> {
>    pragma(msg, "Hello Android!");
> }
>
> extern(C)
> {
>    int printf(in char* format, ...);
> }
>
> extern(C) void main()
> {
>    printf("Hello, %s!\n".ptr, "Android".ptr);
> }
> ------------
>
> compile the _Dmodule_ref into hack.o, then use
> gdc -nophoboslib hello.d hack.o
>

Amazing! You sir, are a genius!
I'm gonna have to have some fun with that after work tomorrow :)

I reckon this binary distro should be put on d-p-l somewhere obvious.


February 06, 2012
On 6 February 2012 02:25, Manu <turkeyman@gmail.com> wrote:

> On 6 February 2012 00:04, Johannes Pfau <nospam@example.com> wrote:
>
>> Am Sun, 5 Feb 2012 18:04:12 +0100
>> schrieb Johannes Pfau <nospam@example.com>:
>>
>> > I will probably need some more time to get this working...
>> >
>>
>> I have some good news: http://www.mediafire.com/?107we120sh3xx
>>
>> I fixed that problem and then the whole build worked fine. I'll post build instructions soon, but the binaries are ready. I only did a simple gdc -c test.d to check the compiler, but it seems to work.
>>
>> Linking against druntime fails, as it uses functions which are not available on Android (backtrace, signal stuff).
>>
>> I also built a simple hello world on linux (printf, no runtime) and ran it on my android phone, and it worked!
>>
>> In case you haven't used GDC without runtime before, a short introduction:
>>
>> * use gdc -nophoboslib to make gdc not link against phobos (and afaik,
>>  druntime)
>> * theres also -nostdlib in case you need it
>> * complex code may require -fno-section-anchors because of bug #120
>> * You'll get an error about a missing _Dmodule_ref symbol. That symbol
>>  is used by module constructors and not generated by gdc if
>>  -nophoboslib was passed. As long as you don't run the module
>>  constructors, you can add a fake _Dmodule_ref in a .c file:
>>
>> ------------
>> void* _Dmodule_ref;
>> ------------
>>
>> * The compiler defines version(Android)
>>
>> Here's my hello world:
>> ------------
>> version(Android)
>> {
>>    pragma(msg, "Hello Android!");
>> }
>>
>> extern(C)
>> {
>>    int printf(in char* format, ...);
>> }
>>
>> extern(C) void main()
>> {
>>    printf("Hello, %s!\n".ptr, "Android".ptr);
>> }
>> ------------
>>
>> compile the _Dmodule_ref into hack.o, then use
>> gdc -nophoboslib hello.d hack.o
>>
>
> Amazing! You sir, are a genius!
> I'm gonna have to have some fun with that after work tomorrow :)
>
> I reckon this binary distro should be put on d-p-l somewhere obvious.
>

I just tried with -mfpu=neon, which should allow GCC to generate neon
opcodes for the simd stuff, but it didn't seem to want to do that. In fact
it generates really horrible code where it CALLS an intrinsic for each
float in the vector...
Any idea why this wouldn't work out of the box?

I wanted to add ARM support to my std.simd work here as a better proof of concept.

Iain: was there anything particularly special you needed to do to hook the x86 SSE stuff to GDC which would need to be duplicated for ARM? gcc.builtins doesn't seen to have any ARM intrinsics in there either...


February 06, 2012
Am Mon, 6 Feb 2012 03:07:31 +0200
schrieb Manu <turkeyman@gmail.com>:

> On 6 February 2012 02:25, Manu <turkeyman@gmail.com> wrote:
> 
> > On 6 February 2012 00:04, Johannes Pfau <nospam@example.com> wrote:
> >
> >> Am Sun, 5 Feb 2012 18:04:12 +0100
> >> schrieb Johannes Pfau <nospam@example.com>:
> >>
> >> > I will probably need some more time to get this working...
> >> >
> >>
> >> I have some good news: http://www.mediafire.com/?107we120sh3xx
> >>
> >> I fixed that problem and then the whole build worked fine. I'll post build instructions soon, but the binaries are ready. I only did a simple gdc -c test.d to check the compiler, but it seems to work.
> >>
> >> Linking against druntime fails, as it uses functions which are not available on Android (backtrace, signal stuff).
> >>
> >> I also built a simple hello world on linux (printf, no runtime) and ran it on my android phone, and it worked!
> >>
> >> In case you haven't used GDC without runtime before, a short introduction:
> >>
> >> * use gdc -nophoboslib to make gdc not link against phobos (and
> >> afaik, druntime)
> >> * theres also -nostdlib in case you need it
> >> * complex code may require -fno-section-anchors because of bug #120
> >> * You'll get an error about a missing _Dmodule_ref symbol. That
> >> symbol is used by module constructors and not generated by gdc if
> >>  -nophoboslib was passed. As long as you don't run the module
> >>  constructors, you can add a fake _Dmodule_ref in a .c file:
> >>
> >> ------------
> >> void* _Dmodule_ref;
> >> ------------
> >>
> >> * The compiler defines version(Android)
> >>
> >> Here's my hello world:
> >> ------------
> >> version(Android)
> >> {
> >>    pragma(msg, "Hello Android!");
> >> }
> >>
> >> extern(C)
> >> {
> >>    int printf(in char* format, ...);
> >> }
> >>
> >> extern(C) void main()
> >> {
> >>    printf("Hello, %s!\n".ptr, "Android".ptr);
> >> }
> >> ------------
> >>
> >> compile the _Dmodule_ref into hack.o, then use
> >> gdc -nophoboslib hello.d hack.o
> >>
> >
> > Amazing! You sir, are a genius!
> > I'm gonna have to have some fun with that after work tomorrow :)
> >
> > I reckon this binary distro should be put on d-p-l somewhere obvious.
> >
> 
> I just tried with -mfpu=neon, which should allow GCC to generate neon
> opcodes for the simd stuff, but it didn't seem to want to do that. In
> fact it generates really horrible code where it CALLS an intrinsic
> for each float in the vector...
> Any idea why this wouldn't work out of the box?

The android toolchain configures gcc with: += --with-float=soft --with-fpu=vfp --with-arch=armv5te

I could try to build an optimized build, but then you'll have to tell me what processor you're using. Cortex A8?

I'm not sure if you can override that at runtime. You could probably
try:
-mfloat-abi=hard -mcpu=cortex-a8 -march=armv7-a -mfpu=neon

> I wanted to add ARM support to my std.simd work here as a better proof of concept.
> 
> Iain: was there anything particularly special you needed to do to hook the x86 SSE stuff to GDC which would need to be duplicated for ARM? gcc.builtins doesn't seen to have any ARM intrinsics in there either...
> 

February 06, 2012
On Mon, Feb 6, 2012 at 1:40 AM, Johannes Pfau <nospam@example.com> wrote:
> Am Mon, 6 Feb 2012 03:07:31 +0200
> schrieb Manu <turkeyman@gmail.com>:
>
>> On 6 February 2012 02:25, Manu <turkeyman@gmail.com> wrote:
>>
>> > On 6 February 2012 00:04, Johannes Pfau <nospam@example.com> wrote:
>> >
>> >> Am Sun, 5 Feb 2012 18:04:12 +0100
>> >> schrieb Johannes Pfau <nospam@example.com>:
>> >>
>> >> > I will probably need some more time to get this working...
>> >> >
>> >>
>> >> I have some good news: http://www.mediafire.com/?107we120sh3xx
>> >>
>> >> I fixed that problem and then the whole build worked fine. I'll post build instructions soon, but the binaries are ready. I only did a simple gdc -c test.d to check the compiler, but it seems to work.
>> >>
>> >> Linking against druntime fails, as it uses functions which are not available on Android (backtrace, signal stuff).
>> >>
>> >> I also built a simple hello world on linux (printf, no runtime) and ran it on my android phone, and it worked!
>> >>
>> >> In case you haven't used GDC without runtime before, a short introduction:
>> >>
>> >> * use gdc -nophoboslib to make gdc not link against phobos (and
>> >> afaik, druntime)
>> >> * theres also -nostdlib in case you need it
>> >> * complex code may require -fno-section-anchors because of bug #120
>> >> * You'll get an error about a missing _Dmodule_ref symbol. That
>> >> symbol is used by module constructors and not generated by gdc if
>> >>  -nophoboslib was passed. As long as you don't run the module
>> >>  constructors, you can add a fake _Dmodule_ref in a .c file:
>> >>
>> >> ------------
>> >> void* _Dmodule_ref;
>> >> ------------
>> >>
>> >> * The compiler defines version(Android)
>> >>
>> >> Here's my hello world:
>> >> ------------
>> >> version(Android)
>> >> {
>> >>    pragma(msg, "Hello Android!");
>> >> }
>> >>
>> >> extern(C)
>> >> {
>> >>    int printf(in char* format, ...);
>> >> }
>> >>
>> >> extern(C) void main()
>> >> {
>> >>    printf("Hello, %s!\n".ptr, "Android".ptr);
>> >> }
>> >> ------------
>> >>
>> >> compile the _Dmodule_ref into hack.o, then use
>> >> gdc -nophoboslib hello.d hack.o
>> >>
>> >
>> > Amazing! You sir, are a genius!
>> > I'm gonna have to have some fun with that after work tomorrow :)
>> >
>> > I reckon this binary distro should be put on d-p-l somewhere obvious.
>> >
>>
>> I just tried with -mfpu=neon, which should allow GCC to generate neon
>> opcodes for the simd stuff, but it didn't seem to want to do that. In
>> fact it generates really horrible code where it CALLS an intrinsic
>> for each float in the vector...
>> Any idea why this wouldn't work out of the box?
>
> The android toolchain configures gcc with: += --with-float=soft --with-fpu=vfp --with-arch=armv5te
>
> I could try to build an optimized build, but then you'll have to tell me what processor you're using. Cortex A8?
>
> I'm not sure if you can override that at runtime. You could probably
> try:
> -mfloat-abi=hard -mcpu=cortex-a8 -march=armv7-a -mfpu=neon

Actually, if the Android default is to build against softfloat ABI, you may be stuck with it. If Android doesn't require hardfloat to run and doesn't let developers provide multiple binaries for different platforms (which it might - I don't know), things get very hard.

Also, with NEON, one of the things you don't really hear until you start working with these is that NEON isn't actually required in most if not all of the ARM CPU specs. I've specifically dealt with the Tegra 2, which is used in a lot of phones and has no NEON support even though it's ARM Cortex-A9.
February 06, 2012
On 6 February 2012 01:07, Manu <turkeyman@gmail.com> wrote:
> On 6 February 2012 02:25, Manu <turkeyman@gmail.com> wrote:
>>
>> On 6 February 2012 00:04, Johannes Pfau <nospam@example.com> wrote:
>>>
>>> Am Sun, 5 Feb 2012 18:04:12 +0100
>>> schrieb Johannes Pfau <nospam@example.com>:
>>>
>>> > I will probably need some more time to get this working...
>>> >
>>>
>>> I have some good news: http://www.mediafire.com/?107we120sh3xx
>>>
>>> I fixed that problem and then the whole build worked fine. I'll post build instructions soon, but the binaries are ready. I only did a simple gdc -c test.d to check the compiler, but it seems to work.
>>>
>>> Linking against druntime fails, as it uses functions which are not available on Android (backtrace, signal stuff).
>>>
>>> I also built a simple hello world on linux (printf, no runtime) and ran it on my android phone, and it worked!
>>>
>>> In case you haven't used GDC without runtime before, a short introduction:
>>>
>>> * use gdc -nophoboslib to make gdc not link against phobos (and afaik,
>>>  druntime)
>>> * theres also -nostdlib in case you need it
>>> * complex code may require -fno-section-anchors because of bug #120
>>> * You'll get an error about a missing _Dmodule_ref symbol. That symbol
>>>  is used by module constructors and not generated by gdc if
>>>  -nophoboslib was passed. As long as you don't run the module
>>>  constructors, you can add a fake _Dmodule_ref in a .c file:
>>>
>>> ------------
>>> void* _Dmodule_ref;
>>> ------------
>>>
>>> * The compiler defines version(Android)
>>>
>>> Here's my hello world:
>>> ------------
>>> version(Android)
>>> {
>>>    pragma(msg, "Hello Android!");
>>> }
>>>
>>> extern(C)
>>> {
>>>    int printf(in char* format, ...);
>>> }
>>>
>>> extern(C) void main()
>>> {
>>>    printf("Hello, %s!\n".ptr, "Android".ptr);
>>> }
>>> ------------
>>>
>>> compile the _Dmodule_ref into hack.o, then use
>>> gdc -nophoboslib hello.d hack.o
>>
>>
>> Amazing! You sir, are a genius!
>> I'm gonna have to have some fun with that after work tomorrow :)
>>
>> I reckon this binary distro should be put on d-p-l somewhere obvious.
>
>
> I just tried with -mfpu=neon, which should allow GCC to generate neon
> opcodes for the simd stuff, but it didn't seem to want to do that. In fact
> it generates really horrible code where it CALLS an intrinsic for each float
> in the vector...
> Any idea why this wouldn't work out of the box?
>
> I wanted to add ARM support to my std.simd work here as a better proof of concept.
>
> Iain: was there anything particularly special you needed to do to hook the x86 SSE stuff to GDC which would need to be duplicated for ARM? gcc.builtins doesn't seen to have any ARM intrinsics in there either...

Nope - its all arch agnostic.  Just requires that:
a) The target you are building for has the functions available
b) The functions in question can be represented using D types.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
February 06, 2012
Am Mon, 6 Feb 2012 01:48:32 -0600
schrieb Andrew Wiley <wiley.andrew.j@gmail.com>:

> 
> Actually, if the Android default is to build against softfloat ABI, you may be stuck with it. If Android doesn't require hardfloat to run and doesn't let developers provide multiple binaries for different platforms (which it might - I don't know), things get very hard.
> 
> Also, with NEON, one of the things you don't really hear until you start working with these is that NEON isn't actually required in most if not all of the ARM CPU specs. I've specifically dealt with the Tegra 2, which is used in a lot of phones and has no NEON support even though it's ARM Cortex-A9.

There's a official armv7-a ABI for android, it doesn't use 'hard', but at least 'softfp' instead of 'soft'.

Just found the relevant documentation: See android-ndk-r7/docs/STANDALONE-TOOLCHAIN.html 4/ ABI Compatibility:
------------------------
If you want to target the 'armeabi-v7a' ABI, you will need ensure that the following two flags are being used:

  CFLAGS='-march=armv7-a -mfloat-abi=softfp'

If you want to use Neon instructions, you will need one more compiler flag:

  CFLAGS='-march=armv7-a -mfloat-abi=softfp -mfpu=neon'

Also, is is *required* to use the following linker flags that routes around a CPU bug in some Cortex-A8 implementations:

  LDFLAGS='-Wl,--fix-cortex-a8'
------------------------
so according to those docs, you simply pass those flags to the compiler, no need to recompile the compiler.
February 06, 2012
On Mon, Feb 6, 2012 at 1:40 AM, Johannes Pfau <nospam@example.com> wrote:
> Am Mon, 6 Feb 2012 03:07:31 +0200
> schrieb Manu <turkeyman@gmail.com>:
>
>> On 6 February 2012 02:25, Manu <turkeyman@gmail.com> wrote:
>>
>> > On 6 February 2012 00:04, Johannes Pfau <nospam@example.com> wrote:
>> >
>> >> Am Sun, 5 Feb 2012 18:04:12 +0100
>> >> schrieb Johannes Pfau <nospam@example.com>:
>> >>
>> >> > I will probably need some more time to get this working...
>> >> >
>> >>
>> >> I have some good news: http://www.mediafire.com/?107we120sh3xx
>> >>
>> >> I fixed that problem and then the whole build worked fine. I'll post build instructions soon, but the binaries are ready. I only did a simple gdc -c test.d to check the compiler, but it seems to work.
>> >>
>> >> Linking against druntime fails, as it uses functions which are not available on Android (backtrace, signal stuff).
>> >>
>> >> I also built a simple hello world on linux (printf, no runtime) and ran it on my android phone, and it worked!
>> >>
>> >> In case you haven't used GDC without runtime before, a short introduction:
>> >>
>> >> * use gdc -nophoboslib to make gdc not link against phobos (and
>> >> afaik, druntime)
>> >> * theres also -nostdlib in case you need it
>> >> * complex code may require -fno-section-anchors because of bug #120
>> >> * You'll get an error about a missing _Dmodule_ref symbol. That
>> >> symbol is used by module constructors and not generated by gdc if
>> >>  -nophoboslib was passed. As long as you don't run the module
>> >>  constructors, you can add a fake _Dmodule_ref in a .c file:
>> >>
>> >> ------------
>> >> void* _Dmodule_ref;
>> >> ------------
>> >>
>> >> * The compiler defines version(Android)
>> >>
>> >> Here's my hello world:
>> >> ------------
>> >> version(Android)
>> >> {
>> >>    pragma(msg, "Hello Android!");
>> >> }
>> >>
>> >> extern(C)
>> >> {
>> >>    int printf(in char* format, ...);
>> >> }
>> >>
>> >> extern(C) void main()
>> >> {
>> >>    printf("Hello, %s!\n".ptr, "Android".ptr);
>> >> }
>> >> ------------
>> >>
>> >> compile the _Dmodule_ref into hack.o, then use
>> >> gdc -nophoboslib hello.d hack.o
>> >>
>> >
>> > Amazing! You sir, are a genius!
>> > I'm gonna have to have some fun with that after work tomorrow :)
>> >
>> > I reckon this binary distro should be put on d-p-l somewhere obvious.
>> >
>>
>> I just tried with -mfpu=neon, which should allow GCC to generate neon
>> opcodes for the simd stuff, but it didn't seem to want to do that. In
>> fact it generates really horrible code where it CALLS an intrinsic
>> for each float in the vector...
>> Any idea why this wouldn't work out of the box?
>
> The android toolchain configures gcc with: += --with-float=soft --with-fpu=vfp --with-arch=armv5te
>
> I could try to build an optimized build, but then you'll have to tell me what processor you're using. Cortex A8?
>
> I'm not sure if you can override that at runtime. You could probably
> try:
> -mfloat-abi=hard -mcpu=cortex-a8 -march=armv7-a -mfpu=neon

I'm pretty sure you have to rebuild the entire toolchain to switch from softfloat to hardfloat.
February 06, 2012
Am Mon, 6 Feb 2012 01:42:26 -0600
schrieb Andrew Wiley <wiley.andrew.j@gmail.com>:

> 
> I'm pretty sure you have to rebuild the entire toolchain to switch from softfloat to hardfloat.

I also thought that, but GCC docs say:
-with-fpu=type
--with-float=type
These configure options provide **default** values for the -mschedule=,
-march=, -mtune=, -mabi=, and -mfpu= options and for -mhard-float or
-msoft-float. As with --with-cpu, which switches will be accepted and
acceptable values of the arguments depend on the target.

That also matches the Android NDK documentation.
February 06, 2012
On 6 February 2012 08:11, Johannes Pfau <nospam@example.com> wrote:
> Am Mon, 6 Feb 2012 01:48:32 -0600
> schrieb Andrew Wiley <wiley.andrew.j@gmail.com>:
>
>>
>> Actually, if the Android default is to build against softfloat ABI, you may be stuck with it. If Android doesn't require hardfloat to run and doesn't let developers provide multiple binaries for different platforms (which it might - I don't know), things get very hard.
>>
>> Also, with NEON, one of the things you don't really hear until you start working with these is that NEON isn't actually required in most if not all of the ARM CPU specs. I've specifically dealt with the Tegra 2, which is used in a lot of phones and has no NEON support even though it's ARM Cortex-A9.
>
> There's a official armv7-a ABI for android, it doesn't use 'hard', but at least 'softfp' instead of 'soft'.
>
> Just found the relevant documentation: See android-ndk-r7/docs/STANDALONE-TOOLCHAIN.html 4/ ABI Compatibility:
> ------------------------
> If you want to target the 'armeabi-v7a' ABI, you will need ensure that the following two flags are being used:
>
>  CFLAGS='-march=armv7-a -mfloat-abi=softfp'
>
> If you want to use Neon instructions, you will need one more compiler flag:
>
>  CFLAGS='-march=armv7-a -mfloat-abi=softfp -mfpu=neon'
>
> Also, is is *required* to use the following linker flags that routes around a CPU bug in some Cortex-A8 implementations:
>
>  LDFLAGS='-Wl,--fix-cortex-a8'
> ------------------------
> so according to those docs, you simply pass those flags to the compiler, no need to recompile the compiler.


>From the ARM Neon Intrinisics page:

"These built-in intrinsics for the ARM Advanced SIMD extension are available when the -mfpu=neon switch is used."


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';