Am Wed, 27 Mar 2013 01:50:40 +0100
schrieb Martin Nowak <code@dawg.eu>:

> On 03/26/2013 06:22 PM, Iain Buclaw wrote:
> > We certainly can do. Which compiler do you have in mind for using?
> >
> I mostly thought of porting GDC and LDC to linux glibc and bionic. A Windows ARM port would be interesting too, but could be out of reach. Support for bare metal targets is interesting too (I've already used GDC for STM32) but way less important.

Android support would be very nice but I'd make it a secondary goal. As we have shared libraries now the only big remaining problem is that Android doesn't have real TLS so we'd have to make the GCC EMUTLS implementation work with our GC. For glibc android targets this issue doesn't exist.

Would be nice if we can get the dmd test suite results to match those for x86. It will be a little annoying though as many floating point test are wrong and simply assume x86 precision.

I'd be glad to help wherever I can though.

> > I have two ARM boards at hand, but will need to get round to buying a monitor to connect up at least one of them to start off the port and testing process. :-)
> >
> I have two android devices, some STM32 boards and getting a raspberry or so would not be a problem. I guess qemu could be used too.
> 

qemu + debian for arm might be a good idea. I wonder whether ARM emulated by qemu is faster than e.g. a Raspberry Pi. Compiling GDC on the raspberry itself takes over 12 hours IIRC so you probably want to build cross compilers or use a faster system.

On 27 March 2013 08:14, Johannes Pfau <nospam@example.com> wrote:

> Am Wed, 27 Mar 2013 01:50:40 +0100
> schrieb Martin Nowak <code@dawg.eu>:
>
> > On 03/26/2013 06:22 PM, Iain Buclaw wrote:
> > > We certainly can do. Which compiler do you have in mind for using?
> > >
> > I mostly thought of porting GDC and LDC to linux glibc and bionic. A Windows ARM port would be interesting too, but could be out of reach. Support for bare metal targets is interesting too (I've already used GDC for STM32) but way less important.
>
> Android support would be very nice but I'd make it a secondary goal. As we have shared libraries now the only big remaining problem is that Android doesn't have real TLS so we'd have to make the GCC EMUTLS implementation work with our GC. For glibc android targets this issue doesn't exist.
>
> Would be nice if we can get the dmd test suite results to match those for x86. It will be a little annoying though as many floating point test are wrong and simply assume x86 precision.
>
> I'd be glad to help wherever I can though.
>
> > > I have two ARM boards at hand, but will need to get round to buying a monitor to connect up at least one of them to start off the port and testing process. :-)
> > >
> > I have two android devices, some STM32 boards and getting a raspberry or so would not be a problem. I guess qemu could be used too.
> >
>
> qemu + debian for arm might be a good idea. I wonder whether ARM emulated by qemu is faster than e.g. a Raspberry Pi. Compiling GDC on the raspberry itself takes over 12 hours IIRC so you probably want to build cross compilers or use a faster system.
>

Through testing I've done in the past, QEMU+ARM is reliable enough that you can compile + test GCC under it.  Other than that, we can go for using cross compilers.

-- 
Iain Buclaw

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

On 27 March 2013 11:06, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 27 March 2013 08:14, Johannes Pfau <nospam@example.com> wrote:
>
>> Am Wed, 27 Mar 2013 01:50:40 +0100
>> schrieb Martin Nowak <code@dawg.eu>:
>>
>> > On 03/26/2013 06:22 PM, Iain Buclaw wrote:
>> > > We certainly can do. Which compiler do you have in mind for using?
>> > >
>> > I mostly thought of porting GDC and LDC to linux glibc and bionic. A Windows ARM port would be interesting too, but could be out of reach. Support for bare metal targets is interesting too (I've already used GDC for STM32) but way less important.
>>
>> Android support would be very nice but I'd make it a secondary goal. As we have shared libraries now the only big remaining problem is that Android doesn't have real TLS so we'd have to make the GCC EMUTLS implementation work with our GC. For glibc android targets this issue doesn't exist.
>>
>> Would be nice if we can get the dmd test suite results to match those for x86. It will be a little annoying though as many floating point test are wrong and simply assume x86 precision.
>>
>> I'd be glad to help wherever I can though.
>>
>> > > I have two ARM boards at hand, but will need to get round to buying a monitor to connect up at least one of them to start off the port and testing process. :-)
>> > >
>> > I have two android devices, some STM32 boards and getting a raspberry or so would not be a problem. I guess qemu could be used too.
>> >
>>
>> qemu + debian for arm might be a good idea. I wonder whether ARM emulated by qemu is faster than e.g. a Raspberry Pi. Compiling GDC on the raspberry itself takes over 12 hours IIRC so you probably want to build cross compilers or use a faster system.
>>
>
> Through testing I've done in the past, QEMU+ARM is reliable enough that you can compile + test GCC under it.  Other than that, we can go for using cross compilers.
>
>

BTW, QEMU+ARM emulation under x86/x86_64 still takes about 8 hours for GCC. :-)

-- 
Iain Buclaw

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

On 03/26/2013 06:22 PM, Iain Buclaw wrote:
>
> We certainly can do. Which compiler do you have in mind for using?

Have you send Andrei a mail to add you as mentor?
I'll add a project idea to the wiki http://wiki.dlang.org/GSOC_2013_Ideas.

On 27 March 2013 15:19, Martin Nowak <code@dawg.eu> wrote:

> On 03/26/2013 06:22 PM, Iain Buclaw wrote:
>
>>
>> We certainly can do. Which compiler do you have in mind for using?
>>
>
> Have you send Andrei a mail to add you as mentor?
> I'll add a project idea to the wiki http://wiki.dlang.org/GSOC_**
> 2013_Ideas <http://wiki.dlang.org/GSOC_2013_Ideas>.
>

Not yet, if this is going to be considered as a project that we are going to move forward with, I'll definitely pick this one up. :-)

-- 
Iain Buclaw

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