- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
that is, when i read ia-32 developer manual volumn2: instruction a-m and amd64 devleloper manual volumn3: general instruction set, i often am puzzed by such as instruction description:
A7 mov ax, moffset8 ...
im working on a disassembler now. i think above should is written as following:
A7 m8 mov ax, moffset8
dont know how ok it is? if it is ok, why not the manual describe it so?
who have idea please tell me, thanks very much!
A7 mov ax, moffset8 ...
im working on a disassembler now. i think above should is written as following:
A7 m8 mov ax, moffset8
dont know how ok it is? if it is ok, why not the manual describe it so?
who have idea please tell me, thanks very much!
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
answer me, ok?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - jvava
answer me, ok?
It looks like the notationof"moffs8" or "m8" to describe different methods of encoding a memory operand is at the center of your question.
The "moffs8", "moffs16", "moffs32", "moffs64" do not use ModR/M byte to encode the source nor the destination operand. So, after the opcode byte, the hardware treats the ensuing 8/16/32/64 bits of value of the instruction stream as an offset address.
In contrast, "m8" refers to the memory operand that use the 3-bit value in ther/m field (bits 7:5) of the modR/M byte (themodR/M byte follows the opcode byte) to encode the indirect memory addressing modes. If the indirect addressing mode uses a base register, theoffset address is the valuein the base register encoded by the 3 bit value of ModR/M:r/m field. In the case of indirect addressing, a 3-bit value in modR/M byte of the instruction streamallows the hardware to decode address offset that may be several bytes long.
Mixing two entirely different methods of memory operand encoding in your disassembler output is not a good idea. It will cause confusion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i must thank you badly for your answer.
but i know that you say.
what puzzled me is that since a address byte follows the opcode, just like a immediate number(byte/word/doubleword) follows the opcode,
why not the manual express it accurately, for example,
A7 address32 .... .....
just like
AA imm32 ... ....
i want to know whether it is ok that i rewrite the opcode format as A7 address32
if not, why? if ok, then the manual why omit this important information?both amd's and intel's manual.
thank you again, still wait you answer again.
but i know that you say.
what puzzled me is that since a address byte follows the opcode, just like a immediate number(byte/word/doubleword) follows the opcode,
why not the manual express it accurately, for example,
A7 address32 .... .....
just like
AA imm32 ... ....
i want to know whether it is ok that i rewrite the opcode format as A7 address32
if not, why? if ok, then the manual why omit this important information?both amd's and intel's manual.
thank you again, still wait you answer again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think I covered two aspects of your previous questions in terms of application recommendation and misunderstanding of the established notations in the manual.
I hope you'll understand that in a variable-length instruction encoding scheme, the byte that follows the opcode byte can serve different purposes, hence the different notation of moffs8 for offset and m8 for r/m indirect addressing. Inventing a new notation to express the same relation that are already documented would not be useful.
I hope you'll understand that in a variable-length instruction encoding scheme, the byte that follows the opcode byte can serve different purposes, hence the different notation of moffs8 for offset and m8 for r/m indirect addressing. Inventing a new notation to express the same relation that are already documented would not be useful.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
sigh! you guy always say your own words ingoring ultimately what i cared, maybe for my poor english expression ability.sinserely, i am appreciated with you still of cause.
what's my mean?
on the context of my working a dissambler, i need make out the instruction's grammar, say, A7 address, why i asserted these sort of notation is that other instruction apply these sort notation, such as AA imm8. i think the manual should unite the book style.
of cause, i dont want to the intel adopt what i say, that is the cause of i always ask whether it is ok that notation it as A7 address32, at least for me.
give me advice, ok.
stilll thanks very much.(maybe puzzeled by my post, sorry)
what's my mean?
on the context of my working a dissambler, i need make out the instruction's grammar, say, A7 address, why i asserted these sort of notation is that other instruction apply these sort notation, such as AA imm8. i think the manual should unite the book style.
of cause, i dont want to the intel adopt what i say, that is the cause of i always ask whether it is ok that notation it as A7 address32, at least for me.
give me advice, ok.
stilll thanks very much.(maybe puzzeled by my post, sorry)

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page