On Tuesday, August 1, 2023 at 11:31:00 PM UTC-7, Christopher Lozinski wrote:
> Here are the slides for my upcoming talk "A Review of Soft Core Forth Processors".
>
>
https://pythonlinks.info/presentations/ForthPresentation.pdf
>
> I will be giving the talk at the August SVFIG meetup, and at the Stocklolm
> FPGA World conference in September.
> Your expert comments would be most appreciated.
Presenting slide shows and giving talks at conferences makes you look
like a sales clown, because this is what sales clowns do.
Nobody will ever believe that you are a programmer after they have seen
you playing the sales clown.
If you want to be a sales clown, then just promote MPE --- maybe Stephen Pelc
will eventually give you a commission --- but promoting multiple internet freebies
such as MeCrisp Ice is a waste of time because there is no commission for freebies.
Stephen Pelc has a "clean-room implementation" of the RTX-2000 on an FPGA.
You could sell that for MPE! It is a useless retro processor, but it might sell
in the Forth hobbyist market as represented by comp.lang.forth.
> The general plan is to build large numbers of MeCrips cores on an FPGA.
I assume that you mean Matthias Koch's MeCrisp-Ice processor.
There is loosely coupled parallelism (a multi-core system such as you are
describing), and then there is tightly coupled parallelism (the MiniForth).
With tightly coupled parallelism, you read and write to registers concurrently.
This is why the MiniForth was fast. It could pack up to 5 instructions into a
single 16-bit opcode and the opcode would execute in a single clock cycle.
The 5 instructions could include an instruction that read from a register and
an instruction that wrote to that same register. This is (I am told) impossible
on an FPGA because FPGA chips lack the connectivity to support multiple
instructions that can simultaneously access (read or write) one register.
I have my TOYF design posted here:
https://board.flatassembler.net/topic.php?t=21841
This is probably not possible to implement on any FPGA.
My MFX assembler did out-of-ordering. The programmer could write his
source-code as if the instructions executed sequentially, but my assembler
would rearrange the instructions to pack them into the opcodes so that
the instructions would execute concurrently but would do the same thing
as if they executed sequentially --- the assembler would pack the instructions
in such a way as to minimize how many NOP instructions had to be inserted.
Also, I wrote a simulator. The assembler would not only generate machine-code
that would run on the MiniForth, but it would also generate Forth code that
simulated this machine-code and would run on the MS-DOS host. This is
very fast! This is fast because the simulator doesn't have to decode the
opcodes at run-time, but all of the decoding is done at compile-time.
With loosely coupled parallelism you have multiple cores running concurrently,
but they can only communicate with each other through memory, and not
concurrently. So, if you have an eight-core system you need to have eight
unrelated tasks to do. This isn't useful in motion-control because you have
only one task to do, and you have to do it at high speed --- you need one fast
processor, not eight slow processors doing eight unrelated tasks.
For the most part, I think that multi-core systems are only useful if each core
does something application-specific and different from what the other cores
are doing. This seems to be how Ilya Tarasov's multi-core FPGA systems work.
This is not going to work for a general-purpose processor in which each core
is not customized for a specific task in the application, but all the cores are alike
and non-specialized. This is why I'm not interested in the Parallax Propeller
although I have been told by many people that this is true parallelism and
I should learn Propeller programming so I can be an expert on parallelism too.