Merging Embed.c and H2.c about forth-cpu HOT 11 CLOSED

Your project really is beautifully documented. Quite impressive.

The only thing which was not clear was the difference between embed.c, and H2.c

I now understand that embed.c is a VM for the forth meta compiler. H2.c contains a number of different sections, one of which is a simulator/debugger for the whole board.

from forth-cpu.

So H2.c is really a simulator for the nexys board. So maybe less confusing if it were called nexys.c

from forth-cpu.

The only thing which was not clear was the difference between embed.c, and H2.c

I have replied in the other issue you have opened about this, eventually I would like to remove 'embed.c', the toolchain is still slightly in flux.

You might want to put your changes on a branch within your forked of the repository, but I won't be accepting any changes to the toolchain (unless you find an issue). This is because one of the things I want to do is change the toolchain.

from forth-cpu.

For those who are new here, h2.c includes an emulator of the Nexsys board running the H2 cpus. Embed.c, is just the H2 CPU running as a VM. There is a Forth cross compiler running on Embed.c which generates the forth image for the H2 FPGA to run.

They really need to be merged. Then the Nexus emulator and the Nexus board could run the cross compiler, it would become a native compiler.

Historically the two diverged. Embed.c can access the stack as an array, the H2 can’t do that. Embed.c directly calls the unix file system and io, the H2 can’t do that. If you look at the cases 25-30 in embed.c, they all run on the OS, not on the board. 25-27 make OS calls. 28 does array access into the stack.

So I do have written up definitions of the variables in embed.c One more proof read and they should be ready to go. You said you would not accept changes to the tool chain. How about changes to embed.c? Should I add the variable definitions tot the top of forth-cpu/embed.c. Would you accept a pull request?

And really there need to be two versions, selected with an #ifdef. One that is H2 compatible. The other that is optimized for C.

We need a file system for the H2. Does the Nexsys board include a Flash Ram? Is their a file system written in Forth which is compatible with your version of Forth?

And I can imagine extending embed.c to support many H2 cores.
I do not know of any multi-core forth VMs.
One for multi-core computers, one for FPGA compatibility. The multicore version, any core could talk to any core, maybe using the GoLang concurrency primitives. The FPGA version would be based on a grid of cooperating H2 cpus.

from forth-cpu.

Embed.c variable definitions.

STK stack size

The basic data structure is called h.
It has
rs return stack
vs data (value?) stack
pc Program counter
rp return pointer
sp data stack pointer
cpu, data about the cpu.
cpu &2 is True if interrupts are enabled.

m_t memory top
s_t return stack top
d_t data stack Top

t Top of stack value

m is program memory
instruction is the current instruction.
l is the number of instructions in the program file.
Opt is just a flag, as to whether
to run cases 25 -30 which require a computer, not the FPGA platform, nor emulator.

Case 25 -30 are OS based calls.

delta is used to increment or decrement the stack and data pointers based on the opcode.

from forth-cpu.

Hello again.

Thank you once again for this excellent project. H2, Nexsys emulator, H2 emulator.

I have been off learning Forth, and trying out different Forths. All looks quite doable.

I looked at other cpus, but came back to this one. I looked at other Forths, but also returned to this one. Interesting.

I think that the biggest block for me, is merging embed.c with H2.c. I did not hear back from you, so I assume that is not your top priority. Understandable. But I am not sufficiently comfortable to proceed without your guidance. So I am not quite sure what to do next.

from forth-cpu.

It's up to you what you want to do next, I think we have different goals for my project. As I said, I'm not really working on this one at the moment as I am busy doing other things. It might be a little too much work for you to do that at the moment without understanding the meta-compiler and the CPU, and the embed project in the detail that I know it.

What is your actual end goal? I don't have any desire to support a multi-core Forth FPGA, if you want do that on your fork, you should go right ahead, but it won't be merge back into this project.

from forth-cpu.

It works.
Of the 4 Forths I tried today, only 2 worked. This is one of the two.
Thank you.
And I am also really happy that I chose this one, the c code has all kinds of details realistically modeling a real circuit.

from forth-cpu.

from forth-cpu.

My central interest lies is in building a high level cpu on a tiny core.

Ok. Sounds good. What do you actually mean by 'high level' CPU. The H2 isn't a 'high level' CPU.

I think that we can both agree that merging embed.c and H2.c is important for self-hosting.

I agree that I should do that eventually, which may be years from now, I do not agree that this is something that is preventing you from doing what you want to do.

I am interested in multi-tasking. I read your link to the reference page on multi-tasking.

The multi-tasking referenced in this project is a bit different from what you want to achieve with a multi-core system.

I am also interested in a test suite. Probably also of interest to you. I was very glad to see that embed.c does out of bounds checks on memory access.

Ok.

I am also interested in memory management. Mainstream cpus have a lot of circuits for memory management. C offers malloc and free. Many languages do garbage collection, and object databases offer persistence.

Mainstream CPUs offer nothing for memory management? They have an MMU, and some have a notion of a stack, but that's it. I also do not see what garbage collection has to do with this CPU, nor how object databases have anything to do with this project.

Hopefully some of these topics are also of interest to you. We will see what happens when you return to this project. In the meantime, I will do my best not to bother you. Eventually I will probably fork the project, but we are a very long way from there right now.

This project is exactly how I want it for now. If you find it useful, use it, but this issue and the others are not actually relevant to my project, nor are they relevant to what you might want to do with it. I suggest you put the issues you've raised against your fork of the project if possible.

from forth-cpu.

from forth-cpu.