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@cs.uiuc.edu

To: squeak@cs.uiuc.edu, Craig.Latta@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>>