Yury has just done the fixes that were causing problems on NT/2K.

It should be starting to shape up as reliable and very useful opcode recognition utility.

Regards,

hutch@movsd.com
Posted on 2003-02-16 03:40:44 by hutch--
it hangs on NT after a search (F2) ... on a quick look it doesnt save the EBX register.
anyway, it is a nice proggie :alright:
Posted on 2003-02-17 00:57:10 by TBD
To make some sence of machine code field,
format must be in bynary not in hex.
With mnemonic-letters for bit fields that changing
hence of opcode. Number of letters must be same as
number of bits it represents:
For example
inc reg opcode format 01000reg
mnemonic "reg" has three letters wich says:
"There are 3bits after bits 01000 and those 3 bits represent
code for register used with the instruction"
The same about bits:
"d" - direction
"w"- width of operand
"s"-sign byte to dword(word) extention.
etc.
And yes, here is GPF on NT when clicking for search.
And it's better to make mnemonics the first column, not the second.
Posted on 2003-02-17 16:44:33 by The Svin
1. There is a lot of ways to solve any problem. I've selected the hex way of opcode rendering because it is shorter. Obviuosly, it entails some troubles but who likes to use binary fields? Anyway, it's just a point of view.
2. If you prefer the mnemonics sorting, you need only to click on the corresponding column.

Regards,
Yury
Posted on 2003-02-20 00:18:47 by Yury Lukach
About opcode format:
Yury, first of all bynary format needed for understanding.
So let's change question for deeper veiw from:
"Who like to use bit fields?" to
"Who need to know opcode format?".
It might be those who write assemblers, disassemblers, debugers
etc. Those who write selfmodifying code and use some tricks with
code that involves multinterpitation of opcode depending of
some condition. Those who in deep size optimization etc.
Bit fields shown give them clear picture, while hex is quite blur way
to see things there.
For example if bit "s" specifyed you know that is possible to code
imm dword as extented byte.
It doesn't mean you need always specify every bit, it need to be done
only if it's matter. Of course, to understand when it is matter - is a long talk.
In one side - you right - presize opcode format is not that everybody needs.
But on other side - hex format is something totally useless IMHO.
If you know opcode format in depth - you hopefully could understand what I mean.

Now about why I think mnemonic should be on the first column
(of course - you're the boss with your utility, my task just explain you why
it's inconvinient to me)
We usually read from left to right. Thus 1st left column is something we start
exploring from. Placing there hex opcode seems to me strange choise.
Second thing is that ListView has inner fiture - jump to list part when you press key.
And it reffer key to text of the 1st column.
So for example if mnemonics were the 1st column I could press "m" on keyboard to
jump to part of listview where are mnemonics starting with first letter "m".

I hope I've clarifyed my point.
BTW: It's nice to see here a programmer from Sverdlovsk - I was studying there for
some years in the begining of 80s and have lots of freind there. I consider it as my second home city :).
Posted on 2003-02-20 03:03:21 by The Svin
To finish this discussion I want to say the following.

The utility like this may have two goals. First, it may be educational, and, second, it may be professional.

In the first case you are absolutely right. We have to sort instructions by mnemonics and to give a detailed (i.e. binary) structure of complex opcodes containing special subfields. (It is particularly right for the Intel processors because their opcode system is somewhat chaotical).

Writing this utility I had in mind the second goal, namely to give the professional developers a fast way to recognize any opcodes that they may meet in the executable code. In the latter case we need the sorting by opcode and we don't need any special comments because we MUST know the Intel architecture. By the same reason I decided that I will not include in the help structures of RegModR/M byte, SIB byte etc. There are more than enough sources on this topic in any human language used by programmers.

It's great to meet here somebody who lived in Sverdlovsk! ;)

Best Regards,
Yury
Posted on 2003-02-20 05:39:52 by Yury Lukach