4 ms·
The only thing better than being able to blame the compiler for something, is being able to blame the CPU
by LispSporks22 3y ago
The only thing better than being able to blame the compiler for something, is being able to blame the CPU
- print_goto_ten 3y agoGreat tshirt
- peheje 3y agoSaving that quote.
- amelius 3y agoBut how are you going to fix it then?
- wongarsu 3y agoChange your code to not trigger the bug, and leave that workaround there for the next decade or so until the buggy CPU generation isn't relevant anymore. Or hope for microcode updates to fix the bug at the CPU level.
- amelius 3y agoThat's my point ... it's a lot harder to do this than to just fix it in your own code.
- JonChesterfield 3y agoYou change the compiler to carefully step around the stuff that doesn't work in the hardware.
- pajko 3y agoCompilers can be patched to automatically do some masking in the code generation step after every LDRB instruction in this case, when compiling for that specific CPU. For example, the Blackfin DSPs have many similar bugs which are fixed this way. Some of which the fixes done automatically, while others could be disabled for performance critical code which has been implemented while keeping the various issues in mind, like -mcsync-anomaly and -mspecld-anomaly. Certain MIPS CPUs also have incorrectly implemented instructions and the -mfix-* compiler parameters could be used to enable workarounds. JIT compilers can do the same.