Hi John:
[snip]
If you manage to get the comiler to do some optimization, let me know how much difference that makes.
I'll try rebuilding with optimization turned off only for the problem module in question...that hopefully will solve the problem until they upgrade the toolchain on handhelds.org.
We actually have an iPaq and I am looking forward to getting Squeak up on it. You mentioned that you were writing down the steps needed to put Squeak on the iPaq. Let me know when that's available (but no rush; it's the holidays!). If I can get the proper development environment set up, I may try to compile a VM myself. Perhaps there is some level of C optimization that produces correct but faster code.
Yes, I will try and finish the howto as soon as possible. I'll put it up on minnow when it's done. :) (It won't happen today as I'm currently trying to rest off the effects of a nine-hour drive...yikes!)
For now, check out the handhelds.org 'howto' section...that will pretty much get you started with Linux on the iPaq.
They recommend not using a cross-compiling setup because they claim it makes life miserable in the long run...I dunno, I've set up GCC in cross-compiling environments before and it wasn't THAT bad. :) Of course you'd have to cross-build all the X11 libraries as well.
You can just telnet to their 'skiff' cluster of ARM boxen and compile whatever you want without the hassle, however. I think the link on how to log into it is on the howto page as well. If you do this, I've already got the squeak 2.9 build sources in the 'kgf@golden.net' subdirectory.
One question: How much RAM is available for the Squeak object heap? (See the VM statistics available under the "help" menu.)
On my iPaq it says I've got 13,615,464 bytes total memory, with about 12 megs free.
Mind you, I've got the image on read-only flash and not in the read-write DRAM filesystem (which would be ideal in the future once they reduce the power sleep/suspend mode uses in the kernel).
Actually, this brings up a point I was wondering about. The DRAM filesystem is the 'live' filesystem where any user data to be kept and synchronized would exist. The FLASH filesystem has all the stuff that doesn't change at all (such as executables and config files). There's only 32megs of DRAM available, and I imagine this gets split between running applications and the DRAM filesystem so.. as far as maximizing space goes, is there any way to keep the image on the read-only filesystem, but have any changes go to the DRAM filesystem? Is this making any sense? :) (My head is still road-addled and filled with road salt).
-- John
Kevin wrote:
I managed to get the image on a read/write segment of memory and I got that benchmark for you...the result of "0 tinyBenchmarks" is: 4667444 bytecodes/sec; 155544 sends/sec
Note that this is on an unoptimized VM (compiling with optimizations has problems on ARM).
Tim Rowledge wrote:
That's not too bad for an unoptimized VM; my 202MHz SA110 Acorn (2 x bigger cache than iPaq SA1100, but much slower main memory bus - hey, it's six years old!) gets 10m & 374k on the same test. I _think_ I got up to about 8m bc/sec on the original Itsy port. On a 276MHz SA110 NetWinder I think it's more like 12m & 600k.