Earlier quoted context omitted.
As an FPGA guy, I want to ask this - what software programming languages, models, etc. exist to support the description of fundamentally concurrent processing, whether task-parallel, data-parallel, hybrid, or "other" (whatever that may be) that will allow for the supplanting of HDLs? I know that there's been long-standing efforts to do C-to-HDL but to my knowledge the successes of this approach have been limited to r…
Communicating Sequential Processes, perhaps? http://en.wikipedia.org/wiki/Communicating_sequential_proces... It's like Erlang, maybe not as HDL-like as you were thinking. But, I don't see why you couldn't model every little gate as a process (obviously impractical), so it theoretically could fit.
Forth Inventor Chuck Moore's $20 144 core CPU now in full production
81–90 of 100 posts
Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production
#82Well if you ever wanted to be 'out there' Chuck's processor would be a great place to start. Chuck Moore invented Forth and has been building machines that can run Forth efficiently for years. Think of it as a Turing machine that can do useful work. He has pushed the edge of computation per watt for years. That being said, I've heard him talk about this chips for years and it is great to see it finally see the light…
I found it very easy to write XC correctly. I think that the CSP/transputer idea is really the best way for most parallel programming to happen. MPI and pthreads allow more flexibility, but in most (say, 80%) of cases, that's not needed for your application.
Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production
#83Earlier quoted context omitted.
Your are focusing on classic applications only. The GA144 is so different from the classic way of computing that it requires new approaches of development. One very interesting feature of GA144 is that all 144 cores can share instructions over I/O lines. That means every core can send instructions to their neighbors who execute them directly without conversion. I/O ist fast enough. I guess it should be possible to ha…
I protyped dynamic dataflow machine which (in theory) could be scaled to hundreds of cores (corelets - something very small which does not have even jump command). In my experiments readying information to be sent accounts for hefty 30%+ of code. http://thesz.mskhug.ru/svn/hhdl/previous/HSDF/CoreletTest.hs The link above contains some simple "Hello, world!" program, in five "big instructions" which contains 21 corele…
Unfortunately I don't have time to dive into your design but AFAIK the GA144 doesn't need 30% preparation code because every instruction can be executed immediately by neighbor nodes.
That means (correct me if I am wrong) if core X has to evaluate a Forth function of say five arguments then it could pass all five arguments to its neighbors (without any preparation) by sending them the code addresses of the arguments, wait until they have finished and then use their results to compute the function result. These neighbor nodes themselves could evaluate (or delegate) subexpressions to other (free) nodes and so on.
This form of parallelization would require an efficient shared memory access. This problem needs to be solved because AFAIK I/O ports are accessible by the edge cores only. It doesn't make much sense to transport each shared data through several columns or rows of cores.
Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production
#84Earlier quoted context omitted.
OTOH, LLVM is, if anything, a register machine, so as to better map to the register machines we're implementing in hardware right now.
Yes, LLVM is a register machine and CPUs are register machines. My point really was that one shouldn't avoid stack-based languages or virtual machines because CPUs don't work that way, since some of the most used and most popular virtual machines are stack machines and get by just fine. (AFAIK both JVM and CLR are stack-based)
FORTH doesn't have one to speak of. No dynamic memory management, no garbage collection. It's about as bare-bones as you can get.
PostScript, the JVM, the CLR and so forth are all backed by runtimes with powerful functionality.
Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production
#85May be if you use 100+ of these (~14400 'computers') you can build a machine with emerging behavior, brain-like?
I knew it. The name "Moore" sounded suspicious to me immediately. Now I know his real name is Chuck Testa!!! On a more serious note, what we need much more of is not the processing speed. What we need much more of is what I call "memory processability", which roughly means "how many times per second can you process the whole memory" - or something like that. Basically how much CPU is there per RAM. Indexing is a grea…
I might be misinterpreting, but I think the phrase you're looking for is "memory bandwidth".
Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production
#86Earlier quoted context omitted.
"difficult" does not even begin to encompass the half of it. It is really cool in theory, but in reality a ridiculously difficult challenge that existing tools are in no way whatsoever up for.
Take a look at the Balsa design system: http://apt.cs.man.ac.uk/projects/tools/balsa/ My colleague uses it for research purposes and he said that it is pretty mature.
Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production
#87Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production
#88Earlier quoted context omitted.
As far as I know, the cores aren't clocked. Instead Chuck designed his own transistors using his own OKAD II VLSI tools to be efficient on the CMOS process node with switching speeds being dictated by the transistor type and interconnect electrical properties, then designed the cores so that they're only switching those transistors when they do actual work.
Ooh, awesome. Clockless computing seems like a really nifty idea, but its difficult. I imagine it might go mainstream when Moore's law finally runs out.
Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production
#89Earlier quoted context omitted.
I hesitate to divide the world into "FPGA guys" and "non-FPGA guys". It's a continuum of computing power; CPU DSP FPGA, and one moves up and down it as the task varies and technology changes. If anything defines an "FPGA guy" is choice of language. Historically FPGAs have been programmed with an HDL, such as VHDL or Verilog, because these languages are concurrent meaning they handle parallel systems. My prediction is…
As an FPGA guy, I want to ask this - what software programming languages, models, etc. exist to support the description of fundamentally concurrent processing, whether task-parallel, data-parallel, hybrid, or "other" (whatever that may be) that will allow for the supplanting of HDLs? I know that there's been long-standing efforts to do C-to-HDL but to my knowledge the successes of this approach have been limited to r…
In (synthesizable) verilog, you have tiny state machines communicating via explicit channels (clock+wires+buses), and functions that get turned into gates. A higher level language would give you ideal channels (mapping onto fixed hardware channels or synthesized to HDL). Depending on their complexity, the functions at each state-node would also be transformed to use more general blocks and intermediate states.
Re: Forth Inventor Chuck Moore's $20 144 core CPU now in full production
#90Earlier quoted context omitted.
Its worth noting that a number of popular VM's, eg, the JVM, have Forth-like stack-based instruction sets.
OTOH, LLVM is, if anything, a register machine, so as to better map to the register machines we're implementing in hardware right now.