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

  • Thread starter Thread starter George Macdonald
  • Start date Start date
G

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??
 
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.
Click to expand...

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.
Click to expand...

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.
 
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.
Click to expand...

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.
Click to expand...

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).
Click to expand...

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.
Click to expand...

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??
 
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.
Click to expand...

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
 
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).
Click to expand...

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
 
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).
Click to expand...

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..... said:
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.
Click to expand...

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??
 
You mean wrt to SSE, SSE2, SSE3, 3DNOW etc.? I don't really think of those
as "compatibility" issues.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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
 
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).
Click to expand...

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.
Click to expand...

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.
Click to expand...

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 said:
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.
Click to expand...

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

Pozdrawiam.
 
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.
Click to expand...

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
Click to expand...

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.
Click to expand...

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