preview of Squeak on VTech Helio

Jay Carlson nop at nop.com
Wed Oct 18 14:47:58 UTC 2000


Ned Konz writes:

> > OK, I finally got up the motivation this weekend to do it.  2.8
> now runs on
> > the Helio on Linux.
>
> Very cool! This is inspirational...
> How much memory do you have left?

Uh...hard to say.  It's complicated.

Flash ROM: basically none.  I ripped out a lot of stuff from the old
vhl-tools demo1 image to get the executable and image to fit.  Like, the
next two candidates for shrinking are 1) recompiling busybox with fewer
features and 2) running the libc reducer to eliminate unused functions from
the libc.so binary....

RAM:

The Helio has 8M of memory.  vhl-tools demo1 uses a RAM resident kernel,
which eats up 930k.  Kernel allocations, page tables, bss, etc bring that up
to around 2M of kernel used in this configuration.

The remaining 6M is harder to account for.  Certainly any read/write data
allocated from application space counts against it, so whatever the -memory
parameter is subtracts.  Ramdisk comes from here too.  In older kernels, we
use a block-based ramdisk that uses a fixed (say) 200k; in newer kernels, we
use ramfs which only allocates memory as it's used.

I was using a 3M arena, with Squeak reporting like 2.2M free space with the
majorShrink'd 2.8 image.  But I could turn up the arena size a lot more, at
least to 5M.

You'll notice I'm not reporting the size of the squeak executable, libc, or
the /bin/sh yet.  That's where things get complicated.  The squeak binary
checks in at a hefty 938k, and 872k of that is actual machine code.  But the
kernel can drop any of that 872k whenever it feels like it---after all, it's
read-only, and it can always reread it from the (compressed) romdisk.  Same
for libc code.  So the actual memory usage is more a matter of how much of
the executable is actually being *used* at any given time, and your
tolerance for delays when the kernel has to reread and decompress pages it
had previously dropped.

Back to ROM.  The ~900k limit on image size (given no further hacking) is
annoying.

However, consider the original orthodoxy about how a PalmOS device *should*
work.  The Pilot is an extension of a PC.  You back up and restore the
device there, where much greater storage resources are available; while away
from your desktop, you never need to do a cold start; if you do, you've lost
everything until you return.

Given such a usage scenario, there is almost nothing to be gained by keeping
a copy of the initial squeak image on precious flashrom.  It will never be
used after device startup, and the kernel can't treat it as backing store
the way it can with read-only executables.

So what I'm thinking about doing is this: when /usr/bin/squeak is run, it
will optionally open the serial port and wait for an XMODEM download of an
image, which wll be processed as it streams in.  (There's not really any
seeking on images, right?)  When it comes time to save the image, we do an
XMODEM upload of whatever we would have written to disk.  If possible, both
of these operations should use compression, of course.

That removes the image size limit.  In fact, if romdisk size can be trimmed
sufficiently, it may be possible to run the kernel directly from ROM,
recovering 938k of RAM for further allocation from userspace.

The only thing that disturbs me about this ~6.5M arena is the lack of
checkpointing.  Some people heavily use "save image"/"restart squeak" as a
giant undo operation, especially when hacking.  Would they be better served
by a 3M/3M split between live heap and "disk" that holds the previous state
of the world.  I dunno.

Jay





More information about the Squeak-dev mailing list