You might consider taking the posts on this topic and writing a book. It would be very useful to people 1)Building a stack machine, 2) building a compiler especially with bison. I would have found it useful for my work.

It is one of the things I've thought of - Especially by taking a relatively simple language and providing the steps to go from creating a grammar, to parsing to code generation... then to interpretation - and showing the interaction between the code generation and the interpretation (almost need the interpreter before the code generator as in our case).

May still try that as a E-book or a blog series (what I have now would need a lot of cleanup, improvement in the data structures, symbol tables, and maybe even adding data structures). It would be introductory only, as the topic is actually quite large and there are several 300+ page books on the subjects (Aho and Ullman has done an entire series). There are also several that could be done with the LLVM compiler construction base, which aims at producing retargetable compilers (haven't used it yet) which came out just a couple of years ago. One of the known limitations of LR(1) parser generators (like Bison is basically) is that it is harder to get error handling right. It is easy to say "parser error at line #" but to say WHY it is an error, to make correction suggestions, and recover to continue looking for more errors is much harder. Bison has extensions to make it easier, but it also starts taking it out of the LR(1) grammar to do so. Complex grammars (even GCC) have been migrating from an LR(1) parser to an LL(1) parser (this uses recursive decent instead of parse tables) because it makes the context of an error MUCH easier to handle. Its just that LL(1) parser generators have not been generally available (they exist, but are rather difficult to use, but things are improving - I believe that is how LLVM works, but I'm not sure). One thing I will need is to get a newer book ("Flex and Bison" from O'Rilly). The new stuff is hard to follow from the reference manual (which is on line by the way).

I remember one of the early Pascal books - I learned a lot about both the Pascal compiler/interpreter (I was the maintainer while a senior) was at the end of the book... It included a "tiny Pascal" with the P-code interpreter. Another was the Concurrent Pascal book that added extensions (~1975 by Per Brinch Hanson) to turn Pascal into a system implementation language - it too included a lot of the compiler, though mostly it had what Microsoft now calls "managed software" for creating a "near-realtime" (as long as you aren't trying to do hard realtime) operating systems and utilities (one of which was the compiler...).

The interpreter itself was for a PDP-11/45, and turned a 16 bit CPU (with 16 bit addressing), with 18 bit hardware address into a threaded code machine with 256k addressability. As I recall, the interpreter itself was fairly small - 8-12K or so.

1 members found this post helpful.

I think I am going to take the week off between Christmas and New Years and do something else. Probably some electronics and have to help out an elderly lady with house repairs. I will get a kit for a radio that operates around 49 MHz as well as I have an oscillator to try to test for repeat-ability and temperature stability.

Have fun.

I'm going to think about the data structures, and (if my wife lets me get to the computer) think about adding experiments with local variables. Might add a bit to the stack machine (a block transfer would be useful).

Merry Christmas Jesse. One thing about errors in code is that you really get to know what you wrote. The code is becoming like an old friend. The more I look at it the better I know it.

Same to you.

Just wait until you are away from it for a couple of months... and then try to fix a bug....

It is what taught me to try and document things better...

I think I am going to go all the way and include a real time clock with coin battery backup and a mass storage USB port running FAT32 file system.

Depending on how it is used, that will call for a kernel running too - device drivers, buffers, applications, and filesystem. Possibly two - one for the FAT32, and one for flash and updates, though that second one might be optional.

The real time clock maintains itself and is accessed over I2C bus. There is only one program running - the interpreter. File I/O through the FAT system is also through the interpreter.

The main issue is that unless you use programmed I/O on the USB, you now have interrupts (or a huge amount of spin lock delay loops waiting for the data). It also means that unless you have interrupts, the interpreter will stop until the file system activity and I/O are completed - per action, thus introducing a rather long delay for any responses.

It also means that the filesystem support, and USB support have to implemented locally - along with the debugging.

It isn't impossible... just time consuming. It usually means the interpreter becomes the operating system.

I have since changed my mind and will use a SD Card instead of USB port. The only USB port will be a serial I/O port to the PC and is handled by an FTDI chip with RX, TX, CTS and RTS. Any interrupts will be built into the interpreter with no user interaction except through PRINT and INPUT statements through the interpreter.

Microchip has Linux Ubuntu for MPLABX (their IDE) and Ubuntu for XC32 (their C compiler). The C compiler is C++/C.

Nice. At least everything should be available for use.

I've made some data structure changes - it simplified the grammar action routines considerably, but did make the code walking a bit trickier (meaning: I haven't debugged it yet .

1 members found this post helpful.

Considering ARM CORTEX M3(!?) You might want to consider ARMv7 for your stack machine as it is a 32 bit GPR RISC system. For information see: http://www.youtube.com/watch?v=7LqPJGnBPMM