![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||
|
Illegal opcode should not be the same like an Undocumented opcode. They are very different. Michael 19:22, 18 October 2007 (UTC)
I don't understand why there is an out-of-date warning. What exactly is supposed to be out of date about the given information? The subject is mainly historical - so there isn't going to be much *new* information that needs to be added. -- 89.182.203.44 ( talk) 11:37, 19 January 2016 (UTC)
This article needs links to Pentium F00F bug along with Pentium FDIV bug.
Also more examples are needed.(such as code and documentation.)
FockeWulf FW 190 ( talk) 16:33, 11 March 2016 (UTC)
BIOS operation links to this article, but that term is not mentioned in the article text. :-( -- RokerHRO ( talk) 21:05, 10 June 2017 (UTC)
I propose splitting the article into Illegal opcode and Unintended opcode, or moving the article and then usurping the original title. The lead in the Unintended opcode page should drop the reference to invalid opcodes. Both articles should include {{ distinguish}} templates.
I'm undecided whether the new Invalid opcode page should discuss privileged instructions used in a context where they are invalid, e.g., an IBM System/360 'Load PSW instruction issued in[problem state. -- Shmuel (Seymour J.) Metz Username:Chatul ( talk) 13:40, 29 December 2021 (UTC)
Yes, UUOs are in the same category as SVC and INT and MME and EMT and IOT and BPT and all other explicitly-defined-to-trap instructions; the only way in which UUOs differ is that some of them, at least on the PDP-10, are explicitly defined to trap to user-mode code. They're not opcodes not mentioned in the architectural specification.
Including them in this article, however, would turn this article into even more of a mishmash of different topics. Explicitly-defined-to-trap instructions, as a general concept, belongs in its own article.
The lede in this article speaks of instructions "that [are] not mentioned in any official documentation released by the CPU's designer or manufacturer, which nevertheless [have] an effect". That does not include SVC/INT/MME/EMT/IOT/BPT/UUOs/etc., as those are mentioned in the instruction set documentation.
That also doesn't say what "an effect" is. It could be "takes bits 2 and 3 of the AC, shifts bits 0 and 1 right by 2 bits, and puts bits 2 and 3 at the top of the AC" (big-endian bit numbering here), or it could be "gets an illegal instruction trap".
Those are not just "common on older CPUs designed during the 1970s, such as the MOS Technology 6502, Intel 8086, and the Zilog Z80"; they're present on any CPU where not all possible opcode values have operations associated with them, including, for example, System/3x0. It's just that, on some processors, they get illegal instruction traps rather than doing whatever the circuitry of the CPU happens, by accident, to cause them to do.
The latter behavior is what, as per the citation for the term, "unintended opcodes" refers to. As I read the 6502 programmer's manual, it has no illegal instruction interrupt (although it does have an explicitly-defined-to-interrupt instruction, BRK). As such, all "illegal opcodes" on the 6502 are "unintended opcodes".
So far, two behaviors for opcodes not mentioned in the manual/ISA spec are described - "do whatever the circuitry happens to make it do, even though the implementers didn't intend anything" and "illegal instruction trap".
Neither of those cover, for example, LOADALL; that's "do whatever the implementers intended, even though they didn't document it". I don't know whether anybody's ever described those as "unintended opcodes", and if they ever did, I'd respond that they're not unintended, they're just undocumented. Both "do whatever the circuitry happens to make it do, even though the implementers didn't intend anything" and "do whatever the implementers intended, even though they didn't document it" could reasonably called "undocumented instructions", so that phrase doesn't necessarily refer only to the latter, although one could argue that "undocumented" might imply an explicit decision not to document it.
In any case, I consider "do something weird and not explicitly intended", "do an illegal instruction trap", and "do something the implementers intended but didn't document" as somewhat separate topics. "Do an illegal instruction trap" is the least exotic; the only way I can see that's interesting beyond "your program gets terminated" is "if, in the future, that opcode gets used for a new, documented operation, you could have the illegal instruction trap handler simulate it, so you can run software for newer processors, albeit slowly, on older processors". (Using them for OS or user-mode traps is risky, as a future processor might implement them. That's why DEC explicitly setting aside 000 through 077 as UUOs matters - that's a promise never to use those opcodes for hardware-implemented instructions.)
So does this call for one article, two articles, or three articles? Guy Harris ( talk) 20:01, 3 January 2022 (UTC)
References
The second operand is placed unchanged at the first operand location. If all zeros are placed at the first operand location, a compare-and-trap-instruction data exception is recognized.
A tag_overflow occurs if bit 1 or bit 0 of either operand is nonzero, or if the addition generates an arithmetic overflow (both operands have the same sign and the sign of the sum is different). If a TADDccTV causes a tag_overflow, a tag_overflow trap is generated and r[rd] and the condition codes remain unchanged.
OK, let's decide what to do.
The introduction says:
An illegal opcode, also called an illegal operation code, unintended opcode or undocumented instruction, is an instruction to a CPU that is not mentioned in any official documentation released by the CPU's designer or manufacturer, which nevertheless has an effect.
and the short description is "Undocumented CPU instruction that has an effect".
Given that, I have a strong suspicion that no valid argument can be constructed that any documented instructions - i.e., "instructions mentioned in any official documentation released by the CPU's designer or manufacturer, which nevertheless has an effect" - should be discussed here.
I also consider "documentation" to include:
The article itself seems not to discuss documented instructions.
So I vote for:
which leaves room for making "illegal opcode" a page that mentions both illegal instruction trapping (including what the trap handlers might do, including "emulate an instruction on processors that don't implement it") and illegal instructions that accidentally perform possibly-useful functions; the latter could mention that and have "undocumented instruction" as the main page.
Barring any technically-correct objections, I will make those changes at some point in the next couple of weeks. Guy Harris ( talk) 21:55, 20 April 2022 (UTC)
-- Mathnerd314159 ( talk) 17:17, 23 April 2022 (UTC)
An editor has identified a potential problem with the redirect
Ub2 and has thus listed it
for discussion. This discussion will occur at
Wikipedia:Redirects for discussion/Log/2022 April 20#Ub2 until a consensus is reached, and readers of this page are welcome to contribute to the discussion. signed,
Rosguill
talk
20:49, 20 April 2022 (UTC)
![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||
|
Illegal opcode should not be the same like an Undocumented opcode. They are very different. Michael 19:22, 18 October 2007 (UTC)
I don't understand why there is an out-of-date warning. What exactly is supposed to be out of date about the given information? The subject is mainly historical - so there isn't going to be much *new* information that needs to be added. -- 89.182.203.44 ( talk) 11:37, 19 January 2016 (UTC)
This article needs links to Pentium F00F bug along with Pentium FDIV bug.
Also more examples are needed.(such as code and documentation.)
FockeWulf FW 190 ( talk) 16:33, 11 March 2016 (UTC)
BIOS operation links to this article, but that term is not mentioned in the article text. :-( -- RokerHRO ( talk) 21:05, 10 June 2017 (UTC)
I propose splitting the article into Illegal opcode and Unintended opcode, or moving the article and then usurping the original title. The lead in the Unintended opcode page should drop the reference to invalid opcodes. Both articles should include {{ distinguish}} templates.
I'm undecided whether the new Invalid opcode page should discuss privileged instructions used in a context where they are invalid, e.g., an IBM System/360 'Load PSW instruction issued in[problem state. -- Shmuel (Seymour J.) Metz Username:Chatul ( talk) 13:40, 29 December 2021 (UTC)
Yes, UUOs are in the same category as SVC and INT and MME and EMT and IOT and BPT and all other explicitly-defined-to-trap instructions; the only way in which UUOs differ is that some of them, at least on the PDP-10, are explicitly defined to trap to user-mode code. They're not opcodes not mentioned in the architectural specification.
Including them in this article, however, would turn this article into even more of a mishmash of different topics. Explicitly-defined-to-trap instructions, as a general concept, belongs in its own article.
The lede in this article speaks of instructions "that [are] not mentioned in any official documentation released by the CPU's designer or manufacturer, which nevertheless [have] an effect". That does not include SVC/INT/MME/EMT/IOT/BPT/UUOs/etc., as those are mentioned in the instruction set documentation.
That also doesn't say what "an effect" is. It could be "takes bits 2 and 3 of the AC, shifts bits 0 and 1 right by 2 bits, and puts bits 2 and 3 at the top of the AC" (big-endian bit numbering here), or it could be "gets an illegal instruction trap".
Those are not just "common on older CPUs designed during the 1970s, such as the MOS Technology 6502, Intel 8086, and the Zilog Z80"; they're present on any CPU where not all possible opcode values have operations associated with them, including, for example, System/3x0. It's just that, on some processors, they get illegal instruction traps rather than doing whatever the circuitry of the CPU happens, by accident, to cause them to do.
The latter behavior is what, as per the citation for the term, "unintended opcodes" refers to. As I read the 6502 programmer's manual, it has no illegal instruction interrupt (although it does have an explicitly-defined-to-interrupt instruction, BRK). As such, all "illegal opcodes" on the 6502 are "unintended opcodes".
So far, two behaviors for opcodes not mentioned in the manual/ISA spec are described - "do whatever the circuitry happens to make it do, even though the implementers didn't intend anything" and "illegal instruction trap".
Neither of those cover, for example, LOADALL; that's "do whatever the implementers intended, even though they didn't document it". I don't know whether anybody's ever described those as "unintended opcodes", and if they ever did, I'd respond that they're not unintended, they're just undocumented. Both "do whatever the circuitry happens to make it do, even though the implementers didn't intend anything" and "do whatever the implementers intended, even though they didn't document it" could reasonably called "undocumented instructions", so that phrase doesn't necessarily refer only to the latter, although one could argue that "undocumented" might imply an explicit decision not to document it.
In any case, I consider "do something weird and not explicitly intended", "do an illegal instruction trap", and "do something the implementers intended but didn't document" as somewhat separate topics. "Do an illegal instruction trap" is the least exotic; the only way I can see that's interesting beyond "your program gets terminated" is "if, in the future, that opcode gets used for a new, documented operation, you could have the illegal instruction trap handler simulate it, so you can run software for newer processors, albeit slowly, on older processors". (Using them for OS or user-mode traps is risky, as a future processor might implement them. That's why DEC explicitly setting aside 000 through 077 as UUOs matters - that's a promise never to use those opcodes for hardware-implemented instructions.)
So does this call for one article, two articles, or three articles? Guy Harris ( talk) 20:01, 3 January 2022 (UTC)
References
The second operand is placed unchanged at the first operand location. If all zeros are placed at the first operand location, a compare-and-trap-instruction data exception is recognized.
A tag_overflow occurs if bit 1 or bit 0 of either operand is nonzero, or if the addition generates an arithmetic overflow (both operands have the same sign and the sign of the sum is different). If a TADDccTV causes a tag_overflow, a tag_overflow trap is generated and r[rd] and the condition codes remain unchanged.
OK, let's decide what to do.
The introduction says:
An illegal opcode, also called an illegal operation code, unintended opcode or undocumented instruction, is an instruction to a CPU that is not mentioned in any official documentation released by the CPU's designer or manufacturer, which nevertheless has an effect.
and the short description is "Undocumented CPU instruction that has an effect".
Given that, I have a strong suspicion that no valid argument can be constructed that any documented instructions - i.e., "instructions mentioned in any official documentation released by the CPU's designer or manufacturer, which nevertheless has an effect" - should be discussed here.
I also consider "documentation" to include:
The article itself seems not to discuss documented instructions.
So I vote for:
which leaves room for making "illegal opcode" a page that mentions both illegal instruction trapping (including what the trap handlers might do, including "emulate an instruction on processors that don't implement it") and illegal instructions that accidentally perform possibly-useful functions; the latter could mention that and have "undocumented instruction" as the main page.
Barring any technically-correct objections, I will make those changes at some point in the next couple of weeks. Guy Harris ( talk) 21:55, 20 April 2022 (UTC)
-- Mathnerd314159 ( talk) 17:17, 23 April 2022 (UTC)
An editor has identified a potential problem with the redirect
Ub2 and has thus listed it
for discussion. This discussion will occur at
Wikipedia:Redirects for discussion/Log/2022 April 20#Ub2 until a consensus is reached, and readers of this page are welcome to contribute to the discussion. signed,
Rosguill
talk
20:49, 20 April 2022 (UTC)