Aaron,

I hate to chip in as I truly believes that code
speak much stronger than words.  But as PDA usage 
was the reason I started learning Squeak, I do
feel a little worried about moving dynapad away
from Morphic because of performance issues.
Consider that,

1. the use of something like Morphic as opposed 
   to, say, MVC, is critical for enabling small
   apps to be designed on the road

2. the portability of Squeak is outstanding. In
   all likelyhood you/we would move Dynapad with
   out as you upgrade your PDA to the next 
   (necessary more powerful) unit.  The choice
   between MVC and Morphic will almost certainly 
   look different at that time and I believe
   that designing for the present might hurt
   in the future.

3. last, but not least, I have a some amount of
   experience with implementation of programming
   languages, especially lazy functional languages
   like Haskell.  When I saw how Squeak is
   implemented I was just blown away at how fast
   Squeak actually feels given its a bytecode
   interpreter with a global method cache.  

   I stand in awe at how well designed Squeak is
   and how works, but never the less, it seems 
   to me that the performance could be improved
   quite a lot if it had to.  

For most desktop systems Squeak already performs 
quite adequate, so there may be less motivation.
On embedded devices we need better performance
for Morphic to be usable.

Caveat: I'm AM a Smalltalk beginner and I do
know and appreciate all the hard work that people
have been doing to improve performance.  I also
do know that probably what I'm about to suggest
has been or is being considered.

First of, I'm not sure that the ARM/StrongARM
VM has really been carefully handtuned.  I know
there are some gcc issues that affects performance.
The first and easy step is attacking this with
profiling tools and carefully handtweaking.  This
most likely affect the portability of the VM
(but not the image), but that's the first price
to accept.

Secondly, it really not that hard to do make 
the VM do dynamic native code generation for 
frequently executed methods (I know Squeak does
have a Jitter, but AFAIK is doesn't generate
native code).  Even simple minded template
based instantiation can improve performance
by a factor of four and more can be had with
varing degree of runtime optimization.

Thirdly, the current implementation of message 
sends is not exactly state of the art (although
it has a lot of nice properties). If you admit
to native JITing, then one option is to make 
message sends implement their own cache in
compiled form (that is, a cache miss could
cause the recompilation of the send).  There
are other less dramatic option: attaching
the compiled cache to the class instead,
or applying a global enumeration scheme
to speed up method lookup for cache misses [1].

Fourth, in the long run, Squeak could be changed
to better suit 

I'm convinced that it's technically feasible
to make Squeak on StrongArm fast enough to make
Morphic usable.  I'm just not sure if we have
enough collective spare cycles to make it happen.

[1] Taming Message Passing: Efficient Method Look-Up
for Dynamically Typed Languages (1994),
Jan Vitek, R. Nigel Horspool

All the best,

  Tommy


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com