Comments (9)
Thanks for pointing this out. The FCOM
without operands must be exactly the opcode D8D1
(yes, the opcode extension 2
is redundant here). In other words, whenever you disassemble FCOM ST, ST1
, it should be disassembled to FCOM
without operands in strict Intel syntax. Given the way the reference is structured, it is not possible to express this using just another syntax inside the same entry.
If you look up FADD
in Intel manual, there is no form of FADD
without operands. But there is FADDP
without operands.
I think I was overly obsessive to follow the Intel syntax that is just... weird and erratic.
If you work with the XML reference, I would always suggest to transform it to the structure that suits you better, for example to remove all these "non operand" entries that noone really cares of.
from x86reference.
Can't you do 2 syntaxes like the FADD
like so:
<syntax mod="mem">
<mnem>FCOM</mnem>
<src nr="0" group="x87fpu" displayed="no">ST</src>
<src>
<a>ES</a>
<t>sr</t>
</src>
</syntax>
<syntax mod="nomem">
<mnem>FCOM</mnem>
<src nr="0" group="x87fpu" displayed="no">ST</src>
<src nr="1" group="x87fpu" address="EST" displayed="no">ST1</src>
</syntax>
I mean The sec_opcd
D1
is redundant in the sense that if I have the second syntax as nomem
I know the modrm byte mod field should be 11
and with the opcode extension field set to 2
I know the reg
field should be 010
and combining this to complete byte 11010000
- D0
meaning the nomem
syntax starting from D0
all the way up to D7
. I had all the information I need to get this range value from D0
to D7
without the sec_opcd
field.
A complete rewrite of FCOM
entry would look like so:
<entry mem_format="00">
<opcd_ext>2</opcd_ext>
<syntax mod="mem">
<mnem>FCOM</mnem>
<src nr="0" group="x87fpu" displayed="no">ST</src>
<src>
<a>ES</a>
<t>sr</t>
</src>
</syntax>
<syntax mod="nomem">
<mnem>FCOM</mnem>
<src nr="0" group="x87fpu" displayed="no">ST</src>
<src nr="1" group="x87fpu" address="EST" displayed="no">ST1</src>
</syntax>
<grp1>x87fpu</grp1>
<grp2>compar</grp2>
<modif_f_fpu>0123</modif_f_fpu>
<def_f_fpu>0123</def_f_fpu>
<note>
<brief>Compare Real</brief>
</note>
</entry>
and it still complies to the strict no operands for the nomem
syntax since I left the displayed
attribute set to no, so a parser of the XML reference should take this into account
from x86reference.
If I remember well, you're right, but I need to check it once more.
from x86reference.
I actually checked it again and I think I'm still correct
The sec_opcd is not only redundant but also limiting, because if a parser would assume it to be correct then it should be obvious the instruction is only useable with this sec_opcd but actually it can be any byte in the range of D0-D7
for the ModR/M register variant.
I would also be thinking of changing the src operand:
<src nr="1" group="x87fpu" address="EST" displayed="no">ST1</src>
To something more general like:
<src nr="i" group="x87fpu" address="EST" displayed="no">STi</src>
If you don't have time to fix it I'll probably open PR soon addressing some of the issues here.
I'm probably going to support AVX and other extensions not in the XML yet in some point.
from x86reference.
As for the AVX, I need to add it too, and you seem to understand the XML structure and the rules quite well. Could we collaborate on AVX? I think it would be better to discuss it in private. If you're interested, my primary email is [email protected].
from x86reference.
As for the AVX, I need to add it too, and you seem to understand the XML structure and the rules quite well. Could we collaborate on AVX? I think it would be better to discuss it in private. If you're interested, my primary email is [email protected].
Sent you an email it's pretty long
from x86reference.
If I remember well, you're right, but I need to check it once more.
I've checked it again and I'm now wondering why even 2 syntaxes are necessary?
Can't we do 1 syntax where the address method is ES
and the operand type is sr
? No need for mod="mem"
mod="nomem"
attributes since the instruction support both memory addressing as-well as register addressing.
Same applies for more instructions in these group, like FADD
which I've stated use the mod="mem"
mod="nomem"
attributes, but for what reason, it's better of just use 1 syntax with ES
and sr
as it support both addressing as-well. Am I wrong here?
from x86reference.
I looked into it finally. The answer to the first question is that you're right, two entries are not needed.
The answer to the second question: we need to indicate the specific syntax for FCOM ST, ST1
that is FCOM
. This can't be expressed using just one syntax
element.
from x86reference.
I looked into it finally. The answer to the first question is that you're right, two entries are not needed.
The answer to the second question: we need to indicate the specific syntax for
FCOM ST, ST1
that isFCOM
. This can't be expressed using just onesyntax
element.
You're correct I've missed that the memory syntax second operand type is sr
32 bits, while the register syntax second operand type is, well there's not type specified but it is an ST(i)
register, so it's 80 bits.
But I think more importantly, the instruction in it's register addressing should support comparison of ST(0)
to any of the ST(i)
registers and not only ST(1)
:
FCOM D8
D8 D0+i | FCOM ST(i) | Compare ST(0) with ST(i).
So like I've previously said, I think in such cases the register addressing entry, second operand should be changed from:
<src nr="1" group="x87fpu" address="EST" displayed="no">ST1</src>
to something like:
<src nr="i" group="x87fpu" address="EST" displayed="no">ST(i)</src>
The entry should be:
<entry mem_format="00">
<opcd_ext>2</opcd_ext>
<syntax mod="mem">
<mnem>FCOM</mnem>
<src nr="0" group="x87fpu" displayed="no">ST</src>
<src>
<a>ES</a>
<t>sr</t>
</src>
</syntax>
<syntax mod="nomem">
<mnem>FCOM</mnem>
<src nr="0" group="x87fpu" displayed="no">ST</src>
<src nr="i" group="x87fpu" address="EST" displayed="no">ST(i)</src>
</syntax>
<grp1>x87fpu</grp1>
<grp2>compar</grp2>
<modif_f_fpu>0123</modif_f_fpu>
<def_f_fpu>0123</def_f_fpu>
<note>
<brief>Compare Real</brief>
</note>
</entry>
I think this also applies to FCOMP D8 /3
and maybe some other instructions I'm not really thinking about, what do you say?
EDIT:
After some more digging in the XML I think pretty much anywhere address EST
is used, it's for an instruction that could potentially reference any ST(i)
register, although the text of the element explicitly state ST1
.
There are some instructions like FLY2X
where an explicit ST(i)
register needs to use like ST1
and it doesn't use the EST
addressing and just use the nr=1
attribute with ST1
in the text of the element like so:
<dst nr="1" group="x87fpu" displayed="no">ST1</dst>
<!-- no @address="EST"! -->
So I think an appropriate change for these EST
addressing instruction would be, to either change it like I've suggested before:
<src nr="i" group="x87fpu" address="EST" displayed="no">ST(i)</src>
or we can drop the nr
attribute and the element text all together like so:
<src group="x87fpu" address="EST" displayed="no"/>
from x86reference.
Related Issues (16)
- No-operand version of FSUB is missing
- Error in Table "32/64-bit ModR/M Byte" HOT 1
- about avx HOT 5
- Document x87 instruction provenance HOT 2
- PALIGNR missing imm8 operand 3
- SIB Notes are wrong/misleading
- Mov Debug register possible wrong operand type HOT 2
- SFENCE requires sec_opcd HOT 4
- AAM AMX instruction entries and AAD ADX instruction entries are wrong HOT 2
- Add XBTS and IBTS instructions (80386 only)
- [Enhancement] Add JSON reference file HOT 2
- Missing Bit Manipulation Instruction Sets: ABM, BMI1, BMI2, and TBM HOT 1
- Relicense suggestion HOT 5
- Possible error in PUSH immediate HOT 1
- Opcode field for SETcc unnecessary HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from x86reference.