There is another "dead" (but not really) language called XPL-0 you might
want to look at:
http://www.piclist.com/language/xpl0

Olin might like it since it's based on Pascal. The I2L interpreter for it
could be adapted to your MicroPascal system if you ever wanted to interpret
rather than compile.

---
James.
 
 

> -----Original Message-----
> From: piclist-bounces@mit.edu 
> [mailto:piclist-bounces@mit.edu] On Behalf Of Byron A Jeff
> Sent: 2005 Feb 20, Sun 09:02
> To: Microcontroller discussion list - Public.
> Subject: Re: [EE] Languages, was Bug in Microchip mcc18 std library?
> 
> On Sun, Feb 20, 2005 at 03:51:39AM -0000, Sergio Masci wrote:
> > 
> > ----- Original Message -----
> > From: Byron A Jeff <byron@cc.gatech.edu>
> > To: Microcontroller discussion list - Public. <piclist@mit.edu>
> > Sent: Saturday, February 19, 2005 6:47 PM
> > Subject: Re: [EE] Languages, was Bug in Microchip mcc18 std library?
> > 
> > 
> > > On Sat, Feb 19, 2005 at 03:14:10PM +0100, Wouter van Ooijen wrote:
> > > > > 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.
> > >
> > > As have I. My NPCI compiler has been stalled the last 4 
> years or so.
> > > It's built around this concept.
> 
> That's not exactly right. The NPCI compiler only generates 
> interpreted bytecode. However it has a call mechanism where 
> it can call native code that's attached to the interpreter.
> 
> Theoretically a backend could be produced that generates 
> threaded or natively compiled code in addition to the 
> bytecode. I deliberatly separated the backend from the parser 
> so that different code generators could be produced.
> 
> [SNIP]
> 
> > Byron you should persevere. Knowledge and experience are 
> good goals in 
> > their own right.
> 
> It's not a dead project, just dormant. There are higher 
> priority things going on right now, like finally finishing my 
> dissertation.
> 
> Also NPCI isn't just a research project. It's purpose was and 
> still is to have a convenient language for coding up projects. 
> 
> > Also here's another: PICs are cheap, you can easiliy pack 
> several on a 
> > small board for very little cost, if you have a compiler that can 
> > generate code that can be executed from an EXTERNAL source you have 
> > the potential to build a system that can pass sections of 
> code between 
> > processors. A big program with a pool of processors executing 
> > different parts, possibly modifying sections and passing 
> them on for further processing, that's a very interesting project.
> 
> Interesting but very dangerous. Self modifying code lends 
> itself to virtually undebuggable errors.
> 
> Thanks for the encouragement.
> 
> BTW if anyone is interested in working on NPCI, let me know. 
> You can find a language overview here:
> 
> http://www.finitesite.com/d3jsys/README-NPCI.html
> 
> BAJ
> --
> http://www.piclist.com PIC/SX FAQ & list archive View/change 
> your membership options at 
> http://mailman.mit.edu/mailman/listinfo/piclist
> 


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