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 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
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.
>