x86asm.net
Message board for the users of x86asm.net
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

X86 Opcode and Instruction Reference, 1.00 - 1.11
Goto page 1, 2  Next
 
Post new topic   Reply to topic    x86asm.net Forum Index -> Discussion on Projects
View previous topic :: View next topic  
Author Message
MazeGen
Site Admin


Joined: 05 Sep 2007
Posts: 89
Location: .cz

PostPosted: Sat Oct 18, 2008 9:46 pm    Post subject: X86 Opcode and Instruction Reference, 1.00 - 1.11 Reply with quote

Let's discuss X86 Opcode and Instruction Reference project.

Massive update of this revision include addition of SSE, SSE2, SSE3 and SSSE3 instructions, and editions sorted by mnemonic:

coder32-abc
coder64-abc
coder-abc

geek32-abc
geek64-abc
geek-abc


The Store was improved, prices discounted.

Quote:
This reference is intended to be precise opcode and instruction set reference (including x86-64). Its principal aim is exact definition of instruction parameters and attributes.


Last edited by MazeGen on Thu Jan 28, 2010 8:34 am; edited 2 times in total
Back to top
View user's profile Send private message Send e-mail Visit poster's website
MazeGen
Site Admin


Joined: 05 Sep 2007
Posts: 89
Location: .cz

PostPosted: Wed Dec 17, 2008 4:53 pm    Post subject: New revision 1.01 Reply with quote

New revision 1.01 is out. Mostly a bugfix release. Complete list is here:

http://ref.x86asm.net/#rev_history
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Mikae
Guest





PostPosted: Tue Jan 13, 2009 1:11 pm    Post subject: EM64T Reply with quote

Hello, I'm trying to use your opcodes table (XML version) in my disassembler. I almost done a table generator, but I've found that coding of some instructions marked with F64 in Intel Manual is inconvenient.
For example, instruction 'call Ev' (marked as F64) is expressed in two entries:
Code:
<pri_opcd>
      <entry>
        <opcd_ext>2</opcd_ext>
        <syntax><mnem>CALL</mnem><dst><a>E</a><t>v</t></dst></syntax>
        <grp1>gen</grp1><grp2>branch</grp2>
                        <grp2>stack</grp2>
        <note>&call;</note>
      </entry>
</pri_opcd>
<pri_opcd>
      <entry>
        <opcd_ext>2</opcd_ext>
        <proc_start>10</proc_start>
        <syntax><mnem>CALL</mnem><dst><a>E</a><t>q</t></dst></syntax>
        <grp1>gen</grp1><grp2>branch</grp2>
                        <grp2>stack</grp2>
        <note>&call;</note>
      </entry>
</pri_opcd>

From your manual 'v' means:
Quote:
Word or doubleword, depending on operand-size attribute (for example, INC (40), PUSH (50)).

And 'q' is:
Quote:
Quadword, regardless of operand-size attribute (for example, CALL (FF /2)).
From this information I can not determine real size of operand. From the point of view of disassemb
Code:
ler the code is very simple:
if (mode == DISASSEMBLE_MODE_64)
    size = 8;
else
    size = get_operand_size_16_32(prefixes);

Are you going to deal with this? May be it is a good idea to add 'vfq' size qualifier? (Yes, I understand that the two entries differs with 'proc_start' attribute, but I've changed your XML a little, merging different entries for the same opcode, for easier parsing. Or, may be you have another version of XML?)

--
Thanking In Advance,
Mikae.
Back to top
MazeGen
Site Admin


Joined: 05 Sep 2007
Posts: 89
Location: .cz

PostPosted: Tue Jan 13, 2009 1:42 pm    Post subject: Reply with quote

Hello Mikae,

it is great that you're trying use the XML in your disassembler.

The thing is that the XML is "biarchitectural". Most of the entries are usable for both x86-32 and x86-64. However, The FF/2 CALL opcode is described using two entries. The latter entry has mode='e' attribute value which means that it applies exclusively to 64-bit mode. The former entry applies to real mode and all protected modes.

Anyway, the whole thing is more complicated. I offer you a deal: if you send me your transformations which work with the XML reference (what you should do, according to the license), I will give you access to the Benefits, which contain helper XSL transformations, which can come in handy for you, and also contrain "Writing a Disassembler Using X86 Opcode and Instruction Reference" article which can help you understand the XML significantly.

My e-mail is mazegen@gmail.com.

Last thing is that you don't seem to use the latest version, which is 1.01. It is available for public download on the homepage.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Mikae
Guest





PostPosted: Tue Jan 13, 2009 2:12 pm    Post subject: Reply with quote

Hello, MazeGen.

I've sent you my XMLs.
Back to top
MazeGen
Site Admin


Joined: 05 Sep 2007
Posts: 89
Location: .cz

PostPosted: Thu Aug 20, 2009 7:42 am    Post subject: 1.10 is out Reply with quote

New revision 1.10 is out.

All SSE4, VMX and SMX instructions added, along with those few new general and system instructions. This makes the reference up-to-date with current Intel processors.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
MazeGen
Site Admin


Joined: 05 Sep 2007
Posts: 89
Location: .cz

PostPosted: Thu Jan 28, 2010 8:33 am    Post subject: 1.11 is out Reply with quote

Revision 1.11 is out. Mostly a bugfix release. Complete list is here:

http://ref.x86asm.net/#rev_history
Back to top
View user's profile Send private message Send e-mail Visit poster's website
AndASM



Joined: 22 Mar 2011
Posts: 1

PostPosted: Tue Mar 22, 2011 10:20 pm    Post subject: Reply with quote

In the 64 bit HTML editions the PUSH (FF /6) instruction is listed with both Ev (r/m16/32) and Evq (r/m16/64) for the operand.

According to the AMD64 manual it appears there is no prefix for encoding FF /6 to take a 32 bit operand in 64 bit mode. Am I misunderstanding something or is this a mistake? It appears several other instructions have both Ev and Evq forms in the 64 bit editions.
Back to top
View user's profile Send private message
MazeGen
Site Admin


Joined: 05 Sep 2007
Posts: 89
Location: .cz

PostPosted: Wed Mar 23, 2011 6:20 am    Post subject: Reply with quote

Hi AndASM, it is a mistake, thanks for reporting it. It will be fixed in next release.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Joshua Scholar



Joined: 09 Oct 2011
Posts: 1
Location: California

PostPosted: Sun Oct 09, 2011 7:08 am    Post subject: Another person who wants to use the XML/DTD Reply with quote

Please excuse me for being a bit lost.

I would like to use the data in the XML file to generate an in-memory assembler for a JIT. Also I would like to generate nodes that can be used for optimization (since your database seems to have information about flag-dependence and about processor pipelines).

I already have a hand coded in-memory assembler, but the fact is that the x-86 instruction set is just too big complicated to hand-code reliably - the amount of testing needed is prohibitive. Also, if i can generate an 32 bit backend from this data, then later on I can generate a 64 bit one.

However I have never used XML or DTD before, so I admit to being somewhat lost. I'm not sure how I can help you and get access to benefits when, at this point, I'm just thrashing around trying to figure out how to read the data. Also, I am sorely tempted to process the data in prolog rather than using the original XML format, since I have a library for that and at least then i will be writing transforms in a language I'm familiar with. I ran ECLiPSe's XML library's xml_parse_file and pretty print function over x86reference.xml and it had no trouble changing the format into a tree that prolog programs can read.

The data looks usable with the information I already know, but it's hard for me to be sure. It is obviously going to take me a few weeks just to get to a point where I can see how complete and consistent and useful a database I can extract.

Can you give me any advice for how to proceed? I don't mind helping out, but as I said, I'm a bit overwhelmed at this point.

Joshua Scholar
Back to top
View user's profile Send private message
Tinctorius



Joined: 31 Mar 2012
Posts: 2

PostPosted: Sat Mar 31, 2012 3:02 pm    Post subject: Reply with quote

In the AMD64 docs, I find the following information (quote from Volume 1, paragraph 3.2.3.3 "Immediate Operand Size" on page 42 of the December 2011 version):
Quote:
In legacy mode and compatibility modes, the size of immediate operands can be 8, 16, or 32 bits, depending on the instruction. In 64-bit mode, the maximum size of an immediate operand is also 32 bits, except that 64-bit immediates can be copied into a 64-bit GPR using the MOV instruction.

When the operand size of a MOV instruction is 64 bits, the processor sign-extends immediates to 64 bits before using them. Support for true 64-bit immediates is accomplished by expanding the semantics of the MOV reg, imm16/32 instructions. In legacy and compatibility modes, these instructions—opcodes B8h through BFh—copy a 16-bit or 32-bit immediate (depending on the effective operand size) into a GPR. In 64-bit mode, if the operand size is 64 bits (requires a REX
prefix), these instructions can be used to copy a true 64-bit immediate into a GPR.


There are however some entries in the reference that imply the possibility of a 64-bit immediate operand:
  • (F7 /0) TEST r/m16/32/64, imm16/32/64
  • its alias (F7 /1)
  • (A1) MOV rAX, moffs16/32/64
  • its converse (A3) MOV moffs16/32/64, rAX
They don't seem to be mentioned anywhere in the AMD64 docs. Am I missing something? Are these errors?
Back to top
View user's profile Send private message
MazeGen
Site Admin


Joined: 05 Sep 2007
Posts: 89
Location: .cz

PostPosted: Tue Apr 03, 2012 9:33 am    Post subject: TEST immediate; moffs64 Reply with quote

Hi Tinctorius,

the TEST instruction immediate size (F7/0 and F7/1) is an error reported some time ago that will be fixed in next release. Thank you for your report anyway.

As for opcodes A0-A3 and the memory offset operand, I'm actually surprised that neither AMD nor Intel manual mentions it in the general chapters related to memory addressing. However, if you look at MOV instruction description in AMD manual, "Volume 3: General-Purpose and System Instructions", it explicitly says:

Quote:
In opcodes A0 through A3, the memory offsets (called moffsets) are address sized. In 64-bit mode,
memory offsets default to 64 bits. Opcodes A0–A3, in 64-bit mode, are the only cases that support a
64-bit offset value. (In all other cases, offsets and displacements are a maximum of 32 bits.)
[...]


So the reference is right in this case.

Reading these manuals has always been pain in the ass Smile
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Tinctorius



Joined: 31 Mar 2012
Posts: 2

PostPosted: Tue Apr 03, 2012 10:04 am    Post subject: Re: TEST immediate; moffs64 Reply with quote

MazeGen wrote:
Hi Tinctorius,

the TEST instruction immediate size (F7/0 and F7/1) is an error reported some time ago that will be fixed in next release. Thank you for your report anyway.
Yes, I saw that later Embarassed

MazeGen wrote:
As for opcodes A0-A3 and the memory offset operand, I'm actually surprised that neither AMD nor Intel manual mentions it in the general chapters related to memory addressing. However, if you look at MOV instruction description in AMD manual, "Volume 3: General-Purpose and System Instructions", it explicitly says:

Quote:
In opcodes A0 through A3, the memory offsets (called moffsets) are address sized. In 64-bit mode,
memory offsets default to 64 bits. Opcodes A0–A3, in 64-bit mode, are the only cases that support a
64-bit offset value. (In all other cases, offsets and displacements are a maximum of 32 bits.)
[...]


So the reference is right in this case.

Reading these manuals has always been pain in the ass Smile
At least references like yours make this kind of information accessible. Thank you for taking the time to do this for us Very Happy
Back to top
View user's profile Send private message
Christian H



Joined: 02 Aug 2012
Posts: 1

PostPosted: Thu Aug 02, 2012 7:15 pm    Post subject: INTO not available in 64-bit mode Reply with quote

The Intel manuals list INTO as not available in long mode, but that instruction is still included in the geek64 edition.
Back to top
View user's profile Send private message
bigfoot



Joined: 20 Oct 2012
Posts: 1
Location: Germany

PostPosted: Sat Oct 20, 2012 11:23 am    Post subject: OUT with port > 255; operand read/write/modify Reply with quote

I'm considering to use your great instruction table for (an auto-generated disassembler module for) a fault-injection tool. While scrolling through the geek-32 version, I noticed a possible error: The 0xEE and 0xEF opcodes (OUT with port in DX, data in AL respectively eAX) are documented to modify DX. I'm pretty sure, OUT only reads DX (just like 0xEC/0xED IN).

Another systematic problem that may involve some manual work on my side: I need to know which registers an instruction (explicitly, or implicitly) reads, and which it writes. I understand this is the purpose of <dst> and <src>, but the case that a register is both read and written is not covered: The XML file does not distinguish between an output register being completely overwritten (e.g., 0x88 MOV Eb Gb) and read/modified/written (e.g., 0x04 ADD AL Ib). (I'm not talking about special cases such as XOR EAX, EAX.) Do you have plans to add this kind of information? This wouldn't even make it necessary to change the DTD; in the 0x04 ADD case, it should suffice to additionally put AL in the <src> part.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    x86asm.net Forum Index -> Discussion on Projects All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group