Embedded REBOL (Re: Population of PDA Users)

Actually, the RAM hardware the heap is in is no faster than the rest of the RAM. The reason it is 32k is because it is accessed using a 16-bit signed offset pointer. Other RAM needs a change of base pointer in addition to the offset, an operation that takes slightly longer. Palm OS is 16-bit, like MS-DOS. The speed difference is similar to that between .com and .exe programs on DOS. The only slower RAM in Palm-compatible handhelds is in the add-on flash cards that are available for Visors and Sonys.

Certainly, because it would run on 16-33 mhz processors.

Palm OS is pretty generous by embedded standards. REBOL just isn't structured by embedded standards. And yes, REBOL would need some minor rewriting to really fly on Palm OS, WinCE or in any other environment that is not based on the slow-disk, large-heap pattern. Palm OS and WinCE are based on a small- heap, in-memory database pattern. WinCE has a potentially larger heap (32-bit addressing) but can have a heap that is too small for traditional REBOL, as I think it does with the HP Jornada 620 when its RAM hasn't been updated. Of course Carl would be the one to ask about this, with his experience in OS design, but I'll give it a shot. What REBOL does now: 1 - Load the native core from the disk to the heap. 2 - Decompress (build?) the REBOL data into the heap. 3 - Run the interpreter. What other languages do on these platforms: 1 - Execute the native code from where it already is. 2 - Access the data directly from in-memory databases in the native format, without needing to put it in the heap. 3 - Run the interpreter. What REBOL would need to do to make this work: 1 - Make sure that as much of the native code as possible is reentrant, so that multiple REBOL instances can be run at the same time from the same code. This could improve the Windows and Linux ports as well, maybe. 2 - Structure the REBOL heap as an object-database, or perhaps several databases. One way would be for the system to get one read-only heap for the mezzanine and below, and one read-write heap for each session. Objects in the main heap changed in a session would be copied to the session heap and changed there. The existing REBOL code is somewhat anti-reentrant, so a little rewriting would be necessary to minimize the copying (and enable multi-threading as well). The database code could just be a wrapper around system database support on platforms that have such, like Palm and WinCE. You can even compress the code in the main heap with a REBOL-to-native compiler, and even store most of the native functions in it. 3 - Some of these platforms don't have an easy mapping to the program concept - on Palm a "program" is a database with native code in its records. They also don't necessarily have specific program opening and closing operations, basically picking up where they left off. The session concept would map quite well to this, allowing you to pause and resume multiple sessions, start new sessions, and even "stop" them by deleting the session database. I'm sure that there are other factors that I haven't thought of (Carl, chime in!), but that should cover the basic changes. The REBOL code should be mostly portable between Palm, WinCE, etc. The native code would be less portable but some careful planning and a REBOL compiler would relieve some of that.

I believe Palm OS 4.0 is supposed to be that. It is even said to be ported to the ARM architecture (I'll believe that when I see it).

I could probably write it in two weeks (at least the basics), after several months of reading and research of course. :( Experience counts. I've been thinking about this, off and on, for a few months now. Carl has actually done things like this before (Amiga comes to mind)...

Me too! Brian Hawley

I did a multi-platform porting/recoding of a PalmOS application originally written in CodeWarrior for Windows/WindowsCE/PalmOS using VB, eMbedded Visual Basic and AppForge (VB for PalmOS) with a database being accessed either through ADO/ADOCE/AppForge PDB Library with a Conduit written in VB that was synchronising data using ODBC and building the MDB, CDB and PDB databases at once... overall, I reuse 90% of the code in all version (only byref object type where modified and the database access !). If Rebol/View existed on all three platforms, I'm sure we would have used it ! And could still use the scripts online to do the same !!! Rebol is a refreshing look in programming I'd like to see more in PDA and Mobile units... Last time I looked at Satellite Forms, the license fee was way overrated ! Chris

</SNIP> I have considered it too. I actually went so far as to test some interpeter designs. I ended up producing something much simpler, more oriented towards data collection for now. Lately I have been really thinking about just s--- canning the Palm, and going with, well, something else that can run REBOL. I might getting one of those VR6's, just to see if I can get REBOL to run on it. --Ryan

Yes, the REBOL Palm port lives in a border town next to the realm of "possibility". REBOL has even been compiled for Palm before, but the problem is that in order for REBOL to run (or even to boot) a segmentation paging scheme (virtual memory) has to be used. Under such a scheme, page faults would occur constantly. More time would be spent moving memory than in being an interpreter. As you approach the problem of a REBOL Palm port, it becomes increasingly infeasible. The other approach is to hack the memory protection of Palm OS. This isn't acceptable, though, because of the potential for accidentally hurting other apps or data on the pda. There's still more issues, from Palm's event model and how REBOL's works, potentially workable, but still an issue. And how do you write scripts -- in graffiti?? Storing and load scripts from the database? Anyhow, there were enough demonstrable problems with it that we scrapped consideration of the Palm -- to the disappointment of many. -jeff

-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -Einstein

I remember asking about this on that IRC conference with Carl back when the very first rebol binaries went public, or rather more specificly back then, wether we could expect to see rebol as shared library or background engine like RexxMast on amiga. If my memory serves me right, the answer was positiv, ahm.. :) -- kolla

-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -Einstein