| View previous topic :: View next topic |
| Author |
Message |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
 Posted: Tue Dec 06, 2005 8:03 pm Post subject: Code size, Ares, Phones, etc. |
 |
|
I've been developing exclusively with Ares for a while now, and have not run into a single issue. Hats' off to Sean for a such great job on Ares!
Have also been working on reducing various dependencies within the Mango Tree ~ in an effort to streamline the executables, and promote some generally healthy habits. The upshot is that "hello world \u263a" is now 77KB. The formatting version (using the Format package) comes in at 92KB; the filecat and filecopy examples weigh-in at 88KB each. All of these are with Unicode support on the console ~ utf16 on Win32, and utf8 on linux. Eliminating the basic C I/O package would remove another 10 to 15KB, though the Digital Mars snn.lib does not want to give that up at all 
Why do this? Well, I'm old-fashioned in some ways ~ just need to get over it. The objective aspect is with regards to development for "small" devices, such as phones and PDA's. I'd like to think we can get a combination of Ares, Mango, and probably SWT onto the Windows Mobile platform and onto some variety of mobile linux?
Thoughts? |
|
| Back to top |
|
 |
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Tue Dec 06, 2005 11:33 pm Post subject: |
|
|
I ran across a paper on GCs for small footprint programs (ie. those that run on cellphones and such). Would something like this be useful? I'll have to make sure I downloaded a copy of it  Hopefully, this GC business doesn't prove to be a huge pain to execute. The theory behind some of them is pretty insane. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Wed Dec 07, 2005 1:16 am Post subject: |
|
|
Would it be possible to replace snn.lib completely with something of our own at some point? It's something of an unknown variable. It would be nice having something that we have more control over.
SWT, Mango, and Ares on Windows Mobile?! Wow... you are forward-thinking, Kris! I'd love to see that!
-JJR[/i] |
|
| Back to top |
|
|
pragma
Joined: 28 May 2004
Posts: 607
Location: Washington, DC
|
| Posted: Wed Dec 07, 2005 8:03 am Post subject: |
|
|
One thing I've noticed about snn.lib is that it has a large number of discrete modules in it. Would it help if you had access to an OMF lib "unpacker" util? At least that way, you wouldn't have to link against the whole thing.
I also think JJR is onto something there. As far as the D community is concerned, we're closer to having a self-hosting solution with D than ever -- AgentOrange ported the D frontend to D, so all we need is something that outputs .obj files. Looking into developing a lightweight "backbone" to Ares might not be as crazy as it sounds.
_________________
-- !Eric.t.Anderton at gmail |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Dec 07, 2005 12:39 pm Post subject: |
|
|
| sean wrote: | | I ran across a paper on GCs for small footprint programs (ie. those that run on cellphones and such). Would something like this be useful? I'll have to make sure I downloaded a copy of it Hopefully, this GC business doesn't prove to be a huge pain to execute. The theory behind some of them is pretty insane. |
That sounds interesting, Sean.
Though, I have to wonder how well the current GC would operate with, say, 32 or 64MB of RAM? Perhaps fine? Worth trying with an artificial cap? I've got a feeling that the current GC with a decent malloc() would do just fine ... perhaps Doug Lea's veritable malloc?
GC theory is often nuts, as you say  |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Dec 07, 2005 12:51 pm Post subject: |
|
|
| JJR wrote: | | Would it be possible to replace snn.lib completely with something of our own at some point? It's something of an unknown variable. It would be nice having something that we have more control over. |
Yes. It would be partly an exercise in assembler (within D, of course). Things like __LDIV__, exception support, and application entry point (console startup, win32 startup). Other things like malloc(), free(), calloc(), can be adopted from elsewhere ~ Doug Lea's malloc() package is a good example. Here's a true list of missing entries from a Mango/Ares filecat.d:
| Code: | OPTLINK (R) for Win32 Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved
SNN.lib
Warning 2: File Not Found SNN.lib
C:\D\mango\mango\io\FileProxy.obj(FileProxy)
Error 42: Symbol Undefined __except_list
C:\D\mango\mango\io\FileProxy.obj(FileProxy)
Error 42: Symbol Undefined _wcslen
filecat.obj(filecat)
Error 42: Symbol Undefined __acrtused_con
C:\D\mango\mango\io\Buffer.obj(Buffer)
Error 42: Symbol Undefined _memcpy
C:\d\dmd\bin\..\lib\phobos.lib(object)
Error 42: Symbol Undefined _memcmp
C:\d\dmd\bin\..\lib\phobos.lib(gc)
Error 42: Symbol Undefined _memset
C:\d\dmd\bin\..\lib\phobos.lib(gc)
Error 42: Symbol Undefined _malloc
C:\d\dmd\bin\..\lib\phobos.lib(deh)
Error 42: Symbol Undefined __local_except_handler
C:\d\dmd\bin\..\lib\phobos.lib(deh)
Error 42: Symbol Undefined _strlen
C:\d\dmd\bin\..\lib\phobos.lib(deh)
Error 42: Symbol Undefined __global_unwind
C:\d\dmd\bin\..\lib\phobos.lib(dmain2)
Error 42: Symbol Undefined ___alloca
C:\d\dmd\bin\..\lib\phobos.lib(dmain2)
Error 42: Symbol Undefined _exit
C:\d\dmd\bin\..\lib\phobos.lib(monitor)
Error 42: Symbol Undefined _free
C:\d\dmd\bin\..\lib\phobos.lib(monitor)
Error 42: Symbol Undefined __assert
C:\d\dmd\bin\..\lib\phobos.lib(monitor)
Error 42: Symbol Undefined _calloc
C:\d\dmd\bin\..\lib\phobos.lib(gcx)
Error 42: Symbol Undefined _realloc
C:\d\dmd\bin\..\lib\phobos.lib(gcx)
Error 42: Symbol Undefined _memmove
C:\d\dmd\bin\..\lib\phobos.lib(win32)
Error 42: Symbol Undefined __end
C:\d\dmd\bin\..\lib\phobos.lib(win32)
Error 42: Symbol Undefined __xi_a
C:\d\dmd\bin\..\lib\phobos.lib(thread)
Error 42: Symbol Undefined __beginthreadex
OPTLINK : Warning 134: No Start Address
--- errorlevel 20 |
| JJR wrote: | | SWT, Mango, and Ares on Windows Mobile?! Wow... you are forward-thinking, Kris! I'd love to see that! |
It's not so far fetched
SWT has a WindowsMobile 2003 system, and 2005 is being debugged. These devices are rapidly becoming powerhouses ~ many have 400 & 500MHz ARM10/XScale processors. Many have 320 x 240 displays ... and the range of connectivity is becoming quite astonishing. It's something I'm really interested in, and DDL can help tremendously with code sharing ...
Edit: I really think D is a great match for these devices. The D# project might actually be the best bet of all.
Last edited by kris on Wed Dec 07, 2005 12:59 pm; edited 1 time in total |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Dec 07, 2005 12:56 pm Post subject: |
|
|
| pragma wrote: | | One thing I've noticed about snn.lib is that it has a large number of discrete modules in it. Would it help if you had access to an OMF lib "unpacker" util? At least that way, you wouldn't have to link against the whole thing. |
Yes! But, some of the snn.lib code appears to be sadly intertwined.
| pragma wrote: | | I also think JJR is onto something there. As far as the D community is concerned, we're closer to having a self-hosting solution with D than ever -- AgentOrange ported the D frontend to D, so all we need is something that outputs .obj files. Looking into developing a lightweight "backbone" to Ares might not be as crazy as it sounds. |
Eminently doable 
I don't know what the license is, but perhaps Walter might allow us to crib some of the core items from snn.lib ~ such as the exception handlers, application startup, etc? |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Wed Dec 07, 2005 2:12 pm Post subject: |
|
|
| kris wrote: | | Though, I have to wonder how well the current GC would operate with, say, 32 or 64MB of RAM? Perhaps fine? Worth trying with an artificial cap? I've got a feeling that the current GC with a decent malloc() would do just fine ... perhaps Doug Lea's veritable malloc? |
That may be the best thing. By the way, is multithreading even an issue in mobile devices? I would assume not for cellphones, but I have no idea whether PocketPCs and the like are capable of it. |
|
| Back to top |
|
|
pragma
Joined: 28 May 2004
Posts: 607
Location: Washington, DC
|
| Posted: Wed Dec 07, 2005 2:14 pm Post subject: |
|
|
| Quote: | | SWT has a WindowsMobile 2003 system, and 2005 is being debugged. These devices are rapidly becoming powerhouses ~ many have 400 & 500MHz ARM10/XScale processors. Many have 320 x 240 displays ... and the range of connectivity is becoming quite astonishing. It's something I'm really interested in, and DDL can help tremendously with code sharing ... |
You're not the only one interested, although I must confess: I don't have a pocket-PC so I'm likely to miss out on the first round of this kind of development. What I do know is that DDL will only help out in as so much as allowing for binary sharing between ARM-based systems as its a radically different processor arch from x86. But I do plan on adding a processor-type field to the DDL header/wrapper to help compensate for things like this.
But from the standpoint that DDL can ease the developer into using portable raw-D building-blocks -- I'm glad that you think it'll help.
Aside: Does GCC even have an ARM backend?
_________________
-- !Eric.t.Anderton at gmail |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Dec 07, 2005 2:55 pm Post subject: |
|
|
| sean wrote: | | kris wrote: | | Though, I have to wonder how well the current GC would operate with, say, 32 or 64MB of RAM? Perhaps fine? Worth trying with an artificial cap? I've got a feeling that the current GC with a decent malloc() would do just fine ... perhaps Doug Lea's veritable malloc? |
That may be the best thing. By the way, is multithreading even an issue in mobile devices? I would assume not for cellphones, but I have no idea whether PocketPCs and the like are capable of it. |
Very, very, useful ~ all that background malarky like filtering SMS, ongoing data-synch, asynchronous GPS updates, etc. Devices like these are in & out of connectivity very often, so threading is helpful at multiple levels. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Dec 07, 2005 3:02 pm Post subject: |
|
|
| pragma wrote: | | Quote: | | SWT has a WindowsMobile 2003 system, and 2005 is being debugged. These devices are rapidly becoming powerhouses ~ many have 400 & 500MHz ARM10/XScale processors. Many have 320 x 240 displays ... and the range of connectivity is becoming quite astonishing. It's something I'm really interested in, and DDL can help tremendously with code sharing ... |
You're not the only one interested, although I must confess: I don't have a pocket-PC so I'm likely to miss out on the first round of this kind of development. What I do know is that DDL will only help out in as so much as allowing for binary sharing between ARM-based systems as its a radically different processor arch from x86. But I do plan on adding a processor-type field to the DDL header/wrapper to help compensate for things like this. |
DDL will help in terms of sharing libraries within a "limited" RAM environment ~ sharing the SWT lib might be a good thing
| pragma wrote: | | Aside: Does GCC even have an ARM backend? |
I believe so ~ both ARM and XScale variants. I understand Intel recommends COFF for the latter. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Wed Dec 07, 2005 3:12 pm Post subject: |
|
|
| sean wrote: | | I ran across a paper on GCs for small footprint programs (ie. those that run on cellphones and such). Would something like this be useful? I'll have to make sure I downloaded a copy of it |
I'd be really interested to hear what memory size they were targeting ... |
|
| Back to top |
|
|
brad
Site Admin
Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA
|
| Posted: Wed Dec 07, 2005 3:54 pm Post subject: |
|
|
Kris,
All of this sounds very 'pervasive' - you tying it into PARC in any way?
BA |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Wed Dec 07, 2005 4:51 pm Post subject: |
|
|
No luck finding that paper so far. It may have been a comment in a more general GC paper I read. I'll keep an eye out for it.
In other news, Ars Technica just did a mini review of pocket-sized linux servers. Seems appropriate for this thread:
http://arstechnica.com/reviews/hardware/pocketserver.ars |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Wed Dec 07, 2005 5:09 pm Post subject: |
|
|
This is all very fascinating. I have my own Dell Axim X50v with 624 MHz XScale and 640x480 Resolution. Windows Mobile 5.0 is a fairly descent improvement over previous Pocket PC OS Editions.
Right now, I've successfully used my Dell for GPS via bluetooth on Ambulance... it vocalizes the addresses and turns, and traces the route. If I take a wrong turn, the GPS software in the Dell automatically re-plots the route and notifies vocally. I also use it for pharmacology lookup, as well as other medical reference. I feel naked without it.
If D could get on that device, I'd be in heaven. But while gcc supports the ARM architecture, I know of no supported PocketPC gcc version. I've searched high and low for this before. I did find that a Russian individual did start a project to support gcc version for Pocket PC, but that has all but disappeared or hasn't been maintained. D#, on the other hand, would probably be the quickest way to get to the platform, though probably not the purest way.
Concerning multithreading, I believe Windows Mobile has supported that for some time. That was one of the features people complained abut Palm OS not having that Pocket PC OSes did have.
I can see D with SWT/Mango/Ares being the most perfect fit for Windows Mobile. I detest the current programming API -- it's exactly like windows unless you use .NET or C++ and MFC. .NET is the most easily adoptable, but I believe it suffers slightly in performance. MFC still stinks.
As for SNN.lib, I imagine replacing some of those functions wouldn't be such a bad idea. Some inline assembly would certainly simplify replacing some of the low-level functions in snn.lib.
-JJR |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
