AMD, Intel x86-64 "near-identical" - MPR

[George Macdonald]

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??

 

[Tony Hill]

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.

 

[George Macdonald]

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.

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??

 

[Robert Myers]

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

 

[The little lost angel]

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

 

[Grumble]

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/[email protected]

 

[George Macdonald]

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

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??

 

[Tony Hill]

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

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.

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]

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).

 

[Jan Panteltje]

Subject: sleazy intel compiler trick (SOURCE ATTACHED)
http://google.com/[email protected]

Yes this is really funny ;-)

 

[RusH]

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.

In this case its about LAHF and SAHF (copying status flags)

Pozdrawiam.

 

[George Macdonald]

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.

OK, yeah I've never come across such stuff in application programming but
I've seen where a BIOS/OS writer would have to be careful.

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

There *are* things which have been added to the later CPU(s) in such
comparisons as well, like global TLB entries which don't have to be flushed
on a context switch and of course the fully process tagged TLB entries of
HT. Then there's been enhancements to page table entries and various
things like that. As for actual doc'd errata the only thing that sticks in
my mind is cache coherency/status issues in very oddball system situations.

I recall a coupla years back someone who had worked on one of the AMD CPUs
(K5 or K6) who posted here, that after they had the thing working to
specification, they were sent back to redo it so it had the same errata as
the Intel CPU.

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.

I don't think gamers are going to pay the cost of a Xeon or P4 + mbrd with
workstation chip mbrd if AMD comes even close on performance. I still
haven't been able to find out if Grantsdale/Alderwood will have the 36-bit
addressing... something else which might be "in there" but disabled.

Rgds, George Macdonald

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