After completing the NAND game I've developed a basic competency in the Hack computer's architecture and assembly language. See https://en.wikipedia.org/wiki/Hack_computer for an overview.

It's an interesting computer architecture because it is Von Neumann, but partitions memory into a program section and a data section. This is because the load A immediate instruction assumes zero for the most significant bit to allow packing a literal into a 16 bit instruction. But that limits data pointers to values below 0x8000. Conversely any instruction which creates a program counter value assumes 1 for that bit, so all code must reside above 0x7fff. The designers assumed programs are written to a ROM mapped to high memory. Basically like a 1980s video game machine.

It's such a crude architecture that creating a VM was the first order of business for its creators. But they chose a Java-like programming language. This got me thinking about how to create a Forth implementation, and I realized it would be difficult because it looks like data structures can't be built in program memory. Indeed the assembler reference doesn't mention directives for byte, word, or string constants. Everything is done via load immediate.

This is a big problem for a Forth implementation because you would need these to build the Forth dictionary for built-in words, and building in RAM at startup would be a massive headache. Granted this is an educational architecture, so its limitations are not something you would see in many real world systems.

But this made me wonder, are their real world architectures that are unable to host a Forth system? It would seem like any Harvard architecture might have a problem due to the need to construct the dictionary.

I am aware that Dr. Brad Rodriguez has at least one CamelForth running on a Harvard architecture, but I'm pressed for time at the moment, so I can't give you a link.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

That was enough info to find this:
https://www.bradrodriguez.com/papers/moving7.htm

He had the issues I thought about and a few more. To work around the issues he physically modified the board so some memory was mapped to both code and data space! He also couldn't add new words because the 8051 can't write to its own program space.

So I guess the bottom line is that my instincts were correct, a Harvard like architecture will have issues with Forth.

That's an interesting architecture. I don't think the fact that data and program memories are segregated is a show-stopper, as pointers in RAM can be pointers to other RAM locations or to ROM locations (eg. you can load a ROM pointer from RAM and then JMP to it). You won't be able to make new CODE words, but if the core Forths words are all in ROM (and these would all have to be code words, I would think), you should be able to make a lot of Forth work. I could also imagine a token-threaded forth where the token sequence for a new word is in data RAM.

The limiting issue I see with this processor is that there is no way to get the current value in the PC onto the data bus. While all of the instructions needed for creating a data stack in RAM are there, there is no way to create a call/return stack. This processor doesn't have a return mechanism in general and can't even do the self-modifying code tricks used on ancient computers without hardware return stacks.

If defining new code words is disallowed and everything is written using only the Forth words in ROM, you might? be able to get it to work? (not entirely sure here). You'd need to keep track of "return" addresses separately using your own stack. Conveniently, the most significant bit could be used to determine if a pointer points to a RAM word or a ROM word, as the ROM words will all need to be CODE words and will need to be JMPed to while the RAM words will all need to use the inner interpreter. I would need to use more brain power than is currently available to figure out how create/does would work.

Building the initial dictionary for the ROM words would be painful.

I'm sure I'm missing something - what's the fatal flaw?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Well I haven't posted here on 6502.org often in the past few years. As a consequence I lost my post.

I think you'd have to classify the PIC16 family as a "Turing Complete" instruction set architecture. Therefore, although it could be wildly inefficient, I would think that there is an implementation for a Forth interpreter that can be developed. It may require that both the program and data for the Forth program be implemented in external serial memory devices. It would require the development a custom instruction set that a PIC-based interpreter would use to implement the Forth primitives. I also think that even the small internal data memory of a PIC16C5x should be sufficient to implement all of the standard Forth interpreter registers that Brad R. describes.

Just to be clear, I don't think this is an ideal means for a Forth interpreter, but I do think it is feasible. The implementation would essentially would utilize the PIC16 program space to implement the interpreter for the Forth VM, and the data space would provide the Forth VM working registers. A simple I2C or SPI serial RAM, like those available from Microchip, or FRAM / MRAM SPI devices easily provide 64kB of merged program / data space.

I do agree that within the Harvard architecture of the PIC16 family it would be fairly difficult to implement a Forth VM if no external von Neumann memory devices were used to hold the Forth program and data.

Thoughts?

_________________
Michael A.

The nand2tetris course achieves function calls/returns for this processor using a "virtual machine translator" which generates machine code from bytecode. The bytecode for a function call translates to machine code which pushes the correct return address for the call site to the software stack before jumping to the function address. Here's a screenshot from the course material (captured from the material for project 7 here: https://www.nand2tetris.org/course.) The nandgame (https://nandgame.com/) achieves a similar outcome via a macro assembler and macros which generate the necessary code at function call sites to 'manually' push the return address to a software stack.

Machine code to populate data structures in RAM, similarly can be generated by the virtual machine translator or macro assembler and I woutld think these approaches provide an adequate foundation for creating a Forth interpreter. Of course a true compiler that can run on this architecture, for any language will require some means to move data from RAM into program memory.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

As David Wheeler supposedly remarked, any problem in computer science can be solved with another layer of indirection

…except for the problem of too many layers of indirection.

@All, thanks for the replies. Based upon the responses and thinking about it more. If you built a high level language that compiled to Hack assembly you could probably solve most of the thorny problems. For example a series of load A immediate instructions followed by a store in RAM could build the dictionary pointing back to code addresses in high memory. It would be inefficient because all that code would be wasted after initialization and reduce available RAM, but it could work. The two stacks are easy to implement in software, but they would also be slow.

So I think the answer is that such an architecture could host Forth, but it would be a bad choice to do it.

Adding another ROM memory mapped into data space would probably be a huge win for such an endeavor because it would eliminate the dictionary initialization problem.

You could perhaps split the initialisation application from the runtime application.

Edit : in the case of loading, perhaps less so in the case of ROM code.

I feel for you, Garth. I recently started using the PIC32 and it really seems like an upgrade over what came before it. It comes in DIP if that's of interest to you. It was very easy to set up and start working on Windows. 64K RAM, 256K flash, and single-cycle 32-bit CPU at 50MHz is pretty awesome. You might want to check it out if you are open to a new chip.

If all primitives are in 'CODE' space and compounds are in 'DATA' space, no problem.
PS. primitives does machine code, compounds does references