The VM's are all written in very portable C

Post #102,667 by tuberculosis 5/19/03 10:03:08 PM Reply	The VM's are all written in very portable C you have to port them if you want to use them. There's a reason Squeak runs binary equivalent on Windows, Linux, Solaris, Macintosh, Mac OS X, the Sharp Zarus, and some other little handheld gadgets. The core VM is portable but there are stubs you need to do hardware/filesystem/network/display/input device interfacing. FWIW, there have been a number of embedded Smalltalk projects over the years. You might not be able to afford Squeak on your smaller devices. You may be able to afford PocketSmalltalk though. There is some info here: [link\|http://www.iutc3.unicaen.fr/serge/62\|http://www.iutc3.unicaen.fr/serge/62] or [link\|http://www.pocketsmalltalk.com/\|http://www.pocketsmalltalk.com/] "Packed like lemmings into shiny metal boxes. Contestants in a suicidal race." - Synchronicity II - The Police
Post #102,675 by deSitter 5/19/03 10:37:48 PM Reply	Re: The VM's are all written in very portable C I've got a spare 2gig laptop disk that was intended as a testing place for "FORTH OS" so I think I will play around with this. Has anyone ever tested Smalltalk as an extension of the FORTH VM? Kinda like running win or startx from the command prompt. FORTH is paradoxically fast in some situations, like moving data (probably why it's good for graphics). You could have a completely portable hardware interface in FORTH. [link\|http://www.zetetics.com/bj/papers/moving1.htm\|http://www.zetetics....apers/moving1.htm] How would ST map onto this? -drl
Post #102,694 by tuberculosis 5/20/03 12:31:42 AM Reply	Funny you should mention it Just ran across a thread on Squeak list talking about changing a couple low level operations in the VM to support something more like IDT on message sends to allow any object to be used as a CompiledMethod (the object that represents executable code). Which raised the following comment: Incidentally, does anyone know of prior art for doing that kind of jumping from VM to meta-interpreter and back, in Smalltalk or other similar (OO, bytecode) systems? There's a company doing exactly that to enable call/cc in Java, and I'm curious if their patent application has any validity. ------ My first thought was that your question reminded me of indirect-threaded Forth implementations, which is the classic style of Forth implementation. In an indirect-threaded Forth, each "subroutine" (called a "word" in Forth) begins with the address of its interpreter. Also, consider the similar, but slightly different, direct-threaded Forth implementation style where every "word" begins with machine code which is the interpreter for that "word" (it is typically a jump or call to the interpreter for that class of Forth "word"). Maybe that could be seen as prior art, without needing to squint too hard? I suppose this goes back to the late 1960s or early 1970s. There was a nice article in Byte (1980? or early 1980s) with a title something like "Threaded Interpreters" which went into some detail about indirect-threading, direct-threading, subroutine-threading, and token-threading. "Packed like lemmings into shiny metal boxes. Contestants in a suicidal race." - Synchronicity II - The Police
Post #103,039 by deSitter 5/21/03 10:16:51 PM Reply	Re: Funny you should mention it Well, the ideal system to me would be: 1) A FORTH VM for hardware abstraction 2) A Smalltalk windowing environment. If the basic Smalltalk ideas map onto FORTH constructs like code and parameter fields, and threading, and dictionaries, then it's a done deal to write Smalltalk in FORTH. 3) An APL system coded in Smalltalk. This would be an acid test because APL HAS to be very fast at moving data, which is what really takes the most time. -drl

Welcome to IWETHEY!