Microprocessor Design (2017)

Then why does the author use a truck analogy at the start? An student with that type of background would most likely be able to understand the concepts more abstractly.

Because instructions and data share the same memory space in general? Potentially, in such a system architecture any bug or bad implementation might lead to memory leaks from the whole memory range.

Amdahl's law. The von Neumann bottleneck continues to get bigger and bigger with each iteration. We can do far more calculations in the same amount of time on a chip, due to the increasing number of transistors we can fit on them, and also improvements in the internal designs (superscalar architectures, etc). The speed of memory access however, has only been increasing at marginal rates in comparison, and now we have increasing contention for execution units in the processor to access it as we increase the number of distinct cores. Caching, prefetching, etc. have partially helped to mitigate some of the problems, but only as far as you can avoid cache misses (common in object oriented code, due to frequent pointer dereferencing). We're still at the stage, with all these technologies, that the VNB is what's preventing us from doing more in the same amount of time. Writing high-performance code is also difficult as often the hardware specializations are inaccessible to a programmer, and he has to rely on the compiler/microassembler to do the right thing. Often this means designing code in ways to suit the CPU (eg, vectorizing all your data), rather than to suit the programmers (eg, OOP).

We should really be aiming towards NUMA, many-core processors with high-speed message passing between cores, and a programming model which suits development over that kind of architecture (eg, the Actor model).

I think that there have been discussions, but everyone being on this one-big-complex-cpu-doing-everything train over the years made companies pursue financial goals rather than security. You cannot have a complex and secure CPU. That would be too expensive, so it's not a question of will-it-work, rather will-it-sell.

That's a rather closed view of history. Vector processors were the norm in supercomputers until the early 2000s, when they were killed off by general purpose CPUs like SPARC and POWER. Intel itself has made two big bets on alternative architectures--Itanium (essentially VLIW) and Xeon Phi (CMP gone insane), the former of which failed miserably, and the latter of which appears to be quietly dying.

One of the major problems with developing alternative highly-parallel architectures is that most algorithms, particularly as they are written in source code today, simply aren't parallelizable. There's only so much ILP that can be extracted, and data parallelism isn't achievable without very heavy annotation of source code. Getting high data parallelism (as GPGPU does) is sometimes possible with algorithmic rewrites, but you're talking about rewriting several portions of your code to make that happen. That's the reason NVidia is successful--they've got an offload model, so you only need to rewrite the kernels that need parallelism, and they've got the proprietary lock-in on CUDA since no one wants to rewrite that code several times. But even then, there are classes of code that can't be run on GPGPUs very well because you just don't have the necessary data parallelism.

Yay for asynchronous :D

It's honestly criminal how little attention async gets.

But absolutely disagree on massively parallel processors. What do you think your GPUs, TPUs/DPUs not to mention Tilera types are?

I think it's more the humans that aren't up to the task, or at least have not built enough conceptual infrastructure to make it feasible to program these things.

A moderate number of people can grasp the imperative "do this then that" model, which CPUs strive so hard to maintain the appearance of despite speculative and out-of-order execution. Fewer people are comfortable with "functional" style programming. Other paradigms are relegated to corners. Multithreaded programming is still a bit of a black art.

Graphics programming only manages parallelism because there's an implicit huge map of "do this to every pixel" around everything. The actual shader programming language .. is imperative, because that's what people understand.

> 4004 -> 8008 -> 8080 -> x86

The progression is more interesting than that: it's Datapoint 2200 -> 8008 -> 8080 -> x86. The Datapoint 2200 was a "programmable terminal" (really a desktop computer) that had a CPU made from TTL chips. They got Intel to make a MOS version of the processor, which was the 8008. (TI made a MOS processor for them too, beating Intel with the forgotten TMC 1795.) Because the Datapoint 2200 used serial shift-register memory, it needed to be little endian, and that's why the x86 is little endian.

Also, the marketing names make 8008 sound like an 8-bit version of the 4004, but they are really unrelated. The 4004, for instance, wasn't even von Neumann.

https://en.wikipedia.org/wiki/Datapoint_2200

If you make a living writing software, that sounds like an argument against more architectures.

The Transputer T800 was formally verified. It would also be a great candidate vor hardware isolation, with different processes running on different CPUs, linked via the Transputer's hardware channels.

https://www.cs.bris.ac.uk/~dave/transputer.html

UPDATE: T800 had 250K transistors, Skylake has 1-2 billion, so you could fit around 4K-8K T800s on the same kind of die.

So you are talking about a special purpose processor solely for the purpose of being 100% deterministic? It'll be slow, but potentially more secure than its general purpose counterparts. Which of both would be more reliable security-wise? If you put both in a single system respecting the purposes, a heterogeneous system is the result.

Rather less the same system architecture reiterated in different cpu architecture implementations (AMD, Intel), and more special purpose processors for a heterogeneous/hybrid system architecture following certain standards.

Honestly, I find buzz like this to be extremely bad taste. It is trivially simple to post links like that on HN and wait for the "ha, Intel, this is how you should have been doing things!!!1".

If this bug is really present in all chips since 1995, then where have all these people been for the last 22 years? If they're so competent about CPU design, why haven't we seen literally tens of Intel competitor startups pop up and succeed?

Although the supposedly 2016 article was in fact last updated today, and discusses the recently disclosed problems.