They say it steam engines when its steam engine time. I don't have ahead of steam up yet but I was thinking recently that a dumbish interpreter would be a "nice" way of extending the memory capacity of low code size CPUs. The only excuse I can think of for doing this is because the cpu + eerom cost is much lower than an alternative capability cpu. The new flash PICs will hopefully remove this justification. I was thinking about what the minimum useful instruction set was that scold be executed by such a machine. Long ago there was an interpreter called "CHIP-OS" which ran initially AFAIR on the COSMAC and later on t he 6802 and no doubt other chips. It used 2 byte tokens had a 4096 address space virtual machine. I have a 15 page article on the language (BYTE (!), December 1978 pp 108-122.. An Easy Programming System - Joseph Weisbecker, NJ). He claims all sorts of advantages for this type of interpretive language. Says it typically takes 512 bytes for a full language and resultant code is 6 times as dense as BASIC (his claims). As I recall, CHIPOS could achieve some remarkable results considering its rudimentary nature. Something like this may be not too hard to write (he says a new language takes him about a week :-)). Russell McMahon -----Original Message----- From: William Chops Westfield To: PICLIST@MITVMA.MIT.EDU Date: Friday, December 04, 1998 10:54 AM Subject: Re: Interpreter Engine >A "nanoForth" would be just about right, depending on the complexity of the >"scripts" you have. The forth-like "execute" loop would only execute one >word per invocation, and then let your main loop do stuff. Since you'd have >control of what words were available, you can guarantee that they are all >short enough... (um, I think this is pretty much a standard forth with a >modified main interpretter loop - probably ANY interpretter would work if >you have source access to the main interpretter loop...) > >I don't know of any PRODUCTS that allow this, though. > >BillW >