Slashdot Mirror
Linus on Intel's 64 bit Extensions
ceswiedler writes "KernelTrap is running a thread on the Linux-Kernel mailing list about Intel's new IA-32e 64-bit chip. Linus complains 'what I found so irritating is that _hours_ after the Intel announcement,
people were _still_ confused about whether the new intel chip was actually compatible with AMD's chips.' It is, of course, but you have to do a thorough comparison of Intel's reference manuals to discover that-- they don't mention the fact that their new chip is instruction-set compatible with AMD's x86-64 chip." See the previous story for background. So it looks like the reason Intel was vague about their announcement is that they didn't want the WORLD TO KNOW THAT THEY WERE COPYING AND FOLLOWING AMD rather than developing some new thing on their own. Slashdot is proud to help Intel in this quest; wouldn't want the public to know that INTEL WAS SIMPLY FOLLOWING IN AMD'S FOOTSTEPS. Hope this helps.
so, exactly how soon can i expect to see them on my desktop? does it make linux look any better? i doubt it. if you ask me, 64 bit is way too ahead for its times.
How does this serve their interests? I don't understand were the pressure was coming from.
If the extensions were not compatible I could easily see Intel pushing AMD out of market.
-ashot
It's about bloddy time. Isn't that what's next?
"The absurd is clear reasoning recognizing its limits"
-Albert Camus
Intel had no choice but to use AMD's instructions if they wanted their chips to be Windows-compatible.
Paper Launch or not, we need to know a little bit more about what changes are going to be made to the memory controller and bus specifications.
i rer.net
Linus should have also come out with Transmeta's plans for implementing iAMD64....
It is an exciting time when Intel is taking a following to AMD.
Sources for AMD info:
http://www.amdzone.com
http://www.theinqu
Will the Windows 64 Demo work on Intel's 64 bit implementation as it currently sits?
They're damned when they go AMD and would be double-plus dammed if they didn't.
Intel doesn't have to be as careful as you may think. The general public has no idea about Intel/AMD differences. This makes it much easier on Intel to just keep producing crap that is just couple tenths of a gigahertz faster and pass it off for a few hundred more dollars and make more profit. AMD is still not close to taking the processor lead.
those people who think they know everything are a great annoyance to those of us who do. -isaac asimov
Uhm, didnt i read somewhere that Intel licensed AMDs 64bit extensions? Just the same as AMD license ia-386 stuff from Intel? This may be covered in the article, which I cant currently get to, and i just cant be bothered to google.
The ascent of modern business:
Microsoft: embrace and extend
Intel: embrace, extend, and don't get sued for monopolistic practices
PA-RISC and Itanium are completely different.
A deep unwavering belief is a sure sign you're missing something...
Given a general cpu register like eax it looks like this:
31--------------15-------7------0 Bits
|--------------eax--------------|
|------ax------|
|--ah---|--al---|
And now AMD's come up with the brillant idea of extending a register. The 64 bit accumlitive register is now RAX with it's low 32 bits being EAX and the low 16 are ax and so on.
The continuation of adding on register extensions is great for backwards compatiblity but it makes the instruction set a mess. Intel knows this but people don't seem to be will to give up compatibility or performace. The only way this is probably ever going to go away is if every one is forced to write a C compiler.
The sad thing is that a new cpu could have a compatibility layer that had a slight performance hit but with a lack of software supporting new 64 implementations people wouldn't buy it because the pretty little bar graphs that the sales drones produce.
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
Seriously people, everything but x86 is Big endian, and we (embedded software people) have endian issues all the time. Wil there finally be 32 and 64 bit big endian instructions?
PLEASE SAY YES!
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Downplaying the announcement wasn't just to keep down the shame of following their chief rival, it was also to confuse those in the current market for a new server. From what I understand, Itanium/Itanic has been a serious flop thus far. What will the motivation be for IT departments to buy Itaniums now if they know something more compatible and better for them is coming along Real Soon Now?
Original AC posting again.. Hate to follow up my own shit, but my comments were based on my old knowledge of Intel chipsets.
Much to my chagrin, I went to my favorite online shop and looked up Intel based motherboards. The third-party motherboards all had Firewire ports (Asus, Gigabyte, etc) but the 'Genuine Intel' motherboards? No dice.
So, to this day, Intel is still playing the "we didn't make it therefore it sux0rs" game. You'd think the millions of MiniDV camcorders and the fact that their competitors are offering more featureful motherboards would convince them otherwise.
Intel has their own Reality Distortion Field. They need to be careful, Steve Jobs might take offense. </joke>
"they're adopting a technology developed by a company a fraction of their size with a fraction of the resources. It gives AMD much more credibility."
How much credibility is AMD really lacking when buck for buck they've almost always been a better deal for the speed than Intel? How much are they really lacking when they beat Intel to the 1 GHz mark and for a long while thereafter had the fastest x86 desktop chip on the market? Or when they beat Intel to wide market penetration with 64 bit chips? Or when they beat Intel to 64-bit on the desktop? Or when benchmarks showed that the Athlon FX-51 beat both Intel's flagship and PPC chips?
If AMD doesn't have credibility now, this 'specification war' won't give it to them if you ask me.
Cheers
~Dalcius
Rome wasn't burnt in a day.
Since AMD followed in Intel's footsteps regarding instruction sets for so long, it's ironic that the first external set that Intel has used gets so much negative publicity.
In fact.. I can't figure out why Intel gets so much negative publicity in general (particularly on Slashdot). What marketing practices does Intel employ that are really so bad? Intel seems much more benevolent than a vast majority of companies. I certainly wouldn't say it's business practices are worse than AMD. Did AMD ever say: "Hey Intel, great job with your new instruction set!" And if you say that AMDs new instructions are superior, you may want to think about what the concept of 64 bit extensions really mean. Any way you look at it, it's a messy patch job, and it's not surprising that Intel wanted to avoid it.
I was once layed off from Intel, and if anyone should resent the company, I think I have that right. However, this type of biased slander is completely unwarranted. I hope you realize that AMD's marketing strategy relies on this type of 'underdog is always superior' mentality to gain market share. Intel relies on the 'the most popular must be the best' mentality. Which is worse? Buying into either one means you are the one that really loses. Seeing it as a front cover story is very disturbing.
The parent was talking about the best performing memory.
Business practises and evil patents don't change those numbers.
The owls are not what they seem
Alright, alright, alright.
3dNow!, while possibly one of the silliest names for an instruction set extension, is not just a rip of MMX.
3dNow! was the first x86 floating-point vector extension. In that respect, it's far more similar to Altivec. 3dNow! DSP (of Athlon fame) is also not a rip of Intel.
Intel later decided to add their own floating-point VMX, namely SSE, on (iirc) the PIII.
SSE only became available in AMD-land on the AthlonXP, and SSE2 is only available (to my knowledge) on the Opteron-class chips. Those of us doing vector optimization on x86 would love it if these four instruction sets were compatible, but they're not.
http://www.pbs.org/cringely/pulpit/pulpit20021226. html
Either way, it only helps the consumer to have a standard like this.
I remember when compatability with existing platforms was a Good Thing.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
All that is part of the x86(-32) instruction set that Intel developed and AMD executes natively with their chips.
Come on, I mean. Next you'll want me to break out the LDA instruction and make sure Intel gets credit for it separately from any other assemboy instruction.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
No, you have a good point. All of those boards use a PCI firewire controller chip and are higher-priced "luxury" models. At one time Intel promised to integrate 1394 directly into their core chipset, which would mean that it would be available on 100% of boards.
No kidding. I was expecting a slightly modified "consumer-grade" Itanium, possibly renamed the Pentium-64 or some such, and then AMD having to scrap their 64-bit chip to copy the Itanium. That's what I would have done if I were Intel. Think about it: no real development costs, lots of new development cost for your only real competitor, and the ability to pitch the 8086 finally. The only real cost would be a new advertising campaign, and manufacturing facility conversion.
Best Slashdot comment ever
Rambus was a different way of organizing memory. In some ways it was better in others worse. I liked the analogy of using a train (RAMBUS) or a fleet of trucks (SDRAM) to deliver data. The train works great when you have to move a ton of stuff from one place to another, the trucks work better when you have to move lots of little loads from many places. Video editing is an area where RDRAM shines, multitasking is a disadvantage. Now there were many things that served to help RDRAM in its disadvantages, the P4 was developed to work very well with RDRAM it loved the bandwidth and made up for the latency with clock cycles. Dual channel was a big part of the enhancement, too. Have you ever been stuck on a machine with only a single stick of RDRAM or a P3? DDR was much faster. Once you got over about 128 MB of RDRAM you ended up waiting a long time for the addressing scheme to access different portions of RAM. When you pulled from each area sequentially, it was wonderful. I'm typing this from an early P4 that used RDRAM and it works quite well, but I wish the company had waited for socket 478.
Price performance was an easy win for an Athlon with DDR in those days. I'd love to find the powersupply and finally put together a dual xeon with a whole boatload of RDRAM and some fast drives.
Degaussing scares the bad magnetism out of the monitor and fills it with good karma.
you are correct, but are missing a key issue here. The way it works now is amd pays intel for the "intellectual property" they use, but the agreement favors intel as they don't have to pay amd for copying their technology. Don't you just love our legal system?
A Fatal OE Exception has occurred, Sig will now reboot.
Your right on the licensing between Intel and AMD. But Intel created the SSE1 and SSE2 optimizations as a way around that.
It is fairly well-known to insiders that Dave Cutler, chief software architect for Windows NT at Microsoft, approached AMD with the concept of extending the x86 instruction set for 64-bit instructions and data.
The motivation for this move was probably complicated, but Intel's slow-motion malaise regarding its IA64 strategy was no help. Microsoft needed a 64-bit platform that would gain wide acceptance before it devoted a significant amount of resources to drive Windows support on the platform to consumer-level quality.
Some even make the further claim that Cutler may have actually designed the instruction set for AMD and handed it to them intact. In other words, he approached them and said, "If you build a chip that runs this instruction set, we can guarantee NT support for it, and backwards compatibility with x86-32 will come for free."
AMD even acknowledges Dave Cutler and has a page with his information on their web site. If you do a search for articles, you'll find supposedly leaked memos mentioning builds of NT running on the new chip before it was even announced publicly (and hence before SuSe knew about it either).
You be the judge.
Everything I've heard (admittedly hearsay) said that Intel switched was going for VLIW because the vendors didn't want a hybrid chip with 64 bit hacks on a 32 bit hack on a 16 bit hack of an instruction set, so they set out to make a pure 64 bit CPU. And I don't blame Intel for not wanting to make a pure RISC ISA because it's been done before.
Intel supposedly could have had Yamhill technology in PIII but no hardware vendor wanted to bother with it.
They did. Have you heard AMD use any other names for MMX, SSE and SSE2 than MMX, SSE, SSE2. They also note in there documentation that their implementations are compatible with Intels.
Notice btw, that SSE was just Intel last attempt of trying to get around having to copy AMDs implementation. SSE is really superior, just more featurefull, which could have come from extending 3dnow as well.
The pain of a wacky instruction set is isolated in the translation part of the chip, and doesn't significantly hold back the chip in other ways.
Actually it does. The extra translation stage leads to longer pipeline delays, which tend to slow down the chip when has to branch. Most of these delays are mitigated by branch prediction logic in the processor. This branch prediction logic adds considerably to the complexity of the chip (hence size and cost). It costs intel lots of development bucks to keep this compatibility and while trying to increase processor performance.
Intel is seeing the end of the road for the x86 architecture and wants to start down a new path with the IA64 architecture.
I know of nobody who has a xeon in a home pc meant for games. This chip is not being marketed in that segment nor will it be priced to compete there. It _will_ affect their Itanium sales.
Just to be clear, I never said that I thought the extended Xeons would target games. I think they will target graphical workstations(for solidworks, SI etc).
If you think that the new extended 64bit xeons will take Itanium2 place as their 64bit server product, well ok. That's your view on things, personally i dont think thats the case.
I think they target home desktop/pro workstations with IA32e and the server marked with Itanium2.
Translation logic... Size of microops in reordering queus=more area for reordering queus more power comsumption, and smaller reordering windows.
The pain of a wacky instruction set is isolated in the translation part of the chip, and doesn't significantly hold back the chip in other ways.
Yeh right like power comsumption was not an issue these days? And strick memory ordering rules complicate memory ordering doesn't hurt? The fact remains that intel and AMD get their chips so fast in INTEGER because a) They are made with more advanced process than any RISC. b) They trow lot of engineers to deep optimization tasks. c) Alphacide happened, =Managers killed a company and got personal profit out of it, and killed the fastest RISC processor family that was practicly only family as much hand optimized for speed as X86 is these days. [They had their 0.35u processors running faster than any 0.18u intel processor!] [2 process generations difference.]
RISC fans predicted years ago that CISC would die, because RISC is so much better.
They under estimated need for compability. Nothing more. nothing less.
But CISC chips contain RISC cores these days,
RISC was coined with many PROGRAMMER VISIBLE registers architecture optimized for COMPILER target, load/store architecture, and REDUCED complexity. You should read the acronym properly (Reduced Instruction) Set Computer.
And the old idea that RISC instructions would win because they are easier to decode didn't pan out.
Risc superiority cannot beat the amount of hand optimization that goes in intel/amd chips its because of volumes. Besides decoding was only a PART of advantage.
CISC instructions get decoded to RISC-like micro-ops, as I said, and it turns out not to be a huge deal.
It is, only thing is that you have to be Electrical Engineer who designs micro chips to fully realize WTF the big deal is. Besides being better compiler target by having large and regular register sets and staying without non register dependencies between instructions. [Flags, complicate reordering.]
Meanwhile, those CISC instructions are denser than RISC instructions, so you fit more of them into your limited cache space, which helps speed.
This is blatantly FALSE statement. P4 takes 72bits per instruction in Icache and AMD takes 11Bits per byte Icache inorder to have acceptable parallerism. So instruction cache sence RISC beats both hands down, on dencity.
In short, modern chips do all kinds of clever stuff, and the instruction set architecture is not really holding them back.
In short with a clean 64bit risc with EQUAL developement resources /hand optimizations compared to INTEL/AMD and equal volumes, we would get more parallerism than opteron and about same clock speed as P4 at similar costs. But unfortunately RISC high end is not high volume, and that dooms it from practically getting big chunks.
If you want me to feel sad, you need to back this up with some facts. Show me why you feel the Athlon64 would be faster if it were not backward-compatible with x86.
A) FPU, FPU, FPU !!!! The FPU has been crap. Always on X86. PPro was 1/2 as fast as equally clocked INORDER alpha with 1 integer and 1 FPU pipeline in floating point.... Remeber that intel required one process generation advantage and extreme packaging to get there. Today it has't really changed.
B) FLAGS!!!!! Screw the flags they complicate REORDERING LOGIC.
C) Simplicity gives a huge advantage, from implementation point of view. Less rules to adhere to. Less tricky logic trying to work over the braindamaged ISA and some really complex and large units can be simplified a lot. Like Reordering side, and control logic. And all the partial register dependencies yak
For me as EE st
Emacs is good operating system, but it has one flaw: Its text editor could be better.
Yes, when you give a product a name based on the number of bits it processes at once you should double the number in its successor even if the number of bits hasn't changed. For example Soundblaster 16 (for 16-bit samples), then Soundblaster 32 (for the number of FM channels it has) and then Soundblaster 64 (for the number of channels the software supports). So Intel should have said Itanium 2 implemented the IA-128 architecture, leaving them free to use the number 64 for the Pentium V or whatever it is.
Yep, Intel is especially bad about this, since they see using anyone else's technology and admitting it as a sign that their "leadership" is failing.
You can see this on Intel motherboards: every other motherboard out there comes with IEEE1394 ports standard now, along with components from various vendors (ethernet, sound, etc.). Intel boards only have Intel components, and nothing else. Since Intel doesn't make an IEEE1394 controller (and doesn't want to since it competes with USB2), their motherboards don't have them. Got a firewire DV camera? Better not get an Intel motherboard.