Where do hardware-related glitches come from?

>>59117188
for two-plus decades, advanced CPUs haven't even remotely resembled on the inside what instruction set streams look like on the outside.

superscalar and out-of-order execution, register renaming, speculative branch taking (and unwinding on mis-predicts), etc. mean that processors are just trying to emulate the side effects of whatever the ISA looks like as quickly as possible.

all these tricks are extremely complicated to design in the first place, then the designers have to make sure they haven't inadvertently violated some promise the ISA already made. hardware mistakes ("errata") of varying severity get found all the fucking time, and it should be at least a little terrifying when you think about how much IRL stuff relies on hardware being near infallible.

>>59117336
So basically what you're saying is, the processor takes what the executable says and does whatever the programmer who designed the microcode thinks is the same thing?

I can't help but wonder if there's a less stupid way to do it

>>59117188

what do you mean by hardware?

theres lots of shit that can go wrong

>malloc

overflows of all sorts etc

The more control you have the more can go wrong. Just look at all the shit bad C programmers have caused so far.