Markus Kohler said:
>As far as I know the Pilot processort is not 32 Bit.
>Therefore porting Squeak could be difficult.

With respect to memory addressing, the current instances of Palm OS
machines (i.e., Pilots) use the Motorola Dragonball processor, a 68K
instruction set.  Palm OS also uses the early Mac 68K memory model and
calling conventions.  Therefore, developers have all the early-Mac problems
of "near" vs. "far" addressing, limits on code segments greater than 32KB,
etc.  The current Pilot hardware has 24 address lines, so it is possible to
address 16 MB of memory (I have a third-party, TRG, memory card in my Palm
III that has 2 MB of flash memory and 8 MB of RAM).

The issue of porting Squeak to Palm OS keeps coming up, so I'll repeat my
earlier msg below.  The current update is that there is an undocumented
system call in Palm OS that can be used to get around the memory write
protection (MemSemaphoreReserve(), see "really bad news" below), but the
issues of having to break up the Squeak heap into 32KB "pages" still
remain.

I also still have good intentions to return to this porting effort
sometime, but I've got one other (experimental) handheld device port to
worry about first :-)

Mike Wirth

===========================================

Please respond to squeak at cs.uiuc.edu

To:   squeak at cs.uiuc.edu, Craig.Latta at NetJam.org
cc:   Michael Wirth/Almaden/IBM
Subject:  Re: (Status of) Palm III port?





Craig, et al,
I've spent a fair bit of time digging into the technical issues of porting
Squeak to the Palm OS.  (BTW, John Maloney has been extremely helpful in
assisting this effort, resulting in the "minimal port" C file that he
recently released.  Thanks, John.)  I originally thought that the release
of Palm OS 3.0 (on the Palm III device) would solve the critical problems.
But it didn't.  Here's a copy of an earlier (6/29/98) message that I
circulated privately on this topic:
==========================================
I have good news and I have bad news.
The good news is:
* Palm OS 3.0 SDK final (docs, sample code, headers, etc.) is now out.
* We have our TRG memory cards for the Palm III (2 MB flash, 8(!) MB RAM)
* We expect to get our Palm III's RSN :-)
* Palm Computing has taken over the CoPilot, the Pilot emulator (runs on
Windows, Mac and elsewhere), and upgraded it to Palm OS 3.0.
* Heaps in "storage memory" (where Palm databases live) are no longer
limited to 64 KB.  In Palm OS 3.0, all available RAM (after allocating a 96
KB "dynamic heap") is put in a single heap.
* I went on a trip to NY for business last week and finally had a number of
hours of undisturbed time on the airplane and in the motel to pour over the
memory management description in the Palm OS 3.0 docs.
The bad news is:
* Palm database records (which is where all the RAM is) are not supposed to
contain any memory pointers (or even handles) because the Palm memory mgr
wants to be able to move records around (and in the general case, Palm OS
supports removable memory cards -- but not in the current hardware -- which
would cause card base addresses to move around as a card was moved between
slots).
* Palm database "records" = memory allocation "chunks" (with a little bit
of record header info at the front) are still limited to 64K!!!
This actually doesn't seem too bad :-)  I can force the mem mgr to not move
my (Squeak heap) records around by locking down the handles.  I can
relocate the pointers when Squeak starts up or shuts down (or when a card
is moved -- someday)
Keeping the Squeak heap in a collection of Palm database records would
actually be a "good thing".  Then we could use the normal Palm desktop
synchronization facilities to backup/restore the Squeak image to/from the
desktop.  And if new/changed Squeak objects are localized, then the sync
only has to copy part of the image/database.  I'm presuming I can rewrite
Squeak's "new" method (and a few other places) to allocate objects within
this "paged"/db-record environment without too much trouble.  But, of
course, the GC may be affected.
But the REALLY BAD! news is:
* You can't directly write into a database record (i.e., storage memory).
The memory is write-protected.  You have to go through a memcopy function
that does some bounds checking and unprotects/reprotects storage memory
around the actually copy operation.  I suppose the idea is to protect user
databases from errant applications at all costs (indeed! :-)  But I see
this "feature" as deadly to a Squeak (or any OO runtime) for two reasons:
-- I'd have to change the compiler to code every write to go thru this
interface, as well as accomodate it in the platform-support C code.
-- I'm sure the performance hit will be significant (I'll code it up and do
some timing tests :-) on an already marginal platform.
I suspect the answer will be that I have to cheat and disable this
write-protection somehow.  If all else fails, I'll get Jeff Hawkins
(founder of Palm Computing) to tell me how when he visits Almaden in July
(I'm supposed to host a visit for him and a team from Palm :-)
Any ideas?  What percentage of bytecodes executed are writes to objects (as
opposed to the stack)?
==========================================
Update:
1. We got (and are enjoying :-) our Palm IIIs.
2. I haven't had time to code up the mentioned timing tests on the Palm OS
API for copying to database records.
3. Jeff Hawkins and Donna Dubinsky have left 3Com/Palm Computing, raising
several questions about the future of the platform and our interaction with
it  :-)
4. Lately I've been working on another port to an experimental handheld
device.
Anybody out there in Squeak-land have any better info on Palm OS or ideas?
I'd still like to see this port happen.
Mike Wirth
IBM Almaden Research Center
<<usual disclaimers>>