I thought this might be of interest since many Be engineers went on to work at PalmSource etc…
Basically the project reverse engineers and extends PalmOS to run on Thumb only MCUs which should eventually result in a complete Palm device clone … with adequate performance. There is supposed to be source code released once it’s done. It runs on Native hardware as well as on PC via emulation.
All respect for the efforts of Dmitry (as ever), but man, it sounds like Palm made a real pigs ear of their OS.
Yes, and that’s often the case in an embedded system… that has many goals and tight constraints something has to give, especially in a system that must retain backwards compat on a shoestring budget.
A real world OS that isn’t a pigs ear… in some way or other would be far more surprising.
Well, I should qualify that I call it a pigs ear as an embedded developer myself. I’ve seen this happen many times and been in a position where there isn’t time and budget myself as well… but that doesn’t mean it’s the right thing to do and it irks me. Even more so when you have a large developer community that you’ve a responsibility to. IMO moving to ARM should have been an opportunity to maintain source compatibility, with the API recreated to execute in ARM rather than through emulation traps, and provide memory protection, supporting backwards compatibility as necessary through the specialised kernel layer they created. Clearly they took a shortcut here, and it appears to have made quite a mess…
Haiku is surprising 
I concede embedded is a different kettle of fish though.
I’m not sure why you think they used emulation traps extensively or in a dirty manner? That’s just rePalm doing that for the sake of time as he didn’t want to rewrite all the libs in Thumb… (granted they did in some cases apparently in PACE the 68k layer).
What he did say was all Thumb code is entered as ARM code, and that does enforce clean consistency across all the libraries… also PalmOS Cobalt was going to have many of the other things you mentioned and then some but it died at that point essentially.
Also some ugliness may come from disassembly… it may have not been too bad in the original source.
In essence, the unpleasant part is here:
Perhaps I read this wrong, but it sounds very much like the way they supported an ARM API was to force all API calls from ARM to go through the 68k emulation layer. It might have looked nice enough in source code, sure, and clearly it was fast enough, but it’s pretty black.
Yeah I missed that, sounds super wonky…
Well, they had existing apps to keep running and the focus was on that. They had the same problem that MacOS was facing and that eventually led to creating Be 
But there is a stronger reason for this design choice. Palm had been running on 68k for a rather long time. Dropping support for all these applications was not an option. They had to switch to ARM, but at the time it was not clear that this was a good choice. Maybe they would need to switch to yet another CPU a few year later. So, the concept was that everything would run in an m68k virtual machine, whatever the native CPU was. But they still allowed native calls for performance reasons, knowing that apps using this would need an update if they ever changed the native CPU again.
Incidentally, some of the engineers from Palm eventually found jobs in the Android team, and they used mostly the same architecture, except replacing m68k with a Java virtual machine. You can still not call much of the OS functions directly from native code in Android. Does using Java make it look uglier or cleaner?
This reasoning makes sense in some kind of way, but it is rather terrible planning wouldn’t you say? And they still have the worst of both worlds: They allow new applications to have ARM code in them, so if they did switch archs again none of those applications would work anyway. But those new applications are already second class citizens to the OS, making them slower. And the OS can’t take advantage of the safety features of an MMU or privileged execution modes because the whole setup is some kind of strange 68k VM. The obvious thing to do would have been to make a source compatible ARM API, and have the 68k emulator call into this, not the other way around.
This is a very different situation. Java is a high level language designed to be sandboxed and efficiently JIT executed. This gives it speed and memory safety and other security features. When android started out, ARM chips also still quite commonly supported jazelle even (having said that, I’d be surprised if android used it). You are comparing this to deciding not to use any of the safety features of available from an MMU, and additionally making all your code jump through an emulation layer for a totally different arch to ask the system for anything. So I’d say the answer is a pretty obvious, yes, using java is much, much cleaner.
It’s a story of legacy. Palm couldn’t have used a VM when they started, for performance reasons (and quite likely they were aware of the efforts at Xerox with Smalltalk at least at some point - and you can clearly see that from, for example, the execute-in-place design where applications are stored only in RAM, and run from there). And when the time came to switch CPUs, they took the opportunity to virtualize the applications. It may not be the cleanest solution, indeed. But it got them running on ARM quickly, and allowed them to continue shipping devices while they were working on the next features.
Yes, if you look only at the final result, this is not how you would have done things. But if you put it in perspective of the history, the engineer culture of that time, and the market and hardware constraints, to me it seems to make sense. And indeed it worked for Palm, and allowed to spawn Android on a similar, but cleaner, base. Meanwhile, Cobalt, the clean native ARM stuff with bits of BeOS inside it, never caught on.
Also, as a former ARM-based Palm device user, I can tell you that the battery life was great, and the apps were super fast. The 68k emulation wasn’t getting in the way at all, and compatibility was great with existing apps. And I was running the cheapest offer at the time, A Palm Zire 21with just 8MB of RAM and 120MHz CPU.
I know it fits with their history and was born out of the constraints, and it clearly worked fast enough as I said before. But it’s still a monstrous bodge from an engineering perspective IMO. You can’t really even call it virtualisation. It must have made their build tools pretty horrendous too.
I’m not suggesting a VM is the best idea either. A clean architecture switch with an emulator for backwards compatibility would have been fine (many others have done it).
It’s cool that it eventually influenced the design of Android though (though even then a phone running java was not a super original idea).
nice, very nice