Hi, you are right, it's an ARM3.
But the cloudx.cc project also supports AVR, MSP430 and soon a Thumb2 clone.
I'm not sure if instruction sets (or their complexity) really matter these days or in the future. There are other (multicore) challenges …
With little or no memory on the chip this just makes the "memory wall" more of a problem.
To execute an instruction the opcode and 2 operands are required and something has to be done with the result.
RISC trades CPU complexity for many, many more instructions.
Better to start with structured program statements and implement using memory blocks.
Horizontal microcode with local storage for variables is fast and reduces memory bus utilization.
ISAs have been massaged over and over for years and all this is taking a subset of a popular ISA.
I do not get the point.
I am sure they will matter because instruction set complexity is related to compiler and computational efficiency, which is ultimately related to energy efficiency.
However as you indicate the challenges of multicore operation and benefits to be derived by doing it well may be greater than those from swapping out one ISA and replacing with another.
But better to do both in an optimum manner.
There are uses for simple processors, or large sets of them, but they are not general computing ie you won't be running Word on them any time soon. A large number of real world applications need lots of data, and that means that making use of 1000 cores is pretty tricky if they all need to fetch data at the same time from 'random' locations.
Some applications can be rewritten to make use of cellular automata, or streaming, or systolic arrays or whatever in which the data moves through the processors in an ordered way so only the processors on the edge need to access memory and the rest just shift it through, transforming it as they go.
Since the early Inmos days these applications have become more widespread, eg video and audio compression/decompression can make use of this - but then there are specialised hardware implementations that do it better than a CPU anyway.
There are super-computing applications that might make use of lots of processors, but again they tend to need quite a lot of RAM per node (that is one reason the big machines use x86's and similar and not 1000 times as many tiny CPU's).
The problem remains not how to put lots of little brains on a chip, but how to make use of them in real applications.
(The original T400 transputer had 15 core instructions, and a mechanism to use the 16th to add extra ones which gradually happened over time. The instructions were all 1 byte long, with 4 bits for instruction and 4 bits for data, one instruction was used to extend the data into further nibbles. It was extremely RISC and had around 50k transistors I think, of which more than half were in the on chip RAM. I have the manual somewhere ...)
"you won't be running Word on them any time soon"
I beg to differ; a divide-and-conquer approach with a many-core CPU could work very well indeed, by passing both parallel and "systolic" tasks:
- keyboard interpreter
- mouse controls
- buffer editor
- mass storage manager
- window formatting
- font renderer
I see no reason why this couldn't be viable.
Actually, the real value in RISC is by breaking up the instructions into single cycle steps, you enable the CPU to make the maximum use of the data bus. You could also argue that you are eliminating the microcode engine. The cost is that you have more instructions in a program. The benefit is that you can more closely hone the performance of that program on simpler hardware.