
Deprecating the PCOMMIT Instruction - mslusarz
https://software.intel.com/en-us/blogs/2016/09/12/deprecate-pcommit-instruction
======
userbinator
It's very rare that an instruction gets removed; the few instances that I can
think of are XBTS/IBTS on the very first stepping of the 386, and the CMPXCHG
on early 486s that occupied the same opcode briefly. Do any CPUs have this
instruction?

It looks like the encoding of PCOMMIT (+66 0F AE/7) is basically the same as
CLFLUSH except with a +66 prefix, so if a CPU doesn't know about PCOMMIT it'll
probably try to execute it as a CLFLUSH with an ignored prefix.

But hopefully this "deprecated" information stays around, if for nothing other
than "archaeological" purposes:

[http://www.os2museum.com/wp/curious-
instructions/](http://www.os2museum.com/wp/curious-instructions/)

~~~
moosecombinator
Author here. The PCOMMIT encoding you mention produces an undefined opcode
fault on all existing CPUs (written as #UD in the specs). Since no CPU has
shipped supporting PCOMMIT, this gives us high confidence that no code
containing PCOMMIT is currently in-use or it would be producing #UD faults.
Since the need for PCOMMIT has gone away, that fact allowed us to remove the
instruction before it created legacy code we'd be signed up to support
forever.

I love your examples of other removals -- didn't know about those.

------
JoachimSchipper
For a gentler introduction/motivation, consider [http://danluu.com/clwb-
pcommit/](http://danluu.com/clwb-pcommit/).

("Deprecating pcommit" means that persistent memory is _simpler to use_ ;
persistent memory itself is not deprecated.)

------
eloff
This is a nice improvement. Now instead of having sfence/pcommit/sfence to
flush writes to nvram, you would use just an sfence to ensure ordering with
subsequent stores (e.g. a store that publishes the written data.)

Its analogous to fysnc() to ensure data reaches the disk in a way that
survives power failure. This is like just treating all writes as fsynced and
not needing to worry about fsync at all, like with O_DIRECT writes.

~~~
caf
Not exactly, you still need a cache flush if you want to ensure that your
write is persistent.

~~~
eloff
Sorry, yes I omitted that detail. You do need the cache flush still for each
written cache line.

------
loeg
Basically they've expanded the persistence domain from just the DIMMS, to the
DIMMS and memory controller, obviating PCOMMIT.

------
gaius
They've either just averted or triggered a temporal paradox, I'm not sure
which

~~~
fowl2
Both? ;)

------
DiabloD3
Okay HN, this is ELI5 time: is this instruction for interacting with SSDs that
fit into DIMM slots?

~~~
wmf
It _was_ the instruction for interacting with XPoint DIMMs (I wouldn't call
them SSDs but whatever), but now you just use CLWB instead.

~~~
loeg
Previously you would use CLWB, SFENCE, then PCOMMIT. Now you use CLWB, then
SFENCE.

~~~
jdmichal
From the article, there was another SFENCE after PCOMMIT.

~~~
loeg
Sure.

------
mkj
So is consumer XPoint hardware really coming soon?

------
jbb555
"Persistence domain". Ugh. This is supposed to be a CPU not some marketing
speak showcase.

~~~
moosecombinator
Ouch -- accused of marketing speak. That one stings.

I had been using the term "power-fail safe domain" to talk about the line a
store crosses where it is then persistent in the face of power failures. But
that led people to think power failure was the only event considered so we
started saying "persistence domain." I'm certainly open to suggestions on
terminology.

------
_RPM
Does GCC use PCOMMIT?

~~~
caf
This isn't the kind of instruction a compiler would emit for regular code.

~~~
_RPM
What would this be used for?

~~~
loeg
Kernel direct access to Xpoint and similar DIMMs. Potentially applications via
mmap. You'd probably write a simple assembly function for it and invoke that
from a language that can call assembly routines.

Obvious applications are filesystems and databases.

