3 ms·
The point is, it didn't matter as people wrote assembly by hand, and it doesn't matter now when everybody is using compilers. The opcode details are trivially s
by acqq 7y ago
The point is, it didn't matter as people wrote assembly by hand, and it doesn't matter now when everybody is using compilers. The opcode details are trivially solved by the tables, the know-how of those who programmed assembly was enough for most of the times they programmed, compilers can handle a lot, and the real problems that really have to be solved are simply not dependent on these issues at all.
And diagonally, the instruction set is surely not the reason why every internet page is tracked by thousands of companies and has to download more megabytes than the total RAM the whole x86 computers had.
And like I've said, all instruction sets since a while have to take care to be "compressed" in a way, which is simply a total opposite of what the critics pointed since RISC was introduced. Pure RISC was/is useful only under some very specific assumptions.
The appearance of "mess" is a result of "if was successful." But the problems it solved were/are real.
- Dylan16807 7y ago"It doesn't matter" (much) that it's a mess is one thing. "It's not a mess" is quite another. But 'compression' and 'mess' are very very different things. You can have organized compression. Look at the length encoding on RISC-V, or something. No prefix bytes in sight. On x86 the balance and methodology for getting different instruction sizes is completely garbage for historical reasons. > The appearance of "mess" is a result of "if was successful." But the problems it solved were/are real. It's because it's been collecting legacy since it was 8-bit all the way to 64-bit with vector units, not as an inevitable result of being successful.