Talk:Disassemble
Compacted x86 Opcode List?
So is this like a copied over and (sorta) wikified x86 opcode format and instruction listing? Or is it 43 kilobytes of x86 ramblings? --Troy Martin 00:30, 22 January 2009 (UTC)
I have several problems with this:
- Performing your own disassembly has little to do with OS development in practice
- Everything mentioned in this article can be found within the intel manuals (2A and 2B)
- The same manuals tend to disagree about the opcode placement - all binary arithmetic opcodes come in six, several come in pairs (byte and w/d/q), and some comparable opcodes are positioned above each other. Mathematical operators are all over the place. There's just way more noise than the article suggests...
- Its a copy of a complete article written by someone else, which has serious copyright implications. Do you have permission?
- Combuster 09:04, 22 January 2009 (UTC)
And there already is an article on X86 Instruction Encoding, (which I did't write specifically for disassembly, but more for programs like IL2CPU, Bartok implementations and SharpOS AOT). Virtlink 13:27, 22 January 2009 (UTC)
Every definition and explaination of the instruction encoding that I've ever seen (except for this one) describes the format in hex, and therefore over complicates the otherwise simple octal nature of the encoding.
Performing your own disassembly has little to do with OS development in practice
I disagree, there are several places where disassembly can be useful in a kernel. It's useful for displaying crash dumps, emulating protected instructions in user code or gathering detailed information about page faults.
Everything mentioned in this article can be found within the intel manuals (2A and 2B)
No it cant, read the article. This is an entirely different approach to understanding the instruction encoding. This post describes the instruction encoding with octal instead of hex making the task of encoding or decoding the instructions much easier than hex descriptions.
Its a copy of a complete article written by someone else, which has serious copyright implications. Do you have permission?
Its a news group post as outlined at the beginning of the document. There was no copyright so no permission to distribute it is required. I left the original author, forum, topic and post date on the page for reference.
there already is an article on X86 Instruction Encoding
This page is a different approach which simplifies things. X86 Instruction Encoding defines things in hex which, in my opinion, is the wrong way to present it. Nearly the entire instruction set is defined here using the more simple octal approach.
Tantrikwizard 18:29, 22 January 2009 (UTC)
Yet another soul caught unaware by the Convention of Berne - If there's no message, its "all rights reserved". I therefore must delete this unless you can provide a legal reason not to.
Rules aside, there's nothing in this article that I hadn't figured by looking at (mainly the opcode map) the intel manuals. Yes the i386 has 8 registers which makes octal a reasonable approach, but only a limited set of unary operators come in eights. basic binary maths come in groups of six, and shifts/divs/multiplies are odd exceptions. BCD stuff is all over the place, as are the prefixes. There are just too many exceptions to claim that everything's grouped in sets of eight - everything's grouped in natural alignment: eight if there's an opcode for each register, two for each operation to distinguish byte and larger sizes, four if a memory operand can be used in either place, and then the holes are filled with whatever random stuff is left. In other words: The x86 is a mess - Combuster 01:00, 23 January 2009 (UTC)
I think that we should try to contact the original author of this because it would be a waste to have to remove this excellent description of the x86 that takes it from a hex encoded instruction set with heaps of exceptions to an octal with only a few.
And, Combuster; Yes the x86 is a mess, but it evolved that way from a clean start. Thinking of instructions this way means that it is easier to decode most opcodes, and the rest can be decoded in a separate code block.
Addendum: I've emailed the author of the original asking for permission. I asked him to inform us of his decision.
- Thepowersgang 03:14, 23 January 2009 (UTC)
The octal approach is nice, but the article seems to focus mainly on convincing us that octal is better, with lots of examples and the like. When we don't get permission, it might be an idea to rewrite it to your own wording. In addition to changing the mono spaced text into tables, create headers. Clarify the hexadecimal, octal, decimal numbers, since just looking at a number currenlty doesn't tell me which number system is used. And when we do get permission, do we have the permission to modify it from the original? (Which will surely happen since this is a wiki.) Virtlink 10:37, 23 January 2009 (UTC)
I've emailed the author of the original asking for permission.
Thanks for that. I remember this post coming across the alt.lang.x86 about 10 years ago and lost it. Subsequently I wrote an assembler then re-discovered this post. After re-writing the binary generator portion using this octal approach the resulting code was about 1/2 the size than using the intel hex descriptions (I'm not so sharp as combuster to recognize the octal nature of the instruction encoding).
When we don't get permission, it might be an idea to rewrite it to your own wording.
Yea, its not put together well enough to be a beginners article or cross reference, its more of an informative post. It should be redone for osdev.org IMO. I can assist here and there if this effort is undertaken. Tantrikwizard 05:53, 24 January 2009 (UTC)
On the note of emailing, I sent the email to the listed address but it doesn't seem to be valid anymore (GMail failed to send it) so we should probably just re-write it ourselves.
- Thepowersgang 14:28, 26 January 2009 (UTC)
Silly
This article is completely silly. "The 80x86 is an Octal Machine" says it all. Of course, the 80x86 is binary, and as such, it shouldn't surprise us to find that groups of instructions that use 8 different parameter combinations to have a count of 0-7 of certain adjacent three bits. The fact that this may be either 0-7 or 8-e in hex is also not a big surprise. 'Octal' says something about the [i]representation[/i] of a number, to call the instruction set 'octal' is just plain silly. Jal 15:20, 12 February 2009 (UTC)
- Which is a good reason this article was the victim of a content wipe. As well as the fact that it has a freaking horrible page name for a wiki. "x86 Opcode Breakdown" would be better. --Troy Martin 23:36, 13 February 2009 (UTC)
Deletion?
Since nobody has made any move on rewriting this article, and several members (and I agree) think the article is "completely silly" anyway, should it be deleted? JackScott 10:26, 7 April 2009 (UTC)
- Emptied and redirected to X86 Instruction Encoding. Functionally equivalent to deletion. - Combuster 14:59, 7 April 2009 (UTC)
