3 ms·

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

by arbaal 5y ago

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.

anyfoo 5y ago
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.org/wiki/index.php?title=6502_Opcode_8B_(XAA,_ANE) https://web.archive.org/web/20210405071521/http://visual6502...
- IcePic 5y ago
  There is a writeup in PDF here https://csdb.dk/release/?id=198357 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.
  - anyfoo 5y ago
    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.org/wiki/index.php?title=6502_Opcode_8B_(XAA,_ANE) https://web.archive.org/web/20210405071521/http://visual6502...

by arbaal 5y ago

anyfoo 5y ago

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.org/wiki/index.php?title=6502_Opcode_8B_(XAA,_ANE) https://web.archive.org/web/20210405071521/http://visual6502...

IcePic 5y ago
There is a writeup in PDF here https://csdb.dk/release/?id=198357 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.
- anyfoo 5y ago
  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.org/wiki/index.php?title=6502_Opcode_8B_(XAA,_ANE) https://web.archive.org/web/20210405071521/http://visual6502...