View unanswered posts | View active topics It is currently Sun Dec 16, 2018 3:36 am



Reply to topic  [ 79 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6
 TOYF (Toy Forth) processor 
Author Message

Joined: Sun Jul 23, 2017 1:06 am
Posts: 93
BigEd wrote:
If you ever chance upon a diagram for the p2, please share! It sounds interesting. I did look at the forum thread linked earlier but didn't see what I wanted.

I agree that the P2 is interesting --- if you start a thread on the subject of the P2 I will read it!

It is conceivable that I will write code for the P2, although not very likely. There is a guy on the Parallax forum who wrote a Forth for the Propeller, but he is just value-adding to Parallax products for free --- this possibly boosts Parallax's sales of the Propeller, but all the guy gets for this is "ego-boo," and not very much of that as loyal Parallax customers will routinely say that Spin is far superior.
Realistically, processor vendors don't want third-party compilers to exist. The reason is that some customer might start complaining:
"My program was written perfectly, but it doesn't work, so there must be a bug in the hardware!"
Most of the time, a technical-support person will examine the code that supposedly demonstrates the hardware bug and discover that it is actually a software bug and the hardware is fine. This only works however, if the code is written in a language that the technical-support person understands, and a compiler that the technical-support person feels confident doesn't have any bugs.

I have no intention of ever allowing any assembler/compiler except my own to be available for the TOYF (assuming that the TOYF makes it into an FPGA).
I especially will strive to prevent an ANS-Forth compiler from being written for the TOYF. The problem here is that ANS-Forth is the Standard (with a capital 'S') and my compiler is automatically relegated to being a non-standard wanna-be. A big feature in the TOYF is that I support quotations that have access to the parent function's local variables despite the fact that the HOF (higher-order function) that was called by the parent function and is executing the quotation, has local variables of its own. Quotations have been indirectly banned in ANS-Forth by various rules, and have been explicitly banned in Forth-200x --- so, any ANS-Forth or Forth-200x compiler will generate crippled TOYF code that doesn't take advantage of the TOYF's primary feature and makes the TOYF look like a typical crude and stupid Forth processor. Note that Stephen Pelc did a "clean-room implementation" of the RTX-2000 in an FPGA that he is selling, so he is financially motivated to cripple any other Forth FPGA implementation to prevent it from having features that the RTX-2000 lacks.

Anyway, the P2 does loosely-coupled parallel processing. As interesting as this may be, it has nothing to do with tightly-coupled parallel processing.
There is no round-table access to common data in the TOYF, and there isn't going to be. The registers are common data, but they have to be read from and written to in parallel --- the three processors (A B M) can't take turns accessing the registers.

If people think that the TOYF design is dumb (everybody seems to, so far), I would prefer that they just ignore this thread (everybody has been ignoring it for many months, until just recently) rather than divert the thread into something that is interesting such as the P2 or RISC-V.


Fri Nov 09, 2018 4:14 am
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1030
Hi Hugh
Indeed, it would be good to have some other discussion threads on points arising. As you'll have noticed, this forum is rather quiet, but there are a number of people here with a great interest in CPU design, so any activity here on this thread is liable to raise some general reflections. Please don't think of it as unhelpful topic drift - to design a new CPU, it always helps to have a good understanding of existing CPUs. There are several people here who can help with glimpses of other CPUs.

You are right, and I would give the same advice, that anyone who has only negative things to say about a project is well-advised to stay away from the thread. I don't think we've seen that here, yet. What we've seen is the sort of discussion you'd get in a common room over coffee with a collection of experienced engineers. In other words, it's a forum. A forum has different dynamics than a blog. If you're seeking to write definitive descriptions of what you're doing without interactions from your readers, then maybe a good thing to do is to publish your thoughts on the web and then we can all discuss them here on anycpu - just let us know where you've published.

Cheers
Ed


Fri Nov 09, 2018 6:43 am
Profile

Joined: Tue Jan 15, 2013 10:11 am
Posts: 110
Location: Norway/Japan
Yes, a topic on the Propeller (and the new P2 variant) could be interesting. I won't add much more in this thread, just that what Hugh says about compilers/forth etc and people vs Parallax isn't really that way at all - there's a unique collaboration going on between the company and the users, different from anything I've seen elsewhere.

But that'll be for the other yet-to-come thread. There are several members of this forum with Propeller knowledge btw - more than myself, e.g. Jac, and others.


Fri Nov 09, 2018 8:23 am
Profile

Joined: Sun Jul 23, 2017 1:06 am
Posts: 93
BigEd wrote:
Hi Hugh
Indeed, it would be good to have some other discussion threads on points arising. As you'll have noticed, this forum is rather quiet, but there are a number of people here with a great interest in CPU design, so any activity here on this thread is liable to raise some general reflections. Please don't think of it as unhelpful topic drift - to design a new CPU, it always helps to have a good understanding of existing CPUs. There are several people here who can help with glimpses of other CPUs.

You are right, and I would give the same advice, that anyone who has only negative things to say about a project is well-advised to stay away from the thread. I don't think we've seen that here, yet. What we've seen is the sort of discussion you'd get in a common room over coffee with a collection of experienced engineers. In other words, it's a forum. A forum has different dynamics than a blog. If you're seeking to write definitive descriptions of what you're doing without interactions from your readers, then maybe a good thing to do is to publish your thoughts on the web and then we can all discuss them here on anycpu - just let us know where you've published.

Cheers
Ed

Well, I'm sorry if I seemed overly sensitive. It is just that a lot of people seem to want to tell me that VLIW is 1990s technology, and that it was a bad idea in the 1990s too. Typically they tell me that smart programmers use the ARM Cortex and GCC, although sometimes other processors such as the RISC-V or Propeller are mentioned. I don't want to hear it --- I'm just trying to be creative --- the TOYF really has nothing at all to do with state-of-the-art technology.

Anyway, the TOYF has very few registers. Connectivity is the major problem, even with such a small set of registers.
If you can solve the connectivity problem and get the design to route, then you can also do this twice on the same FPGA because having a dual-core system doesn't add any more connectivity issues. The only connection between the two processors would be a block of dual-port RAM, plus a parallel port that is used for the semaphore communication that prevents the processors from stepping on each other's toes.
So, there you go! Loosely-coupled parallel processing --- similar to the P2, but with only 2 cores rather than 8 --- one processor polls the I/O and processes it, and the other processor is the main-program.
The two processors don't necessarily have to be the TOYF --- you want the main-program to be the TOYF because the TOYF has support for quotations and data-structures --- the I/O handler could be something much simpler though (possibly the 65ISR-chico).

Also, I already mentioned the possible need for a coprocessor (such as a C8051) to pony up the TOYF, and I mentioned the possibility of also using this coprocessor as a sound-chip for a video-game machine. This is loosely-coupled parallel processing too --- very loosely coupled, as a UART is used for communication, rather than dual-ported RAM --- still though, you do have "true parallel" execution as the two processors are doing different things at the same time.


Fri Nov 09, 2018 8:14 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 79 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software