• kenny (13/13) Aug 20 2007 quick background... I wanted to do some fast network socket stuff using ...
• Chad J (49/67) Aug 20 2007 No you didn't waste your time, you learned :)
• Marco A (5/11) Apr 11 2008 What issues would that be?
• Ingo Oeser (6/11) Aug 21 2007 Yes! That is quite cool.
• %u (2/2) Feb 21 2008 Coding for the AVR in D would be just awesome. I don't know very much ab...

kenny <funisher gmail.com> writes:

quick background... I wanted to do some fast network socket stuff using
libowfat... so I converted the h file and stuff... good stuff, then I
remembered it was linked against dietlibc, not glibc. So, instead of converting
to Tango (which is what I should have done), I added the necessary symbols to
dietlibc for the GC to work, and converted phobos over.

I now have a bunch of code that I don't know what to do with... (I ended up
converting/linking libowfat against glibc).

Would anyone be interested in an embedded D project? I would obviously maintain
it and develop it, if there was interest. I have D phobos linked against
dietlibc already. Once the gc is separate, I think I can get D producing 32K
executables, dynamically linked against dietlibc + phobos or tango (leaning
more toward tango).

At the moment, phobos + dietlibc only accounts for about 300KB extra, so it
would actually be a very small installation (less than 1MB) compared to the
monstrosity of glibc. dietlibc is a bit slower in a few functions though. One
of the most often complaints I hear about D is it's executable size (because of
statically linking phobos). Perhaps this can help


/usr/diet/lib-i386/start.o -o test test.o dmain2.o libphobos2.a -lpthread
-D__dietlibc__ /usr/diet/lib-i386/libc.a -lgcc -lm -lowfat
/usr/diet/lib-i386/libc.a

        not a dynamic executable

-rwxr-xr-x 1 root root 390302 Aug 20 18:40 test


-rwxr-xr-x 1 root root 279296 Aug 20 18:41 test

Ideas? Opinions? I know I wasted my time, but I want to make something useful
out of it :) This would also allow D (assuming gdc support) to create small
executables for ARM, alpha, sparc, s390, ppc, and mips.

Chad J <gamerChad _spamIsBad_gmail.com> writes:

kenny wrote:
 quick background... I wanted to do some fast network socket stuff using
libowfat... so I converted the h file and stuff... good stuff, then I
remembered it was linked against dietlibc, not glibc. So, instead of converting
to Tango (which is what I should have done), I added the necessary symbols to
dietlibc for the GC to work, and converted phobos over.
 
 I now have a bunch of code that I don't know what to do with... (I ended up
converting/linking libowfat against glibc).
 
 Would anyone be interested in an embedded D project? I would obviously
maintain it and develop it, if there was interest. I have D phobos linked
against dietlibc already. Once the gc is separate, I think I can get D
producing 32K executables, dynamically linked against dietlibc + phobos or
tango (leaning more toward tango).
 
 At the moment, phobos + dietlibc only accounts for about 300KB extra, so it
would actually be a very small installation (less than 1MB) compared to the
monstrosity of glibc. dietlibc is a bit slower in a few functions though. One
of the most often complaints I hear about D is it's executable size (because of
statically linking phobos). Perhaps this can help
 

/usr/diet/lib-i386/start.o -o test test.o dmain2.o libphobos2.a -lpthread
-D__dietlibc__ /usr/diet/lib-i386/libc.a -lgcc -lm -lowfat
/usr/diet/lib-i386/libc.a

         not a dynamic executable

 -rwxr-xr-x 1 root root 390302 Aug 20 18:40 test


 -rwxr-xr-x 1 root root 279296 Aug 20 18:41 test
 
 Ideas? Opinions? I know I wasted my time, but I want to make something useful
out of it :) This would also allow D (assuming gdc support) to create small
executables for ARM, alpha, sparc, s390, ppc, and mips.

No you didn't waste your time, you learned :)

Anyhow, while I do like the idea of small executable size, it is really 
not the thing stopping D from going embedded.  Yeah having a 300 kB exe 
would suck on a smartphone/pda, but it would still WORK and people tend 
to have 1-4 GB data cards jammed into such devices anyways.

It would be sweet to have small executable size though.  The demoscene 
might appreciate it.  It would also be NICE for smartphone type platforms.

I think what you are talking about is a D framework.  Have the GC and a 
whole load of library functions as a shared resource, outside of the 
executable.  Tango probably would be a prime candidate for such a thing. 
    Then executables merely consist of a bunch of some minimal code with 
calls to the framework, and maybe some runtime type info which is unique 
to the program and useful for the GC to avoid memory leaks.

<ramble>
Oh, I almost forgot to describe what IS stopping D from going on a 
smartphone.  So far I have managed to get gdc to target arm-wince-pe, 
basically an ARM processor with the WinCE OS.  Someone else managed to 
get gdc to target a Nokia device, which (correct me if I'm wrong) was a 
ARM processor with Symbian OS.


it.  I'm a student with not enough time to do this kind of stuff, and I 
have other projects I'd rather work on.


important stuff like rectangular arrays and variadic functions.  Details 
are in the attachment "limitations.d".  This kind of stuff rests in the 
guts of GDC and GCC, and I have no idea how to fix these things.  I did 
try to debug and stacktrace, but all I ended up with was some very low 
level GCC code (probably in codegen) that I did not understand at all.


licensing issues.  None of this would stop you from writing a commercial 
application in D on an ARM smartphone, but you'd have to pay attention 
to the licenses and give the appropriate credits/disclaimers/etc.  The 
less dedicated D programmers would probably not be pleased by this.


option is ever going to become a default part of GDC.

There are other little issues with arm-wince-gdc, like the lack of 
Tango.  That simply needs some work to fix.  It isn't helped by the fact 
that GDC only builds gphobos by default.  I had plenty of pain trying to 
modify GDC's build scripts for gphobos to get it /just/ right, and I am 
not looking forward to repeating that with Tango, as much as I do love 
Tango.  Tango itself looks very portable.

For other reference, Manfred Hansen was nice enough to host the 
arm-wince-pe-gdc compiler on his website.  (Thank you Manfred)
http://www.steinmole.de/d/arm-wince-pe-gdc.tar.bz2
It includes binaries, source, and some documentation.

There was also some discussion on D.gnu from about a year ago involving 
the arm-wince-pe-gdc compiler.
</ramble>

Marco A <Marco nospam.com> writes:

Chad J Wrote:

 

 licensing issues.  None of this would stop you from writing a commercial 
 application in D on an ARM smartphone, but you'd have to pay attention 
 to the licenses and give the appropriate credits/disclaimers/etc.  The 
 less dedicated D programmers would probably not be pleased by this.

  What issues would that be?  

http://www.intel.com/design/intelxscale/dev_tools/031121/license.txt

http://sources.redhat.com/newlib/COPYING.NEWLIB

Code that statically links newlib code is freely distributable under any
license terms you choose.

Ingo Oeser <ioe-news rameria.de> writes:

kenny wrote:
 Would anyone be interested in an embedded D project? I would obviously
 maintain it and develop it, if there was interest. I have D phobos linked
 against dietlibc already. Once the gc is separate, I think I can get D
 producing 32K executables, dynamically linked against dietlibc + phobos or
 tango (leaning more toward tango).

Yes! That is quite cool.

If one links statically, you might even be able to support 
the AVR platforms, which have a huge and happy community.


Best Regards

Ingo Oeser

%u <ola brunborg.org> writes:

Coding for the AVR in D would be just awesome. I don't know very much about what
this requires, but I do know it'd be appreciated by many.