Real mode, Mod R/M and SIB byte encoding weirdness, REX prefixes, 80-bit floats, parity flag, hard-wired registers for shifts/multiplies/divisions, builtin CRC32 over the wrong polynomial, Pascal calling convention support, binary-coded decimal, high halves of 16-bit registers, MMX overlap with x87 floating point, etc. etc.

This is completely off topic, but I've seen things like the "^W^W" a few times before, and I don't know what it means.

Is this a weird encoding mismatch thing? is it from some editor/system that people instinctively type? Is it from some other forum which has a strange markup syntax for something?

'^W' is what would appear instead if you weren't in a readline/emacs editor, but instead a dumb line terminal. Thus, leaving '^W' behind makes it look like you didn't realize what you just corrected is still visible.

It's a joke. I've now explained and ruined it.

I've used Linux daily for like 15 years now, and I know about control characters, but since I never really used emacs (or readline beyond the copy+pasted command here or there) I just completely missed the meaning.

This readline behavior follows a Unix tty driver. I'm not sure off the top of my head which one introduced it. I don't think it was on xenix but am pretty sure some 4.x bsd had it.

In Unix line editors it is traditionally used to mean 'erase the previous word'.

See also documentation for ASCII (http://www.robelle.com/smugbook/ascii.html for example) for origins of ^C, ^D, ^S, etc.

The funniest part of Itanium for me was that it was supposedly helpful to compilers. Yet the compiler people I knew did not like to use the "helpful" parts of the ISA. The loop unrolling stuff got in the way of software pipelining, for example.

Mill is an example of a processor that's actually helpful to compilers, because its design is being led by an actual compiler person.

Somewhere around 3 disciplines? Nobody's using your system.

Such was the paradoxical brilliance of SQL and Excel. By limiting knowledge scope, they greatly enhanced utilization (and thereby utility).

Well that kinda was the concept - but they greatly underestimated the difficulty of producing a "sufficiently smart compiler". If VLIW had worked it would have greatly simplified processor design, no (or at least much less) need to worry about cleverly handling out-of-order execution for example. That in turn would have meant e.g. bigger L1 caches because you would have the die space to play with, or more execution units, or whatever.

It didn't work out and Intel did make some stupid decisions along the way (also underestimating the importance of backwards compatibility with existing code - not only binaries, but you also needed to be able to compile existing source well) but it was worth a punt, and maybe will be again someday - maybe a DL-based compiler could produce good VLIW code? Maybe a new (or old) language will be more amenable to VLIW compilation than C?

I would say certainly, given Fran Allen's point of view on C compilers.

I don't think it's fair to say Kernel research is a thing of the past.

There’s nothing in it for anyone else.

Although I'm a little worried about driver performance, especially in cases when there's just ~100 microseconds time for the driver to react.

Giving Android away to OEMs is in large part a vector to get the Play store, Chrome, Maps, and their monetizable services and data scarfing on the device.

But some OEMs don't bundle everything. Think of the de-Googled Android variant ran by the Kindle Fire series, or the Chinese phones that include local stores and service providers that work there instead. Google can try to bludgeon them into playing ball with the trademark and various over-the-top agreements, but they can't stop them from saying "We'll take AOSP and make our own version and call it FireOS."

With full licensing control up and down the stack, they can close that door much tighter.

Also, similarly to Apple, GCC just got removed from Android.

Only the kernel is left.

Reading between the lines of some Joe Duffy posts, I think Midori was a victim of rise to power from WinDev after that whole Longhorn/Vista history, only to end with UWP slowly getting back all the .NET features that they decided to throw away on the initial version of WinRT.

Apparently post .NET Core 3.0 there will be some changes happening to .NET Native. It was briefly mentioned at Connect 2018, but they didn't wanted to precise what exactly.

I think the i432 would be a worthy challenger to that title

https://en.m.wikipedia.org/wiki/Intel_iAPX_432

Intel was writing architectural checks (bit-aligned instructions, capability-based permissions, "everything is an object") they couldn't cash (very, very bad performance).

I'm a software guy, so naturally I took a course in VLSI design in college. It was fun. This was maybe a year before the iAPX 432 was canceled; our teacher had some sample chips embedded in clear plastic, gewgaws handed out at some conference he'd been to. He passed them around one day in class, and they were huge and there were like four of them in the processor chipset. And I remember thinking "how the heck is that thing going to be fast with all that off-chip traffic?" And of course it wasn't.

Elliot Organick, of Multics fame, wrote a book about the 432 architecture. I just found it on my bookshelf and leafed through it again; I'd forgotten that all of his code examples were in Ada (another "big bet" at the time).

Mind you, if nothing beyond the smallest silicon processes turns out to be practical then we might see attention turning back to re-thinking CPU architecture, but until then I think a lot of money will be spent looking at materials and manufacturing over interesting ISAs.

There are a lot of reasons. Open source, cloud providers, etc. But a big one is that you can't just depend on CMOS process shrinks to make processors faster. Therefore, your new design isn't necessarily going to be eclipsed by whatever new x86 CPU comes out in 12 months.

And the RISC (possibly DEC Alpha "inspired") - https://en.wikipedia.org/wiki/Sunway_SW26010

Not sure it presents much of an advantage over any of the existing architectures, or RISC-V, though.

I am no expert on this, but my personal impression is that projects of this kind slowly try to migrate towards RISC-V.

There are some forked versions of the main zlib library with MIPS optimisations in them that really fly, but nothing that has ever hit upstream, and I'm not crazy enough to want to rely on unpatched/unsupported code like that.

I’m legit confused. Are those supposed to be good things.

As an aside, Merced too forever for Intel to tape out. Part of the agreements between HP and Intel was that they needed to ship chips for HP. As a result, Intel had to fab some of the last PA-RISC chips due to the schedule slip and contractual obligations.

I worked on some Itanium system software once upon a time.

I could argue it was doomed from the beginning as well for various technical reasons given how the industry evolved. But there's at least an argument that better time to market might have been enough to get established as a dominant 64-bit architecture.

Itanium was also, in many ways, designed for a world where ILP, rather than TLP, ruled. That distinction wouldn't become terribly important for a few more years but it would have eventually. Intel made a number of decisions in this vein. See also NetBurst Architecture. (An Intel exec told me, at some point after it had become obvious that multi-core was the future, that Microsoft had really pressured Intel to go down the few/fast cores route.)

If we switch from the "Every year the clock rate goes up 30%" model to "50% more cores every year", you're going to trigger the "recompile the universe" event. This is an esistential-level threat for the Microsoft of 15 years ago.

Microsoft's biggest selling point for years was the backwards compatibility. Keep running that old software forever, and the magic of Intel running the clock up means it still gets faster every year.

If that train stops, you may well think "if I have to rebuild anyway to support many-cores, why not do so on Linux?"

I'd be curious to hear why that had that outlook. Wasn't HP still doing gangbuster's business at that point? Or was it something else besides having the financial resources?

Fast-forward and now Linux is dominant and who even uses HP-UX or the other proprietary UNIXes?

It had 32 64bit FP registers that could also be used as 64 32bit registers or 16 128bit registers. For the time this was novel.

What is EFI here - extensible firmware interface? If so what is the connection between that and Itanium?

IMHO, as someone who cares about security, that's not necessarily a bad thing. (I do lament the passing of tagged architectures, but that ship sailed a long, long time ago.)

Solaris with SPARC ADI, Android with the upcoming ARM Memory Extensions are two examples of it.

Well it may be a dumpster fire, but it is the finest, most consistent flame we've gotten from the firmware dumpster; which is why it is fast becoming the only standard firmware interface in actual use. UEFI is fast becoming the standard for ARMv8, it's creeping back to ARMv7, and it's becoming popular with RISC-V.

You will either learn to love it, or you will suffer forever. Mark my words, UEFI will still be booting your machine in 2040, when the President is literally a deep fake controlled by a troika of Jack Dorsey, Jeff Bezos, and Priscilla Chan.

We really just wanted a nice clean 64-bit BIOS, with all the datatypes 64-bit. The BIOS is pretty decent if you strip out redundant interfaces, segmentation, and never-used functionality. Adding extra functionality to firmware is madness. Firmware needs to initialize key hardware like RAM, load a boot loader, and get out of the way. Firmware doesn't need to be practically an OS.

The old 16-bit BIOS was actually working OK. Sure, it was nasty to program for, but almost nobody had to deal with that.