Squeak on iPaq..success!
kgf at golden.net
Sun Dec 31 22:47:19 UTC 2000
> 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 at 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
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.
More information about the Squeak-dev