Curious Instructions

Years ago, Geoff Chappell (the author of DOS Internals, among other things) published an article about mysterious instructions that Microsoft’s LINK knows but Intel’s documentation is silent about. The fourteen listed instructions were: LOADALL, CFLSH, WRECR, RDECR, SVDC, RSDC, SVLDT, RSLDT, SVTS, RSTS, SMINT, XBTS, IBTS, ZALLOC.

Mr. Chappell then explains why Intel never mentioned SVDC, RSDC, SVLDT, RSLDT, SVTS, RSTS and SMINT: Those are instructions defined by Cyrix and in fact reasonably well documented.

But that still leaves seven instructions: LOADALL, CFLSH, WRECR, RDECR, XBTS, IBTS, and ZALLOC. What are those instructions? And why did Intel not document them?

The instructions actually fall into roughly three categories. Undocumented, withdrawn, and not implemented in production processors.


The LOADALL instruction is notable for being present in all production 286 processors, but only described in a confidential document provided by Intel to selected third parties under a non-disclosure agreement.

Despite the shady nature of the LOADALL instruction, it was well documented in contemporary literature and used by several major software titles (including OS/2 1.x and Microsoft Windows 3.x).


These instructions are not so much undocumented as forgotten. XBTS and IBTS, or eXtract BiT String and Insert BiT String, were present in early production steppings of the Intel 386 processor, and removed in the B1 stepping in 1986 or so. Intel’s justification for the removal was that the functionality could be achieved using the SHLD/SHRD instructions without much trouble.

It is unlikely that any production software uses XBTS/IBTS for their intended purpose. However, several major operating systems (from Microsoft, IBM, and others) may attempt to execute XBTS or IBTS on 386 processors, solely for the purpose of distinguishing the B0 and earlier steppings from its successors. This is needed for software to decide whether it needs to activate workarounds for the various severe errata found in the Intel 386 B0 stepping (or refuse to work on such broken hardware).

The XBTS and IBTS instructions were documented, for example in the 80386 datasheet from April 1986 (as seen here). Undocumented PC also describes these instructions. However, all mentions of XBTS/IBTS were removed from later editions of the Intel 386 documentation; only the empty spaces in the opcode map remained. For that reason, it’s fair to call these instructions mysterious, even though they weren’t truly undocumented like LOADALL.


These four instructions are true phantoms. They were almost certainly never present in any production processor, but they were documented in preliminary specifications of the Intel P6 processor, later known as Pentium Pro. The preliminary documentation was naturally only available under a non-disclosure agreement, but Microsoft clearly had no trouble obtaining the confidential documents, which explains LINK’s secret knowledge.

Extremely little is known about these instructions, and since they cannot be seen in the wild, they are strictly historical curiosities. The OS/2 Museum recently obtained information from reliable sources which should shed some light on these instructions.

The RDECR and WRECR instructions were intended to read and write so-called Extended Control Registers (ECRs). Intel apparently decided to drop the ECR idea and would-be ECRs for machine check and MTRR control became MSRs instead.

The ZALLOC instruction allocated a zero-filled cache line and was intended to speed up block memory writes and copies. The semantics were rather odd which may be why the instruction was dropped.

Finally the CFLSH instruction flushed the cache as the name suggests, but only for “restricted cache” (RC) lines, later known as write-combined memory regions. The CFLSH instruction was intended as a performance hint for graphics intensive operations; it allowed software to flush cached framebuffer memory and thus avoid unnecessarily polluting the cache with memory that wasn’t going to be used again (or at least not soon).

The RDECR and WRECR instructions could only executed at privilege 0 (i.e. the most privileged code), while CFLSH and ZALLOC could be executed at any privilege level.

It may also be of interest that in the CPUID capability flags (returned in the EDX register after executing CPUID with EAX equal to 1), two bits were reserved for the above instructions: bit 11 for the ECR feature (RDECR/WRECR) and bit 16 for ZALLOC.

The ZALLOC instruction was mentioned publicly a long time ago (see this post and the link within). The RDECR/WRECR instructions, but not CFLSH and ZALLOC, are listed in this document (in Polish, on page 26) as Pentium Pro additions—who knows what the source of the information was.

All in all, some versions of MS LINK do contain a rather interesting list of curiosities.

This entry was posted in Documentation, Intel, x86. Bookmark the permalink.

11 Responses to Curious Instructions

  1. Yuhong Bao says:

    What is fun is that most Intel NDAs from this period seems to have been 15 years and are probably expired by now.

  2. dosfan says:

    The 486 A stepping had CMPXCHG use the same opcodes (0Fh A6h and 0Fh A7h) as XBTS and IBTS but were of course moved in later steppings and all later processors.

    CPUID level 1 EDX bit 11 indicating ECRs on the Pentium Pro explains this note from the official documentation:

    When the CPUID instruction is executed on the Pentium Pro processor (model 1), the processor returns a the SEP flag as set, but does not support the SYSENTER/SYSEXIT instructions.

    What were the opcodes for CFLSH, RDECR, WRECR, and ZALLOC ?

  3. dosfan says:

    For some reason the article link wasn’t working when I first responded. CFLSH being at 0Fh 0Ah explains why there is a gap there in the opcode map now.

  4. Yuhong Bao says:

    As a side note, I wonder if Intel is finally willing to release the 486 errata docs that was formerly under NDAs publicly.

  5. Michal Necasek says:

    Have they made public the errata for 386/286/8086 CPUs? They certainly did have the errata sheets, it was just super duper secret back then…

  6. Yuhong Bao says:

    I think they were publicly available if you asked, and did not require you to sign an NDA.

  7. dosfan says:

    Since the Pentium Pro has CPUID level 1 EDX bit 11 set is there any chance that ECRs and RDECR/WRECR are actually present or is the flag being set just a leftover which someone forgot to clear ?

  8. Michal Necasek says:

    In the Pentium Pro documentation (order no. 242691 from Dec 1995, page 11-74), bits 10 and 11 are marked as reserved. Do actual PPro CPUs really have that bit set? I’ll have to check…

  9. Michal Necasek says:

    I’m aware of the existence of “confidential” 386 errata sheets, certainly nothing that would look like public documents. Is there some evidence that there were public 286/386 errata documents in the 1980s? (I’m not talking of the official F-step 386 spec updates from the late 1990s.)

  10. Sean McDonough says:

    Any clue why CFLSH was dropped, or why Intel dropped the ECR concept (thus obsoleting WRECR and RDECR)?

    Wouldn’t odd semantics have been a better reason to redesign ZALLOC than to scrap it?

    Is it really as easy to reimplement the XBTS/IBTS functionality using SHLD/SHRD as Intel claims it is?

    And does anyone have any access to one of the prototype Pentium Pros using the four phantom instructions?

  11. Michal Necasek says:

    I think SHLD/SHRD use as XBTS/IBTS replacement is reasonable, and Intel provided an example in their documentation. I definitely don’t have any Intel prototypes, just a few ES/QS (Engineering/Qualification Sample) CPUs that are very close to their production counterparts.

    As to why Intel changed the design of the Pentium Pro so much… I don’t know. Perhaps it’s normal and the prototypes 2-3 years before production are significantly different from the finished product. I can only guess that the ECRs were dropped because Intel decided that MSRs do the job well enough. And by now the MSRs are a pretty big mess, but that is not a problem with the instruction per se.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.