RE: Intel vs AMD x86-64

RE: Intel vs AMD x86-64

[Sean Fao]

Linus Torvalds wrote:

>Now, I'm not above complaining about Intel (in fact, the Intel people seem
>to often think I hate them because I'm apparently the only person who gets
>quoted who complains about bad decisions publicly), but at least I try to
>avoid complaining before-the-fact ;)
>

It must come with the territory ;-).  Your message has already made it to
Slashdot so I'm sure this time will be no different.

RE: Intel vs AMD x86-64

[Linus Torvalds]

On Tue, 24 Feb 2004, Sean Fao wrote:
>
> Linus Torvalds wrote: 
> >Now, I'm not above complaining about Intel (in fact, the Intel people seem
> >to often think I hate them because I'm apparently the only person who gets
> >quoted who complains about bad decisions publicly), but at least I try to
> >avoid complaining before-the-fact ;)
> >
> 
> It must come with the territory ;-).  Your message has already made it to
> Slashdot so I'm sure this time will be no different.

Yeah, and that's unfair to Intel. They've done the right thing 
technically, and I applaud them for that, but their marketing people are 
pricks.

Everybody else is "Intel-compatible" when they make x86 chips.  Intel is
apparently a bit too used to _not_ saying "AMD-compatible".

Oh, well. The marketing people are probably proud of their "branding", and 
screw the confusion.

		Linus

Re: Intel vs AMD x86-64

[Timothy Miller]

Linus Torvalds wrote:
> 
> On Tue, 24 Feb 2004, Sean Fao wrote:
> 
>>Linus Torvalds wrote: 
>>
>>>Now, I'm not above complaining about Intel (in fact, the Intel people seem
>>>to often think I hate them because I'm apparently the only person who gets
>>>quoted who complains about bad decisions publicly), but at least I try to
>>>avoid complaining before-the-fact ;)
>>>
>>
>>It must come with the territory ;-).  Your message has already made it to
>>Slashdot so I'm sure this time will be no different.
> 
> 
> Yeah, and that's unfair to Intel. They've done the right thing 
> technically, and I applaud them for that, but their marketing people are 
> pricks.
> 
> Everybody else is "Intel-compatible" when they make x86 chips.  Intel is
> apparently a bit too used to _not_ saying "AMD-compatible".
> 
> Oh, well. The marketing people are probably proud of their "branding", and 
> screw the confusion.


I've been reading some people's comments relating to this, and it 
reflects a glimmer of an idea that occurred to me initially.  To begin 
with, I completely agree that it was unethical for Intel to imply that 
this was their innovation, giving no credit to AMD.  It was wrong, and 
they should be ashamed.

On the other hand, I don't see how Intel's marketing department could 
possibly justify to themselves doing "the right thing".  In this case, 
doing the right thing would be very bad for business, because giving 
proper credit would be like saying, (to paraphrase one commenter on 
osnews) "Well... we're behind the times, so we had to copy AMD's ideas, 
so there's little point in buying from us, because we didn't really do 
anything interesting, so you might as well give your business to AMD 
instead.  They're smarter than us."

Intel, being an organization driven by marketing and image, really 
CANNOT "do the right thing" without some kind of penalty that they would 
  find unacceptable.  Mind you, if Intel were driven by _performance_ 
and _superior_products_, rather than marketing, things would be a lot 
different.  That is to say, Intel's MUCH BIGGER sin is putting marketing 
ahead of technical merit.  (Hmmm, seems to me I've seen this sort of 
attitude elsewhere in the wintel industry.)

Re: Intel vs AMD x86-64

[Davide Rossetti]

Linus Torvalds wrote:

>On Tue, 24 Feb 2004, Sean Fao wrote:
>  
>
>>Linus Torvalds wrote: 
>>    
>>
>>>Now, I'm not above complaining about Intel (in fact, the Intel people seem
>>>to often think I hate them because I'm apparently the only person who gets
>>>quoted who complains about bad decisions publicly), but at least I try to
>>>avoid complaining before-the-fact ;)
>>>
>>>      
>>>
>>It must come with the territory ;-).  Your message has already made it to
>>Slashdot so I'm sure this time will be no different.
>>    
>>
>
>Yeah, and that's unfair to Intel. They've done the right thing 
>technically, and I applaud them for that, but their marketing people are 
>pricks.
>
>Everybody else is "Intel-compatible" when they make x86 chips.  Intel is
>apparently a bit too used to _not_ saying "AMD-compatible".
>
>Oh, well. The marketing people are probably proud of their "branding", and 
>screw the confusion.
>  
>
actually, the real hungry peaple should be the Intel engineering staff 
who have been working on the first "ia32e" chip... they started working 
on it let's say 1, 1.5 years ago, maybe 2 or more??? I bet chip 
design-to-silicon time is not 6 months even for Intel...

I kind of see Intel marketing people pressing on them saying: "... in 
the end it's just a backup project, just in case ia64, which is more 
money making, does not take off...".

Maybe they already had a designed "x86 64bit" chip, only more different 
from AMD64 one, but they were forced to refactor it to make it x86-64 
compatible.

Re: Intel vs AMD x86-64

[Timothy Miller]

Sean Fao wrote:
> Linus Torvalds wrote:
> 
> 
>>Now, I'm not above complaining about Intel (in fact, the Intel people seem
>>to often think I hate them because I'm apparently the only person who gets
>>quoted who complains about bad decisions publicly), but at least I try to
>>avoid complaining before-the-fact ;)
>>
> 
> 
> It must come with the territory ;-).  Your message has already made it to
> Slashdot so I'm sure this time will be no different.


People always love controversy and contention.  This is especially true 
when the come from statements from "cult leaders" like Linus.

Fortunately, Linus is very antithetical to many other cult figures in 
that he is very much NOT a psychopath.  :)

Re: Intel vs AMD x86-64

[Linus Torvalds]

On Tue, 24 Feb 2004, Timothy Miller wrote:
> 
> Fortunately, Linus is very antithetical to many other cult figures in 
> that he is very much NOT a psychopath.  :)

I'm happy you put it that way, because otherwise I'd have had to take out 
my chain saw and run around naked trying to kill you.

Mwhahhahhaahaa!

		Linus

Re: Intel vs AMD x86-64

[Dave Jones]

On Tue, Feb 24, 2004 at 01:31:26PM -0800, Linus Torvalds wrote:

 > > Fortunately, Linus is very antithetical to many other cult figures in 
 > > that he is very much NOT a psychopath.  :)
 > 
 > I'm happy you put it that way, because otherwise I'd have had to take out 
 > my chain saw and run around naked trying to kill you.

If you listen carefully, you'll hear the sound of thousands of Linux hackers
trying to scratch out their minds-eyes at that image.  8-)

		Dave

Re: Intel vs AMD x86-64

[Kai Henningsen]

davej@redhat.com (Dave Jones)  wrote on 24.02.04 in <20040224212823.GA23551@redhat.com>:

> On Tue, Feb 24, 2004 at 01:31:26PM -0800, Linus Torvalds wrote:
>
>  > > Fortunately, Linus is very antithetical to many other cult figures in
>  > > that he is very much NOT a psychopath.  :)
>  >
>  > I'm happy you put it that way, because otherwise I'd have had to take out
>  > my chain saw and run around naked trying to kill you.
>
> If you listen carefully, you'll hear the sound of thousands of Linux hackers
> trying to scratch out their minds-eyes at that image.  8-)

Why? That's the Linus we know and love. (Preferrably with a good sauce.)

MfG Kai

RE: Intel vs AMD x86-64

[Nakajima, Jun]

>-----Original Message-----
>From: Nakajima, Jun
>Sent: Tuesday, February 24, 2004 3:15 PM
>To: 'Pavel Machek'
>Cc: Linus Torvalds; Adrian Bunk; Herbert Poetzl; Mikael Pettersson;
Kernel
>Mailing List
>Subject: RE: Intel vs AMD x86-64
...
>Other than the standard IA-32 differences (eg. HT, SSE3, Intel Enhanced
>SpeedStep, etc.), there are few differences between the implementations
of
>IA-32e and AMD64. The software visible ones are:

Clarification to the BSF/BSR behavior when source is 0.

IA-32e inherits the existing behavior, which is "if the contents source
operand are 0, the contents of the destination operand is undefined."
One needs to check the ZF to detect such a condition. The defined
behavior for 64-bit mode is consistent with the one for 32-bit mode,
i.e. if the operand size is 64-bit, the whole destination is undefined
if the contents source operand are 0.

>BSF/BSR when source is 0 & operand size is 32:
>  In 64-bit mode, the processor sets ZF, and the upper 32 bits of
>  the destination are undefined. Should always check the ZF or do not
use
>  32-bit operand size.
>

So in this case, the lower 32 bits of the destination are undefined as
well, thus, the whole destination is undefined.

The advice is: Always check the ZF. You can use BSF/BSR with the 32-bit
operand size as long as you check the ZF. 

Jun

RE: Intel vs AMD x86-64

[Nakajima, Jun]

Yes, that's the very reason I said "useless for compilers." The way
IP/RIP is updated is different (and implementation specific) on those
processors if 66H is used with a near branch. For example, RIP may be
zero-extended to 64 bits (from IP), as you observed before.

Jun
>-----Original Message-----
>From: H. Peter Anvin [mailto:hpa@zytor.com]
>Sent: Wednesday, February 25, 2004 4:14 PM
>To: Timothy Miller
>Cc: Nakajima, Jun; linux-kernel@vger.kernel.org
>Subject: Re: Intel vs AMD x86-64
>
>Timothy Miller wrote:
>>
>>
>> Nakajima, Jun wrote:
>>
>>> For near branches (CALL, RET, JCC, JCXZ, JMP, etc.), the operand
size is
>>> forced to 64 bits on both processors in 64-bit mode, basically
meaning
>>> RIP is updated.
>>>
>>> Compilers would typically use a JMP short for "intraprocedural
jumps",
>>> which requires just an 8-bit displacement relative to RIP.
>>
>> I see.  It's too bad you can't have a 16-bit displacement.
>>
>> Ummm... so if 66H were used with a near branch, would that affect the
>> size of the immediate operand which gets added to RIP, or would that
>> affect the the portion of IP/EIP/RIP affected?  If it's the latter,
>> that's pretty silly.
>>
>
>Yes, that would be pretty silly.
>
>I honestly don't remember off the top of my head what "o16 jmp blah"
>does on i386; I have a vague memory that it zero-extends %eip to 32
>bits, which makes it useless, of course.
>
>	-hpa

Re: Intel vs AMD x86-64

[Timothy Miller]

Nakajima, Jun wrote:
> Yes, that's the very reason I said "useless for compilers." The way
> IP/RIP is updated is different (and implementation specific) on those
> processors if 66H is used with a near branch. For example, RIP may be
> zero-extended to 64 bits (from IP), as you observed before.
> 

This is obviously an extremely minor nit-pick, because we're talking 
about one instruction here with an interpretation that is far from 
obvious, but given that there are now only two architectures which 
support x86-64, did Intel choose to do it differently from AMD because 
it was poorly defined, or because it wasn't important enough to want to 
impact the efficiency of the design?

There are people who would go way out of their way to get a 5% 
improvement in performance or decrease in size.  If using 66H with near 
branches could in some way do that, they would really really want to use 
it.  This is why I'm curious.

Re: Intel vs AMD x86-64

[Bill Davidsen]

Timothy Miller wrote:
> 
> 
> Nakajima, Jun wrote:
> 
>> Yes, that's the very reason I said "useless for compilers." The way
>> IP/RIP is updated is different (and implementation specific) on those
>> processors if 66H is used with a near branch. For example, RIP may be
>> zero-extended to 64 bits (from IP), as you observed before.
>>
> 
> This is obviously an extremely minor nit-pick, because we're talking 
> about one instruction here with an interpretation that is far from 
> obvious, but given that there are now only two architectures which 
> support x86-64, did Intel choose to do it differently from AMD because 
> it was poorly defined, or because it wasn't important enough to want to 
> impact the efficiency of the design?

How about because they messed up trying to clone the instruction set? 
Never attribute to malice what can be explained by stupidity. <-(quote)
> 
> There are people who would go way out of their way to get a 5% 
> improvement in performance or decrease in size.  If using 66H with near 
> branches could in some way do that, they would really really want to use 
> it.  This is why I'm curious.

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

RE: Re: Intel vs AMD x86-64

[Nakajima, Jun]

For near branches (CALL, RET, JCC, JCXZ, JMP, etc.), the operand size is
forced to 64 bits on both processors in 64-bit mode, basically meaning
RIP is updated.

Compilers would typically use a JMP short for "intraprocedural jumps",
which requires just an 8-bit displacement relative to RIP. 

Jun
>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
>owner@vger.kernel.org] On Behalf Of H. Peter Anvin
>Sent: Wednesday, February 25, 2004 8:17 AM
>To: linux-kernel@vger.kernel.org
>Subject: Re: Intel vs AMD x86-64
>
>Followup to:  <403CCBE0.7050100@techsource.com>
>By author:    Timothy Miller <miller@techsource.com>
>In newsgroup: linux.dev.kernel
>>
>>
>> Nakajima, Jun wrote:
>> > No, it's not a problem. Branches with 16-bit operand size are not
>useful
>> > for compilers.
>>
>>  From AMD's documentation, I got the impression that 66H caused near
>> branches to be 32 bits in long mode (default is 64).
>>
>> So, Intel makes it 16 bits, and AMD makes it 32 bits?
>>
>> Either way, I don't see much use for either one.
>>
>
>Both claims are pretty bogus.  Shorter branches are quite nice for
>intraprocedural jumps; it reduces the cache footprint.
>
>	-hpa
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

Re: Intel vs AMD x86-64

[Timothy Miller]

Nakajima, Jun wrote:
> For near branches (CALL, RET, JCC, JCXZ, JMP, etc.), the operand size is
> forced to 64 bits on both processors in 64-bit mode, basically meaning
> RIP is updated.
> 
> Compilers would typically use a JMP short for "intraprocedural jumps",
> which requires just an 8-bit displacement relative to RIP. 


I see.  It's too bad you can't have a 16-bit displacement.


Ummm... so if 66H were used with a near branch, would that affect the 
size of the immediate operand which gets added to RIP, or would that 
affect the the portion of IP/EIP/RIP affected?  If it's the latter, 
that's pretty silly.

Re: Intel vs AMD x86-64

[H. Peter Anvin]

Timothy Miller wrote:
> 
> 
> Nakajima, Jun wrote:
> 
>> For near branches (CALL, RET, JCC, JCXZ, JMP, etc.), the operand size is
>> forced to 64 bits on both processors in 64-bit mode, basically meaning
>> RIP is updated.
>>
>> Compilers would typically use a JMP short for "intraprocedural jumps",
>> which requires just an 8-bit displacement relative to RIP. 
> 
> I see.  It's too bad you can't have a 16-bit displacement.
> 
> Ummm... so if 66H were used with a near branch, would that affect the
> size of the immediate operand which gets added to RIP, or would that
> affect the the portion of IP/EIP/RIP affected?  If it's the latter,
> that's pretty silly.
> 

Yes, that would be pretty silly.

I honestly don't remember off the top of my head what "o16 jmp blah"
does on i386; I have a vague memory that it zero-extends %eip to 32
bits, which makes it useless, of course.

	-hpa

Re: Intel vs AMD x86-64

[Bill Davidsen]

Timothy Miller wrote:

> I've been reading some people's comments relating to this, and it 
> reflects a glimmer of an idea that occurred to me initially.  To begin 
> with, I completely agree that it was unethical for Intel to imply that 
> this was their innovation, giving no credit to AMD.  It was wrong, and 
> they should be ashamed.

Actually, it is unclear enough to me if the Intel chips will have any 
technical advantages that I have postponed buying the dual Opteron I was 
  planning for 1Q04 until I read the Intel specs more carefully.

These are the issues of interest:
- hyperthreading

   will Intel offer it and will it be in some way better than the 10-30% 
gain I see from HT on a P4.

- cost

   If Intel follows the previous price models for new chips they are not 
in any way going to be competitive on cost/performance. On the other 
hand they know that, they know they are playing catch-up in this market, 
and they might be aggressive for a change.

- SSE3

   what does it provide, is it in any way useful for anything I ever do, 
and will gcc or the free for personal use Intel C compiler support it?

- availability

   will this be a product or just a product announcement? I can wait 
until 2Q04 if there's a reason to do so, after that I assume it's just FUD.

- will it work

   or will it follow Itanium and take another generation before it runs 
faster than the hardware emulator? Speaking of which, I would like Intel 
to release the hardware emulator so I can do benchmarking now.

Having HT in a single package has some advantages, but talk is cheap, 
and AMD is shipping. I personally hope it works really well and keeps 
prices down.

-- 
bill on the road

Re: Intel vs AMD x86-64

[Moritz Muehlenhoff]

Bill Davidsen wrote:
> - SSE3
>
> and will gcc [..] support it?

GCC 3.3.3 (released yesterday) already supports SSE3.

RE: Intel vs AMD x86-64

[Nakajima, Jun]

No, it's not a problem. Branches with 16-bit operand size are not useful
for compilers.

Jun 
>-----Original Message-----
>From: Chris Wedgwood [mailto:cw@f00f.org]
>Sent: Tuesday, February 24, 2004 5:53 PM
>To: Nakajima, Jun
>Cc: Pavel Machek; Linus Torvalds; Adrian Bunk; Herbert Poetzl; Mikael
>Pettersson; Kernel Mailing List
>Subject: Re: Intel vs AMD x86-64
>
>On Tue, Feb 24, 2004 at 03:15:18PM -0800, Nakajima, Jun wrote:
>
>> Near branch with 66H prefix:
>>   As documented in PRM the behavior is implementation specific and
>>   should avoid using 66H prefix on near branches.
>
>Presumably this isn't a problem with current gcc's right?
>

Re: Intel vs AMD x86-64

[Timothy Miller]

Nakajima, Jun wrote:
> No, it's not a problem. Branches with 16-bit operand size are not useful
> for compilers.

 From AMD's documentation, I got the impression that 66H caused near 
branches to be 32 bits in long mode (default is 64).

So, Intel makes it 16 bits, and AMD makes it 32 bits?

Either way, I don't see much use for either one.

> 
> Jun 
> 
>>-----Original Message-----
>>From: Chris Wedgwood [mailto:cw@f00f.org]
>>Sent: Tuesday, February 24, 2004 5:53 PM
>>To: Nakajima, Jun
>>Cc: Pavel Machek; Linus Torvalds; Adrian Bunk; Herbert Poetzl; Mikael
>>Pettersson; Kernel Mailing List
>>Subject: Re: Intel vs AMD x86-64
>>
>>On Tue, Feb 24, 2004 at 03:15:18PM -0800, Nakajima, Jun wrote:
>>
>>
>>>Near branch with 66H prefix:
>>>  As documented in PRM the behavior is implementation specific and
>>>  should avoid using 66H prefix on near branches.
>>
>>Presumably this isn't a problem with current gcc's right?
>>

Re: Intel vs AMD x86-64

[H. Peter Anvin]

Followup to:  <403CCBE0.7050100@techsource.com>
By author:    Timothy Miller <miller@techsource.com>
In newsgroup: linux.dev.kernel
>
> 
> Nakajima, Jun wrote:
> > No, it's not a problem. Branches with 16-bit operand size are not useful
> > for compilers.
> 
>  From AMD's documentation, I got the impression that 66H caused near 
> branches to be 32 bits in long mode (default is 64).
> 
> So, Intel makes it 16 bits, and AMD makes it 32 bits?
> 
> Either way, I don't see much use for either one.
> 

Both claims are pretty bogus.  Shorter branches are quite nice for
intraprocedural jumps; it reduces the cache footprint.

	-hpa

Re: Intel vs AMD x86-64

[Timothy Miller]

H. Peter Anvin wrote:
> Followup to:  <403CCBE0.7050100@techsource.com>
> By author:    Timothy Miller <miller@techsource.com>
> In newsgroup: linux.dev.kernel
> 
>>
>>Nakajima, Jun wrote:
>>
>>>No, it's not a problem. Branches with 16-bit operand size are not useful
>>>for compilers.
>>
>> From AMD's documentation, I got the impression that 66H caused near 
>>branches to be 32 bits in long mode (default is 64).
>>
>>So, Intel makes it 16 bits, and AMD makes it 32 bits?
>>
>>Either way, I don't see much use for either one.
>>
> 
> 
> Both claims are pretty bogus.  Shorter branches are quite nice for
> intraprocedural jumps; it reduces the cache footprint.

I think we were talking about absolute branches when referring to "near 
branches".  For absolute branches, having a 32-bit address restricts you 
to the lower 4G of the address space.

For long mode on AMD64, default operand size for _relative_ branch is 32 
bits.  I get the impression that the size of the relative branch operand 
is handled differently from the "segment default word size".

Re: Intel vs AMD x86-64

[H. Peter Anvin]

Timothy Miller wrote:
> 
> I think we were talking about absolute branches when referring to "near 
> branches".  For absolute branches, having a 32-bit address restricts you 
> to the lower 4G of the address space.
> 

You're talking about *indirect* near branches?  Those are the only 
absolute near branches which exist...

	-hpa

Re: Intel vs AMD x86-64

[Timothy Miller]

H. Peter Anvin wrote:
> Timothy Miller wrote:
> 
>>
>> I think we were talking about absolute branches when referring to 
>> "near branches".  For absolute branches, having a 32-bit address 
>> restricts you to the lower 4G of the address space.
>>
> 
> You're talking about *indirect* near branches?  Those are the only 
> absolute near branches which exist...


I don't know.  I seem to vaguely recall seeing some disassembled x86 
code which was a branch which had an absolute address.  Maybe I remember 
incorrectly.

RE: Intel vs AMD x86-64

[Nakajima, Jun]

I think we have a bug in the inline function. Actually this behavior is 
consistent with the IA-32, which says "if the contents source operand
are 0, 
the contents of the destination operand is undefined." So the code in
32-bit 
also has a bug there. Today it is set to zero fortunately, and the code 
happens to be working.

Jun

>-----Original Message-----
>From: ak@suse.de [mailto:ak@suse.de]
>Sent: Tuesday, February 24, 2004 3:49 PM
>To: Nakajima, Jun
>Cc: linux-kernel@vger.kernel.org
>Subject: Re: Intel vs AMD x86-64
>
>"Nakajima, Jun" <jun.nakajima@intel.com> writes:
>
>> Other than the standard IA-32 differences (eg. HT, SSE3, Intel
Enhanced
>> SpeedStep, etc.), there are few differences between the
implementations
>> of
>> IA-32e and AMD64. The software visible ones are:
>
>Thanks for the detailed list.
>
>> BSF/BSR when source is 0 & operand size is 32:
>>   In 64-bit mode, the processor sets ZF, and the upper 32 bits of
>>   the destination are undefined. Should always check the ZF or do not
>> use
>>   32-bit operand size.
>
>This one sounds a bit scary. I think it could hurt the
>asm-x86_64/bitops.h:find_first_zero_bit if there is a race that
>changes the value in memory between the last scasl and the bsfl
>and the inliner assumes the edx output argument is zero extended.
>Hopefully that case should be unlikely enough. I guess best would
>be to change the function to use 64bit accesses to avoid this
completely.
>
>-Andi

Re: Intel vs AMD x86-64

[Andi Kleen]

"Nakajima, Jun" <jun.nakajima@intel.com> writes:

> Other than the standard IA-32 differences (eg. HT, SSE3, Intel Enhanced
> SpeedStep, etc.), there are few differences between the implementations
> of 
> IA-32e and AMD64. The software visible ones are:

Thanks for the detailed list.

> BSF/BSR when source is 0 & operand size is 32:
>   In 64-bit mode, the processor sets ZF, and the upper 32 bits of 
>   the destination are undefined. Should always check the ZF or do not
> use 
>   32-bit operand size.

This one sounds a bit scary. I think it could hurt the 
asm-x86_64/bitops.h:find_first_zero_bit if there is a race that 
changes the value in memory between the last scasl and the bsfl
and the inliner assumes the edx output argument is zero extended.
Hopefully that case should be unlikely enough. I guess best would
be to change the function to use 64bit accesses to avoid this completely.

-Andi

RE: Intel vs AMD x86-64

[Nakajima, Jun]

>Could you publish list of differences between amd64 and ia32e?
>
>I probably could took those two 300+ page documents and try to compare
>them by hand, but I believe you know already.
>								
>								Pavel

Other than the standard IA-32 differences (eg. HT, SSE3, Intel Enhanced
SpeedStep, etc.), there are few differences between the implementations
of 
IA-32e and AMD64. The software visible ones are:

Fast system calls:
  Syscall/sysret is supported only in 64-bit mode (not in compatibility 
  mode). Sysenter/Sysexit is supported in both 64-bit and compatible
mode.

CPUID:
  If you look at Table 2-8 of Volume 1, you will find IA-32e specific
things,
  including, GenuineIntel, HT, SSE3, monitor/mwait, Intel Enhanced
SpeedStep, 
  and cmpxchg16b.

  The function 8000_0001h doesn't duplicate standard-feature bits from 
  function 1 in EDX. It sets only the new features that are implemented.

MSRs:
  Not all MSRs are architectural, and IA-32e does not implement SYSCFG, 
  TOP_MEM, TOP_MEM2, for example. MSR usage should be vendor specific
and 
  be guarded with CPUID.Model

Fast-FXSAVE/FXRSTOR:
  IA-32e always saves all of the FP state on FXSAVE/FXRSTOR. Does not 
  support FXSAVE/FXRSTOR with reduced FP state.

Microcode Update:
  IA-32e supports microcode update as the 32-bit mode does, as you
already 
  found the discussions in the mailing list.

NX (No-Execute) bit:
  Initial implementation will not support the NX bit.

BSF/BSR when source is 0 & operand size is 32:
  In 64-bit mode, the processor sets ZF, and the upper 32 bits of 
  the destination are undefined. Should always check the ZF or do not
use 
  32-bit operand size.

Near branch with 66H prefix:
  As documented in PRM the behavior is implementation specific and
should 
  avoid using 66H prefix on near branches.

Not supported in IA-32e
=======================
  3DNow instructions (including prefecthw or prefetch with the opcode 0f
0d)

Thanks,
Jun

>-----Original Message-----
>From: Pavel Machek [mailto:pavel@ucw.cz]
>Sent: Tuesday, February 24, 2004 5:25 AM
>To: Nakajima, Jun
>Cc: Linus Torvalds; Adrian Bunk; Herbert Poetzl; Mikael Pettersson;
Kernel
>Mailing List
>Subject: Re: Intel vs AMD x86-64
>
>Hi!
>
>> Sorry for the miscommunication. The page
>> http://www.intel.com/technology/64bitextensions/faq.htm says at the
>> _bottom_ at least:
>>
>> Q9: Is it possible to write software that will run on Intel's
processors
>> with 64-bit extension technology, and AMD's 64-bit capable
processors?
>> A9: With both companies designing entirely different architectures,
the
>> question is whether the operating system and software ported to each
>> processor will run on the other processor, and the answer is yes in
most
>> cases.
>
>Could you publish list of differences between amd64 and ia32e?
>
>I probably could took those two 300+ page documents and try to compare
>them by hand, but I believe you know already.
>								Pavel
>
>--
>When do you have a heart between your knees?
>[Johanka's followup: and *two* hearts?]

Re: Intel vs AMD x86-64

[Chris Wedgwood]

On Tue, Feb 24, 2004 at 03:15:18PM -0800, Nakajima, Jun wrote:

> Near branch with 66H prefix:
>   As documented in PRM the behavior is implementation specific and
>   should avoid using 66H prefix on near branches.

Presumably this isn't a problem with current gcc's right?

Re: Intel vs AMD x86-64

[Albert Cahalan]

David S. Miller writes:
> Linus Torvalds <torvalds@osdl.org> wrote:

>> In fact, I _think_ you could actually use the AGP bridge as a strange
>> IOMMU. Of course, right now their AGP bridges are all 32-bit limited
>> anyway, but the point being that they at least in theory would seem to
>> have the capability to do this.
>
> Ok, I see.  In fact, I remember some vague notion that the AGP bridge
> on the Athlon's could technically be used as a full-on IOMMU, especially
> since it was all derived from Alpha PCI chipsets which did use things
> this way.

This is exactly the way it works. The AGP bridge is
a replicated per-CPU thing, along with the memory.
Good boards have a BIOS option marked "Linux only"
that lets you choose an IO-MMU window size ranging
from 32 MB to 2 GB. Direct your 32-bit PCI DMA
into that window and you get an IO-MMU.

Memory can be interleaved across the CPUs or not,
on 4 kB boundries. It's a BIOS option, though some
insane code could be written to change the setting.
Setting up only one of the IO-MMUs would be neat.

Re: Intel vs AMD x86-64

[Dave Jones]

On Mon, Feb 23, 2004 at 09:42:05PM -0500, Albert Cahalan wrote:
 > Setting up only one of the IO-MMUs would be neat.

AGPv3 standard mandates that you MUST keep all GARTs coherent,
so this isn't possible.  The amd64 GART driver goes to great
lengths to make sure it does update the northbridges on every
CPU whenever something changes.

		Dave

Re: Intel vs AMD x86-64

[Albert Cahalan]

On Tue, 2004-02-24 at 11:44, Dave Jones wrote:
> On Mon, Feb 23, 2004 at 09:42:05PM -0500, Albert Cahalan wrote:
>  > Setting up only one of the IO-MMUs would be neat.
> 
> AGPv3 standard mandates that you MUST keep all GARTs coherent,
> so this isn't possible.  The amd64 GART driver goes to great
> lengths to make sure it does update the northbridges on every
> CPU whenever something changes.

Of course. That's the easy way; you won't need
to worry about memory interleave or out-of-bounds
prefetch if you keep everything coherent.

I'm just saying it would be neat, and potentially
useful, to intentionally violate this. Of greatest
interest would be the 2-way Opteron boards that
only have RAM connected to the CPU closest to PCI.
The sidecar CPU :-) could be ignored.

Re: Intel vs AMD x86-64

[Dave Jones]

On Tue, Feb 24, 2004 at 10:11:22AM -0500, Albert Cahalan wrote:

 > > so this isn't possible.  The amd64 GART driver goes to great
 > > lengths to make sure it does update the northbridges on every
 > > CPU whenever something changes.
 > 
 > Of course. That's the easy way; you won't need
 > to worry about memory interleave or out-of-bounds
 > prefetch if you keep everything coherent.
 > 
 > I'm just saying it would be neat, and potentially
 > useful, to intentionally violate this. Of greatest
 > interest would be the 2-way Opteron boards that
 > only have RAM connected to the CPU closest to PCI.
 > The sidecar CPU :-) could be ignored.

Why on earth would you want to do that ?
It wouldn't buy you anything at all other than a world of pain.

		Dave

Re: Intel vs AMD x86-64

[Albert Cahalan]

On Tue, 2004-02-24 at 12:34, Dave Jones wrote:
> On Tue, Feb 24, 2004 at 10:11:22AM -0500, Albert Cahalan wrote:
> 
>  > > so this isn't possible.  The amd64 GART driver goes to great
>  > > lengths to make sure it does update the northbridges on every
>  > > CPU whenever something changes.
>  > 
>  > Of course. That's the easy way; you won't need
>  > to worry about memory interleave or out-of-bounds
>  > prefetch if you keep everything coherent.
>  > 
>  > I'm just saying it would be neat, and potentially
>  > useful, to intentionally violate this. Of greatest
>  > interest would be the 2-way Opteron boards that
>  > only have RAM connected to the CPU closest to PCI.
>  > The sidecar CPU :-) could be ignored.
> 
> Why on earth would you want to do that ?
> It wouldn't buy you anything at all other than a world of pain.

faster IO-MMU operations

Re: Intel vs AMD x86-64

[Dave Jones]

On Tue, Feb 24, 2004 at 10:29:07AM -0500, Albert Cahalan wrote:

 > >  > I'm just saying it would be neat, and potentially
 > >  > useful, to intentionally violate this. Of greatest
 > >  > interest would be the 2-way Opteron boards that
 > >  > only have RAM connected to the CPU closest to PCI.
 > >  > The sidecar CPU :-) could be ignored.
 > > Why on earth would you want to do that ?
 > > It wouldn't buy you anything at all other than a world of pain.
 > faster IO-MMU operations

huh ? You're talking about saving a handful of pci config space writes
per every insertion/removal of entries in that GATT, which need a cpu
cache flush anyway.

		Dave

Re: Intel vs AMD x86-64

[Xose Vazquez Perez]

Adrian Bunk wrote:

> In the long term, x86_64 creates more confusion:
> - SuSE says AMD64 [1]
> - RedHat says AMD64 [2]
> - Debian says AMD64 [3]

AMD64 is the incarnation done by AMD and
IA-32e is the incarnation done by Intel
of x86-64 architecture.

I like x86-64 as a generic name, because the same kernel
port runs on both chips and they run the same binaries.

--
x86-64 GenuineIntel

RE: Intel vs AMD x86-64

[Nakajima, Jun]

Sorry for the miscommunication. The page
http://www.intel.com/technology/64bitextensions/faq.htm says at the
_bottom_ at least:

Q9: Is it possible to write software that will run on Intel's processors
with 64-bit extension technology, and AMD's 64-bit capable processors?
A9: With both companies designing entirely different architectures, the
question is whether the operating system and software ported to each
processor will run on the other processor, and the answer is yes in most
cases.

Jun

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
>owner@vger.kernel.org] On Behalf Of Linus Torvalds
>Sent: Monday, February 23, 2004 9:31 AM
>To: Adrian Bunk
>Cc: Herbert Poetzl; Mikael Pettersson; Kernel Mailing List
>Subject: Re: Intel vs AMD x86-64
>
>
>
>On Mon, 23 Feb 2004, Adrian Bunk wrote:
>>
>> In the long term, x86_64 creates more confusion:
>> - SuSE says AMD64 [1]
>> - RedHat says AMD64 [2]
>> - Debian says AMD64 [3]
>>
>> Renaming might be some work today, but it might actually remove
>> confusion in the future.
>
>Well, the thing is, I _like_ a vendor-neutral name.
>
>I think it's important to have multiple sources for a chip, and I think
>one of the problems with IA-64 was that it was a locked-in chip with
>patents and no serious competition internally (ignore the Intel
mouthing
>about "open").
>
>The x86 is so great partly because there's been real competition. So I
>think it's very important to x86-64 to have real competition to make
sure
>nobody gets too dishonest.
>
>So AMD64 is a bad name, partly for the same reason IA32 is a horrible
name
>(and who have you ever heard use the IA32 name except for people who
are
>paid to do so by Intel?)
>
>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. Why the f*ck not just come out and say so,
>and talk about it? It took people actually reading the manuals (which
>didn't mention it either) to convince some people on the architecture
>newsgroups that yes, "ia32e" was really the same as "amd64" except in
the
>small details that have always set Intel and AMD apart.
>
>So I don't really want to change the name. "x86-64" is a good name. I
just
>wish there was more honesty involved, and less friggin *POSTURING*.
>
>			Linus
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

Re: Intel vs AMD x86-64

[Pavel Machek]

Hi!

> Sorry for the miscommunication. The page
> http://www.intel.com/technology/64bitextensions/faq.htm says at the
> _bottom_ at least:
> 
> Q9: Is it possible to write software that will run on Intel's processors
> with 64-bit extension technology, and AMD's 64-bit capable processors?
> A9: With both companies designing entirely different architectures, the
> question is whether the operating system and software ported to each
> processor will run on the other processor, and the answer is yes in most
> cases.

Could you publish list of differences between amd64 and ia32e?

I probably could took those two 300+ page documents and try to compare
them by hand, but I believe you know already. 
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Intel vs AMD x86-64

[Peter Maas]

Hit send too soon...

INTEL HAS PUT up a 354 page PDF which describes software developing for the
64 bit extensions that will appear in the Nocona and Prescott processors.


> http://www.theinquirer.net/?article=14222
>
> ____________________________________________________________________
>
> Ok,
> now that Intel has finally come clean about their x86-64 implementation
> (see
>
>
http://www.intel.com/technology/64bitextensions/index.htm?iid=techtrends+spotlight_64bit
>
> for full details), can somebody write up a list of differences? I know
> there are people who have had access to the Intel docs for a while now,
> and obviously Intel is too frigging proud to list the differences
> explicitly.
>
> >From what I can tell from a quick look, it looks like it is basically
just
> the 3DNow vs SSE3 thing, but I assume there are other details too. Can
> people who have been involved with this make a quick list for the rest of
> us who only got to see the final details today?
>
> (And I assume there's somebody with a few patches pending..)
>
> Thanks,
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

Re: Intel vs AMD x86-64

[Peter Maas]

http://www.theinquirer.net/?article=14222

____________________________________________________________________

Ok,
now that Intel has finally come clean about their x86-64 implementation
(see

http://www.intel.com/technology/64bitextensions/index.htm?iid=techtrends+spotlight_64bit

for full details), can somebody write up a list of differences? I know
there are people who have had access to the Intel docs for a while now,
and obviously Intel is too frigging proud to list the differences
explicitly.

>From what I can tell from a quick look, it looks like it is basically just
the 3DNow vs SSE3 thing, but I assume there are other details too. Can
people who have been involved with this make a quick list for the rest of
us who only got to see the final details today?

(And I assume there's somebody with a few patches pending..)

Thanks,
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Intel vs AMD x86-64

[Linus Torvalds]

Ok, 
 now that Intel has finally come clean about their x86-64 implementation
(see

	http://www.intel.com/technology/64bitextensions/index.htm?iid=techtrends+spotlight_64bit

for full details), can somebody write up a list of differences? I know
there are people who have had access to the Intel docs for a while now,
and obviously Intel is too frigging proud to list the differences
explicitly.

>From what I can tell from a quick look, it looks like it is basically just
the 3DNow vs SSE3 thing, but I assume there are other details too.  Can
people who have been involved with this make a quick list for the rest of
us who only got to see the final details today?

(And I assume there's somebody with a few patches pending..)

	Thanks,
		Linus

Re: Intel vs AMD x86-64

[Mikael Pettersson]

Linus Torvalds writes:
 > 
 > Ok, 
 >  now that Intel has finally come clean about their x86-64 implementation
 > (see
 > 
 > 	http://www.intel.com/technology/64bitextensions/index.htm?iid=techtrends+spotlight_64bit
 > 
 > for full details), can somebody write up a list of differences? I know
 > there are people who have had access to the Intel docs for a while now,
 > and obviously Intel is too frigging proud to list the differences
 > explicitly.

>From what I can see from these docs, Intel's "IA-32e" is very very close
to the natural combination of P4 with AMD64. No hyperlink stuff, but
otherwise the same. The local APIC and performance counters should be
exactly as in P4 :-)

What about naming? IA-64 is taken, AMD64 is too specific, Intel's
"IA-32e" sounds too vague, and I find x86-64 / x86_64 difficult to type.
"x64" perhaps?

Re: Intel vs AMD x86-64

[Diego Calleja García]

El Wed, 18 Feb 2004 10:56:44 +0100 Mikael Pettersson <mikpe@csd.uu.se> escribió:

> From what I can see from these docs, Intel's "IA-32e" is very very close
> to the natural combination of P4 with AMD64. No hyperlink stuff, but
> otherwise the same. The local APIC and performance counters should be
> exactly as in P4 :-)

Does that mean that the opteron-based distros will be able to run 
their x86-64 kernelspace/userspace in intel micros without modifications,
or only the userspace?

Re: Intel vs AMD x86-64

[Bryan O'Sullivan]

On Wed, 2004-02-18 at 06:31, Diego Calleja García wrote:

> Does that mean that the opteron-based distros will be able to run 
> their x86-64 kernelspace/userspace in intel micros without modifications,
> or only the userspace?

Presumably there will be some minor kernel modifications needed, but
Intel's public position is that going forward, there's only one 64-bit
kernel and userspace needed for both platforms.

	<b

Re: Intel vs AMD x86-64

[Stefan Smietanowski]

Tjena Mikael.

>  >  now that Intel has finally come clean about their x86-64 implementation
>  > (see
>  > 
>  > 	http://www.intel.com/technology/64bitextensions/index.htm?iid=techtrends+spotlight_64bit
>  > 
>  > for full details), can somebody write up a list of differences? I know
>  > there are people who have had access to the Intel docs for a while now,
>  > and obviously Intel is too frigging proud to list the differences
>  > explicitly.
> 
>>From what I can see from these docs, Intel's "IA-32e" is very very close
> to the natural combination of P4 with AMD64. No hyperlink stuff, but
> otherwise the same. The local APIC and performance counters should be
> exactly as in P4 :-)
> 
> What about naming? IA-64 is taken, AMD64 is too specific, Intel's
> "IA-32e" sounds too vague, and I find x86-64 / x86_64 difficult to type.
> "x64" perhaps?

You're not planning on inventing new names for existing technology are
you? That's for the manufacturers to mess up :)

// Stefan

Re: Intel vs AMD x86-64

[Linus Torvalds]

On Wed, 18 Feb 2004, Mikael Pettersson wrote:
> 
> What about naming? IA-64 is taken, AMD64 is too specific, Intel's
> "IA-32e" sounds too vague, and I find x86-64 / x86_64 difficult to type.
> "x64" perhaps?

x86-64 it is. Maybe you can remap one of your function keys to send the 
sequence ;)

This whole "ia32" crap has always been ridiculous - nobody has _ever_ 
called an x86 anything but x86, and Intel is just making it worse by 
adding random illogical letters to the end.

In contrast, x86-64 tells you _exactly_ what it's all about, and is what 
the kernel has always called the architecture anyway.

		Linus

Re: Intel vs AMD x86-64

[Herbert Poetzl]

On Wed, Feb 18, 2004 at 07:47:21AM -0800, Linus Torvalds wrote:
> 
> 
> On Wed, 18 Feb 2004, Mikael Pettersson wrote:
> > 
> > What about naming? IA-64 is taken, AMD64 is too specific, Intel's
> > "IA-32e" sounds too vague, and I find x86-64 / x86_64 difficult to type.
> > "x64" perhaps?
> 
> x86-64 it is. Maybe you can remap one of your function keys to send the 
> sequence ;)
> 
> This whole "ia32" crap has always been ridiculous - nobody has _ever_ 
> called an x86 anything but x86, and Intel is just making it worse by 
> adding random illogical letters to the end.
> 
> In contrast, x86-64 tells you _exactly_ what it's all about, and is what 
> the kernel has always called the architecture anyway.

hmm, so the current x86_64 will be changed to x86-64 or
will there be x86_64 and x86-64?

probably I missed something important, but AMD64 seems 
to be labeled x86_64 in 2.4 and 2.6


# ls linux-2.4.25/arch/
alpha/  cris/  ia64/  mips/    parisc/  ppc64/  s390x/  sh64/   sparc64/
arm/    i386/  m68k/  mips64/  ppc/     s390/   sh/     sparc/  x86_64/

# ls linux-2.6.3/arch/
alpha/  cris/   ia64/       mips/    ppc64/  sparc/    v850/
arm/    h8300/  m68k/       parisc/  s390/   sparc64/  x86_64/
arm26/  i386/   m68knommu/  ppc/     sh/     um/

TIA,
Herbert

> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Intel vs AMD x86-64

[Linus Torvalds]

On Sun, 22 Feb 2004, Herbert Poetzl wrote:
> 
> hmm, so the current x86_64 will be changed to x86-64 or
> will there be x86_64 and x86-64?

No. The filesystem policy _tends_ to be that dashes and spaces are turned 
into underscores when used as filenames. Don't ask me why (well, the space 
part is obvious, since real spaces tend to be a pain to use on the command 
line, but don't ask me why people tend to conver a dash to an underscore).

So the real name is (and has always been, as far as I can tell) x86-64. 

Actually, I'm a bit disgusted at Intel for not even _mentioning_ AMD in 
their documentation or their releases, so I'd almost be inclined to rename 
the thing as "AMD64" just to give credit where credit is due. However, 
it's just not worth the pain and confusion.

Any Intel people on this list: tell your managers to be f*cking ashamed of
themselves. Just because Intel didn't care about their customers and has
been playing with some other 64-bit architecture that nobody wanted to use
is no excuse for not giving credit to AMD for what they did with x86-64.

(I'm really happy Intel finally got with the program, but it's pretty 
petty to not even mention AMD in the documentation and try to make it 
look like it was all their idea).

		Linus

Re: Intel vs AMD x86-64

[Tomasz Rola]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 21 Feb 2004, Linus Torvalds wrote:

> into underscores when used as filenames. Don't ask me why (well, the space 
> part is obvious, since real spaces tend to be a pain to use on the command 
> line, but don't ask me why people tend to conver a dash to an underscore).

Maybe because they think dash looks ugly and can sometimes lead to
invoking programs with bad options?

bye
T.

- --
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBQDgkXRETUsyL9vbiEQKcZACg8ankB9l+tyOsM4TRm55NKd3osTEAnAwc
iV3m6qU9hI7CqW1yGnYxTxid
=U1T0
-----END PGP SIGNATURE-----

Re: Intel vs AMD x86-64

[Mike Fedyk]

Tomasz Rola wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sat, 21 Feb 2004, Linus Torvalds wrote:
> 
> 
>>into underscores when used as filenames. Don't ask me why (well, the space 
>>part is obvious, since real spaces tend to be a pain to use on the command 
>>line, but don't ask me why people tend to conver a dash to an underscore).
> 
> 
> Maybe because they think dash looks ugly and can sometimes lead to
> invoking programs with bad options?
Only if it begins with a dash...

Re: Intel vs AMD x86-64

[Scott Robert Ladd]

Linus Torvalds wrote:
> Any Intel people on this list: tell your managers to be f*cking ashamed of
> themselves. Just because Intel didn't care about their customers and has
> been playing with some other 64-bit architecture that nobody wanted to use
> is no excuse for not giving credit to AMD for what they did with x86-64.
> 
> (I'm really happy Intel finally got with the program, but it's pretty 
> petty to not even mention AMD in the documentation and try to make it 
> look like it was all their idea).

I couldn't have put it better myself. Were it polite to attach sounds to 
mailing list posts, I would add thunderous applause to my approbations.

Intel chips have been a part of my professional life for a very long 
time; I've never owned an AMD processor, and I'm certainly not one of 
their fanboys. I've worked closely with folk at Intel on some projects, 
and they have been quite generous at times. Some fine technologists work 
for them.

But on a corporate level, Intel has disappointed me with their arrogant 
failure to give credit where credit is due.

Last week, before Intel's announcement, I ordered a new Linux 
workstation. As a "lone wolf" consultant, I sometimes agonize over 
whether I make the right decisions when buying equipment. In this case, 
I feeling pretty dang good: the new system will arrive with a pair of 
Opterons on the motherboard.

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: Intel vs AMD x86-64

[Timothy Miller]

Scott Robert Ladd wrote:
> Linus Torvalds wrote:
> 
>> Any Intel people on this list: tell your managers to be f*cking 
>> ashamed of
>> themselves. Just because Intel didn't care about their customers and has
>> been playing with some other 64-bit architecture that nobody wanted to 
>> use
>> is no excuse for not giving credit to AMD for what they did with x86-64.
>>
>> (I'm really happy Intel finally got with the program, but it's pretty 
>> petty to not even mention AMD in the documentation and try to make it 
>> look like it was all their idea).
> 
> 
> I couldn't have put it better myself. Were it polite to attach sounds to 
> mailing list posts, I would add thunderous applause to my approbations.
> 
> Intel chips have been a part of my professional life for a very long 
> time; I've never owned an AMD processor, and I'm certainly not one of 
> their fanboys. I've worked closely with folk at Intel on some projects, 
> and they have been quite generous at times. Some fine technologists work 
> for them.
> 
> But on a corporate level, Intel has disappointed me with their arrogant 
> failure to give credit where credit is due.
> 
> Last week, before Intel's announcement, I ordered a new Linux 
> workstation. As a "lone wolf" consultant, I sometimes agonize over 
> whether I make the right decisions when buying equipment. In this case, 
> I feeling pretty dang good: the new system will arrive with a pair of 
> Opterons on the motherboard.
> 

I don't know how accurate this information is, but... (take it with a 
grain of salt)

I have a good friend who worked at a lab where a lot of scientific 
simulations were being done.  Lots of floating-point math.  His 
colleagues tried both AMD and Intel processors.  According to this 
friend, what they found was that not only were the AMD processors FASTER 
at FP math, but the results they got were also a lot more ACCURATE when 
dealing with computations at the far end of FP precision.

In theory, IEEE FP is IEEE FP, but it seems that Intel may have cheated 
in their design, silently reducing precision for the sake of some other 
aspect of their design, making their processors less useful (or 
useless?) for scientific applications.  Another example of Intel 
arrogance?  Or perhaps a reasonable design compromise?  You decide.

Re: Intel vs AMD x86-64

[Tom Vier]

On Sun, Feb 22, 2004 at 07:38:59PM -0500, Timothy Miller wrote:
> In theory, IEEE FP is IEEE FP, but it seems that Intel may have cheated 
> in their design, silently reducing precision for the sake of some other 
> aspect of their design, making their processors less useful (or 
> useless?) for scientific applications.  Another example of Intel 
> arrogance?  Or perhaps a reasonable design compromise?  You decide.

did they use -miiie? was the same compiler (exact same version) used? if the
answer to either is no, that would account for the difference.

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0xE6CB97DA

Re: Intel vs AMD x86-64

[Geert Uytterhoeven]

On Sat, 21 Feb 2004, Linus Torvalds wrote:
> (I'm really happy Intel finally got with the program, but it's pretty
> petty to not even mention AMD in the documentation and try to make it
> look like it was all their idea).

Perhaps they licensed the technology from AMD _without_ the advertising clause?
:-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Intel vs AMD x86-64

[Vojtech Pavlik]

On Sat, Feb 21, 2004 at 07:12:20PM -0800, Linus Torvalds wrote:
> 
> 
> On Sun, 22 Feb 2004, Herbert Poetzl wrote:
> > 
> > hmm, so the current x86_64 will be changed to x86-64 or
> > will there be x86_64 and x86-64?
> 
> No. The filesystem policy _tends_ to be that dashes and spaces are turned 
> into underscores when used as filenames. Don't ask me why (well, the space 
> part is obvious, since real spaces tend to be a pain to use on the command 
> line, but don't ask me why people tend to conver a dash to an underscore).
> 
> So the real name is (and has always been, as far as I can tell) x86-64. 

As far as I know, the real reason for the underscore in x86_64 in Linux
is that autoconf/configure hate dashes in arch names, because of this
notation:

	x86_64-gnu-linux-pc

If a dash were used, the string would be unparseable without prior
knowledge of all arch names.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Intel vs AMD x86-64

[Clay Haapala]

On Sat, 21 Feb 2004, Linus Torvalds outgrape:
> Actually, I'm a bit disgusted at Intel for not even _mentioning_ AMD
> in their documentation or their releases, so I'd almost be inclined
> to rename the thing as "AMD64" just to give credit where credit is
> due. However, it's just not worth the pain and confusion.

I move we:

  s/ia64/itanic/g
  s/x86_64/ia64/g

and acknowledge that the "a" in "ia64" now stands for "AMD".
-- 
Clay Haapala (chaapala@cisco.com) Cisco Systems SRBU +1 763-398-1056
   6450 Wedgwood Rd, Suite 130 Maple Grove MN 55311 PGP: C89240AD
 Not everything derived from the base class "patentable" inherits the
       "non-obvious, "non-trivial", and "original" attributes.

Re: Intel vs AMD x86-64

[Adrian Bunk]

On Sat, Feb 21, 2004 at 07:12:20PM -0800, Linus Torvalds wrote:
>...
> Actually, I'm a bit disgusted at Intel for not even _mentioning_ AMD in 
> their documentation or their releases, so I'd almost be inclined to rename 
> the thing as "AMD64" just to give credit where credit is due. However, 
> it's just not worth the pain and confusion.
>...

In the long term, x86_64 creates more confusion:
- SuSE says AMD64 [1]
- RedHat says AMD64 [2]
- Debian says AMD64 [3]

Renaming might be some work today, but it might actually remove 
confusion in the future.

> 		Linus

cu
Adrian

[1] http://www.suse.com/us/business/products/server/sles/amd64.html
[2] http://www.redhat.com/software/rhel/comparison/
[3] http://www.debian.org/ports/

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Intel vs AMD x86-64

[Linus Torvalds]

On Mon, 23 Feb 2004, Adrian Bunk wrote:
> 
> In the long term, x86_64 creates more confusion:
> - SuSE says AMD64 [1]
> - RedHat says AMD64 [2]
> - Debian says AMD64 [3]
> 
> Renaming might be some work today, but it might actually remove 
> confusion in the future.

Well, the thing is, I _like_ a vendor-neutral name.

I think it's important to have multiple sources for a chip, and I think 
one of the problems with IA-64 was that it was a locked-in chip with 
patents and no serious competition internally (ignore the Intel mouthing 
about "open").

The x86 is so great partly because there's been real competition. So I 
think it's very important to x86-64 to have real competition to make sure 
nobody gets too dishonest.

So AMD64 is a bad name, partly for the same reason IA32 is a horrible name 
(and who have you ever heard use the IA32 name except for people who are 
paid to do so by Intel?)

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. Why the f*ck not just come out and say so,
and talk about it? It took people actually reading the manuals (which
didn't mention it either) to convince some people on the architecture
newsgroups that yes, "ia32e" was really the same as "amd64" except in the
small details that have always set Intel and AMD apart.

So I don't really want to change the name. "x86-64" is a good name. I just 
wish there was more honesty involved, and less friggin *POSTURING*.

			Linus

Re: Intel vs AMD x86-64

[Kees Bakker]

>>>>> Linus Torvalds writes:
> 
> So AMD64 is a bad name, partly for the same reason IA32 is a horrible name 
> (and who have you ever heard use the IA32 name except for people who are 
> paid to do so by Intel?)

So, what about these OSDL people :-)
   http://www.osdl.org/projects/26lnxstblztn/results/

Re: Intel vs AMD x86-64

[viro]

On Tue, Feb 24, 2004 at 10:47:06AM +0100, Kees Bakker wrote:
> >>>>> Linus Torvalds writes:
> > 
> > So AMD64 is a bad name, partly for the same reason IA32 is a horrible name 
> > (and who have you ever heard use the IA32 name except for people who are 
> > paid to do so by Intel?)
> 
> So, what about these OSDL people :-)
>    http://www.osdl.org/projects/26lnxstblztn/results/
                                  ^^^^^^^^^^^^

You know, it probably violates some IBM patents...

Re: Intel vs AMD x86-64

[Andrew Walrond]

On Monday 23 Feb 2004 5:31 pm, Linus Torvalds wrote:
>
> The x86 is so great partly because there's been real competition. So I
> think it's very important to x86-64 to have real competition to make sure
> nobody gets too dishonest.

I think linux's support for so many architectures is important in this 
respect. I can now compare and choose between several distinct architectures, 
rather than just different flavour of x86. That's where the real competition 
will be long-term. (indeed, I would probably buy ia64 if not for the fact 
that I can put together 5 opteron systems for the price of 1 ia64...)

I'm don't usually subscribe to conspiracy theories, but I've got this really 
nasty suspicion that intel really did conspire with microsoft to delay win64 
until their x86-64 chip was ready.

The more influential linux becomes, the easier it will become for amd et al to 
compete, and relegate this sort of bullshit to then past, where it belongs. 
And competition means faster/better/cheaper processors, which is what I care 
about.

Andrew Walrond

Re: Intel vs AMD x86-64

[Christoph Hellwig]

On Mon, Feb 23, 2004 at 06:03:36PM +0100, Adrian Bunk wrote:
> In the long term, x86_64 creates more confusion:
> - SuSE says AMD64 [1]
> - RedHat says AMD64 [2]

Not the rpm architecture, though :)

Maybe they also say IPF for ia64?

Re: Intel vs AMD x86-64

[Rik van Riel]

On Sat, 21 Feb 2004, Linus Torvalds wrote:

> I'm really happy Intel finally got with the program,

With the program?  They still don't have an IOMMU ;)

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Intel vs AMD x86-64

[Linus Torvalds]

On Mon, 23 Feb 2004, Rik van Riel wrote:
> On Sat, 21 Feb 2004, Linus Torvalds wrote:
> 
> > I'm really happy Intel finally got with the program,
> 
> With the program?  They still don't have an IOMMU ;)

Hmm.. Let's see what their chipsets will look like for this thing. Since
they don't have an integrated memory controller, they can't very well do
the IOMMU on the CPU, now can they?

So you can't blame them for that.

		Linus

Re: Intel vs AMD x86-64

[David S. Miller]

On Mon, 23 Feb 2004 13:36:43 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:

> On Mon, 23 Feb 2004, Rik van Riel wrote:
> > On Sat, 21 Feb 2004, Linus Torvalds wrote:
> > 
> > > I'm really happy Intel finally got with the program,
> > 
> > With the program?  They still don't have an IOMMU ;)
> 
> Hmm.. Let's see what their chipsets will look like for this thing. Since
> they don't have an integrated memory controller, they can't very well do
> the IOMMU on the CPU, now can they?

You mean the PCI controller is in the CPU, else how else would you
accomplish this?

Or are you suggesting something else?

Really, not having an IOMMU on a 64-bit platform these days is basically like
pulling out one's toenails with an ice pick.

Re: Intel vs AMD x86-64

[Linus Torvalds]

On Mon, 23 Feb 2004, David S. Miller wrote:
> 
> You mean the PCI controller is in the CPU, else how else would you
> accomplish this?

The IOMMU basically needs to be on the northbridge or at least in between
the PCI bus an a northbridge (pretty much by definition: the bridge
between IO and memory). On an Opteron, that's on-the-chip. For current
Intel chips that's a separate chip.

In fact, I _think_ you could actually use the AGP bridge as a strange
IOMMU. Of course, right now their AGP bridges are all 32-bit limited
anyway, but the point being that they at least in theory would seem to
have the capability to do this.

> Really, not having an IOMMU on a 64-bit platform these days is basically like
> pulling out one's toenails with an ice pick.

Well, as long as they had that "64-bit is server" mentality, they can 
honestly say that you just have to use 64-bit-capable PCI cards.

Now, the "server only" mentality is obviously crap, but since we haven't
even seen the chipsets designed for the 64-bit chips, we shouldn't
complain. At least yet.

Now, I'm not above complaining about Intel (in fact, the Intel people seem
to often think I hate them because I'm apparently the only person who gets
quoted who complains about bad decisions publicly), but at least I try to
avoid complaining before-the-fact ;)

			Linus

Re: Intel vs AMD x86-64

[David S. Miller]

On Mon, 23 Feb 2004 14:08:40 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:

> In fact, I _think_ you could actually use the AGP bridge as a strange
> IOMMU. Of course, right now their AGP bridges are all 32-bit limited
> anyway, but the point being that they at least in theory would seem to
> have the capability to do this.

Ok, I see.  In fact, I remember some vague notion that the AGP bridge
on the Athlon's could technically be used as a full-on IOMMU, especially
since it was all derived from Alpha PCI chipsets which did use things
this way.

Re: Intel vs AMD x86-64

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.58.0402231335430.3005@ppc970.osdl.org>
By author:    Linus Torvalds <torvalds@osdl.org>
In newsgroup: linux.dev.kernel
>
> 
> 
> On Mon, 23 Feb 2004, Rik van Riel wrote:
> > On Sat, 21 Feb 2004, Linus Torvalds wrote:
> > 
> > > I'm really happy Intel finally got with the program,
> > 
> > With the program?  They still don't have an IOMMU ;)
> 
> Hmm.. Let's see what their chipsets will look like for this thing. Since
> they don't have an integrated memory controller, they can't very well do
> the IOMMU on the CPU, now can they?
> 
> So you can't blame them for that.
> 

No, it should be in the northbridge.  Note that *most* AGPGARTs work
as IOMMUs, but not all.  They may not be 64 bits, though.

	-hpa

Re: Intel vs AMD x86-64

[Thomas Zehetbauer]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

On Sam, 2004-02-21 at 19:12 -0800, Linus Torvalds wrote:  
> Any Intel people on this list: tell your managers to be f*cking ashamed of
> themselves. Just because Intel didn't care about their customers and has
> been playing with some other 64-bit architecture that nobody wanted to use
> is no excuse for not giving credit to AMD for what they did with x86-64.

This very clear statement deserves standing ovations :-)

If anyone from Intel is really listening here I would like them to know
that I am pretty much pissed of by their product politics as well.

Although older Celeron processors supported SMP configurations they were
not supported and to my knowledge never used in the primary SMP market.
So in fact they even helped Intel to increase their revenues by allowing
hobbyists to build their own affordable SMP boxes. Nonetheless Intel has
decided to disable this capability in current Celeron and even Pentium
processors attempting to force hobbyists into the professional market
with about four times the cost of previous configurations.

For my part I have understood the message from Intel, that they do not
want hobbyists looking for cheap SMP configurations as their customers
and will accordingly buy AMD in the future.

Tom


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

Re: Intel vs AMD x86-64

[John Heil]

On Tue, 24 Feb 2004, Thomas Zehetbauer wrote:

> Date: Tue, 24 Feb 2004 02:01:02 +0100
> From: Thomas Zehetbauer <thomasz@hostmaster.org>
> To: Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: Intel vs AMD x86-64
>
> On Sam, 2004-02-21 at 19:12 -0800, Linus Torvalds wrote:
> > Any Intel people on this list: tell your managers to be f*cking ashamed of
> > themselves. Just because Intel didn't care about their customers and has
> > been playing with some other 64-bit architecture that nobody wanted to use
> > is no excuse for not giving credit to AMD for what they did with x86-64.
>
> This very clear statement deserves standing ovations :-)
>
> If anyone from Intel is really listening here I would like them to know
> that I am pretty much pissed of by their product politics as well.
>
> Although older Celeron processors supported SMP configurations they were
> not supported and to my knowledge never used in the primary SMP market.
> So in fact they even helped Intel to increase their revenues by allowing
> hobbyists to build their own affordable SMP boxes. Nonetheless Intel has
> decided to disable this capability in current Celeron and even Pentium
> processors attempting to force hobbyists into the professional market
> with about four times the cost of previous configurations.
>
> For my part I have understood the message from Intel, that they do not
> want hobbyists looking for cheap SMP configurations as their customers
> and will accordingly buy AMD in the future.
>
> Tom
>

I'll second that.

For whatever it's worth I replaced all my intel business boxes w AMD
w the advent of the K7/Athlon's and haven't looked back since,
including SMP. Next up for us will be dual Opteron. I cannot see
ever returning to Intel.


johnh

-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

Re: Intel vs AMD x86-64

[Timothy Miller]

John Heil wrote:

> 
> 
> I'll second that.
> 
> For whatever it's worth I replaced all my intel business boxes w AMD
> w the advent of the K7/Athlon's and haven't looked back since,
> including SMP. Next up for us will be dual Opteron. I cannot see
> ever returning to Intel.
> 


This is not a comment in favor of Intel... just a lament...

Things may have changed, but when I last built a Linux box (Athlon XP 
2800+), I was not able to find a motherboard for recent AMD processors 
with 64bit/66mhz PCI slots.  If I'd needed that, I would have had to go 
with Intel.

Re: Intel vs AMD x86-64

[Scott Robert Ladd]

Timothy Miller wrote:
> This is not a comment in favor of Intel... just a lament...
> 
> Things may have changed, but when I last built a Linux box (Athlon XP 
> 2800+), I was not able to find a motherboard for recent AMD processors 
> with 64bit/66mhz PCI slots.  If I'd needed that, I would have had to go 
> with Intel.

The Tyan K8W S-2885ANRF (a dual Opteron board) has:

One 8X AGP / AGP Pro110 slot
Two independent PCI-X buses
Two 64-bit 100/66/33 MHz (3.3-Volt)
Two 64-bit 133/100/66/33 MHz (3.3-Volt)
One legacy 32-bit 33MHz (5-Volt) PCI slot

This is the board I've ordered in my new workstation. I've heard that 
people have used this board quite successfully with Linux (fingers crossed).

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing

Re: Intel vs AMD x86-64

[Rogier Wolff]

On Tue, Feb 24, 2004 at 08:32:07AM -0500, Timothy Miller wrote:
> Things may have changed, but when I last built a Linux box (Athlon XP 
> 2800+), I was not able to find a motherboard for recent AMD processors 
> with 64bit/66mhz PCI slots.  If I'd needed that, I would have had to go 
> with Intel.

Ehmm. We've been trying to get 64/66 slots in our systems a while, and
the only affordable option I've been able to find are the dual-athlon 
boards (Tyan, Asus). 

We found tons of Intel boards that didn't have them until we figured 
out that the popular Intel chipsets didn't support it....

	Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
**** "Linux is like a wigwam -  no windows, no gates, apache inside!" ****

Re: Intel vs AMD x86-64

[John Heil]

On Tue, 24 Feb 2004, Rogier Wolff wrote:

> Date: Tue, 24 Feb 2004 20:43:54 +0100
> From: Rogier Wolff <R.E.Wolff@BitWizard.nl>
> To: Timothy Miller <miller@techsource.com>
> Cc: John Heil <kerndev@sc-software.com>,
>      Thomas Zehetbauer <thomasz@hostmaster.org>,
>      Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: Intel vs AMD x86-64
>
> On Tue, Feb 24, 2004 at 08:32:07AM -0500, Timothy Miller wrote:
> > Things may have changed, but when I last built a Linux box (Athlon XP
> > 2800+), I was not able to find a motherboard for recent AMD processors
> > with 64bit/66mhz PCI slots.  If I'd needed that, I would have had to go
> > with Intel.
>
> Ehmm. We've been trying to get 64/66 slots in our systems a while, and
> the only affordable option I've been able to find are the dual-athlon
> boards (Tyan, Asus).


And so far, I've found Tyan to be the slightly more reliable of the two.

johnh


>
> We found tons of Intel boards that didn't have them until we figured
> out that the popular Intel chipsets didn't support it....
>
> 	Roger.
>
> --
> ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
> *-- BitWizard writes Linux device drivers for any device you may have! --*
> **** "Linux is like a wigwam -  no windows, no gates, apache inside!" ****
>

-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

Re: Intel vs AMD x86-64

[Mike Fedyk]

John Heil wrote:
> And so far, I've found Tyan to be the slightly more reliable of the two.

How so?  What kind of failures did you have with the ASUS board?

Re: Intel vs AMD x86-64

[John Heil]

On Tue, 24 Feb 2004, Mike Fedyk wrote:

> Date: Tue, 24 Feb 2004 12:03:20 -0800
> From: Mike Fedyk <mfedyk@matchmail.com>
> To: John Heil <kerndev@sc-software.com>
> Cc: Rogier Wolff <R.E.Wolff@BitWizard.nl>,
>      Timothy Miller <miller@techsource.com>,
>      Thomas Zehetbauer <thomasz@hostmaster.org>,
>      Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: Intel vs AMD x86-64
>
> John Heil wrote:
> > And so far, I've found Tyan to be the slightly more reliable of the two.
>
> How so?  What kind of failures did you have with the ASUS board?
>

IIRC The Asus had problems w DMA for IDE bus 1 and moving
     to whatever Tyan I replaced it w solved the prob.
     ...I know... that's southbridge chip specific...
     but Asus chose the chipset...

Just my .02

johnh

-
-----------------------------------------------------------------
John Heil
South Coast Software
Custom systems software for UNIX and IBM MVS mainframes
1-714-774-6952
johnhscs@sc-software.com
http://www.sc-software.com
-----------------------------------------------------------------

Re: Intel vs AMD x86-64

[Timothy Miller]

John Heil wrote:
> On Tue, 24 Feb 2004, Rogier Wolff wrote:
> 
> 
>>Date: Tue, 24 Feb 2004 20:43:54 +0100
>>From: Rogier Wolff <R.E.Wolff@BitWizard.nl>
>>To: Timothy Miller <miller@techsource.com>
>>Cc: John Heil <kerndev@sc-software.com>,
>>     Thomas Zehetbauer <thomasz@hostmaster.org>,
>>     Kernel Mailing List <linux-kernel@vger.kernel.org>
>>Subject: Re: Intel vs AMD x86-64
>>
>>On Tue, Feb 24, 2004 at 08:32:07AM -0500, Timothy Miller wrote:
>>
>>>Things may have changed, but when I last built a Linux box (Athlon XP
>>>2800+), I was not able to find a motherboard for recent AMD processors
>>>with 64bit/66mhz PCI slots.  If I'd needed that, I would have had to go
>>>with Intel.
>>
>>Ehmm. We've been trying to get 64/66 slots in our systems a while, and
>>the only affordable option I've been able to find are the dual-athlon
>>boards (Tyan, Asus).
> 
> 
> 
> And so far, I've found Tyan to be the slightly more reliable of the two.


The problem was that the Tyan I found which did 64/66 was a dual 
processor board (not a problem) that had a maximum FSB of 266mhz (or 
maybe it was 200?).  I would have been stuck with dual Athlon XP 2400+ 
(or worse), rather than something faster like the 2800+ I have.  Well, 
the dual would be faster if I were running multi-threaded applications, 
but most of the CPU-intensive stuff I tend to tinker with is 
single-threaded and also memory-intensive, making the single 2800+ more 
attractive (I could have gotten the 3000+, but the cost increase wasn't 
worth the small performance increase).

Re: Intel vs AMD x86-64

[Matt Seitz]

Linus Torvalds wrote:
> The filesystem policy _tends_ to be that dashes and spaces are turned 
> into underscores when used as filenames. Don't ask me why (well, the space 
> part is obvious, since real spaces tend to be a pain to use on the command 
> line, but don't ask me why people tend to conver a dash to an underscore).

Perhaps to comply with the ISO-9660/ECMA-119 standard for CD-ROM file systems? 
ISO 9660/ECMA-119 requires file names to contain only 0-9, uppercase A-Z, 
underscore, a single dot ("."), and a single semicolon (";")[1].  For details, 
see section 7.5.1 of ECMA-119:

http://www.ecma-international.org/publications/standards/Ecma-119.htm

[1] One can use various techniques to create file names that contain additional 
characters within a valid ISO 9660 file system.  However, these file names may 
not be accessible on all operating systems.

Re: Intel vs AMD x86-64

[Aaron Lehmann]

On Wed, Feb 18, 2004 at 10:56:44AM +0100, Mikael Pettersson wrote:
> What about naming? IA-64 is taken, AMD64 is too specific, Intel's
> "IA-32e" sounds too vague, and I find x86-64 / x86_64 difficult to type.
> "x64" perhaps?

I feel that AMD64 is appropriate. We've been calling all the AMD/Cyrix
chips IA32 processors, and this is no different.

Re: Intel vs AMD x86-64

[Mikael Pettersson]

Aaron Lehmann writes:
 > On Wed, Feb 18, 2004 at 10:56:44AM +0100, Mikael Pettersson wrote:
 > > What about naming? IA-64 is taken, AMD64 is too specific, Intel's
 > > "IA-32e" sounds too vague, and I find x86-64 / x86_64 difficult to type.
 > > "x64" perhaps?
 > 
 > I feel that AMD64 is appropriate. We've been calling all the AMD/Cyrix
 > chips IA32 processors, and this is no different.

Actually I would call them x86, never IA32.

Re: Intel vs AMD x86-64

[Terje Eggestad]

To whom ever making a list

The sysenter/syscall thing continues. 

On ia32e sysenter/sysleave is legal in 64 bit, but since ia32e also
implement syscall in 64bit (only, not in legacy, nor compatability) this
shouldn't have any practical implications. 

TJ

On Wed, 2004-02-18 at 02:44, Linus Torvalds wrote: 
> Ok, 
>  now that Intel has finally come clean about their x86-64 implementation
> (see
> 
> 	http://www.intel.com/technology/64bitextensions/index.htm?iid=techtrends+spotlight_64bit
> 
> for full details), can somebody write up a list of differences? I know
> there are people who have had access to the Intel docs for a while now,
> and obviously Intel is too frigging proud to list the differences
> explicitly.
> 
> >From what I can tell from a quick look, it looks like it is basically just
> the 3DNow vs SSE3 thing, but I assume there are other details too.  Can
> people who have been involved with this make a quick list for the rest of
> us who only got to see the final details today?
> 
> (And I assume there's somebody with a few patches pending..)
> 
> 	Thanks,
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 

Terje Eggestad
Senior Software Engineer
dir. +47 22 62 89 61
mob. +47 975 31 57
fax. +47 22 62 89 51
terje.eggestad@scali.com

Scali - www.scali.com
High Performance Clustering