> Basically, it is a compiler that can generate both compiled code 
> (fast) and interpreted (small) code. The programmer can mark 
> every function that should be interpreted, and it would 
> transparently be compiled differently (into something like a 
> p code that then gets interpreted by a runtime
> engine). I found the thought intriguing.

It is an interesting idea, and of course I have been thinking about this
for years. But I could not find a clear way to do it 'right'. Problems
are:

- If you can have P-code in the PICs Flash you surely also want the
option to have P-code in the PIC EEPROM, and why not in an external
EEPROM? And why not in another external medium?

- It is not trivial to define a (P-)code that is more compact than PIC
assember for bit and byte operations.

- A two-way choice for a programmer (fast/large versus slow/compact)
seems a bit restricted, and very vague. How slow is acceptable? A factor
10 slower than normal PIC code? A factor 10000?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist