As Computer Engineer: oh well, do I have bad news for you ;-)

Quite a few processors have some undefined behavior, some instructions flags are just not specified, and no not just "this is reserved and must be zero", that would be Ok.

The result of the `bsf` or `bsr` instructions on the 0 value

And please, don't look too much at the FPU either or it may do some random stuff and jump at you.

Indeed, best to avoid any eye contact with the FPU at all.

Only if you define "undefined behavior" as in a very constraint sense (as in "the language specification doesn't specify the behavior").

But CPU architectures also have undefined behavior. ARM for example calls these "UNPREDICTABLE" and "CONSTRAINED UNPREDICTABLE". Have a at the Armv8 architecture reference and grep for those. Lot's of ways to write programs in pure assembly with undefined behavior too!

x86, 6502 and Z80 etc all have undefined / unpredictable behavior too.

6502 is extra fun, because it has "unstable" instructions, whose result would be dependent on specific chip, temperature, and other factors. I can't find the article that dissected some of them anymore, but as I recall it was because of stuff like an (internal) bus conflict with multiple drivers enabled (EDIT: close, but it's even wilder than that).

EDIT: Thanks to IcePic's answer, I found it here: https://web.archive.org/web/20210405071521/http://visual6502...

There is a writeup in PDF here https://csdb.dk/release/?id=198357 about what actually happens on all the unimplemented instructions that still "run" parts of the CPU, some with decent results, and some with less.

And for the last part of your sentence, it depends on what address you run some of the instructions from, since they take a byte out of that in account when doing the weird operations, so some bad instructions can be used, if you are running from $fe00 - $feff because it takes the high byte ($fe), adds one to it, then ands something else with it and lastly produces a result that leads to a usable instruction, but only if the and is with $FF so it doesn't drop bits on you. =)

Lots of weird/fun reading there.

Thanks, but I meant something even more unpredictable, which is hinted at in your document: "ANE [...] is chip- and/or temperature dependent" and "can not be reproduced in visual6502, which hints on it being some analogue side effect that the simulation does not cover".

It's a shame that I cannot find the other article, because I remember that the author actually had looked at the individual transistors, and figured out the bus conflict or whatever it was, which pretty exactly described what happened, and maybe even why some bits would be more "weak" than others.

EDIT: Oh, hah! Your PDF actually links to it in the same section. The wiki seems currently down, but here's an archive.org link of the page that describes the unstable opcode in great detail. So thanks a lot! https://web.archive.org/web/20210405071521/http://visual6502...

I invite you to search the ARM reference manual (the so called "ARM ARM") for the terms UNKNOWN and UNPREDICTABLE. There is also actually UNDEFINED, but in the context of ARM it means that a specific exception happens, so it's pretty much the most PREDICTABLE of the bunch.

The old VLSI Technology Inc (later Philips, now NXP) reference manuals for one of the first ARM processors (the one used in the Acorn Archimedes 305, 310) mentioned that the algorithm used for cache eviction was not something relatively predictable like LIFO or FIFO but essentially random. Which in theory means that if you were 'unlucky' then your program would run slower than for a luckier person etc.

Ha. Though if you're seeing a persistent difference over time, thousands and millions of evictions, your luck is already so immaculately bad that you should expect the power to go out every time you try to run a program.