Talk:Opcode

Unnamed section
could some one change the title from "Opcode" to Op-Codes/Op-code please

Op-Code=Operation-Code Opcode=Operationcode??? Op-Codes whould would be better because of the implied plurality.

even with one bit you would have two op-codes 0/1 ;p thank......... — Preceding unsigned comment added by 71.106.6.150 (talk) 2005-04-27T23:00:46‎


 * Um, no, because the proper abbreviation is "opcode". Btw, this article is horrible at this point.  One might suggest looking at the format of other wiki articles to start with.
 * — Preceding unsigned comment added by 64.223.123.9 (talk) 2005-06-21T02:50:13‎


 * ¨As an example let's design a crude 4-bit microprocessor¨
 * This is a terrible bad example. Mess all the article.
 * A real one x86 should be used instead.
 * --Zzzzzzus 15:35, 1 September 2005 (UTC)zzzzzzus

Re-wrote the whole thing
Pointed to here by User:Kosebamse's recently-posted lists of 20 random articles, I was shocked by how bad this was, so I rewrote it.

I removed the example, since I felt it would not be helpful to anyone - it would not make sense to anyone who didn't already know this kind of thing well enough not to need the explanation. Perhaps someone can create a better one in future.

I disagree with making the example x86, though. The x86 instruction set is horribly irregular and is a bad teaching tool, even if common. Most RISC architectures have a much simpler to understand instruction format.

&mdash;Morven 20:06, 8 November 2005 (UTC)


 * I have come to this article rather late, but on looking into the page's histories a bit, I agree it might be illuminating having the anatomy of an ordinary, theoretical 5 bit microprocessor laid out for general inspection.  While it may not be possible to have a highly regular instruction set, you might want to set aside the exceptions to the rule, right up front, and take things in stride from that point on.   What we might agree on, however, is that each memory address hold 8 bits of information, and the program counter be 16 bits wide, cleared to zero at reset, adds 2 each time an instruction is executed, and returns to zero on overflow.   That ought to be complicated enough.   Should there be a stack, and why?   Should there be an accumulator, and why?   How about a smaller accumulator that tends to overflow when converting binary to decimal numbers?   That sort of thing.   I for one would find a theoretical construct of that nature highly fascinating, and notable if it were given a page of its own.
 * --Dexter Nextnumber (talk) 02:30, 5 December 2009 (UTC)

Suggestion missing information
A variation to this topic: 'Polimorphic Opcode'

It is being mentioned (and explained a bit) here: Perl Unicode caveat.

— Preceding unsigned comment added by 213.84.10.118 (talk) 2006-06-28T11:25:40‎