What happens when a microprocessor like the 8085 fetches an invalid opcode, i.e. not part of its instruction set, from memory and attempts to decode and run it? I found, in some forum, that invalid opcodes are treated as NOPs, but that's no good since it doesnt inform the programmer that there's a problem. Is this really what happens or is some interrupt (TRAP?) triggered? What if invalid opcodes somehow made their way down to a modern processor? How different is the behaviour, with respect to an 8085's?

I'm asking because I'm building an 8085 trainer which will require students to enter opcodes in hex directly into RAM from where they'll be executed, so I'd like to know what would happen if they enter incorrect code. Also, how likely is it that the one wrong opcode will ruin the rest of the program? Thanks.

  • 1
    \$\begingroup\$ Having spent a short while playing with old Heathkit trainers this winter (6800, not 8085) my guess would be 1 wrong opcode will very probably ruin the rest of the program. One instance of "undefined behavior" is generally sufficient for that. There were few resources to spare, and programmers were expected to get it right. If your trainer is built with some sort of serial interface so code could be saved and edited on a computer, then loaded, it would be a lot less annoying to work with than keying in hex, which is a "learning experience" that one learns is annoying PDQ. \$\endgroup\$
    – Ecnerwal
    May 8, 2016 at 2:40
  • \$\begingroup\$ Some bits maybe treated as "dont care" others can run some trivial operation depending on how things are hardwired inside, muxs, etc... \$\endgroup\$
    – Elbehery
    May 8, 2016 at 3:08
  • \$\begingroup\$ @Ecnerwal The PC-trainer idea is great. I'll have to add that after I'm done with the main functionality though; plus, change isnt so welcome here. So an invalid opcode will cause undefined fall-through, until a HLT or something stops execution? \$\endgroup\$ May 8, 2016 at 3:28

3 Answers 3


With something like an 8085 processor, the result is probably "undefined behavior". Those 1970s devices had limited logic available for instruction decoding, and they designed the opcodes to require minimal decoding effort. For example, maybe every op-code that had a '1' in the 4th bit would result in an update to the accumulator.

These devices wouldn't inform the programmer of anything because they couldn't spare the resources to detect a wrong op-code. It also wouldn't necessarily behave as a NOP, because the fields of the opcode might actually pass through the decode logic and produce some behavior that changed the state of the processor.

It would be the job of the programmer or the compiler to not generate invalid opcodes, which isn't really very difficult when you think about it. A compiler is not going to produce any opcode that it hasn't been programmed to produce.

It seems likely that newer processors, with vastly more resources, can spare some to detect invalid opcodes and produce some defined behavior, but I'm not familiar enough with them to comment on that.

  • \$\begingroup\$ Thanks. I've edited the question so that it provides some clarity, in case it helps you form a better answer. \$\endgroup\$ May 8, 2016 at 2:35
  • \$\begingroup\$ @The Photon. The old CPU's will run a 'NOP' cycle, but then run the next instruction it finds. It WILL be a bad or out of sync instruction. If the CPU keeps running it will likely output garbage. \$\endgroup\$
    – user105652
    May 8, 2016 at 3:02
  • 3
    \$\begingroup\$ @Sparky256 at least in the case of the 6502, invalid instructions were more likely to do something odd, rather than being a NOP. People collected these behaviors, and sometimes software relied on them: ffd2.com/fridge/docs/6502-NMOS.extra.opcodes \$\endgroup\$ May 8, 2016 at 3:14
  • \$\begingroup\$ @microtherion. Thx for the input. I did not get serious about CPU's until I used a PIC17C44, which already had traps built in. \$\endgroup\$
    – user105652
    May 8, 2016 at 3:18

The invalid opcodes would probably be interpreted as something and do something rather than acting as NOPs or causing "illegal instruction" traps, either of which would take additional hardware resources to decode and either nullify or trap.

What that something is, for the 8085, I have no idea.

However it shares many instructions with the contemporary (slightly earlier) Z80, as they were both derivative designs of the Intel 8080.

For the Z80, it was fairly well known (unofficially, as an urban legend) that there were additional instructions and even additional registers, accessible through the undocumented opcodes.

This was hypothesised by people inspecting the bit patterns of the documented and undocumented instructions, basically guessing what the holes did, and testing these hypotheses in assembly language (or more likely, raw binary).

I don't know the full story, but I suspect these instructions and registers were architected, but found not to be sufficiently reliable across all variations of process, supply voltage and temperature, and the revised instructions were written out of the spec, rather than delaying the product release. And given the success of the Z80, that was probably the smart choice.

There is still (unofficial) documentation available for the missing Z80 instructions...

Unfortunately, I have never heard similar stories about the 8085...

(Anecdotally, there was one invalid opcode for the 6809 which could destroy it, given the highly unofficial mnemonic HCF, for Halt and Catch Fire)

  • \$\begingroup\$ With the first ZIF-sockets, some hackers found the Eject-CPU code by accident. \$\endgroup\$
    – ott--
    May 8, 2016 at 19:00

Responding to

What if invalid opcodes somehow made their way down to a modern processor? How different is the behaviour, with respect to an 8085's?

More modern processors than 8085, like an ARM, detect several invalid conditions and trap through specific trap/interrupt vectors.

ARMs detects and traps on invalid op codes, and also traps on valid co-processor op-codes when the co-processor is missing. This allows the co-processor to be emulated in software.

IIRC, ARMs are more sophisticated than just recognising invalid opcodes. Specifically, there are valid opcodes where some register numbers, which are valid in other operations, are invalid. I'll need to go looking for examples if you need them (I woke to get a drink and visit the bathroom :).

Also, many early RISC processors could not have instructions or some types of data aligned on odd-byte-address boundaries, and would trap if an address has the lower bit set.

  • \$\begingroup\$ Thanks! Any additional detail is welcome. So you agree that an invalid opcode will most likely cause undefined behaviour and ruin the rest of the program? Will the 8085 just keep running nonsense till it encounters a HLT or something? \$\endgroup\$ May 8, 2016 at 3:24
  • 1
    \$\begingroup\$ I used to use invalid opcodes on the 68000 family to generate a trap for software emulation of an instruction that seemed useful but did not exist; handy for implementing floating point without a co-processor. \$\endgroup\$ May 8, 2016 at 13:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.