IA-64 (https://en.wikipedia.org/wiki/IA-64#Architecture) already exists, with its explicitly parallel instruction set, which leaves branch prediction and speculative execution up to the software. So you can still get many of the performance benefits, but it's under control of the software, giving a lot more flexibility for being able to mitigate or eliminate these kinds of issues.
I think that it was probably introduced ahead of its time, and targeted at the wrong markets, but it's kind of sad that with the Spectre vulnerabilities, we don't have any way of comprehensively addressing it in software without jumping through a lot of hoops and applying microcode updates.
Unfortunately, from a security perspective, moving those things to software doesn't make the vulnerability go away. You can have the same vulnerabilities in your software implementation.
From a performance perspective, we have no general solution to parallelizing a serial program. GPUs used to be VLIW. AMD switched from VLIW-5 to VLIW-4 because the average width was only ~3.5 (Nvidia had switched from VLIW to SIMD long before this). Today, Nvidia and AMD both use a MIMD threaded approach to execute on SIMD units.
Later-generation Itanium chips wound up including branch predictors and speculative execution. From what I understand, under the hood, they were normal RISC-style processors (like all the x86 micro-arch are today). Just ignore the VLIW and run one set at a time serially with the ILP hardware optimizing as it goes.
In today's programs, the programmer specifies data-level parallelism where possible (and if necessary, re-adjusts the code so the compiler heuristics recognize it as optimizable). The compiler then tries its best to detect the parallel data and use SIMD and organize instructions so that the parallelizable ones are closer together (so they fit in the CPU reorder buffer). When they hit the CPU, it examines the code as it runs to optimize speculative execution and uses the reorder buffer to make efficient use of its computation units (load, store, ALU, FPU, SIMD, etc). You move from explicit to implicit-ish (you know that putting similar instructions will optimize in all modern processors), but don't have the drawbacks of noop code bloat or having to compile different code when someone changes from VLIW-2 to VLIW-3 code.
Can you elaborate on how the halting problem relates to the IA-64 architecture?
In the context of IA-64, that means that generally, the compiler will not be able to determine when it's save to use parallelism. We can only program it to use parallelism in a bunch of special cases for which we think it will be safe.
Given that simias originally asked for a simpler platform that we can trust in more, this seems to be a pretty strong argument that IA-64 is not that architecture.
"Leaves branch prediction and speculative execution up to the software" means that in practice you need to either use the Intel compilers or hand-optimise your software to get the benefits, while simply recompiling your legacy software with GCC or LLVM ends up being disappointingly slow.
Intel could have solved this problem by contributing to GCC and LLVM instead of keeping their optimizations proprietary. Then they would also be more easily auditable as well.
There were no magic secret optimizations to release. It just straight up did not work. They had to add back dynamic branch prediction, and even then the load store latency was such trash that they had to put ginormous L3 caches on it to get even close to reasonable performance.
Yeah, compilers today are no better. We found the limits of statically scheduled parallelism pretty fast. On code that uses static scheduling, a modern OoO processor can easily duplicate what IA64 was capable of (and a pipelined loop using AVX will utterly smoke it), while being far better at all the stuff IA64 failed at.
I remember going to a corporate presentation by Intel about the revolutionary CPU architecture. They had to turn the machine off because the cooling fan was making so much noise we couldn't hear the speaker.
And this at precisely the wrong moment in history, as mobile devices, with their stringent power consumption constraints, were becoming popular.
In particular, you end up losing the ability to avoid stalling on cache misses, and the memory wall becomes an increasingly gigantic problem even as Moore's Law progresses.
We don't need to give up on performance, even with low-performance RISC-V chips. What we need is a new architecture which takes advantage of low-speed multicore processors. If it is possible to produce thousand-core RISC-V chips [1] then any core could be assigned a single thread - which implies that there is no need for a complex multitasking OS.
[1] Towards Thousand-Core RISC-V Shared Memory Systems (PDF)
https://riscv.org/wp-content/uploads/2016/11/Wed1000-Thousan...
What would have been the right ones?
PS3 with Cell would have been a failure had Sony not eventually caved in, and released a PS3 SDK that made most of the work Sony was initially expecting devs to do, regarding low level programming.
That work became PhyreEngine.
That's the real problem with an open platform, whether it's about hardware or about software. To get enough funding, support, and manpower an open secure platform initiative would have to get entangled with global players that simply do not have the ultimate privacy and security of all citizens in mind. It's primarily a political issue.
"Browsing the web" is not likely to become a task that can satisfy high security requirements ever again. Too much cruft gets added to browsers faster than it can be thoroughly audited.
If you need absolutely no CPU bugs (including bad design decisions "working as intended"), take a well-understood, possibly older design like 680x0 or MIPS and run it on an FPGA.
Single-thread performance would suffer, though, unless you're ready to pay quite a lot. And it's still hugely important in many cases.
I used a couple of Single Board Computers as my main computers for a while a couple of years back and it was really quite painful. Especially web browsing.
Would you consider installing and running dozens of random untrusted 3rd party applications every day on your real OS even if they were (somewhat poorly) sandboxed? Because that's what the modern web is like.
I wouldn't mind opting-in to additional "interactive" features for webapps that I want to trust but having everybody (including 3rd parties of 3rd parties of the website I'm browsing) run code on my computer when I'm on some random webpage is just insane when you take a minute to think about it.
Gmail or Facebook aren't the problem. People could be convinced to use desktop apps for them fairly easily (just like they do on their phones). The issue is all the other one-off apps. Users can't be bothered to go and download some random app, so the company runs that app in the browser. You simply cannot fight that level of market pressure.
[2] http://www.tomshardware.com/news/big-tech-players-risc-v-arc...
Lots of issues are down to market competition, lies and spec distortion; also double driver games (see the pre vulkan era).
And since it's ARM, it's at least half-open.
Cloud providers will be interested - slower cpu's = more money, plus selling the cloud as a more secure option to your data center.
And once you have a cpu that with a hardware switch can become more secure but slower, maybe there's a decent enough niche somewhere.
What do you mean by that?
China has Loongson also MIPS.
As you said, 99% people don't care about security. It's hard enough to get people to use ddg over google, making them use open source processor thats likely slower and costlier would be practically impossible.
The problem of course is that it's probably a very niche market at the moment. Most people probably don't really understand what's at stake and might not even care either way. As such I don't expect that people could manufacture open CPUs and sell them at a reasonable price. So you'd end up with overpriced, under-powered CPUs which won't drive adoption.
I can't imagine such a project being successful if it's not backed by a big company or a government. I kind of wish the European Union would try its hand at it, after all computing is absolutely critical these days (and it's only going to get more critical as time passes) yet we're completely dependent on american and chinese companies to provide us with CPUs. If the EU thought that Galileo was worthwhile to have our own positioning system certainly it also makes sense to have our own CPUs for critical tasks?