It boils down to the way the PalmOS was designed. (I'm no expert here, and I haven't touched palm since PalmOS 3, so this may no longer hold true. Chips are up to 400mhz these days, PalmOS will have to improve enventually. Evolve or die!)

While the hardware has 32mb, PalmOS handles memory in 64k blocks called records. This is the biggest chunk of code you can execute, but not all ram in a palm is executable, it is also split into storage ram. Storage ram is executed in place and is not loaded into an executable space.

Suppose you have an app that displays jpg files. Your app loads and runs in executable ram. It gets to the point where it wants to display your jpg. Instead of loading the image into ram and twiddling bits, the app points to the jpg in storage and the code runs through it. This is one of the tricks that allows palm to run in low amounts of ram.

Back to perl, the parser is pretty big. I believe it's up to a few megs these days. Obviously this is too big for the 64k limit. Google for "microperl" and "palm" and you can read about what people are doing to work on it and how these limitations affect them.

There exists a good paper discussing how the JavaVM was ported to Palm to build the KVM. Google for "j2me palm kvm" and I'm sure it will come up. It's not too heavy and goes over alot of design decisions and roadblocks they ran into. I don't remember, but I think they ended up chaining 64k blocks somehow. Other interesting bits like removing Unicode from the KVM libraries removed something like 21mb of bloat on hello world.

Perl on Palm explains how python was able to be ported.

HTH!