http://www.3dchips.net/content/story.php?id=3927
That's a nasty one. I guess the only way to fix that is to fix the CPU and replace the CPUs that have already been sold.
Intel Inside! :)
That's a nasty one. I guess the only way to fix that is to fix the CPU and replace the CPUs that have already been sold.
Intel Inside! :)
One of the big advantages of the micro-code conversions is that this kind of thing can probably be fixed.
By the sound of it (from the description) they can probably insert some delay to ensure the bug isn't ever hit, although this will hit performance. It's not a F00F bug by any means.
Mirno
By the sound of it (from the description) they can probably insert some delay to ensure the bug isn't ever hit, although this will hit performance. It's not a F00F bug by any means.
Mirno
One of the big advantages of the micro-code conversions is that this kind of thing can probably be fixed.
By the sound of it (from the description) they can probably insert some delay to ensure the bug isn't ever hit, although this will hit performance. It's not a F00F bug by any means.
Mirno
hey do u know where I can get a desc of the FOOF bug? I remember hearing about the Pentium FDIV bug but not the FOOF one?
A'ight my bad :(
Just joking around, I love that pic and am always looking for a place to use it :) The funny part was that the website is practically named after you (x86.org).
It's not a F00F bug by any means.
It's not? I think it is. It seems to be a bug in the decoder itself, and that part is probably hardwired for speed. We'll have to see if AMD fixes it, and how (they haven't fixed known bugs in Athlon either).
I don't think it's like F00F. I think it is much worse, especially because (only?) x86-64's selling point is IA-32 binary compatibility (in an inferior operating mode).
I liked AMD during 486 days and K6 days, and sort of neutral during GHz frenzy with slight slant, but this is a major turn-off.
I liked AMD during 486 days and K6 days, and sort of neutral during GHz frenzy with slight slant, but this is a major turn-off.
I dont know, I mean no much code uses the Direction Flag anymore, almost always cleared, but I guess you cant take any chances, in otherwords I dont have a thing against AMD. I mean how many million transistors does this chip have? how large is its VHDL source? I mean its a hacked x86 architecture with soo many enhancements, of course its gonna have bugs, we're not dealing with RISC CPU's here..
I mean its a hacked x86 architecture with soo many enhancements, of course its gonna have bugs, we're not dealing with RISC CPU's here..
Is that any excuse though? If the design becomes too complex to manage, I would say the design choices were poor. Perhaps they should have chosen the RISC path instead of extending x86.
Is that any excuse though? If the design becomes too complex to manage, I would say the design choices were poor. Perhaps they should have chosen the RISC path instead of extending x86.
that is exactly my point! :grin:
I think it would be nice for the PC users to migrate to a new RISC architecture that has backward compatibility for the x86 apps.
No, no backwards compatibility, this is why we're still stuck with x86 - and damn AMD for patching this pile of crap patchwork even further with a ho-humm 64bit extension.
No, remove all x86 legacy hardware support (and thus quite an amount of transistors, giving die size that could be used for much better things like more cache), and implement x86 support via software emulation (JITing).
No, remove all x86 legacy hardware support (and thus quite an amount of transistors, giving die size that could be used for much better things like more cache), and implement x86 support via software emulation (JITing).
Ever will the past be flawed and the future brighter.
I think it would be nice for the PC users to migrate to a new RISC architecture that has backward compatibility for the x86 apps.
We've had that since Pentium, basically.
They are RISC-CPUs with an x86-to-RISC translator in front. But it doesn't help much. Some people think that this means you get RISC performance... But you don't. The RISC backend is fine, but because you have to use it through the x86 instructionset, you cannot take full advantage of it. You still have a low register limit, 2 operands, and such.