You didn't mention types of programs

Post #102,599 by tuberculosis 5/19/03 3:06:49 PM Reply	You didn't mention types of programs "Packed like lemmings into shiny metal boxes. Contestants in a suicidal race." - Synchronicity II - The Police
Post #102,612 by jb4 5/19/03 4:48:20 PM Reply	Sorry, thot I was clear earlier... ..We're doing embedded processing (and by that, I mean "real" embedded stuff, not Micros~1's bastardation of the term). Realtime data acquisition and control stuff, with a microprocessor of some sort (like the sort I mentioned) running things. For this, I've got some real good C95 compilers, and some ANSI (and not-so-ANSI) C++ compilers. I haven't seen a C99 compiler in this space yet. (In fact, I haven't seen a C99 compiler in any space yet; I don't think either Micros~1's or Borland's are C99-compliant yet). No Smalltalk. No Objective C (which I would expect to be the first). No Python or Ruby. Yet... jb4 "We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's." Simon Phipps, SUN Microsystems
Post #102,619 by tuberculosis 5/19/03 5:20:34 PM Reply	Still doesn't tell me enough What is your memory budget? Persistent storage? Is there a file system? Do you drive a display? What about a network interface? If you have a couple megabytes, you can likely use your C compiler to bring up squeak and use Smalltalk (one guy has a 400k image working). So just because nobody ported it to your machine doesn't mean you can't use it. The tiny smalltalk guys use a pair of executables - a tiny executive on the device and a big fat dev environment on a regular machine. They push down little clusters of serialized objects to the executive to update the exec. This is more likely to succeed than porting the ObjectiveC runtime I think. But its up to you - all you need is a C compiler and you can run whatever you like in there - you just have to port the machine yourself. Most Squeak ports take a week or so but that's for a full blown machine with video, network, file system access, keyboard and mouse. You can skip any of these or implement them in new ways. "Packed like lemmings into shiny metal boxes. Contestants in a suicidal race." - Synchronicity II - The Police
Post #102,630 by jb4 5/19/03 6:57:25 PM Reply	Re: Still doesn't tell me enough What is your memory budget? Persistent storage? Is there a file system? Do you drive a display? What about a network interface? Whatever the device will support. (1MB for the 80186, 64K for the HJC1x or the 8051...you get the picture). EPROM or Flash. We partition the total memory address space between ROM and RAM. Not usually. I did recently get to work on a box that supported QNX as its OS/Kernel, and we used a 486 in protected mode. A "file system" was supported (the flash was made to look like a file system). Such luxuries are rare, however.... Yes, generally an LCD of insufficient size ;-) . sometimes color, often monochrome, never using standard parts (except for that QNX box I mentioned earlier...) In your (and my) dreams.... So what I hear you saying is that we download a VM-equivalent for Smalltalk, then download class definitions, and away we go? jb4 "We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's." Simon Phipps, SUN Microsystems
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!