Professor David May, a leading computer scientist, has looked at producing an implementation of a simplified ARM instruction set architecture. He has started work on the project in the interests of teaching how processors work and the fundamentals of parallel programming.
Professor May revealed the project – based around the 30 or so most-useful ARM Thumb instructions – at the end of a lecture entitled "Heterogeneous processors: Why?" given at the Multicore Challenge one-day conference organized by Test and Verification Solutions Ltd. (TVS) recently and held in Bristol.
Professor May, of Bristol University and who is also CTO of XMOS Ltd.,
is still probably best known as the lead architect of the transputer, a
processor designed explicitly for ease of parallel processing.
As I expected, he provided much food for thought in his talk. I was unable to attend the conference, but thanks to TVS archiving material on YouTube I have been able to experience the presentation almost as if I had been there.
In his talk Professor May pointed out that heterogeneous multiprocessing systems have been around for a long time but he also argued for keeping systems simple and, where possible, resisting the urge to use multiple architectures, in the interests of simplicity and computational and development efficiency. "One architecture means one set of programming languages and tools," he pointed out.
The extension of that argument was that if you want heterogeneity it would be better to have it in the implementation of processor cores based on a single architecture rather than in multiple architectures, which sounds like an argument for designing CPUs, GPUs, I/O processors and radio processing units all within a single common architecture framework.
One could argue that ARM's "big-little" implementation of Cortex-A15 and Cortex-A7 processor cores falls in-line with this argument, although Professor May could not resist a little gibe at ARM asking: "Is a chip with several different ARMs heterogeneous? You could argue it is fairly heterogeneous given that it takes a 1,000-page manual to describe all the different variants."
Professor David May of Bristol University and CTO of XMOS Ltd.
@DutchUncle: personally, I design CPUs just for fun, but I do see a lot of new processors out there, with different ISAs and different architectures.
Let me be honest: I don't think that multi-core/SMP is the way to go. These two techniques explore paralellism, and have a lot of drawbacks (synchronization, lack of predicability).
There's another technique that does just about the same - superscalar.
The hardware always is inherently parallel - we have combinatory circuits feeding synchronous elements, all at the same time. What we fail to do so far is to figure out how to explore this massive parallel infrastructure into our benefit, without turning the General Purpose Computer in a specific one - meaning we can indeed explore this parallelism, but only for certain tasks.
Perhaps we are doing it all wrong. Perhaps we don't need "general purpose" registers. Perhaps we don't need stacks. We still use programming/CPU architecture (general purpose) as it was done in the early days (in late fifties).
Restricting the set of instructions has its benefits: it simplifies the design, reduces size and power consumption, while having an impact on the performance - this might pay off for more simple execution streams.
I do think we are specializing CPU too much: I don't think it makes much sense to have a CPU doing "complex" tasks like vector arithmetic, SIMD, and others. There might be a solution for this: not multi-core, but multiple specialized execution units, that can somewhat be independent of each other. This would require a new programming model though.
I think Professor May does want to build the processor on the lab bench at the register level.
He makes the point that no schoolchildren today have ever seen any form of mechanical calculator; neither slide-rule nor hand-cranked calculator nor even the three-position dialing machine for calculating the remainder to score in a darts game.
As a result first-year students have no idea about what sits between a high-level language and the 1s and 0s toggling on a digital chip's pins....to them it is simply "magic."
Modern processor architectures are so complex and full of exceptions and special cases that it would be highly wasteful of time to teach processor architecture in that context.
Why bother creating a new processor, unless the point is to build it out of 74xx NAND chips just to show that you can? Restricting oneself to a subset of the available instruction set, or being forbidden to use a particularly helpful built-in operation, was one of the tricks used by my professor in CS205 class back in the 1970s.
But in the interests of energy efficiency it is generally better to complete task in reasonable time and then put the system to sleep.
So not pointless with regard to energy consumption...or you could be doing other things.
If anyone wants a simple computer, think about: structured programs evaluate a relational expression(condition) and either continue with the next sequential or jump/branch to a target.
next is either an assignment or another relational expression.
The location of the expression and the first 2 operands and operator are all that are requied.
Dual port embedded RAM can deliver the two operands simultaneously while a second delivers the operator and next address.
I would not disagree with that.
But keeping multiprocessors coherent probably only works for a relatively small number of processors or applications where maintaining coherence is not overly burdensome.
A more scalable multiprocessing may require the adoption of incoherence..like the Internet.