Smalltalk in A PDA 
Author Message
 Smalltalk in A PDA

Smalltalkers-

        At Solutions this year there were some comments from Randy Best that
there is a alpha (pre alpha?) version of a Development environment for
the Palm Pilot... does anyone know anything about this?

        Thanks!

        Jason W. Frye



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA

writes:

Quote:
>t Solutions this year there were some comments from Randy Best that
>there is a alpha (pre alpha?) version of a Development environment for
>the Palm Pilot... does anyone know anything about this?

Prior to the latest Palm release, there were memory problems which
prevented porting even Squeak to the Palm. I hear that this problem is
fixed now and it might be possible to port Squeak (because it can be made
to run in under one meg total, including source).

However, the screen is so tiny that one would really have to redesign all
browsers, etc., for the Pilot.

Some people see it as a fast way to do application prototyping, doing the
development on a larger machine and running the apps in Smalltalk on the
Pilot.

Maybe you heard about a different effort?

Dave

_____________________________________________
David N. Smith
IBM T J Watson Research Center, Hawthorne, NY

Home Page: http://www.dnsmith.com/
_____________________________________________
Any opinions or recommendations are those
of the author and not of his employer.



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA
I think the best thing [IMHO] would be to have a ST Dev environment on
the "PC" and deploy a "parcel" to the PDA... that could run in a slimmed
down VM.

I have a Palm III, it comes with 2 Megs standard. I might make for a
really cool dev env for the Palms... I can just see it now... an UI
buidler the size of my palm top...

Maybe someone could talk those guys at UIUC into porting VWNC to the
pilot :-)

Jason

Quote:


> writes:
> >t Solutions this year there were some comments from Randy Best that
> >there is a alpha (pre alpha?) version of a Development environment for
> >the Palm Pilot... does anyone know anything about this?

> Prior to the latest Palm release, there were memory problems which
> prevented porting even Squeak to the Palm. I hear that this problem is
> fixed now and it might be possible to port Squeak (because it can be made
> to run in under one meg total, including source).

> However, the screen is so tiny that one would really have to redesign all
> browsers, etc., for the Pilot.

> Some people see it as a fast way to do application prototyping, doing the
> development on a larger machine and running the apps in Smalltalk on the
> Pilot.

> Maybe you heard about a different effort?

> Dave

> _____________________________________________
> David N. Smith
> IBM T J Watson Research Center, Hawthorne, NY

> Home Page: http://www.dnsmith.com/
> _____________________________________________
> Any opinions or recommendations are those
> of the author and not of his employer.



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA

Quote:
>I think the best thing [IMHO] would be to have a ST Dev environment on
>the "PC" and deploy a "parcel" to the PDA... that could run in a slimmed
>down VM.

>I have a Palm III, it comes with 2 Megs standard. I might make for a
>really cool dev env for the Palms... I can just see it now... an UI
>buidler the size of my palm top...

Yikes.. well, I am working on this very thing right now!
Initial measurements show that it's quite practical indeed
to run Smalltalk programs on the Pilot (16 MHz 68k clone).
Footprint for a hello world is only around 5k (!) plus a
20k virtual machine, and all the essentials are there:
blocks, metaclasses, the important collection/stream/number
classes, full Smalltalk syntax, etc.  You develop on the PC
and then it spits out a .pdb file which you hotsync to the
pilot and run.

---



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA
<snip>
: Yikes.. well, I am working on this very thing right now!
: Initial measurements show that it's quite practical indeed
: to run Smalltalk programs on the Pilot (16 MHz 68k clone).
: Footprint for a hello world is only around 5k (!) plus a
: 20k virtual machine, and all the essentials are there:
: blocks, metaclasses, the important collection/stream/number
: classes, full Smalltalk syntax, etc.  You develop on the PC
: and then it spits out a .pdb file which you hotsync to the
: pilot and run.

Wow.  I don't suppose you have a web page that we could look at to keep
us up to date on this?  Are you going to make this generally available?

-Carl
--
------------------------------------------------------------------

 author of Liberty BASIC, a 1996 PC Magazine Awards Finalist!
 http://world.std.com/~carlg/basic.html



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA

Quote:
>: Yikes.. well, I am working on this very thing right now!
>: Initial measurements show that it's quite practical indeed
>: to run Smalltalk programs on the Pilot (16 MHz 68k clone).
>: Footprint for a hello world is only around 5k (!) plus a
>: 20k virtual machine, and all the essentials are there:
>: blocks, metaclasses, the important collection/stream/number
>: classes, full Smalltalk syntax, etc.  You develop on the PC
>: and then it spits out a .pdb file which you hotsync to the
>: pilot and run.

>Wow.  I don't suppose you have a web page that we could look at to keep
>us up to date on this?  Are you going to make this generally available?

I'm working on a white paper which I'll put on my web page.
The system _will_ be publically available (possibly commercial,
possibly not) when it is finished, which will probably be in a
few weeks.  In the meantime, you can look at a program I wrote
with a previous version of the system at this URL:
        http://www.tiac.net/users/ajb/dungeoneers/index.html

It's a medium size game for the Pilot (which will be available
for download as soon as I get a registration system set up :)

---



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA


Quote:

>>I think the best thing [IMHO] would be to have a ST Dev environment on
>>the "PC" and deploy a "parcel" to the PDA... that could run in a slimmed
>>down VM.

>20k virtual machine, and all the essentials are there:
>blocks, metaclasses, the important collection/stream/number
>classes, full Smalltalk syntax, etc.  You develop on the PC
>and then it spits out a .pdb file which you hotsync to the
>pilot and run.

FWIW, I too have been eyeing Smalltalk on the PalmOS.  My initial choice
of a base would be Tim budd's Little Smalltalk v3.x.  It's public domain,
and the interpreter should fit into 30-40kb of compiled code, and intial
image of 60kb (sans source text).  Should be possible to create machine
independent byte codes on a host (PC or Unix).  UI would have to be fashioned,
and probably should take advantage of the Palm's existing UI.  Cool to
also emulate the UI on a host, and do all development there.

The PalmOS presents a few problems, errr, challenges, to the the programmer.
Code is relatively addressed (32 kb +/- jumps),  small amount of stack
space (can't count on more than 16-32kb), the rest of memory allocated in
'databases' of 64kb segments (can be accessed as heap with a few tricks.)

Unfortunately, it's still a 'wish' project on my agenda.
--
Tom Poindexter                       Does any spammer really think that I'd

http://www.nyx.net/~tpoindex/        



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA

Wouldn't Squeak be better option? It appears extremely portable with a
small footprint and a nice GUI framework.

Marc

Quote:



> >>I think the best thing [IMHO] would be to have a ST Dev environment on
> >>the "PC" and deploy a "parcel" to the PDA... that could run in a slimmed
> >>down VM.

> >20k virtual machine, and all the essentials are there:
> >blocks, metaclasses, the important collection/stream/number
> >classes, full Smalltalk syntax, etc.  You develop on the PC
> >and then it spits out a .pdb file which you hotsync to the
> >pilot and run.

> FWIW, I too have been eyeing Smalltalk on the PalmOS.  My initial choice
> of a base would be Tim budd's Little Smalltalk v3.x.  It's public domain,
> and the interpreter should fit into 30-40kb of compiled code, and intial
> image of 60kb (sans source text).  Should be possible to create machine
> independent byte codes on a host (PC or Unix). UI would have to be fashioned,
> and probably should take advantage of the Palm's existing UI.  Cool to
> also emulate the UI on a host, and do all development there.

> The PalmOS presents a few problems, errr, challenges, to the the programmer.
> Code is relatively addressed (32 kb +/- jumps),  small amount of stack
> space (can't count on more than 16-32kb), the rest of memory allocated in
> 'databases' of 64kb segments (can be accessed as heap with a few tricks.)

> Unfortunately, it's still a 'wish' project on my agenda.
> --
> Tom Poindexter                       Does any spammer really think that I'd

> http://www.nyx.net/~tpoindex/        



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA

Quote:
>FWIW, I too have been eyeing Smalltalk on the PalmOS.  My initial choice
>of a base would be Tim budd's Little Smalltalk v3.x.  It's public domain,
>and the interpreter should fit into 30-40kb of compiled code, and intial
>image of 60kb (sans source text).  Should be possible to create machine
>independent byte codes on a host (PC or Unix).  UI would have to be fashioned,
>and probably should take advantage of the Palm's existing UI.  Cool to
>also emulate the UI on a host, and do all development there.

Little Smalltalk is a bit too mismatched for the Palm Pilot platform,
unfortunately.  Basically, half the C code is for a memory manager that
would be instant death on the Pilot (2-space copying garbage collection)
and the other half is for a bytecode interpreter which interprets an
instruction set that is not really reconcilable with the kind of
optimizations I am doing with the compiler.

Quote:
>The PalmOS presents a few problems, errr, challenges, to the the programmer.
>Code is relatively addressed (32 kb +/- jumps),  small amount of stack
>space (can't count on more than 16-32kb), the rest of memory allocated in
>'databases' of 64kb segments (can be accessed as heap with a few tricks.)

Yeah, no kidding.  This is what prompted me to make a Smalltalk
for it in the first place, since then one could avoid those limits.
By turning off write protection on the Pilot I can spread the image
over 16k size (or whatever) memory chunks plus a larger chunk for an
object table which can hold around 8000-16000 objects (using an object
table makes it _much_ more space efficient).  So the only real limit
is the number of objects, which is really no limit at all because
methods don't count as objects (and methods are usually the biggest
consumer of memory in traditional Smalltalk systems).

One novel feature of my system, if anyone wants to comment on it, is
that I added a new kind of block that is much more efficient than
the ordinary block because it causes no memory allocation.  What I
do is statically allocate an array of maybe 30 traditional block
closure objects and then when I run across something like this:

| total |
total := 0.
self do: {:each |
   each isValid ifTrue: [total := total + 1]}.

I just take one of the statically allocated blocks and push it on
a stack.  Then the #do: method is executed for the {} block.
When it returns, the {} block is immediately released (returned
to the list of free blocks).  Notice that no memory was allocated
for this.  The only problem is that the block can't be held beyond the
duration of the #do: message.  That condition is satisfied for
the great majority of uses of blocks.  So now you have the potential
for a Smalltalk system that can run without any memory allocation
at all, except for explicit "MyClass new" expressions.  That's in
contrast to traditional systems which allocate many kilobytes per
second during normal execution.  And if you want to "port" the
{} blocks to another system, all you have to do is search and
replace all { and } by [ and ], since they are otherwise backward
compatible.

---



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA
Have you considered a version for GEOS?  There's a bustling handheld market
there too, and the desktop version of GEOS could really use a Smalltalk!  

see http://www.newdealinc.com

-Carl



<snip>

Quote:
> I'm working on a white paper which I'll put on my web page.
> The system _will_ be publically available (possibly commercial,
> possibly not) when it is finished, which will probably be in a
> few weeks.  

...


Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA

Quote:

> Yikes.. well, I am working on this very thing right now!
> Initial measurements show that it's quite practical indeed
> to run Smalltalk programs on the Pilot (16 MHz 68k clone).
> Footprint for a hello world is only around 5k (!) plus a
> 20k virtual machine, and all the essentials are there:
> blocks, metaclasses, the important collection/stream/number
> classes, full Smalltalk syntax, etc.  You develop on the PC
> and then it spits out a .pdb file which you hotsync to the
> pilot and run.

> ---


Way to go!!!  When will it be out to play with?  I've been dying to have
something like that available for the PalmPilot.  It's a great little
platform but it's a pain to develop apps all in C.

-George

-------------------------------------------------
George F. Santamarina
gsanta at mindspring dot com



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA

Quote:

>FWIW, I too have been eyeing Smalltalk on the PalmOS.  My initial choice
>of a base would be Tim budd's Little Smalltalk v3.x.  It's public domain,
>and the interpreter should fit into 30-40kb of compiled code, and intial
>image of 60kb (sans source text).  Should be possible to create machine
>independent byte codes on a host (PC or Unix).  UI would have to be fashioned,
>and probably should take advantage of the Palm's existing UI.  Cool to
>also emulate the UI on a host, and do all development there.

LST is even smaller. My version 4 (which Budd started but never finished,
unfortunately) has an image size of 84 K, of which some 55 K are source
texts. That image contains a simple collection and number class hierarchy,
the complete byte code compiler but no stream classes.  The interpreter
needs about 5K (text segment only, excluding symbol and relocation
information) and the simple stop&copy garbage collector another 2.5K code.
The interpreter, however, contains no system primitives other than
arithmetic and some i/o commands.

I think, however, the system has to be redesigned. One would have to use
another gc algorithm and the interpreter needs speed improvements.
Currently, the system creates and forgets hundered-thousands of context
objects per second. While the stop&copy gc is very efficent in cleaning up
this, it's still a major performance leak.

The gc has to be adapted for the pilot's memory management.

Quote:
>The PalmOS presents a few problems, errr, challenges, to the the programmer.
>Code is relatively addressed (32 kb +/- jumps),  small amount of stack
>space (can't count on more than 16-32kb), the rest of memory allocated in
>'databases' of 64kb segments (can be accessed as heap with a few tricks.)

The jump-restiction isn't harmful, I think, as the complete VM will easily
fit into 32kb. The memory management would be tricky, however. I'd suggest
to encode segment number, segment offset (and some other information) in
special pointer objects.

Each segment of 64kb can store 16384 32bit words. We need 14 bits to store
these. We can use two additional bits to mark immediate values. We can use
7 bits to map the segment number. This should give us 8 MB of addressable
memory. I'd then reserve 1 bit for the gc. The remaining 8 free bits can be
used to encode whether the object is a fixed size or of variable size and
whether it's a pointers or a bytes object and finally, which class it uses.
We can encode at least 31 of the most used classes.

I suggest to use a mark&sweep gc, because this needs less memory. As a m&s
doesn't move objects, it's also probably easier to interface the palm OS.
To reduce memory fragmentation, it might be useful to use each segment for
only one object size.

But wait, I just read that somebody has written a Lisp system for the
pilot. He had to solve the same problems (well, he hasn't to deal with
class pointers) and perhaps one could use this source (if available) as the
base for a memory manager.

Whatever, I'd love to see a Smalltalk system for a PalmIII as this would
convince me to buy such a machine, I think. Furthermore, it's an
interesting (challenging) project :-)

bye



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA

Quote:

>and the other half is for a bytecode interpreter which interprets an
>instruction set that is not really reconcilable with the kind of
>optimizations I am doing with the compiler.

That means, your system is a real, native code compiler and no bytecode
interpreter?

Quote:
>table makes it _much_ more space efficient).  So the only real limit
>is the number of objects, which is really no limit at all because
>methods don't count as objects (and methods are usually the biggest
>consumer of memory in traditional Smalltalk systems).

That means, you've to method dictionary objects and no compiled method
objects? Does your system support #perform:? (If yes, I'm curious, how)

Quote:
>One novel feature of my system, if anyone wants to comment on it, is
>that I added a new kind of block that is much more efficient than
>the ordinary block because it causes no memory allocation.  What I
>do is statically allocate an array of maybe 30 traditional block
>closure objects and then when I run across something like this:

Perhaps, I don't understand this correctly, but it seems that this is a
normal optimization, I expect from all modern smalltalk system. As most
block closures are used in a stack-like last-in-first-out manner, the VM
can optimize them. However, I'd expect the VM to make this optimization,
not the user. What happens, if I rewrite self>>do: from your example as

   do: aBlock | block |
    block := Date today dayname = #Monday
      ifTrue: [lastBlock]
      ifFalse: [aBlock]
    1 to: self size do: [:each | block value: each].
    lastBlock := block.

Now, a passed {} block will probably fail on mondays on the second call. I
think you can assume that every block will be lifo and can therefore have a
statically allocated block context. If a block is however assigned to a
non-temp variable, you've to create a true block context then. Don't know
whether you can detect all these cases without too much runtime overhead...

Quote:
>| total |
>total := 0.
>self do: {:each |
>   each isValid ifTrue: [total := total + 1]}.

Wouldn't it be better to use { } also for the ifTrue:-block?

bye



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA

Quote:
>I think, however, the system has to be redesigned. One would have to use
>another gc algorithm and the interpreter needs speed improvements.
>Currently, the system creates and forgets hundered-thousands of context
>objects per second. While the stop&copy gc is very efficent in cleaning up
>this, it's still a major performance leak.

I agree... my system allocates contexts strictly lifo, which although
it prevents accessing thisContext, it's efficient and easy to
implement.  (I had to make some design concessions to make it fit
on the Pilot, so thisContext was one of the first things to go...
it's just not really that useful at runtime.  You can still "sort of"
simulate it the way Dolphin and, I gather, VA, do it).

Quote:
>The jump-restiction isn't harmful, I think, as the complete VM will easily
>fit into 32kb. The memory management would be tricky, however. I'd suggest
>to encode segment number, segment offset (and some other information) in
>special pointer objects.

I'm using an object table, which in my particular implementation
works exceedingly well for a few reasons:

1. object data only takes about 1/2 the space it would otherwise
2. there is no need to store identity hashes in the object itself
3. become: is efficiently supported, so that ordered collections
   and friends consist of only 1 object, not 2
4. it's portable in the future to systems which may not support
   tagged pointers

Quote:
>Each segment of 64kb can store 16384 32bit words. We need 14 bits to store
>these. We can use two additional bits to mark immediate values. We can use
>7 bits to map the segment number. This should give us 8 MB of addressable
>memory. I'd then reserve 1 bit for the gc. The remaining 8 free bits can be
>used to encode whether the object is a fixed size or of variable size and
>whether it's a pointers or a bytes object and finally, which class it uses.
>We can encode at least 31 of the most used classes.

I am using a sort of traditional object table implementation where
the object ID's are 15 bits plus 1 tag bit (one for objects and one
for SmallIntegers) giving 32k possible objects and SmallInteger
magnitudes -16384..16383 (I think I have those powers of 2 right :)
Each object carries 3 words plus however many instance variables:
        word 1 - length (untagged integer)
        word 2 - class pointer
        word 3 - administrative info (mark bits, pointerless tag, etc)
(these first three words are of course treated specially by the gc)
Each entry in the object table is a 32-bit ordinary pointer to the
object, which resides in an unprotected database memory chunk.

Quote:
>I suggest to use a mark&sweep gc, because this needs less memory. As a m&s
>doesn't move objects, it's also probably easier to interface the palm OS.
>To reduce memory fragmentation, it might be useful to use each segment for
>only one object size.

I'm using a mark-compact gc (which works really well with an object
table because no forwarding pointer is needed).  It's almost as fast
as mark-and-sweep but it compacts the heap region, making allocation
very quick (basically just incrementing a pointer).  I might add a
small "eden" two space copying collection region (maybe 4k per
semispace) to speed up gc a bit.

Quote:
>But wait, I just read that somebody has written a Lisp system for the
>pilot. He had to solve the same problems (well, he hasn't to deal with
>class pointers) and perhaps one could use this source (if available) as the
>base for a memory manager.

Well... Lisp/scheme is __much__ easier to write a memory manager
for because all objects (conses) and the same size (disregarding
strings and vectors---it's okay to handle those inefficiently in
Lisp).  There are a couple algorithms that are very quick and
simple for that kind of thing.  I think one is called the "two
pointer" or "two finger" algorithm.

Quote:
>Whatever, I'd love to see a Smalltalk system for a PalmIII as this would
>convince me to buy such a machine, I think. Furthermore, it's an
>interesting (challenging) project :-)

Well, I'll post an announcement here when it's ready...
thanks for your comments.

---



Wed, 18 Jun 1902 08:00:00 GMT  
 Smalltalk in A PDA

Quote:
>>and the other half is for a bytecode interpreter which interprets an
>>instruction set that is not really reconcilable with the kind of
>>optimizations I am doing with the compiler.

>That means, your system is a real, native code compiler and no bytecode
>interpreter?

No, my system is a bytecode interpreter.  I was just saying that the
Little Smalltalk instruction set is not compatible with the instruction
set I chose, so there's no point in trying to use it's code.

Quote:
>>table makes it _much_ more space efficient).  So the only real limit
>>is the number of objects, which is really no limit at all because
>>methods don't count as objects (and methods are usually the biggest
>>consumer of memory in traditional Smalltalk systems).

>That means, you've to method dictionary objects and no compiled method
>objects? Does your system support #perform:? (If yes, I'm curious, how)

That's right, and yes it does support #perform: (as well as friends
like #respondsTo:, #doesNotUnderstand: etc...)

Basically the compiler makes one entry in a table for each behavior
(class and metaclass).  Each entry points to a chunk of memory that
holds all the methods defined for that behavior.  Each chunk has
a format like this:

        selector for first method
        offset of code for first method
        ...second method
        ...etc

The selectors are converted into 15 bit integers and arranged
in the above table in ascending order, so I can use a binary
search to locate the method, which is very fast for biggish
method tables.  For classes with less than 6 or so methods I
do a linear search which is even faster.  In addition, I have
a traditional global method cache which hashes on receiver
class and selector to avoid method lookup (if lucky).
After the above seletor/offset table comes the instructions
of the methods, one after the other.  There are no literal
tables, instead the compiler marks literal objects as static
and allocates them at compile time.  The instructions then
refer to the literals by object number.  So no garbage collection
has to take place on the methods themselves, as it does with
traditional Smalltalks.

Block closure objects have special instance variables that
have the "owning class" and the offset of the start of the block's
instructions.  Block instructions are embedded, Blue Book style,
in the containing method's instructions and are jumped around
during method execution.  (Unlike in the Blue Book, my blocks
are true blocks (mostly) and can be recursive, etc.)

Quote:
>Perhaps, I don't understand this correctly, but it seems that this is a
>normal optimization, I expect from all modern smalltalk system. As most
>block closures are used in a stack-like last-in-first-out manner, the VM
>can optimize them. However, I'd expect the VM to make this optimization,
>not the user. What happens, if I rewrite self>>do: from your example as

>   do: aBlock | block |
>    block := Date today dayname = #Monday
>      ifTrue: [lastBlock]
>      ifFalse: [aBlock]
>    1 to: self size do: [:each | block value: each].
>    lastBlock := block.

>Now, a passed {} block will probably fail on mondays on the second call. I
>think you can assume that every block will be lifo and can therefore have a
>statically allocated block context. If a block is however assigned to a
>non-temp variable, you've to create a true block context then. Don't know
>whether you can detect all these cases without too much runtime overhead...

Yep ... exactly right, which is why I defined a new syntax element
for these special blocks.  It's the programmer's responsibility to
ensure that the called method doesn't hold onto the block after the
creating context has returned.  The payoff is that you can pass
"strictly functional" style blocks with no penalty.  A programmer
who writes a do: look like the one above deserves no sympathy :)
Of course, if you don't want to take any "risk" you can just use
ordinary [] blocks, and everything works as expected (but causing
memory allocation for non-clean blocks).

Quote:
>>| total |
>>total := 0.
>>self do: {:each |
>>   each isValid ifTrue: [total := total + 1]}.

>Wouldn't it be better to use { } also for the ifTrue:-block?

Er, you're right of course.  The reason I wrote it with [] is
that the compiler optimizes the block away anyway in this case,
and well, I think [] blocks are prettier :)

---



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Smalltalk on a PDA?

2. PDA module - PDA questions

3. Labview PDA, What component does my Windows CE OS needs to run labview PDA

4. PDA port of J or APL

5. Free Palm Pilot PDA

6. PDA, anyone using one with Clarion

7. PDA Interface

8. What to use for PDA developement

9. PDA OS

10. PDA Conduit

11. PDA's

12. HP Palmtop, or other PDA

 

 
Powered by phpBB® Forum Software