1

Intel manual volume 3, said that there's only CR0,2,3,4 + CR8 in 32E mode, and CR1 is reserved. But when I compile instruction in title, N could be any value < 16. I disassemble the obj file and found that it's encoded just follow reference when N<8. And when 7< N <16, it's encoded same as before but a LOCK prefix is added(make it a "serializing instruction" as NOTED in MOV cr version?).

Why it's encoded without any complain and is this encoding legal? Are those CRs really exist or they are just alias for other registers?

Qutard
  • 355
  • 2
  • 6
  • Why your compiler did not issue an warning when you gave it invalid source code? Which compiler do you use? (for example [FASM](http://flatassembler.net/download.php) → SOURCE → TABLES.INC seems to recognize only `cr0`..`cr9`) – xmojmr Sep 02 '14 at 08:19

1 Answers1

0

I. About "LOCK" prefix: current x86 really doesn't have fixed prefix meaning. There is the set of one-byte prefixes which all have their initial meaning (LOCK, REP, CS segment, etc.) but the latter is applied only to instructions where it has direct sense. But there are other usages when an instruction doesn't have such sense. For example, F3 (REPE) before BSR/BSF converts them to LZCNT/TZCNT respectively. With ordinary memory readings, the same REPE converts to XRELEASE. Segment prefixes 2Eh and 3Eh before branch instructions are prediction hints (used in Pentium 4 line). So, don't treat basic prefix roles as thorough principle.

II. Ongoing question: why reserved CRs should not be encoded, to your mind? I don't see any principal violation in this. For analogy, why don't you require IO instructions to encode only existing ports? You'd accept CR space in the same manner as IO or MSR space, and this won't be a problem anymore. :)

Netch
  • 4,171
  • 1
  • 19
  • 31
  • LOCK is used by AMD instead of REX.R to distinguish between CR8 and CR0. On the other hand, Intel specifies that using LOCK prefix will raise #UD. It seems to be vendor-specific matter, see also discussion here: https://sourceforge.net/p/nasm/mailman/nasm-devel/thread/196838.50771.qm@web39705.mail.mud.yahoo.com/ – vitsoft Jun 02 '16 at 17:53