www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Kuro, MediaMVP, TiVo, TeraStation -- and us?

reply Georg Wrede <georg.wrede nospam.org> writes:
While on the IBM Developer Works site, I stumbled on an interesting 
article about the new breed of computing devices (IMHO, soon to flood 
the world, in numbers exceeding both PCs and cellphones).

http://www-128.ibm.com/developerworks/linux/library/l-lobmediamvp.html

Basically, these are VCR cassette size units containing a single-board 
computer with Linux. They seem to be (again, IMHO) becoming the new 
platform-of-choice for garage firms developing totally new applications 
for the digital world. (Gee, sounds like I'm selling them!)

Many new firms use these as-is in home heating automation, various 
set-top appliances, for automotive control, security systems, robotics, 
toys, point-of-sale terminals, self service trade show stands, 
firewalls, handheld bookkeeping or measuring devices, computers for 
pre-schoolers, etc.

As for myself, for the better part of this year I've been looking for 
something smaller than a real PC, because I need to deploy several 
computers throughout the factory floor, and for this PCs get clunky and 
waste a lot of room, money, and maintenance resources. Some of the 
choices I've eyed at are:

http://www.armkits.com/Product/sbc2410III.asp
http://www.armkits.com/Product/STDV710A.asp
http://www.harerod.de/centipad/html/centipad.html (in German)

Now, what has held me back so far is, I definitely want to continue all 
my development in D! <putting hand behind ear, waiting for intense 
applause and roar from the audience/>

With the GCC toolchain that comes default with most of these, one would 
assume that GDC is a viable alternative.

Opinions?
Nov 03 2006
parent reply Gregor Richards <Richards codu.org> writes:
Georg Wrede wrote:

 While on the IBM Developer Works site, I stumbled on an interesting 
 article about the new breed of computing devices (IMHO, soon to flood 
 the world, in numbers exceeding both PCs and cellphones).
 
 http://www-128.ibm.com/developerworks/linux/library/l-lobmediamvp.html
 
 Basically, these are VCR cassette size units containing a single-board 
 computer with Linux. They seem to be (again, IMHO) becoming the new 
 platform-of-choice for garage firms developing totally new applications 
 for the digital world. (Gee, sounds like I'm selling them!)
 
 Many new firms use these as-is in home heating automation, various 
 set-top appliances, for automotive control, security systems, robotics, 
 toys, point-of-sale terminals, self service trade show stands, 
 firewalls, handheld bookkeeping or measuring devices, computers for 
 pre-schoolers, etc.
 
 As for myself, for the better part of this year I've been looking for 
 something smaller than a real PC, because I need to deploy several 
 computers throughout the factory floor, and for this PCs get clunky and 
 waste a lot of room, money, and maintenance resources. Some of the 
 choices I've eyed at are:
 
 http://www.armkits.com/Product/sbc2410III.asp
 http://www.armkits.com/Product/STDV710A.asp
 http://www.harerod.de/centipad/html/centipad.html (in German)
 
 Now, what has held me back so far is, I definitely want to continue all 
 my development in D! <putting hand behind ear, waiting for intense 
 applause and roar from the audience/>
 
 With the GCC toolchain that comes default with most of these, one would 
 assume that GDC is a viable alternative.
 
 Opinions?


GDC is certainly a viable alternative. With ARM, you're already set. 
configure-make-install and you're done. Cross-compilation is easy.

Seems like a non-problem to me.

  - Gregor Richards

PS: We all know that VMs with Java are the ideal solution for small, 
low-memory low-power boards. Because VMs rool.
Nov 03 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Gregor Richards wrote:

 Georg Wrede wrote:
 

 While on the IBM Developer Works site, I stumbled on an interesting 
 article about the new breed of computing devices (IMHO, soon to flood 
 the world, in numbers exceeding both PCs and cellphones).

 http://www-128.ibm.com/developerworks/linux/library/l-lobmediamvp.html

 Basically, these are VCR cassette size units containing a single-board 
 computer with Linux. They seem to be (again, IMHO) becoming the new 
 platform-of-choice for garage firms developing totally new 
 applications for the digital world. (Gee, sounds like I'm selling them!)

 Many new firms use these as-is in home heating automation, various 
 set-top appliances, for automotive control, security systems, 
 robotics, toys, point-of-sale terminals, self service trade show 
 stands, firewalls, handheld bookkeeping or measuring devices, 
 computers for pre-schoolers, etc.

 As for myself, for the better part of this year I've been looking for 
 something smaller than a real PC, because I need to deploy several 
 computers throughout the factory floor, and for this PCs get clunky 
 and waste a lot of room, money, and maintenance resources. Some of the 
 choices I've eyed at are:

 http://www.armkits.com/Product/sbc2410III.asp
 http://www.armkits.com/Product/STDV710A.asp
 http://www.harerod.de/centipad/html/centipad.html (in German)

 Now, what has held me back so far is, I definitely want to continue 
 all my development in D! <putting hand behind ear, waiting for intense 
 applause and roar from the audience/>

 With the GCC toolchain that comes default with most of these, one 
 would assume that GDC is a viable alternative.

 Opinions?


 
 
 GDC is certainly a viable alternative. With ARM, you're already set. 
 configure-make-install and you're done. Cross-compilation is easy.


Excellent!


 Seems like a non-problem to me.


What sort of executable sizes can I expect from GDC for ARM? (Last time 
I tried, DMD Hello World was monstrous compared to C on Windows and 
Linux.) With limited space this may become an issue when one has to have 
a bunch of subtask-specific executables. (Which one would have when 
doing stuff "in the spirit of Unix". I wouldn't want to resort to 
Busy-Box like binary crunching methods with virtually separate executables.)


 PS: We all know that VMs with Java are the ideal solution for small, 
 low-memory low-power boards. Because VMs rool.


Of course. Then I could go off on a tanget about

  - using only one language for _all_ development on all platforms in 
this project

  - ease of development without bothering with JVMs and Java libraries, 
and possibly other "best-for-this" languages for each task and platform

  - using one language only for everything eases maintenance, 
documentation, in-project portability, human cost, reliability, 
transparency, reviews, debugging, accountability, ....

  - D being a Systems Language and therefore demanding it's good enough 
for this

But frankly, I _want_ to use D, and I recognize this fact. (As opposed 
to hordes of people I've known in various places, who also _want_ 
something, but are unable to recognize this for themselves, and instead 
rationalize (often very convincingly) that choice to everybody, 
including themselves.)

And of course, while D does have a size problem right now, it really 
shines in output per clock tick, which also is important here. The size 
problem I trust will go away with the forever plummeting media costs. 
But for me, today, in this project, it still is a constraint.

A final reason I want to move to SoC/SBC/Linux is to get a head start 
with something that'll become ubiquitous sooner than you'd think today.

Already one can see a trend where such computers are being used where a 
BASIC Stamp, or a PIC microcontroller (the cheapest cost less than a 
dollar a piece) plus a couple of ICs and components (totalling, say $10) 
would be enough. But while the PIC processors have good facilities for 
debugging, downloading and ICE, the SoC/SBC/Linux offer ease of 
development, ease of firmware upgrades, in-situ major on-line 
adjustments, applicability of "standard know-how", a higher abstraction 
level, source code portability, vendor independence -- in other words, 
programmer productivity and time-to-market -- far bayond the (still 
admittedly) large cost difference per deployed unit of hardware, when 
production runs are not very long. And that's increasingly the case with 
small and medium size enterprises.

This situation is quickly becoming the norm instead of the exception.
Nov 03 2006
parent reply Gregor Richards <Richards codu.org> writes:
Georg Wrede wrote:

 
 
 Gregor Richards wrote:
 

 Georg Wrede wrote:


 While on the IBM Developer Works site, I stumbled on an interesting 
 article about the new breed of computing devices (IMHO, soon to flood 
 the world, in numbers exceeding both PCs and cellphones).

 http://www-128.ibm.com/developerworks/linux/library/l-lobmediamvp.html

 Basically, these are VCR cassette size units containing a 
 single-board computer with Linux. They seem to be (again, IMHO) 
 becoming the new platform-of-choice for garage firms developing 
 totally new applications for the digital world. (Gee, sounds like I'm 
 selling them!)

 Many new firms use these as-is in home heating automation, various 
 set-top appliances, for automotive control, security systems, 
 robotics, toys, point-of-sale terminals, self service trade show 
 stands, firewalls, handheld bookkeeping or measuring devices, 
 computers for pre-schoolers, etc.

 As for myself, for the better part of this year I've been looking for 
 something smaller than a real PC, because I need to deploy several 
 computers throughout the factory floor, and for this PCs get clunky 
 and waste a lot of room, money, and maintenance resources. Some of 
 the choices I've eyed at are:

 http://www.armkits.com/Product/sbc2410III.asp
 http://www.armkits.com/Product/STDV710A.asp
 http://www.harerod.de/centipad/html/centipad.html (in German)

 Now, what has held me back so far is, I definitely want to continue 
 all my development in D! <putting hand behind ear, waiting for 
 intense applause and roar from the audience/>

 With the GCC toolchain that comes default with most of these, one 
 would assume that GDC is a viable alternative.

 Opinions?




 GDC is certainly a viable alternative. With ARM, you're already set. 
 configure-make-install and you're done. Cross-compilation is easy.


 
 
 Excellent!
 

 Seems like a non-problem to me.


 
 
 What sort of executable sizes can I expect from GDC for ARM? (Last time 
 I tried, DMD Hello World was monstrous compared to C on Windows and 
 Linux.) With limited space this may become an issue when one has to have 
 a bunch of subtask-specific executables. (Which one would have when 
 doing stuff "in the spirit of Unix". I wouldn't want to resort to 
 Busy-Box like binary crunching methods with virtually separate 
 executables.)
 


Huge, unless you employ one very simple trick: Make libgphobos a shared 
object file.

It won't do it for you, unfortunately, but you can do it manually:

1) Install gdc
2) Go into gdc's source directory, in the phobos directory, and make 
distclean
3) CFLAGS=-fPIC DFLAGS=-fPIC ./configure --prefix=<prefix> && make all 
install
4) cd <prefix>/lib
5) ld -shared -soname=libgphobos.so.0 --whole-archive libgphobos.a 
--no-whole-archive -o libgphobos.so.0.0.0
6) for i in libgphobos.so.0.0 libgphobos.so.0 libgphobos.so ; do ln -s 
libgphobos.so.0.0.0 $i ; done
7) There is no step 7

(This is from memory, no guarantee that it's exactly right)

Now, when you link GDC, you'll actually link against the shared 
libgphobos instead of the static one. The vast majority of the size in 
output binaries is Phobos, so without that weight, they suddenly become 
quite small.

Of course, libgphobos.so.0.0.0 itself is fairly hefty, but there's only 
one of it :)

  - Gregor Richards

PS: BIG FAT NOTE: This can't be done with DMD. DMD's output cannot be 
used to make shared object files. Since DMD can't be used on ARM it's 
irrelevent to this discussion, but if anybody's peeking in ... go 
download GDC to get .so support ;)
Nov 03 2006
parent Gregor Richards <Richards codu.org> writes:
Gregor Richards wrote:

 Georg Wrede wrote:
 

 Gregor Richards wrote:


 Georg Wrede wrote:


 While on the IBM Developer Works site, I stumbled on an interesting 
 article about the new breed of computing devices (IMHO, soon to 
 flood the world, in numbers exceeding both PCs and cellphones).

 http://www-128.ibm.com/developerworks/linux/library/l-lobmediamvp.html

 Basically, these are VCR cassette size units containing a 
 single-board computer with Linux. They seem to be (again, IMHO) 
 becoming the new platform-of-choice for garage firms developing 
 totally new applications for the digital world. (Gee, sounds like 
 I'm selling them!)

 Many new firms use these as-is in home heating automation, various 
 set-top appliances, for automotive control, security systems, 
 robotics, toys, point-of-sale terminals, self service trade show 
 stands, firewalls, handheld bookkeeping or measuring devices, 
 computers for pre-schoolers, etc.

 As for myself, for the better part of this year I've been looking 
 for something smaller than a real PC, because I need to deploy 
 several computers throughout the factory floor, and for this PCs get 
 clunky and waste a lot of room, money, and maintenance resources. 
 Some of the choices I've eyed at are:

 http://www.armkits.com/Product/sbc2410III.asp
 http://www.armkits.com/Product/STDV710A.asp
 http://www.harerod.de/centipad/html/centipad.html (in German)

 Now, what has held me back so far is, I definitely want to continue 
 all my development in D! <putting hand behind ear, waiting for 
 intense applause and roar from the audience/>

 With the GCC toolchain that comes default with most of these, one 
 would assume that GDC is a viable alternative.

 Opinions?





 GDC is certainly a viable alternative. With ARM, you're already set. 
 configure-make-install and you're done. Cross-compilation is easy.




 Excellent!


 Seems like a non-problem to me.




 What sort of executable sizes can I expect from GDC for ARM? (Last 
 time I tried, DMD Hello World was monstrous compared to C on Windows 
 and Linux.) With limited space this may become an issue when one has 
 to have a bunch of subtask-specific executables. (Which one would have 
 when doing stuff "in the spirit of Unix". I wouldn't want to resort to 
 Busy-Box like binary crunching methods with virtually separate 
 executables.)


 
 Huge, unless you employ one very simple trick: Make libgphobos a shared 
 object file.
 
 It won't do it for you, unfortunately, but you can do it manually:
 
 1) Install gdc
 2) Go into gdc's source directory, in the phobos directory, and make 
 distclean
 3) CFLAGS=-fPIC DFLAGS=-fPIC ./configure --prefix=<prefix> && make all 
 install
 4) cd <prefix>/lib
 5) ld -shared -soname=libgphobos.so.0 --whole-archive libgphobos.a 
 --no-whole-archive -o libgphobos.so.0.0.0
 6) for i in libgphobos.so.0.0 libgphobos.so.0 libgphobos.so ; do ln -s 
 libgphobos.so.0.0.0 $i ; done
 7) There is no step 7
 
 (This is from memory, no guarantee that it's exactly right)
 
 Now, when you link GDC, you'll actually link against the shared 
 libgphobos instead of the static one. The vast majority of the size in 
 output binaries is Phobos, so without that weight, they suddenly become 
 quite small.
 
 Of course, libgphobos.so.0.0.0 itself is fairly hefty, but there's only 
 one of it, and it's not too bad if stripped :)
 
  - Gregor Richards
 
 PS: BIG FAT NOTE: This can't be done with DMD. DMD's output cannot be 
 used to make shared object files. Since DMD can't be used on ARM it's 
 irrelevent to this discussion, but if anybody's peeking in ... go 
 download GDC to get .so support ;)


Tpyo: s/Now, when you link GDC/Now, when you link with GDC/

  - Gregor Richards
Nov 03 2006