3 ms·

One thing you'll often find is that processor vendors like to release instructions that expose already-existing capability within the chip, but which previously

One thing you'll often find is that processor vendors like to release instructions that expose already-existing capability within the chip, but which previously wasn't directly accessible. I doubt this takes a remotely significant amount of silicon. Plus, it's all part of the XML hype: people include XML-related technologies in software and now even hardware (they've marketed these as, among other things, accelerators for XML parsing) solely for the purpose of being "Enterprise-grade". Here's a fun fact for you: a very very major network hardware vendor sells extraordinarily expensive boards with "hardware XML parsing" (that's how they can charge so much). In reality, it turned out to be a nightmare to implement, so they just did it in software--and didn't tell their customers.

mahmud 17y ago
It's the exposure that's bad, not the existance of the capability in silicon. Think of all the programmer-hours that will go into retrofiting compilers, libraries and runtime with "hardware accelerated text processing", just because some bonehead PHB heard this news and suddenly wants it? They could have done the right thing and started stripping x86-32 cruft from x86-64 as it gained more traction. As time moved on, we would have had a clean architecture with features being deprecated instead of being added.
- DarkShikari 17y ago
  Think of all the programmer-hours that will go into retrofiting compilers, libraries and runtime with "hardware accelerated text processing" Don't worry, odds are almost nobody will actually use it. They could have done the right thing and started stripping x86-32 cruft from x86-64 as it gained more traction. There isn't really any "cruft" that matters; the old useless instructions do nothing but waste instruction code space, but that's not really a big issue; the real significant improvement would come by re-doing x86 as a three-operand architecture (and make other similar improvements that would be impossible to do "bit by bit"). Another potential improvement would be to just re-do the instruction coding to make it faster to parse; instruction decoding is becoming a significant bottleneck on x86 already. If Intel was going to do an overhaul like that, though, they'd just do it all at once. AVX is actually beginning to go that way; we're going to have three-operand for SIMD, even though we won't have it for regular instructions.
  - limmeau 17y ago
    What's the difference between "re-doing x86 as a three-operand architecture" and switching to a different 64-bit RISC architecture?
    - DarkShikari 17y ago
      The former could probably be done without a complete retooling of the chip designs.
      - limmeau 17y ago
        I don't think it will happen, though; the ratio of people who care about the elegance of their processor's assembly language to people who buy computers is just too low. Not in form of a clean cut, at least: x86-64 brought us eight additional registers and removed the silly BCD-instructions.
tptacek 17y ago
Are you sure "really did it in software" doesn't mean "managed to get a hardware configuration that admitted a fast C implementation"? There's several boutique network hardware vendors that have played games with the MIPS architecture --- multicore with very customized memory bus --- to get themselves to a point where they can set speed records on text processing with C code that will only run on their boards.
- DarkShikari 17y ago
  No, I have a friend who works for an FPGA vendor; the Major Network Hardware Vendor bought FPGAs for them to use for XML parsing, but eventually found that a software implementation was faster and easier--but they kept the FPGAs on the boards so that they could charge $30k a pop for them.

mahmud 17y ago

It's the exposure that's bad, not the existance of the capability in silicon. Think of all the programmer-hours that will go into retrofiting compilers, libraries and runtime with "hardware accelerated text processing", just because some bonehead PHB heard this news and suddenly wants it? They could have done the right thing and started stripping x86-32 cruft from x86-64 as it gained more traction. As time moved on, we would have had a clean architecture with features being deprecated instead of being added.

DarkShikari 17y ago
Think of all the programmer-hours that will go into retrofiting compilers, libraries and runtime with "hardware accelerated text processing" Don't worry, odds are almost nobody will actually use it. They could have done the right thing and started stripping x86-32 cruft from x86-64 as it gained more traction. There isn't really any "cruft" that matters; the old useless instructions do nothing but waste instruction code space, but that's not really a big issue; the real significant improvement would come by re-doing x86 as a three-operand architecture (and make other similar improvements that would be impossible to do "bit by bit"). Another potential improvement would be to just re-do the instruction coding to make it faster to parse; instruction decoding is becoming a significant bottleneck on x86 already. If Intel was going to do an overhaul like that, though, they'd just do it all at once. AVX is actually beginning to go that way; we're going to have three-operand for SIMD, even though we won't have it for regular instructions.
- limmeau 17y ago
  What's the difference between "re-doing x86 as a three-operand architecture" and switching to a different 64-bit RISC architecture?
  - DarkShikari 17y ago
    The former could probably be done without a complete retooling of the chip designs.
    - limmeau 17y ago
      I don't think it will happen, though; the ratio of people who care about the elegance of their processor's assembly language to people who buy computers is just too low. Not in form of a clean cut, at least: x86-64 brought us eight additional registers and removed the silly BCD-instructions.

tptacek 17y ago

Are you sure "really did it in software" doesn't mean "managed to get a hardware configuration that admitted a fast C implementation"? There's several boutique network hardware vendors that have played games with the MIPS architecture --- multicore with very customized memory bus --- to get themselves to a point where they can set speed records on text processing with C code that will only run on their boards.

DarkShikari 17y ago
No, I have a friend who works for an FPGA vendor; the Major Network Hardware Vendor bought FPGAs for them to use for XML parsing, but eventually found that a software implementation was faster and easier--but they kept the FPGAs on the boards so that they could charge $30k a pop for them.