Squeak and PalmOs?

Raab, Andreas Andreas.Raab at disney.com
Sat Apr 14 03:50:46 UTC 2001


Hi Erik,

Interesting summary. From your message, it seems to me that it might not be
that hard to port Squeak to it after all - you have to consider that there
are almost no stores into old space so if there would be a few well known
roots for a squeak application all might be fine. One could even run tests
on platforms with memory protection to see if there are in fact any stores
into old space (I've considered that at some point for the sake of speeding
up full GCs). But it's probably not worth the effort considering that
PocketST does it all already ;-)

Cheers,
  - Andreas

> -----Original Message-----
> From: Eric Arseneau [mailto:eric at ericsworld.com]
> Sent: Friday, April 13, 2001 8:01 PM
> To: squeak at cs.uiuc.edu
> Cc: recipient list not shown
> Subject: RE: Squeak and PalmOs?
> 
> 
> > Just in case this is a little unclear--the PalmOS memory
> > architecture is dumb because it is segmented--meaning that if you
> > have an 8-MB palm machine (or Visor) Squeak cannot address all 8
> > MB at the same time.  Squeak needs to address the PalmOS memory
> > in segments (chunks).  This is a major pain for a Virtual Machine
> > like Squeak's which expects to address a flat memory space.  A
> 
> That is part of the problem, but not really the complete 
> problem.  Squeak
> could still execute quite well in a segmented memory 
> architecture.  The
> problem is that Palm OS has two "types" of memory: storage 
> heap and dynamic
> heap.
> 
> The majority of memory is dedicated to the storage heap, this 
> is is where
> all of the user's data/documents are stored.  In order to 
> protect a user's
> data from a program randomly writing into the storage heap, 
> Palm OS uses
> hardware page protection for protection.  Reading from this 
> memory is not a
> problem, it is writing to it which is slow.  In order to 
> write to this area
> of memory, a semaphore is waited on, a range check is performed and I
> believe a supervisor switch is done.
> 
> The other "type" of memory, the dynamic heap, is limited to a 
> single segment
> (I believe).  This is where the segmentation could be a real 
> pain.  I am not
> absolutely sure, but I think the dynamic heap is limited to a 
> single 64K
> segment.  Could be wrong.  Whatever it is, the OS limits the 
> amount of this
> "type" of memory.  This type of memory is used for the 
> dynamic execution of
> applications, when an application is done, ie it quits, the 
> OS cleans up the
> area of RAM to make sure there are no artifacts left.  Keep 
> in mind that
> this is the same area that the OS itself uses for its dynamic 
> behavior.
> Even though there is 64K, the OS uses a good amount of it 
> depending on what
> services you use.  For example, if you perform serial comms, 
> the OS takes up
> ~28K for itself.
> 
> To recap, the biggest reason Squeak would have a hard time is 
> that keeping
> the locality of writes its code does would be very difficult, 
> otherwise it
> would run fine.
> 
> When I say "type", both types are actually in the same RAM 
> module(s), its
> just the OS itself that creates the distinction.
> 
> More details than anyone cared to know, but I'm a bit partial to this
> platform :-) and thought I would share with everyone :)
> 





More information about the Squeak-dev mailing list