Microcore.
https://github.com/microCore-VHDL/microCore

Hardware pauses are how the Transputer managed Communicaing Sequential Processes (CSP). Ask to receive a message, if it was not there, the process would pause, an interrupt would call some microcode, which would allow another process to run. And now GoLang uses CSP. So here is what the Microcore has to say about pauses.

Interupt: An event which happened which was not expected by the application.

Pause: An event which did not happen, which was expected by the application..

You can read more here: Scroll down to section six, or search for "pause".
https://github.com/microCore-VHDL/microCore/blob/master/documents/uCore_overview.pdf

His CPU was recommended to me by Jim Brake.
https://github.com/jimbrake/cpu_soft_cores

Who was recommended to me by Lorum Ipsum.

So what do you think of pausing?
Are there any other Forth CPU's with pause functionality?
Thank you everyone. None of the faculty at my University seem to know anything about Forth.
Chris

On Saturday, April 8, 2023 at 7:42:29 AM UTC-7, Christopher Lozinski wrote:
> Microcore.
> https://github.com/microCore-VHDL/microCore
>
> Hardware pauses are how the Transputer managed Communicaing Sequential Processes (CSP). Ask to receive a message, if it was not there, the process would pause, an interrupt would call some microcode, which would allow another process to run. And now GoLang uses CSP. So here is what the Microcore has to say about pauses.
>
> Interupt: An event which happened which was not expected by the application.
>
> Pause: An event which did not happen, which was expected by the application.
>
> You can read more here: Scroll down to section six, or search for "pause"..
> https://github.com/microCore-VHDL/microCore/blob/master/documents/uCore_overview.pdf
>
> His CPU was recommended to me by Jim Brake.
> https://github.com/jimbrake/cpu_soft_cores
>
> Who was recommended to me by Lorum Ipsum.
>
> So what do you think of pausing?
> Are there any other Forth CPU's with pause functionality?
> Thank you everyone. None of the faculty at my University seem to know anything about Forth.
> Chris
Googling for "forth multitasking" returns this at the top: https://www.bradrodriguez.com/papers/mtasking.html

PAUSE is Forth's multitasking word. If hardware is busy, pass control to the next task in a round-robin queue. uCore's Pause uses hardware to execute a trap, which could execute PAUSE instead of explicitly coding something like BEGIN TEST WHILE PAUSE REPEAT.

Since you are investing your time in multi-processor designs, it seems to me a more valuable topic would be on-chip networking. NOCs have not had the scrutiny that ISAs have so the field has much room for growth. The low performance of on-chip networks causes applications to favor single-core or few-core platforms, so NOCs are a scalability bottleneck. If apps had more flexible networks, they could exploit more cores.

Also, RISC V is "the thing" now. If you are implementing anything else, you should have a very good reason. Even if you do, you would want your multi-core chip to support the inclusion of RISC V. Oddball cores like Forth processors would be add-ons. That makes the NOC infrastructure the first thing to look at, not the particular CPU design.

On Saturday, April 8, 2023 at 10:42:29 AM UTC-4, Christopher Lozinski wrote:
> Microcore.
> https://github.com/microCore-VHDL/microCore
>
> Hardware pauses are how the Transputer managed Communicaing Sequential Processes (CSP). Ask to receive a message, if it was not there, the process would pause, an interrupt would call some microcode, which would allow another process to run. And now GoLang uses CSP. So here is what the Microcore has to say about pauses.
>
> Interupt: An event which happened which was not expected by the application.
>
> Pause: An event which did not happen, which was expected by the application.
>
> You can read more here: Scroll down to section six, or search for "pause"..
> https://github.com/microCore-VHDL/microCore/blob/master/documents/uCore_overview.pdf
>
> His CPU was recommended to me by Jim Brake.
> https://github.com/jimbrake/cpu_soft_cores
>
> Who was recommended to me by Lorum Ipsum.
>
> So what do you think of pausing?
> Are there any other Forth CPU's with pause functionality?
> Thank you everyone. None of the faculty at my University seem to know anything about Forth.
> Chris

The name was Jim Brakefield, not Jim Brake.

The F18A, by Chuck Moore, uses the pause concept. Adjacent processors in the grid are connected by a communication port. Either processor can write to the port and either can read. If done in a specific way, the writing processor would halt until the word was read by the other processor. Likewise, a read could halt a processor, until that word was written by the other processor. It was a challenge to use productively. There were also ways to use the comm ports without pending a processor.

I worked on Transputer project using dozens of processors. The decision was to not use Occam, and not use pended communications. They used C and an IEEE protocol for comms.

One of the many short comings of the GA144 multiprocessor chip (using the F18A CPU) was the difficulties in using the interprocessor comms effectively.. I don't recall the application, but Chuck himself struggled with this comms structure. He was trying to create a general purpose routing node from an F18A and found it lacking. You might have expected it would have thought about use cases before building the chip.

But it is common in the Forth community to treat design as a playground. That sounds great, but is a very good way to end up with something that is not of much use.

If you don't know where you are going, you are not very likely to get there..

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On Saturday, April 8, 2023 at 12:13:08 PM UTC-4, Brad Eckert wrote:
> On Saturday, April 8, 2023 at 7:42:29 AM UTC-7, Christopher Lozinski wrote:
> > Microcore.
> > https://github.com/microCore-VHDL/microCore
> >
> > Hardware pauses are how the Transputer managed Communicaing Sequential Processes (CSP). Ask to receive a message, if it was not there, the process would pause, an interrupt would call some microcode, which would allow another process to run. And now GoLang uses CSP. So here is what the Microcore has to say about pauses.
> >
> > Interupt: An event which happened which was not expected by the application.
> >
> > Pause: An event which did not happen, which was expected by the application.
> >
> > You can read more here: Scroll down to section six, or search for "pause".
> > https://github.com/microCore-VHDL/microCore/blob/master/documents/uCore_overview.pdf
> >
> > His CPU was recommended to me by Jim Brake.
> > https://github.com/jimbrake/cpu_soft_cores
> >
> > Who was recommended to me by Lorum Ipsum.
> >
> > So what do you think of pausing?
> > Are there any other Forth CPU's with pause functionality?
> > Thank you everyone. None of the faculty at my University seem to know anything about Forth.
> > Chris
> Googling for "forth multitasking" returns this at the top: https://www.bradrodriguez.com/papers/mtasking.html
>
> PAUSE is Forth's multitasking word. If hardware is busy, pass control to the next task in a round-robin queue. uCore's Pause uses hardware to execute a trap, which could execute PAUSE instead of explicitly coding something like BEGIN TEST WHILE PAUSE REPEAT.
>
> Since you are investing your time in multi-processor designs, it seems to me a more valuable topic would be on-chip networking. NOCs have not had the scrutiny that ISAs have so the field has much room for growth. The low performance of on-chip networks causes applications to favor single-core or few-core platforms, so NOCs are a scalability bottleneck. If apps had more flexible networks, they could exploit more cores.
>
> Also, RISC V is "the thing" now. If you are implementing anything else, you should have a very good reason. Even if you do, you would want your multi-core chip to support the inclusion of RISC V. Oddball cores like Forth processors would be add-ons. That makes the NOC infrastructure the first thing to look at, not the particular CPU design.

Being "the thing" is not a thing. RISC V is a CPU design that has as its primary feature, the fact that it is open source and therefore free to sell. I'm not saying it is not a good architecture, I'm saying it has few significant advantages over others, such as ARM and MIPS. At least, that's not why it is used. The ARM processors have huge market penetration and visibility, while the MIPS has a significant presence in comms ASICs. But RISC-V has no royalties.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

Sorry if I got Jim Brakefield's name wrong. I just took it from the name of the repository.

So I think that there is a HUGE difference between how the Microcore does Pause, and how most Forths do pause. 
The Microcore does not have semaphores. Instead each peripheral can raise a pause exception. If the cpu tries to access a peripheral which is not ready, the peripheral issues a pause, the pauses are ORed together, the instruction is aborted and a pause instruction is put on the stack. 
 In contrast, Forth and most of the software world will read a semaphore, and then proceed or pause using the Pause word.

if you only occasionally access shared resources, no one cares. But if you frequently access shared resources, then this would be a lot faster. 

As for on chip networking. I totally agree that is a critical area. I have no idea how it should be done. What do you recommend? KISS They actually have a course here about on-chip networking. 



Why not Risc v? It is not easily accessible. Have you seen how complex the c++ language and compiler are? Forth is so much simpler. I can much more easily do whatever I want. 
A lot more fun.

-Chris

On Saturday, April 8, 2023 at 3:25:11 PM UTC-4, Christopher Lozinski wrote:
> Sorry if I got Jim Brakefield's name wrong. I just took it from the name of the repository.
>
> So I think that there is a HUGE difference between how the Microcore does Pause, and how most Forths do pause. 
The Microcore does not have semaphores. Instead each peripheral can raise a pause exception. If the cpu tries to access a peripheral which is not ready, the peripheral issues a pause, the pauses are ORed together, the instruction is aborted and a pause instruction is put on the stack. 
 In contrast, Forth and most of the software world will read a semaphore, and then proceed or pause using the Pause word.
>
> if you only occasionally access shared resources, no one cares. But if you frequently access shared resources, then this would be a lot faster. 

As for on chip networking. I totally agree that is a critical area. I have no idea how it should be done. What do you recommend? KISS They actually have a course here about on-chip networking. 



Yeah, I'm sure there's lots of ideas on NOC. It's a tough problem which is best solved in the Forth manner, by changing the problem so your solution doesn't need NOC.

The stuff I do is rapid response, real time, but using dedicated processors to the task. I don't design software that has to juggle 20 things, getting wrapped around the axle trying to keep it all moving. The CPU is only there, because when calculations are needed to be done now, but not so fast dedicated hardware is required, they can be done using software, or other logic is required that would be cumbersome in hardware.

Most engineers don't understand that the power of a CPU isn't in it's speed, because it is actually very slow compared to logic. The power of a CPU comes from the huge multiplexer in the program memory, allowing very complex logic to be implemented sequentially, rather than in parallel. So a memory, which is just lots of registers with a massive mux, is used to emulate virtually any logic you choose. An FPGA does the same thing on a much smaller level using 4, 5 or 6 input look up tables (LUTs), otherwise known as memory.

> Why not Risc v? It is not easily accessible. Have you seen how complex the c++ language and compiler are? Forth is so much simpler. I can much more easily do whatever I want. 
A lot more fun.

I didn't say no RISC V. I was responding to Brad saying, "RISC V is "the thing" now". I was responding to the idea that being "a thing" matters. It's only a thing, because it's free. But maybe I don't understand what Brad meant. Maybe he's talking about RISC V making it possible to customize a popular CPU design, rather than having to roll your own or work with rarely used devices.

I'm not at all clear on what your goals are, what the purpose of this effort is. But that's ok. It's not about me. Enjoy.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

Rick C. Said:

> The power of a CPU comes from the huge multiplexer in the program memory, allowing very complex logic to be implemented sequentially, rather than in parallel.


Wow quite eye opening. I thought of them as very diffreent worlds. Thank you.


> I'm not at all clear on what your goals are, what the purpose of this effort is.

The simple answer is that I am getting educated, and building the tools I will need for projects in the future. I am also searching for projects to do in the future. Silesia, Poland is a great place to do that. The cost of living is low. Great health care and public transport. The local university is the best in Poland in Digital Design. They have courses about network on a chip, about vision about lots of other interesting things. Good to speak Polish.

My general sense is that we can do a much better job mapping from software to hardware. So I am exploring what is possible. As just a software developer, I was severely limited in what I could imagine. Yesterday I was reading more about Occam and the Transputer. So in order to have lots of CSP’s they had a fast, hardware fast, way to switch processes. A very interesting idea to be further explored. 

The University library includes subscriptions to the commercial databases which have locked up many of the technical articles on the transputer, the lisp machine, and other interesting cpus.

Why am I here? Well there is something deeply appealing about Forth. As if aliens in another galaxy will also have Forth computers. Their own version of Chuck Moore. Anyhow I still have not fit all the pieces together into a coherent world view.

In article <98f1378b-b746-416f-bf84-0370c4d5d7d8n@googlegroups.com>,
Brad Eckert <hwfwguy@gmail.com> wrote:
<SNIP>
>PAUSE is Forth's multitasking word. If hardware is busy, pass control to the next task in a round-robin queue. uCore's Pause uses hardware to execute a trap,
>which could execute PAUSE instead of explicitly coding something like BEGIN TEST WHILE PAUSE REPEAT.

No it isn't. It is relevant to cooperative multi-tasking on a single core only.

>Also, RISC V is "the thing" now. If you are implementing anything else, you should have a very good reason. Even if you do, you would want your multi-core
>chip to support the inclusion of RISC V. Oddball cores like Forth processors would be add-ons. That makes the NOC infrastructure the first thing to look at,
>not the particular CPU design.

Yesterday (2023 april 8) the Dutch Forth Chapter presented two RiscV Forth's.
On embedded, 32 bit ,in noforth style, and the other ciforth 64 bit linux.
These are mature systems, usable for production.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -