And then was gone before it reached a point when you could just pop an Optane stick into your board and have your memory persist.
Admittedly I cannot find an official specification of the durability either which means that it is either no concern at all or a very big concern. Typically when it’s not a concern at all the maker would still proudly present it. And also if it were a viable technology somebody would likely license it from Intel. Either way it’s academic, Optane is no more.
Doubly so given it’s been shown that persistence can be achieved completely in software with the hardware we have today. Of course, the experimental OS that does it runs on next to no hardware, has next to no application, and next to nobody uses it. You can’t just run Photoshop or SAP on it, not even the X server. It had compositor-based windowing system long before Wayland was a thing.
Not sure that IA64 was such a great thing, Intel is not know for good CPU design, it’s known for throwing money at it until it works. It was certainly interesting in some ways. It has this concept of register ring buffer from which registers were allocated for functions, and if the ringbuffer would overflow/underflow it would be spilled to/refilled from stack. There is a problem with register allocation in current day CPUs. What you write in assembly or machine code are virtual registers, you do not get to see the real registers. And while this mechanism does make register mapping available to the user it’s on function granularity, not instruction granularity. So what happens in practice is that compiler writers reverse-engineer how the CPU would allocate real registers and arithmetic units, and try to generate code that makes optimal use of these resources to which they do not have direct access. All in the name of making the CPU look like a Z80 with immediate execution and no pipelining.
There is another problem that is related to faking immediate execution: branching. While Sparc has delayed branching, and all the instructions that are already loaded into the pipeline at the time a branch is resolved get executed most other architectures try to pretend that branch happens at the exact place where it is in the assembly. Which means that they speculatively load and execute some following instructions, and if it turns out that the execution took a different branch they pretend it did not happen - except Spectre and Meltdown happen then. The Sparc approach of making the thing that is really happening visible and put under user control needs to be extended to more aspects of the CPU if we want to have any chance at having usable CPUs in the future.