C++ is faster and safer than Rust (2020)

Re:C++ is faster and safer than Rust (2020) by anyfoo on Thursday October 07, 2021 @02:06AM (#28782730)

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...

[ Parent | on HN ]

Re:C++ is faster and safer than Rust (2020) by IcePic on Thursday October 07, 2021 @02:22AM (#28782866)

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.

[ Parent | on HN ]

Re:C++ is faster and safer than Rust (2020) by anyfoo on Thursday October 07, 2021 @02:30AM (#28782922)

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...

[ Parent | on HN ]