3 ms·

If they somehow magically knew the future of the whole industry decades in advance, and were able to design the perfect ISA based on that, sure. But that's not

by lmm 2y ago

If they somehow magically knew the future of the whole industry decades in advance, and were able to design the perfect ISA based on that, sure. But that's not how things go in practice. If they'd put in all the opcodes that they thought would be important in the future back in the '80s and implemented them in microcode, I guarantee that we'd be a whole lot worse off now, with loads of pointless opcodes for 5GL and semantic networks and all the other dead ends of the era, and no space for things that turned out to be important like POPCNT.

adrian_b 2y ago
POPCNT was not from the future, it was from the past. The Intel designers only assumed that this belongs to the operations that would not be frequently used in the applications expected for their processors. This was caused in part because they were not personally familiar with such applications. Even if POPCNT actually has a very wide area of applicability, during the seventies of the 20th century the only people who were concerned with the speed of executing POPCNT were some who worked at cryptographic applications and at that time almost all such work was classified. However, with such operations there is always a chicken and egg problem. When they are not implemented in hardware, the programmers and the compiler writers avoid expressing algorithms with them and use various workarounds to implement in a different way the algorithms that would benefit from them. This leads to a low frequency of use of such operations, which is then used to justify that it is not necessary to implement them in hardware. The correct analysis whether such operations would be worthwhile when implemented in hardware requires much more work in writing alternative versions of various algorithms, to be run in simulated hardware, and this is almost never done.
- sumtechguy 2y ago
  There are also a few different algorithms to handle it https://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetNaive https://graphics.stanford.edu/~seander/bithacks.html#CountBi... x86 started as basically a calculator chip. Not a lot of need in that particular space/usecase for it, and more importantly silicon space for it. However, what is interesting is how long it took to add it to the x86 set of instructions. But at least we have it now.

by lmm 2y ago

adrian_b 2y ago

POPCNT was not from the future, it was from the past. The Intel designers only assumed that this belongs to the operations that would not be frequently used in the applications expected for their processors. This was caused in part because they were not personally familiar with such applications. Even if POPCNT actually has a very wide area of applicability, during the seventies of the 20th century the only people who were concerned with the speed of executing POPCNT were some who worked at cryptographic applications and at that time almost all such work was classified. However, with such operations there is always a chicken and egg problem. When they are not implemented in hardware, the programmers and the compiler writers avoid expressing algorithms with them and use various workarounds to implement in a different way the algorithms that would benefit from them. This leads to a low frequency of use of such operations, which is then used to justify that it is not necessary to implement them in hardware. The correct analysis whether such operations would be worthwhile when implemented in hardware requires much more work in writing alternative versions of various algorithms, to be run in simulated hardware, and this is almost never done.

sumtechguy 2y ago
There are also a few different algorithms to handle it https://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetNaive https://graphics.stanford.edu/~seander/bithacks.html#CountBi... x86 started as basically a calculator chip. Not a lot of need in that particular space/usecase for it, and more importantly silicon space for it. However, what is interesting is how long it took to add it to the x86 set of instructions. But at least we have it now.