To Intel's defense, there is a reason they resort to their approach of gradual improvements. In 1981, after a couple of successful iterations on their CPU, they did make a clean break with the past with iAPX 432 [1] - an entirely new 32-bit CPU designed to be programmed entirely in high-level languages. Hardly anyone seems to remember it, and for a reason: it failed, hard. Intel seems to have learned the lesson and didn't do this anymore.

[1] https://en.wikipedia.org/wiki/Intel_iAPX_432

A good point. I didn't cite it here because its implementation problems were severe and the reason it failed. Yet, I do give credit in more thorough discussions on INFOSEC history because the architecture was pretty awesome for Intel. Then, they watered that down with BiiN's i960MX. Then, even less radical (in security) Itanium. They lost hundreds of man years on the first, around a billion on second w/ Siemens, and at least $100 mil sunk into Itanium w/ HP.

Intel certainly tried to make up for their x86 monstrosity several times. They got smarter and smarter about how they did so in terms of market acceptance. A combination of engineering mistakes and foolish market choices (imho) made them pay. As you said, they learned to give customers the insecure garbage they wanted or risk extremely large losses. Links below for those interested in the specifics of their better work.

Intel i432 Capability System http://homes.cs.washington.edu/~levy/capabook/Chapter9.pdf

Intel/Siemens BiiN System (w/ i960MX manual) https://en.wikipedia.org/wiki/BiiN

Itanium Security Features http://www.intel.com/content/dam/www/public/us/en/documents/...

And then there was the i860 https://en.wikipedia.org/wiki/Intel_i860 (the original target for WinNT!), and later of course Itanium. Intel seems to have embraced the "x86 everywhere" vision much later than others (maybe 2004? http://www.anandtech.com/show/2493/4 ), only uttering the phrase in early 2008 http://www.computing.co.uk/ctg/news/1819476/intel-x86-future afaics. (Talk about awkward timing...)

Interesting, though this shouldn't be an indictment on HLAs in general, rather the iAPX 432 in particular. Same way the Mach server was only the tip of the iceberg in the sphere of microkernels.

True: the LISP machines, Wirth's Lilith w/ M-code processor, ASOS embedded Ada system, JOP embedded Java processor, and Azul Systems' Vega processors show HLA's can work just fine. Even better than competing offerings in ways. :)

Outside the mainframes, the survivors are IBM i (System/38 descendant), HP NonStop, Boeing SNS Server, BAE's STOP OS on XTS-400/500, and maybe Aesec's GEMSOS. That's not many... And B5000 blew my mind as well: so far ahead of its time then, even now somewhat, that I can't see how they came up with it given designs of the time. Must have had a time machine that gave them brief glimpses into the future of computer science or at least one real wizard on the team. Occam's Razor is clearly no fun here. ;) The System/38 architecture was also brilliantly designed in that it chose right tradeoffs to have much robustness plus being very practical. Both described here [1] in detail with others.

There are new projects copying some of the lessons learned such as Sandia Secure Processor (SSP/Score), SAFE (crash-safe.org), CHERI (Cambridge), and quite a number of academic/proprietary works. I suggested on Schneier's blog we could do what Geer thought was impossible by straight up copying the old NonStop architecture (published in detail) while swapping legacy CPU's for security-enhanced variants like above w/ extra I/O security. Five 9's, linear scaling, immunity to most attacks, and support for higher-level languages. I'll take 10! In theory, it might get down to a few grand a unit for each logical processor with careful management of development costs & sacrificing multicore for first generation. Be a nice root of trust for other systems security, administration, and recovery needs.

[1] http://homes.cs.washington.edu/~levy/capabook/index.html

[2] https://www.schneier.com/blog/archives/2014/04/dan_geer_on_h...

Btw, look at the Flex article and its links. It was some wild stuff. I'd love to see efforts to do a modern take on it with top security engineering principles used. All fitting in on SOC and cheap board, for instance.

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

May as well mention the B5500 emulator at http://retro-b5500.blogspot.ie/ .

That's pretty badass. It would be a pain to try to work with now given much of it is strange to a modern user or admin. Cool that they built it. My takeaway from Burrough's is to do much interface protection at compile time, pointers + code protection in memory during runtime, bounds-checking on arrays, simplified assembler, dedicated I/O processor/programs, and good recovery of failed components. That plus what we know from other systems would make for quite a resilient system combined with a RISC processor such as Gaisler's Leon SPARC I.P. or the Rocket RISC-V CPU.