3 ms·

If your feature wish list doesn't translate into relevant performance boosts, you're wishing for a whole new stack of problems and challenges that buy you nothi

If your feature wish list doesn't translate into relevant performance boosts, you're wishing for a whole new stack of problems and challenges that buy you nothing at all. The parent poster was right: you just predicted 2001. Intel and HP combined lost to amd64 because they'd bet on a redesign which failed to provide any meaningful gains. Backward compatibility is there to avoid problems, and nowadays it's highly unlikely that performance gains from new products will be more than marginal.

yuhong 9y ago
IA-64 had plenty of other problems which did not help either. This proposal would make x86 more like a normal "RISC" processor instead without breaking user mode and hopefully not even driver compatibility. Main benefit would be to get rid of a lot of microcode for example.
- geezerjay 9y ago
  IA-64 had its own problems, but your proposal would have its own problems as well. Breaking backward compatibility is all about creating problems, and you failed to point out any gain as a trade-off for all that pain. Getting rid of microcode only causes problems for the potential clients and developers, and for what?
  - yuhong 9y ago
    That is why I tried to keep it to a minimum, with only OSes being needed to be upgraded for the most part. Modern 32-bit and 64-bit user mode programs should still work, but a lot of x86 complexity would be removed. https://news.ycombinator.com/item?id=14560455 https://news.ycombinator.com/item?id=14560455 is a good thread on some of them. Reducing complexity also helps opening x86 to more competition too.
  - 0xbear 9y ago
    Breaking backwards compat isn’t actually such a big deal in certain cloud applications, or for e.g. Java or Go. When you have full control of the stack, a lot of interesting possibilities open up. The main issue is probably that removing old crap isn’t going to save that much die area.
    - yuhong 9y ago
      In this case it would be easier because most JITs and compilers would not have to be modified.

yuhong 9y ago

IA-64 had plenty of other problems which did not help either. This proposal would make x86 more like a normal "RISC" processor instead without breaking user mode and hopefully not even driver compatibility. Main benefit would be to get rid of a lot of microcode for example.

geezerjay 9y ago
IA-64 had its own problems, but your proposal would have its own problems as well. Breaking backward compatibility is all about creating problems, and you failed to point out any gain as a trade-off for all that pain. Getting rid of microcode only causes problems for the potential clients and developers, and for what?
- yuhong 9y ago
  That is why I tried to keep it to a minimum, with only OSes being needed to be upgraded for the most part. Modern 32-bit and 64-bit user mode programs should still work, but a lot of x86 complexity would be removed. https://news.ycombinator.com/item?id=14560455 https://news.ycombinator.com/item?id=14560455 is a good thread on some of them. Reducing complexity also helps opening x86 to more competition too.
- 0xbear 9y ago
  Breaking backwards compat isn’t actually such a big deal in certain cloud applications, or for e.g. Java or Go. When you have full control of the stack, a lot of interesting possibilities open up. The main issue is probably that removing old crap isn’t going to save that much die area.
  - yuhong 9y ago
    In this case it would be easier because most JITs and compilers would not have to be modified.