On Sat, Feb 19, 2005 at 08:27:34PM +0100, Wouter van Ooijen wrote:
> > No reason. I took care of that by integrating a gettoken function in
> > the interpreter.
> 
> Now can I write, in your language, in a single program, both the code to
> accesses the external storage device, and the code that is to be
> translated to be P-code?

I don't think so. NPCI does a 100% translation into NPCI bytecode. I'm
saying that an arbitrary gettoken function can be written to access that
bytecode.

The interpreter accesses the external storage device.

> And what does the output look like, one hex
> file for the pic and another one for the external storage device?

A single hexfile with the NPCI bytecode. At the time I was last working
on it I had built a serial EEPROM programmer out of a 16F84 that would
program the external serial EEPROM. It also had a back debugging channel.


> 
> > Point is that you provide a mechanism and then allow the programmer
> > to choose the implementation policy. 
> 
> That is not nearly enough fir me to feel 'good'. The programmer does not
> need a choice, he needs control over then end effect. Somthing like
> 'this code should run within 100us', or 'this code must not take more
> than 3000 instructions (bytes? words?)'. What this means in terms of
> real code / interpreted code can depend on the target (for instance the
> processor speed).

Interesting point. So you want the compiler to give auto diagnostics as
to the speed/size of certain code sections?

I guess that would require some type of profiling support. That could be
added to the interpreter for the speed.

However I'm not sure if the code is isosyncronous in the interpreter,
especially if you have busy waiting.

Like I said an interesting point.

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