Content deleted Content added
rate |
Tag: |
||
(6 intermediate revisions by 5 users not shown) | |||
Line 1:
{{Talk header}}
{{WikiProject Computer science|class=Start|importance=High}}▼
{{WikiProject banner shell|class=C|
{{WikiProject Computing |importance=Low |science=y |science-importance=High |hardware=y |hardware-importance=Mid |software=y |software-importance=Mid |java=y |java-importance=Low}}
}}
== Unnamed section ==
could some one change the title from "Opcode" to Op-Codes/Op-code please
Line 9 ⟶ 14:
even with one bit you would have two op-codes 0/1 ;p
thank.........
<!-- Template:Unsigned IP --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/71.106.6.150|71.106.6.150]] ([[User talk:71.106.6.150|talk]]) 2005-04-27T23:00:46</small>
: 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.▼
: <!-- Template:Unsigned IP --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/64.223.123.9|64.223.123.9]] ([[User talk:64.223.123.9|talk]]) 2005-06-21T02:50:13</small>
::¨As an example let's design a crude 4-bit microprocessor¨▼
▲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.
:: This is a terrible bad example. Mess all the article.▼
:: A real one x86 should be used instead.
▲¨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. [[User:Zzzzzzus|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.
[[User:Morven|—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. [[User:Dexter Nextnumber|Dexter Nextnumber]] ([[User talk:Dexter Nextnumber|talk]]) 02:30, 5 December 2009 (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.
== suggestion missing information ==▼
: --[[User:Dexter Nextnumber|Dexter Nextnumber]] ([[User talk:Dexter Nextnumber|talk]]) 02:30, 5 December 2009 (UTC)
A variation to this topic: 'Polimorphic Opcode'
It is being mentioned (and explained a bit) here: [http://webmaster.iu.edu/perl56/pod/perlunicode.html#important%20caveat Perl Unicode caveat].
<!-- Template:Unsigned IP --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/213.84.10.118|213.84.10.118]] ([[User talk:213.84.10.118|talk]]) 2006-06-28T11:25:40</small>
|