MO K
November 7th, 2000, 02:55
Look who is here, I knew i would fetch a legend out :-)
What i posted was crap, i said SETxx where the only single operanded opcodes that take a ModRegR/M byte, not so, look at group 4/5/6
Well, I am playing with a prototype disassembler at the moment, to be writen from scratch. And I thought the 0F9x where special, and such, wanted to code their own ModRm decoder, and dedicate the big ModRm decoder for the opcodes with two or more operands.
Its quite irritating in the case of the single operanded instructions. I am deciding the src/dest combination by testing the second bit of the opcode bit-1. Where the opcode takes two operands, this is Ok. Three operands? still ok, the third operand is (mostly?) either 1 or CL, and i can pretty much ignore it. I cann't base my decision of the src/dest by the misleading comma in the opcode table, it was meant as a reading aid, not disassembly.
When an opcode takes a single operand, there is no need to find src or dest. I think i should handle this seperatly, either by flagging them as such in the opcode tables, and testing for this in every invocation of the ModRm decoder. Or, by writing a mini ModRm decoder for them, which is well tailored for The SETxx and groups 4/5/6, and handle them there.
Well, if you are wondering why this awkwardness, well, i want the disassembled instruction to be output to a structure which is then passed to the printing module. I want to extract more information from a disassembled instructions (i.e. cross-referencing, predicting disassembly, etc.) and such, would like further inspection. Syntax independance is also a requirement of mine. Off-course, this goals could be adjusted, depending on mood and time ;-)
As you can see, I am still working on the blue print, so, I have nothing -yet- to bring out to public.
Well, that is all, Just stick around for tech support :P
What i posted was crap, i said SETxx where the only single operanded opcodes that take a ModRegR/M byte, not so, look at group 4/5/6
Well, I am playing with a prototype disassembler at the moment, to be writen from scratch. And I thought the 0F9x where special, and such, wanted to code their own ModRm decoder, and dedicate the big ModRm decoder for the opcodes with two or more operands.
Its quite irritating in the case of the single operanded instructions. I am deciding the src/dest combination by testing the second bit of the opcode bit-1. Where the opcode takes two operands, this is Ok. Three operands? still ok, the third operand is (mostly?) either 1 or CL, and i can pretty much ignore it. I cann't base my decision of the src/dest by the misleading comma in the opcode table, it was meant as a reading aid, not disassembly.
When an opcode takes a single operand, there is no need to find src or dest. I think i should handle this seperatly, either by flagging them as such in the opcode tables, and testing for this in every invocation of the ModRm decoder. Or, by writing a mini ModRm decoder for them, which is well tailored for The SETxx and groups 4/5/6, and handle them there.
Well, if you are wondering why this awkwardness, well, i want the disassembled instruction to be output to a structure which is then passed to the printing module. I want to extract more information from a disassembled instructions (i.e. cross-referencing, predicting disassembly, etc.) and such, would like further inspection. Syntax independance is also a requirement of mine. Off-course, this goals could be adjusted, depending on mood and time ;-)
As you can see, I am still working on the blue print, so, I have nothing -yet- to bring out to public.
Well, that is all, Just stick around for tech support :P