Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I wonder how design decisions like this happen. Surely there's existing reserved/invalid, instead of existing "valid and theoretically useless, but may possibly be emitted by a sufficiently stupid compiler" opcode space they could've used?

On x86, Intel has both reserved-invalid (generates an exception) and reserved-valid (acts as a NOP) space for future instruction extensions which are intended for code that's exclusively used on CPUs supporting them and code that only serves as a hint for supporting CPUs but harmless otherwise.



Opcode space is limited on fixed-width instruction CPUs and expensive on CPUs with potentially ‘unlimited’ numbers of instructions such as the x86.

Why waste part of it if you can instead take it from an instruction that already wasted some opcode space?


It is useful to use an existing legal op code for this, because the code is still compatible with older (or less optimized) cpus that don’t exhibit the behavior.


The reason you do this is because you have an instruction that means nothing. You save space by recycling it. Why bother making a new instruction? That's against the whole idea of RISC.

It's not their problem if the compiler writer doesn't read the documentation. I mean, the documentation is literally written for them.


I haven't done a ton of PowerPC assembly but I knew this. Frankly, it seems that the people writing the PowerPC output didn't know PPC that well, which is always a problem. There are probably more bugs than this.


I wonder if the valid NOPs "payload" are used by debuggers?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: