4 ms·

Congratulations, cptskippy. You just predicted 2001. Intel and HP combined lost to amd64. This time around, Intel will have to take on more than just AMD. You

Congratulations, cptskippy. You just predicted 2001. Intel and HP combined lost to amd64. This time around, Intel will have to take on more than just AMD. You think eschewing backwards compatibility will work better this time?

yuhong 9y ago
It would not be the same as IA-64. My idea would be to ditch the segment registers and act if the segment base is always zero except FS and GS for example, with a new way to handle interrupts etc of course. As a side note, I am thinking that in such a proposal only up to SSE2 should be mandatory, as these are the Intel patents most likely to expire soon. We should also choose either SYSENTER or SYSCALL for 32-bit system calls and make it the same for all x86 vendors (I am thinking of assuming that all OSes are 64-bit and only running user mode programs in 32-bit).
- geezerjay 9y ago
  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

It would not be the same as IA-64. My idea would be to ditch the segment registers and act if the segment base is always zero except FS and GS for example, with a new way to handle interrupts etc of course. As a side note, I am thinking that in such a proposal only up to SSE2 should be mandatory, as these are the Intel patents most likely to expire soon. We should also choose either SYSENTER or SYSCALL for 32-bit system calls and make it the same for all x86 vendors (I am thinking of assuming that all OSes are 64-bit and only running user mode programs in 32-bit).

geezerjay 9y ago
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.