Sounds like Niklaus Wirth's P-Code implementation of Pascal. A very
powerful virtual machine running (in my case) on an 8080
A more up to date example is the OOPIC which uses an 16F877 or
similar PIC and implements a virtual machine using external EEPROM
for the tokenized object code.
See www.oopic.com or the OOPIC group here on Yahoo. --- In , "sergio masci" <smypl@x> wrote:
> Michael Millikan wrote:
> > I meant that there may not be enough program memory.
> > As pointed out by a few people, the approach I originally had
> > the code from the EERPOM to the flash memory in the PIC) was a
> > because the flash would wear out rather quickly.
> > I was thinking about another approach, which particularly takes
> > the fact that the PIC has only 35 instructions. So I could store
> > posible instructions in the PIC memory as subroutines and use
> > a kind of pointer to tell the PIC which subroutines to execute.
> > all rather complicated because you need to have special codes
> > data into the instructions and special codes for program jumps,
> > definitely think this can be done.
> > A few potential problems: the PIC would slow way way down,
probably by at
> > least 50 times (this isn't an issue most of the time). It would
> > essentially developing a higher level language and an
> This sounds like a fun project. Go for it!
> The resulting program will run a hell of a lot slower than 1/50
> speed. Your biggest bottle neck is going to be transferring
> of the external EEPROM and into the 877 (I don't mean copying them
> internal FLASH - just reading them into RAM). I2C at 400kHz will
> about 14000 bytes / second or about 7000 instructions / second.
> a native program running at about 5,000,000 instructions / second
> be a reduction in speed of about 7/5000 or about 1/720.
> One way to speed things up would be to use much more powerful
> than native PIC machine code. Each emulated instruction would then
> work than a standard PIC instruction. Maybe implement a simple 16
or 32 bit
> virtual processor.
> You might also consider preloading special functions into the 877
> executed at full speed. Most of your program would be executed in
> mode and some of the subroutine calls would actually jump out of
> mode and call real subroutines then return back to emulation mode
> real subroutine returns.
> You might also consider some kind of hybrid. Since all 877
> 14 bits wide and you will be reading 16 bits per instruction from
> external EEPROM, you could use the top bit to indicate whether the
> instruction is a PIC instruction or a more powerful virtual
> instruction (16 or 32 bit processor as mentioned above).
> The thing about storing a tokenised high level language program in
> external EEPROM is that you get a very high level of functionality
> read from the EEPROM. This will greatly improve performance.
> I would be interested to know how you get on. Maybe you can
> progress on a web page. Tell me where it is and I will call by
from time to
> time to see how you are getting on.
> Sergio Masci
> http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC
reading program from external EEPROM
--- In , "rtstofer" <rstofer@p...> wrote:|
> Sounds like Niklaus Wirth's P-Code implementation of Pascal. A
> powerful virtual machine running (in my case) on an 8080
> A more up to date example is the OOPIC which uses an 16F877 or
> similar PIC and implements a virtual machine using external EEPROM
> for the tokenized object code.
> See www.oopic.com or the OOPIC group here on Yahoo.
How about considdering the actual use of the memory ?
Write a program that would look at the code and see how much stack
usage each part of the program, subroutines and function takes ?
Analize the code to see what uses the most memory and then tighten
the code for those parts.
Check out Don K's "RAMalizer" idea
http://www.kinzers.com/don/BX24/ I was involved (indirectly) with computer control of some processes
bay in the early 80's and with something like 2,000 total points
being monitored, 2 point took more programming than the rest of them
It may not be fair to compaire boolian logic on 1,998 points and
floating point math, square root and PID on 2 points, but you might
get the idea that concentrating on WHERE the memory is used may make
a better use of your time than on expanding where the operators are
stored. There are co-processors like the PAC-x modules from AWE
There are a dozen or so modules if you search around on the site.
The idea is that if you can isolate one or more program hogs, you can
use a co-processsor that can do those and free up space in your main