digitalmars.D - embedded D?
- kenny <funisher gmail.com> Aug 20 2007
- Chad J <gamerChad _spamIsBad_gmail.com> Aug 20 2007
- Marco A <Marco nospam.com> Apr 11 2008
- Ingo Oeser <ioe-news rameria.de> Aug 21 2007
- %u <ola brunborg.org> Feb 21 2008
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
L3 phobos # dmd -gc -c test.d && gcc -static -nostdlib -L /usr/diet/lib-i386/
/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
L3 phobos # ldd test
not a dynamic executable
L3 phobos # ls -l test
-rwxr-xr-x 1 root root 390302 Aug 20 18:40 test
L3 phobos # strip test
L3 phobos # ls -l 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.
Aug 20 2007
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 L3 phobos # dmd -gc -c test.d && gcc -static -nostdlib -L /usr/diet/lib-i386/ /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 L3 phobos # ldd test not a dynamic executable L3 phobos # ls -l test -rwxr-xr-x 1 root root 390302 Aug 20 18:40 test L3 phobos # strip test L3 phobos # ls -l 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. #1) I'm the guy working on arm-wince-pe, and I'm not really working on 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. #2) While gdc on arm-wince-pe works for most of D, it is missing some 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. #3) arm-wince-pe-gdc currently relies on newlib, thus incurring some 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. #4) Haven't heard from the Nokia guys in a while. I wonder if that 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>
Aug 20 2007
Marco A <Marco nospam.com> Chad J Wrote:#3) arm-wince-pe-gdc currently relies on newlib, thus incurring some 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.
Apr 11 2008
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
Aug 21 2007
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.
Feb 21 2008