This story has been reported in several places but here's the owner's
summary of the full report, which is only available by subscription:
http://tinyurl.com/3a9kn

Interesting that it's been reported, http://tinyurl.com/2l7jw that they
found differences which neither Intel nor AMD were aware of but I'd assume
(hope) that those are fairly esoteric.

I'm not sure they're right about Intel reverse engineering here. I've
suspected for a while that Intel cross-licensed the x86-64 stuff about the
time that AMD licensed SSE2 to replace their original intention to do a
completely new FPU.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

On Tue, 06 Apr 2004 05:31:41 -0400, George Macdonald
<fammacd=!SPAM^(E-Mail Removed)> wrote:
>This story has been reported in several places but here's the owner's
>summary of the full report, which is only available by subscription:
>http://tinyurl.com/3a9kn
>
>Interesting that it's been reported, http://tinyurl.com/2l7jw that they
>found differences which neither Intel nor AMD were aware of but I'd assume
>(hope) that those are fairly esoteric.

Well, as we've mentioned a few times before, Intel's P4 and AMD's
AthlonXP are NOT 100% compatible as it is. Same goes for Intel's P4
vs. Intel's PIII. However the same code generally works on both
unless you really go out of your way to use the incompatible code.
There are certainly going to be a few rather minor differences between
AMD64 and Intel's EMT64/IA-32e/name-of-day, but compilers should be
able to take care of them with no trouble at all.

The only problem Intel might have is running code that has already
been compiled for AMD's chips before any differences between them
became known. However, this is simply the price that Intel has to pay
for arriving WAY late to the game (IMO AMD was late to the game and
they've still got a year and a half's head start).

>I'm not sure they're right about Intel reverse engineering here. I've
>suspected for a while that Intel cross-licensed the x86-64 stuff about the
>time that AMD licensed SSE2 to replace their original intention to do a
>completely new FPU.

Intel and AMD definitely have cross-licensing agreements in place, so
I'm sure that you are correct, not really much need for reverse
engineering except maybe for a bit of validation purposes. I don't
know if this all relates back to SSE2 or simply general
cross-licensing agreements that exist between the two companies, but
the end result is pretty much the same.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

On Tue, 06 Apr 2004 07:14:55 -0400, Tony Hill <(E-Mail Removed)>
wrote:

>On Tue, 06 Apr 2004 05:31:41 -0400, George Macdonald
><fammacd=!SPAM^(E-Mail Removed)> wrote:
>>This story has been reported in several places but here's the owner's
>>summary of the full report, which is only available by subscription:
>>http://tinyurl.com/3a9kn
>>
>>Interesting that it's been reported, http://tinyurl.com/2l7jw that they
>>found differences which neither Intel nor AMD were aware of but I'd assume
>>(hope) that those are fairly esoteric.
>
>Well, as we've mentioned a few times before, Intel's P4 and AMD's
>AthlonXP are NOT 100% compatible as it is. Same goes for Intel's P4
>vs. Intel's PIII.

You mean wrt to SSE, SSE2, SSE3, 3DNOW etc.? I don't really think of those
as "compatibility" issues.

> However the same code generally works on both
>unless you really go out of your way to use the incompatible code.
>There are certainly going to be a few rather minor differences between
>AMD64 and Intel's EMT64/IA-32e/name-of-day, but compilers should be
>able to take care of them with no trouble at all.

It would still be interesting to know what they came up with but I don't
have the spare $$ for the report. The thought of paying for it, just to
find out it was something already fairly well known would be a umm
disappointment.:-) The suggestion of "probing" for the CPU type could
just mean SSE3 or it could be something more subtle.

>The only problem Intel might have is running code that has already
>been compiled for AMD's chips before any differences between them
>became known. However, this is simply the price that Intel has to pay
>for arriving WAY late to the game (IMO AMD was late to the game and
>they've still got a year and a half's head start).

I'm sure Intel will (try to) find a way to not "pay" here.:-) I have the
feeling that game market is where they could get hurt most here, for one
reason or another.

>>I'm not sure they're right about Intel reverse engineering here. I've
>>suspected for a while that Intel cross-licensed the x86-64 stuff about the
>>time that AMD licensed SSE2 to replace their original intention to do a
>>completely new FPU.
>
>Intel and AMD definitely have cross-licensing agreements in place, so
>I'm sure that you are correct, not really much need for reverse
>engineering except maybe for a bit of validation purposes. I don't
>know if this all relates back to SSE2 or simply general
>cross-licensing agreements that exist between the two companies, but
>the end result is pretty much the same.

IIRC they both made announcements at the time and AMD made a point of
saying that it was a bilateral exchange of IP. Not long after, AMD ditched
the new FPU in favor of SSE2 - the pieces certainly did fit, to me.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

On Tue, 06 Apr 2004 07:14:55 -0400, Tony Hill
<(E-Mail Removed)> wrote:

>On Tue, 06 Apr 2004 05:31:41 -0400, George Macdonald
><fammacd=!SPAM^(E-Mail Removed)> wrote:
>>This story has been reported in several places but here's the owner's
>>summary of the full report, which is only available by subscription:
>>http://tinyurl.com/3a9kn
>>
>>Interesting that it's been reported, http://tinyurl.com/2l7jw that they
>>found differences which neither Intel nor AMD were aware of but I'd assume
>>(hope) that those are fairly esoteric.
>
>Well, as we've mentioned a few times before, Intel's P4 and AMD's
>AthlonXP are NOT 100% compatible as it is. Same goes for Intel's P4
>vs. Intel's PIII. However the same code generally works on both
>unless you really go out of your way to use the incompatible code.
>There are certainly going to be a few rather minor differences between
>AMD64 and Intel's EMT64/IA-32e/name-of-day, but compilers should be
>able to take care of them with no trouble at all.
>

It's off the main point of the OP (or maybe not) but these tiny
discrepancies are why I resolutely pass up opportunities to buy AMD
hardware. I use mostly Intel or Intel-supported compilers (and an
Intel/HP Itanium simulator).

The compilers will probably work almost all the time for AMD hardware,
but the possibility that I might wind up spending alot of manhours
trying to track down a bug due to one of these differences is enough
to keep Intel Inside stickers on everything.

There is at least one known instance of Intel making intentional
"Intel-only" mods to an Intel compiler; I believe it was discussed in
comp.arch and not here.

FUD is the standard tactic of the dominant player, and, in the
instance of this particular user, it works. I am cynical enough to
believe that Intel will have scruntinized the 64-bit extensions for
every opportunity to keep busy cowards like me in the fold.

RM

On Tue, 06 Apr 2004 18:25:08 -0400, Robert Myers <(E-Mail Removed)>
wrote:

>It's off the main point of the OP (or maybe not) but these tiny
>discrepancies are why I resolutely pass up opportunities to buy AMD
>hardware. I use mostly Intel or Intel-supported compilers (and an
>Intel/HP Itanium simulator).

But given that between Intel processors and even steppings there are
the same small discrepancies, are you just restricting yourself
unnecessarily?
--
L.Angel: I'm looking for web design work.
If you need basic to med complexity webpages at affordable rates, email me
Standard HTML, SHTML, MySQL + PHP or ASP, Javascript.
If you really want, FrontPage & DreamWeaver too.
But keep in mind you pay extra bandwidth for their bloated code

Robert Myers wrote:

> There is at least one known instance of Intel making intentional
> "Intel-only" mods to an Intel compiler; I believe it was discussed
> in comp.arch and not here.

Subject: sleazy intel compiler trick (SOURCE ATTACHED)
http://google.com/groups?threadm=a13...ing.google.com

On Tue, 06 Apr 2004 18:25:08 -0400, Robert Myers <(E-Mail Removed)>
wrote:

>On Tue, 06 Apr 2004 07:14:55 -0400, Tony Hill
><(E-Mail Removed)> wrote:
>
>>On Tue, 06 Apr 2004 05:31:41 -0400, George Macdonald
>><fammacd=!SPAM^(E-Mail Removed)> wrote:
>>>This story has been reported in several places but here's the owner's
>>>summary of the full report, which is only available by subscription:
>>>http://tinyurl.com/3a9kn
>>>
>>>Interesting that it's been reported, http://tinyurl.com/2l7jw that they
>>>found differences which neither Intel nor AMD were aware of but I'd assume
>>>(hope) that those are fairly esoteric.
>>
>>Well, as we've mentioned a few times before, Intel's P4 and AMD's
>>AthlonXP are NOT 100% compatible as it is. Same goes for Intel's P4
>>vs. Intel's PIII. However the same code generally works on both
>>unless you really go out of your way to use the incompatible code.
>>There are certainly going to be a few rather minor differences between
>>AMD64 and Intel's EMT64/IA-32e/name-of-day, but compilers should be
>>able to take care of them with no trouble at all.
>>
>
>It's off the main point of the OP (or maybe not) but these tiny
>discrepancies are why I resolutely pass up opportunities to buy AMD
>hardware. I use mostly Intel or Intel-supported compilers (and an
>Intel/HP Itanium simulator).

Hmmm, I thought the Digital compilers were supposed to be the best for x86
numerical work. Has Intel corrupted them so they only work properly with
iChips now?:-) If it's the Itanium emulation you're really
after.....<shrug>

>The compilers will probably work almost all the time for AMD hardware,
>but the possibility that I might wind up spending alot of manhours
>trying to track down a bug due to one of these differences is enough
>to keep Intel Inside stickers on everything.
>
>There is at least one known instance of Intel making intentional
>"Intel-only" mods to an Intel compiler; I believe it was discussed in
>comp.arch and not here.
>
>FUD is the standard tactic of the dominant player, and, in the
>instance of this particular user, it works. I am cynical enough to
>believe that Intel will have scruntinized the 64-bit extensions for
>every opportunity to keep busy cowards like me in the fold.

I sense a watershed in the making here - AMD has the reigns with x86-64 and
Intel is cutting its nose off to spite its face with no EMT64 desktop
chipsets... unless Grantsdale/Alderwood has it but it looks unlikely, given
the announced strategy and lack of info. AMD has just announced the
availability of a "free downlaod" math library
http://biz.yahoo.com/bw/040405/45061_1.html for AMD64.

It looks like people who stick to iChips are going to find themselves
paying more for the system - i.e. one with a workstation chipset like E7505
- to get lower system performance and EMT64 CPU performance is reportedly
not matching up either. Sooner or later... even the "cowards" may have to
fold.:-)

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

On Tue, 06 Apr 2004 18:03:19 -0400, George Macdonald
<fammacd=!SPAM^(E-Mail Removed)> wrote:
>On Tue, 06 Apr 2004 07:14:55 -0400, Tony Hill <(E-Mail Removed)>
>wrote:
>>Well, as we've mentioned a few times before, Intel's P4 and AMD's
>>AthlonXP are NOT 100% compatible as it is. Same goes for Intel's P4
>>vs. Intel's PIII.
>
>You mean wrt to SSE, SSE2, SSE3, 3DNOW etc.? I don't really think of those
>as "compatibility" issues.

No, I'm mostly referring to the fact that some of the odd-ball and
seldom used instructions in the x86 ISA will return slightly different
values when executed on different chips. Often it's something so
small as what flags are set after the instruction is executed and you
almost never run into any problems from these.

Most of these differences are just documented as "Errata" or
"Specification Updates", and while occasionally a new stepping will be
released to fix them, as often as not they are simply left as is.
Some of the differences aren't even documented as errata as they
simply depend on what chip you're comparing against. If AMD is
comparing their chips to the Pentium and Intel compares their chips to
the PII, they will come up with slight differences

>> However the same code generally works on both
>>unless you really go out of your way to use the incompatible code.
>>There are certainly going to be a few rather minor differences between
>>AMD64 and Intel's EMT64/IA-32e/name-of-day, but compilers should be
>>able to take care of them with no trouble at all.
>
>It would still be interesting to know what they came up with but I don't
>have the spare $$ for the report. The thought of paying for it, just to
>find out it was something already fairly well known would be a umm
>disappointment.:-) The suggestion of "probing" for the CPU type could
>just mean SSE3 or it could be something more subtle.

Well, they could be talking about things like the CMPXCHG8
instructions, used to compare and exchange 8 byte value. This
instruction is supported on some chips but not on others (I know VIA
chips do not support it, I'm not sure about AMD's line-up though). Or
there are things like the No-Execute bit for pages, enabled on AMD's
Opteron and Athlon64 in 64-bit Long mode but not on Intel's current
chips.

When you've got as much baggage as x86 has, there are lots of little
things that you need to check for.

>>The only problem Intel might have is running code that has already
>>been compiled for AMD's chips before any differences between them
>>became known. However, this is simply the price that Intel has to pay
>>for arriving WAY late to the game (IMO AMD was late to the game and
>>they've still got a year and a half's head start).
>
>I'm sure Intel will (try to) find a way to not "pay" here.:-) I have the
>feeling that game market is where they could get hurt most here, for one
>reason or another.

Could be, though fortunately most games come with the ability to be
patched, so it would be a simple matter of downloading a new patch to
fix any problems.

Tony

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

On Tue, 06 Apr 2004 18:25:08 -0400, Robert Myers <(E-Mail Removed)>
wrote:
>On Tue, 06 Apr 2004 07:14:55 -0400, Tony Hill
><(E-Mail Removed)> wrote:
>>Well, as we've mentioned a few times before, Intel's P4 and AMD's
>>AthlonXP are NOT 100% compatible as it is. Same goes for Intel's P4
>>vs. Intel's PIII. However the same code generally works on both
>>unless you really go out of your way to use the incompatible code.
>>There are certainly going to be a few rather minor differences between
>>AMD64 and Intel's EMT64/IA-32e/name-of-day, but compilers should be
>>able to take care of them with no trouble at all.
>>
>
>It's off the main point of the OP (or maybe not) but these tiny
>discrepancies are why I resolutely pass up opportunities to buy AMD
>hardware. I use mostly Intel or Intel-supported compilers (and an
>Intel/HP Itanium simulator).

The only problem with that is that Intel is not 100% Intel compatible
either!

>The compilers will probably work almost all the time for AMD hardware,
>but the possibility that I might wind up spending alot of manhours
>trying to track down a bug due to one of these differences is enough
>to keep Intel Inside stickers on everything.

The possibility still exists, even from one stepping to another. You
might be limiting the chances of this sort of thing happening, but the
probability of running into a problem was already pretty negligible.

>There is at least one known instance of Intel making intentional
>"Intel-only" mods to an Intel compiler; I believe it was discussed in
>comp.arch and not here.

There are plenty of Intel-only mods in Intel's compiler, though the
one discussed over in comp.arch was a bit of an annoying one more than
anything else. The problem was that Intel was simply checking the
CPUID bits to see if it was an Intel chip rather than actually doing
any Intel-only optimizations.

FWIW GCC also has modes that will ONLY operate on certain chips. If
you compile your code as "march=pentium4" your code will likely not
run on AMD chips, and similarly a "march=athlon-xp" will generate code
that might not run on Intel chips. So this isn't an Intel-only thing,
it's just that Intel doesn't have an optimization mode for any AMD
chips (for obvious reasons).

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

On a sunny day (Wed, 07 Apr 2004 12:58:50 +0200) it happened Grumble
<(E-Mail Removed)> wrote in <c50mtb$r10$(E-Mail Removed)>:

>Robert Myers wrote:
>
>> There is at least one known instance of Intel making intentional
>> "Intel-only" mods to an Intel compiler; I believe it was discussed
>> in comp.arch and not here.
>
>Subject: sleazy intel compiler trick (SOURCE ATTACHED)
>http://google.com/groups?threadm=a13...ing.google.com
Yes this is really funny ;-)