Maybe people should try and think alittle before declaring intel the big bad boy.

Imagine you make a compiler that use SSE1-2-3/MMX/64bit and so on with any CPU that got them.

Now you have to validate everything with every CPU. So basicly Intel would need to validate itĀ“s compiler against any AMD, any VIA, any Transmeta CPU etc. And if it should bloody fail on another CPU using any extensions...damn I could smell lawsuit. Thats why the Intel compiler uses the failsafemode on non Intel CPUs.

Imagine yourself, selling a car from vendor A, your customer changes the engine to Vendor B. But you as vendor A still have full responsiblity about anything on the car. Is that how business should be?

Intel uses ALOT of money on quality testing, the same reason alot of people buy Intel. You buy assurance and quality. Not some perfect AMD cpu with some crappy nforce/via chipset on a too cheap taiwan motherboard that will fail before you even get to the point of upgrading.

This is what Intel says about there compiler as of 3:00 PM est 7/15/05

"*Accelerate Windows* Applications

Develop high-performance software for desktops, servers, handheld devices and mobile phones that is optimized for IntelĀ® architecture using IntelĀ® Compilers for Windows*."

It says right there that they are optimized for the Intel architecture.
http://www.intel.com/cd/software/products/asmo-na/eng/compilers/219...

Tht's exactly what Intel's page says in the first paragraph when describing all of their compilers. But what I have explained is that the Intel Visual Fortran compiler (originally Compaq) was specifically dumbed down for AMD processors. There were no improvements added for Intel processors. That action specifically harmed previous purchasers of AMD processors and that action is the basis of the antitrust allegation.

There is a lot of history to the "Intel" compiler that the readers should know in order to evaluate AMD's complaint.

The "Intel" compiler started life as Microsoft "Power Fortran." It was sold to Compaq sometime in the late 90's and became the Compaq Visual Fortran compiler. It's Microsoft origins is why is has the name "Visual Fortran."

The compiler was subject to much controversy in 2002 and 2003 when BAPCO, who shared office space with Intel, created a set of benchmarks using the then Intel Fortran compiler. One of the items noticed by Van Smith of Vanshardware was that changing the string "Genuine Intel" to "Authentic AMD"(both 13 characters) significantly improved the scores of the AMD processors in the BAPCO benchmarks to the delight of the AMDroids. Many of the Intellitubies cried foul and said that you wern't allowed to change the software on a benchmark to make a given processor run faster.

One of the side discussions was that both AMD and Intel processors ran faster on the then Compaq Visual Fortran compiler. But AMD's performance improved much more and was superior. Shortly after the controversy, BAPCO disappeared from sight and Intel acquired the Compaq Visual Fortran compiler and renamed it the Intel Visual Fortran Compiler. The same deal also saw the Alpha killed. (The Alpha was clearly superior to the then x86 processors).

I was troubled by the deal at the time an I have always wondered why DOJ never objected. Anyway, the now Intel Visual Fortran compiler seems to produce code which runs very poorly on AMD processors and has the same objectionable test ("Genuine Intel" vs "Authentic AMD") that the original Intel compiler used.

It would seem to me that this is a clear case of buying a propduct that made AMD processors look good and "dumbing" it down. So while many Intellitubies may observe that there is nothing wrong with Intel writing a compiler which makes their processors look better than AMD's, I find there is a problem with Intel buying third party software used by AMDroids and making it worse. The AMD customers were harmed and that is the basis of the antitrust complaint.

I've been thinking this was the case for years. Why hasn't this been realized sooner? It makes total sense for Intel, the competitor, to make it's compilers do goofy things for their competition.

Sure it's evil, but is Intel really in the wrong? I mean they are out to win not put millions into compiler development that helps AMD too. Does AMD deserve a free-ride compiler? Maybe Intel should be required to put something like "optimized for Intel CPUs" on the info sheet.

It's an interesting argument. I don't think AMD can afford to develop their own compiler. It would take years and years too.... Obviously I'd think Intel's compiler will always be faster than MS's, but I've also read that Inte's compilers are a bitch to use.

I suppose someone in Intel doesn't believe the compiler should trust a processor when it says it can do something but isn't a GeniueIntel processor. I suppose this could be true but it really is a poor programing decision.

Does anyone know any details regarding the AMD/ Intel SSE/SSE2/SSE3 licensing agreement?

As a layman, the way I see it is that AMD licensed these instruction sets from Intel only to have Intel actively prevent their usage on its cpus with a actively mass-marketed product aimed at developers creating code for all x86 platforms.

To use the Ford analogy, I see this as being equivalent to Ford:

1) Having the monopoly on car sales
2) Licensing an engine component to its competitors, which they pretty much have to license because all new forms of fuel will seek to use it for optimal performance
3) Then selling a widely used form of fuel (sold as being optimised for Ford cars, but capable of running in any car), which, in additional to not using the new engine component, actively misfires when it detects it is running in a non-ford engine(as suggested by these stories regarding "per byte" memcpy).

Am I right with this?

Wow there is alot or bias intel people in here. What intel is doing with the compliers is wrong, checking for the instruction set and not the cpu type is what the complier should be doing as many have stated. Why would they license these to AMD then to just cripple the processors whnen trying to use these instructions! it is wrong plain and simple! it is irrelvant if AMD makes there own compliers or not. This act is anti competitive.

I can't believe I am gonna do this.....First Post!

Wasn't there something with Window Media Encoder a while back when the AXP first got SSE? I think it had something to do with Sysmark. So I think the idea is not really that new.

The fact of the matter is SSE, SSE2 and SSE3 are Intel's intelllectual property. AMD processors really don't have *genuine* SSE, SSE2 and SSE3 instructions...they are reversed engineered versions of them. For example, AMD's SSE3 is missing instructions related to Hyperthreading. Thus it's really NOT SSE3, but a bootlegged version.

I too would see no reason to support such reverse engineering of my intellectual property if I were Intel. In fact, if I were Intel, I would make it so the ICC would simply refuse to compile for AMD processors.

The fact is this lawsuit is nothing more than a PR stunt by AMD. It has no legal basis whatsoever.

What is the problem here?

That AMD donĀ“t make their own compiler?

Or that Intel maybe donĀ“t wanna boost itĀ“s compiler on AMD chips, or using the failsafe method so the compiler wont crash something.

ItĀ“s pretty simple, if you are unsure..go the safe path. And you have no extra enchancements. I canĀ“t really see a problem here. Unless you actually want an unfair business model were intel have to help and boost performance on AMD CPUs with itĀ“s own compiler.

Also the crash part is a pipedream. Performance difference yes..crash..no. I have both AMD and Intel systems, and I have coded for both. And itĀ“ s not like the standard compilers does any good for any CPU. So basicly when Intels compiler is used, we get same performance on AMD chips (or better in most cases), but always better performance on Intel chips. If thats a problem for AMD, I still wait to the enjoyment of buying a compiler from them...when they make one.

Edit: the title of this article is misleading. It should be "Does Intel's Compiler only Accelerate Intel CPU Performance?"

Hold on, wait. What?! In no way is making my compiler only perform faster on my chip, anti-competitive. Now, if I made my compiler explicity work slower on other chips, that would be. There IS a difference, as trivial as it may seem.

Herbal Essences shampoo works better when followed by Herbal Essences conditioner... "But I wan't to use Suave!" So sue Clairol? No!

Come on! I made my compiler for me. I give it to people who understand it is made for my chips, (pro-AMD developers DO NOT use the Intel compiler because it doesn't even compile on non-GenuineIntel systems) and I understand that I may make some people mad.

But in the end, I do want JUST my chips to succeed! That's the point of all business ventures. I mean... would anyone create a business to be *just* second?

If AMD wants a good compiler, make it on their own. For now, I will make mine for my chips.

Besides... it's not as if the compiler says "If AuthenticAMD then make slower."

I found this issue myself about a year ago via a post on comp.arch. Since then I've post-processed my Intel C compiler executables to remove the "GenuineIntel" trademark check. I admit I would have never figured it out on my own, it was that posting that gave me the knowlege and tool to do it.

Pork?? Naw...really?? #5 should know:)

FWIW, I can confirm that the Intel compilers (all of them) on the Linux side at least, check for Intelhood before considering using SSE/SSE2/SSE3. I've been watching for a while and Intel has said a few times that they're happy with the way the Intel check works.

For me, the legitimacy of their claim went out the window when a P4-optimized binary will fall back but still use SSE1 when a P3 is detected, but an Opteron gets no SSE1 nor SSE2. If they're checking for capability, that's fine, but checking for 'GenuineIntel' is not kosher. Just my 0.02$, though.

Here's something that no one has thought about. Remeber that Intel's partnership with Apple can result in OSX going on to the PC market. That means that Microsoft will get kicked between the legs.

Intel and Microsoft have a very tough relationship that is why Intel has been trying to court Apple for years now. Microsoft doesnt like Intel's move towards Apple, because that means that Intel is trying to go into Microsoft territory. Thnk about it Intel x86 running MAC OSX, who wouldnt oggle at those words.

Remember that Microsoft has been a big AMD supporter with its 64bit and so forth. It doesnt come as a surprise that AMD is fileing a suit right after the Intel/Apple partnership was announced.

Hasnt anyone notice how Microsoft has been a background noise these past few months, being quiet about Intel/Apple and softly settling law suitsl like with IBM.

Watch Microsoft being a major player once the AMD/Intel suit goes big. Microsoft always has a part in these kinds of schemes. Microsoft wants to hurt Intel for stepping over to the Apple.

The best analogy I can come up with is if you use Microsoft FrontPage and think you're generating a "clean" web site. But what if the site only opens properly in IE because they explicitly disable some basic features like CSS in other browsers, even though the features are actually supported?

(Disclaimer: This is a fake scenario (AFAIK)).

I'm going to agree with this...

The /. story was kinda screwy about stuff, FWIW.

However, I agree that it should check for the necessary x86 extension in the CPUID - it seems like a no-brainer, unless, of course, you're trying to run the slow codepath on a non-Intel chip.

I've also heard (on the /. article, though) that it's actually checking for a Pentium 4 (or, probably, a Pentium M will also do). If it doesn't see one, it'll run a non-MMX, non-SSE, non-SSE2 codepath. That's right, it discriminates against the P3 as well. Not even fscking MMX!

And, apparently the assembly code that it generates in the slow codepath is braindead code that isn't even recommended for the 8086, let alone a P3 or AMD chip...

Can't say I'm surprised about all this. It wouldn't be the first time Intel has used anti-competitive measures to show themselves in a more favorable light. I'm about to read the full complaint (very interesting stuff since I'm in law school right now), but I hope AMD pulls this one out. Hell, if they could get evidence on Dell alone it would be enough to win the case.

AMD chips don't technically support ALL of SSE3. I believe there are 2 instructions that apply specifically to hyperthreading.

What would happen if those instructions were passed to an amd chip? would it silently error? or crash the program?

See, I can see intel turning on sse3 for amd chips, and when programs start crashing because they're calling those 2 instructions on athlons, Intel can point their finger at AMD and say it's their fault for not implementing ALL of sse3.

It's not about "optimizing for only your own products" !
If intel makes a compiler that uses SSE,SSE2, or SSE3 optimizations, they should work on ALL chips that have those instructions.
NOT just "Genu ineI ntel".
At the very least, let people KNOW that the compiler opt's will only run on intel gear. Blatant BS to suggest otherwise.

(IIRC, the "cross-licensing agreement" was really about not having the right to sue if one company reverse-engineers the other company's chips/instruction set. Correct me if I'm wrong, gerbils.)

EDIT: oh, and WRT #4, the odor of "the other white meat" is definitely drifting ovah heah.

Posts on Ace's Hardware talked about this stuff years ago. The AMD CPUs would show a flag for SSE2 but not utilize it anyway if the program was compiled with Intel compilers.

Intel pushes that on software developers for that extra 10%.

(1) Time for a rematch with some recompiled benchmarks?

(2) Is it a DMCA violation to patch a compiler so it skips the "GenuineIntel" trademark check?

Wasn't this the root cause of why the fsck we K8 proc users can't get QMD core work units from Folding@Home? The SSE2 capability is on the chip but they can't compile the core to use the instructions on A64/Opty chips. Disgusting.

Didn't Microsoft get burned for similar behavior by not revealing API's in Windows to outside vendors? If I recall, that was the basis for their initial injunction.

It's quite evident, especially in video rendering programs and encoding programs where Intel boxes run away with the performance crown. As a counter-point, I'm sure we've all seen what happens when AMD64 boxen run Windows Media Encoder - it's a straight-out slaughter.

When AMD implements SSE2 support, Intel introduces SSE3. It's not enough for them to have to compete on an "even playing field", they have to tilt the table in their favour 24/7. I can accept the new instruction set. I CAN'T accept the deliberate crippling of supported instruction sets for performance (and not compatibility) reasons.

It's like walking onto a used car lot, and the salesman knowingly sells Intel cars. He takes you out in a V8 car... it hauls ass. He then takes you out in an AMD turbo 4-cyl. It hauls just as fast as the Intel, but uses less gas to do it. Disgusted, the salesman pulls one of the sparkplug wires before you test-drive the car, and then reconnects the wire immediately thereafter.

That's misrepresentation of your competitor's product by a deliberate action on your part. Last I checked, that's cause for a lawsuit. But please don't try the case in Canada. They'll get a slap on the wrist and their own TV spot upon release from prison.