Resources

[PythonLinks]

There is an excellent resources section at the bottom of the README.md Having chosen social isolation, I am a bit bored, so I thought I would clean it up a bit. In a private email exchange, I mentioned the visible script tag at the end of the readme, and
@howerj replied:

That's sort of intentional, I tend to put that little bit of (mostly CSS) at the end of my markdown files so when they are converted to HTML it renders it how I like when using things like pandoc or the original markdown script. Unfortunately GitHub does not take it into account. Thanks for letting me know though.

Turns out when you read the readme.md source code there are even more links listed there, not displaying on github.

Not quite sure what I should do next.

And while I am mentioning things., I took a look at the fpga board for this, not that I am anywhere near buying one, but it does appear to be no longer available.

[howerj]

If you want, you can make a pull request with the fixed links, or you could mention them here and I could fix them.

The nexys3 board is quite old, there's no reason that it couldn't be made to work on the nexys4, although I don't have one so I wouldn't be able to help you if it goes wrong, and they're quite expensive.

[PythonLinks]

I am more than happy to clean up the links so that they are Github compatible. The best way to first engage with an open source project is with the documentation. And really you have done a brilliant job, way more docs that the lines of vhdl or json.

As for the board. Should I ever get that far, it would be so much easier to buy a board and send it to you, then to figure out myself how to upgrade an FPGA board. I am more of a software guy, than a hardware guy. Although I did use to work at Intel and NCR in manufacturing.

[howerj]

While I'm more than happy to help with the project as it is, I'm not willing to put the effort into porting this to a new platform at the moment, even if provided with the hardware. It may be as simple as updating the constraints file, or it may require some quite difficult debugging and I have other projects I am working on at the moment.

The main reason I wrote all that documentation is because it is quite difficult to find good information about meta-compilation. You might want to look into the eForth books as well.

[howerj]

That comment about meta-compilation might make sense if I linked to the documented meta-compiler: https://github.com/howerj/embed/blob/master/embed.fth.

That version, which targets a similar, but not the same, virtual machine, documents the meta-compiler.

[PythonLinks]

Thank you for that very interesting link. Let me see if I got this right.

First there was the J1 in Verilog. Then the H2 n VHDL. Similar, but a little different. H2 supports interrupts.

There is a J1 interpreter/VM over at J1eforth. As of March 10th, 2020, 186 lines of C code, last updated March 27, 2015.

And you have a H2 interpreter/VM/ 267 lines of code. Most of the files over there are from 16 months ago, although you did update the embed.1 in January. And it has an embed.c file from 15 months ago.

But then on forth-cpu, you have embed.c, embed.fth, and h2.c. Your forth-cpu embed.c file was last updated 2 months ago. Those are your most recently updated files. So what is the difference between the two embed.c files?

And then you have the H2.c file. 2616 lines of code. It is an assembler/compiler a simulator, a disassembler, and a debugger. That is a mouth full. I sm just starting to look at that. Maybe good to break it up into smaller files.

You documented the H2 so carefully to support the Meta Compiler. Whatever the reason, from my perspective, your project is just so much more accessible than the J1. Somehow with the J1, with less documentation, it was a bit opaque to me.

Not asking you to do the following, but here are some thoughts. So maybe from an introduction perspective, the first thing that is needed are all the background materials. Then links to all of the projects, then an index into what the different files are.

And then there are some obvious questions. There are so many stack machines, why does everyone jump on the J1 architecture. What are the alternatives, and why were they rejected?

How does your C simulator differ from the J1 C simulator/VM? How does your C simulator/VM differ from the H2? What is the difference between your two embed.c files?

Thank you for estimate of the number of cores. Somehow on the J1, I always go the sense that one could only have 1 on an FPGA. Maybe they were targeting low end FPGAs.

Anyhow this is all very interesting. I keep reading and pealing off layers of the onion.

I never quite know what I am going to do next, but my guess is take a closer look at the embed.c file over the forth-cpu page. And then add lots of comments. I think that is the easiest way for me to really understand your cpu.

The file dates indicate that your attention is more on the tools than the FPGA chip. Maybe that works well for both of us. You will get someone reviewing that code and making comments. I will get someone engaged in the process.

I am curious why you built the H2 and its tools? What motivates you?

Thank you for all of your answers. Most appreciated.

[howerj]

So the history of this project and it's tool chain is quite complicated.

Originally there was the H2 CPU, and an assembler written in perl. I then wrote a compiler for a Forth like language in C that targeted the H2 as the perl assembler was not up to scratch. Using this cross-compiler I then wrote and adapted an eForth system for the target. I then thought that this would make quite a nice little 16-bit Forth system for a computer, so I took the H2 simulator and the image that ran on it and turned that into the 'embed' project - the 'embed' project was meant to be a small VM that ran on a microcontroller, or was embedded in a game, hence the name. That project was actively developed separately from this one for quite a while.

Eventually the 'embed' project became self-hosting, it could create new images without the forth like cross compiler. However, the 'embed' project VM and the H2 VM and FPGA had diverged at this point. The images targeting the 'embed' project would not run on the H2 and vice versa.

Eventually I decided that this was silly, I should make an effort to make the 'embed' VM similar as possible to the H2 VM/FPGA so that the H2 system could become self-hosting. It is currently about half-way through that redesign. The 'embed' eForth image and VM is used to cross compile an image for the H2, the original H2 cross-compiler having been removed from 'h2.c'.

The documentation for the toolchain needs cleaning up, but the toolchain itself needs improving upon. I do not have time to do this at the moment, but I would like to do it myself one day. The toolchain is however usable for application development.

My motivation is purely because I find this interesting and nothing more.

I'd have to remind myself of the differences between the H2 and the embed CPUs, but the main ones are that the 'embed' CPU can do things that are not possible or easy to do in hardware - like write to disk in a single instruction or index into the stack like it was an array. As I said, I have been slowly making the 'embed' VM behave more like the H2 CPU, so that eventually I will remove 'embed.c' from the 'forth-cpu' project. There is a branch in the 'embed' project called 'h2' where this was going on.

[PythonLinks]

Thank you for that excellent information. It is the nature of exploration that it does not take a straight path.

Your documentation in the file embed.fth is also off the charts awesome.

I looked at the GitHub repository for the J1, the readme file was only a few lines long. No wonder this project looked more welcoming.

I am not sure where I am going, but the embed project looks like where I should be. It is only 200 lines of C code. It is so close to what I need.

But I also need to be as close to the hardware as possible. I quite agree with you that we should merge the two projects. We should get rid of indexing the stack as an array. And we should replace disk access in a single call with whatever the H2 compatible thing would be. Any other such changes needed?

Those would be two great projects for me. I can do them. They are useful to you. They bring the embed.c VM closer to the hardware. They engage you. They educate me.

So thank you for the pointer to that other branch.

Again I am not quite sure what I am going to do, but that looks like a useful direction. What do you think? Does that sound useful to you?

[howerj]

If you find it useful, you should do it. I'm going to close this issue.