Sergio Masci wrote:

>>> The only real problem that I can see with this is the relatively huge
>>> overhead of providing an interpreter. For a small device like a PIC I
>>> think that the net gain would be small and cost considerable effort.
>>
>> I also thought what Wouter wrote: that possibly the net gain is not that
>> big, with today's good optimizing compilers. Anyway, it would be something
>> for the bigger processors.
> 
> I'm sorry but I'm a bit confused. Are you saying I've missed something?

Nope. I just wanted to express (probably did that a tad clumsily) that I
agree with you and Wouter in that the net gain possibly would be small.


>> Or where the goal can be controlled, by function (or file).
> 
> "optimise for efficiency" and "optimise for size" tend to work against each.
> Allowing the user too much control over which functions are optimised in which
> way would probably end up generating executables that are not optimised in
> either way (result is both slow and big).

Hm... you're the compiler writer :)  But from a user's perspective, this
would probably be quite desirable -- if possible. 


> Forget p-code. p-code is stack based and uses a dynamic runtime stack. 

It's as Wouter said: I didn't really think of "real" p code. I don't know
"real" p code from the inside. I took John Payson's original idea and
purported it here, and I used his original use of p code as anything where
code is stored in some compressed form, in tokens. Maybe "token code" would
be better...

It also occurred to me, as you said, that the static call stack of PIC
compilers is a real problem for all this. It is a problem for the
interpreter, and it is a problem for calling back and forth between
interpreted and compiled code.

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