AMD64 = IA-32e

[Black Jack]

Regarding whether Intel is going to be using the AMD64 language or not, and
answer is not, it's using the IA-32e language. Other than the name it's
exactly the same as AMD64, right down to the number of registers, and lack
of support for Virtual-8086 mode, etc.

Here is AMD's AMD64 documentation:
http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html

Here is Intel's IA-32e documentation:
Vol 1: http://www.intel.com/technology/64bitextensions/300834.htm
Vol 2: http://www.intel.com/technology/64bitextensions/300835.htm

It doesn't even look like Intel did much to change the formatting of their
PDFs from AMD's. :-)

Yousuf Khan

[steve harris]

Black Jack wrote:
Regarding whether Intel is going to be using the AMD64 language or not, and answer is not, it's using the IA-32e language. Other than the name it's exactly the same as AMD64, right down to the number of registers, and lack of support for Virtual-8086 mode, etc. Here is AMD's AMD64 documentation: http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html Here is Intel's IA-32e documentation: Vol 1: http://www.intel.com/technology/64bitextensions/300834.htm Vol 2: http://www.intel.com/technology/64bitextensions/300835.htm It doesn't even look like Intel did much to change the formatting of their PDFs from AMD's. :-) Yousuf Khan

http://www.investorshub.com/boards/read_msg.asp?message_id=2404565

[joe smith]

> > Here is Intel's IA-32e documentation: Vol 1: http://www.intel.com/technology/64bitextensions/300834.htm Vol 2: http://www.intel.com/technology/64bitextensions/300835.htm It doesn't even look like Intel did much to change the formatting of
their PDFs from AMD's. :-) Yousuf Khan http://www.investorshub.com/boards/read_msg.asp?message_id=2404565

This is all very good news, even for little troll a-holes like me. I must
applaud Intel's decision to put their pride aside and doing a very good
decision for themselves and their customers. Don't have to think of
medium-term (shy on using long-term in context of desktop PC's..) effects of
the investment: the latest cutting-edge X86 extended instructions will be
usable no matter which vendor's way you go on this regard. SSE3 is another
issue, but atleast can't go wrong as far as 64-bit X86 spin-offs are
concerned. Very nice.

From technical perspective, it looks amazingly nice to look at the number
and width of the registers side-by-side (yes, identical sets.. that's the
point). I don't know if Microsoft's earlier announcement regarding support
for more than one 64-bit X86 based architechture has anything to do with
this, but if it has, I'm glad Microsoft used their monopoly position FOR
ONCE (okay, this is a bit strong wording but just think is mildly amusing)
for common good.

Without possibility of variety, things can go stagnant easily.. this is why
systems where most available architechtures work (thinking of UNIX and the
mindset that goes with that) without being locked to a single (or few)
hardwired standards like what kind of CPU is inside the machine, is a good
thing. I'm ofcourse referring to compiling sourcecode against widely adopted
standards like POSIX and X11 for instance.

The bytecode mindset Microsoft has in mind, which is processor architechture
independent (Yup, that's .NET, atleast in theory :) is a way forward which
will give wider opportunity to optimize (okay, atleast match) shipped
application with the client's hardware better. This is a step forward, even
if at first it is a step backwards (as far as performance is concerned, .NET
is yet to demonstrate being of higher performance than traditional languages
like C or C++ for example, but it's getting closer all the time, and when
the packed datatype support/optimizations and better runtimes arrive, who
knows when, or when the difference on things that count is made neglible by
the Moore's Law there shouldn't be much room for complaints).

That put aside, as long as statically compiled software (or dll runtimes)
are the way most of the software is written for the desktop, it's atleast a
good thing overall for the industry and customers alike that there is less
different architechtures that have to be taken care of. It's easy to go
where the fence is the slowest. It's the nature of man. If the fence is the
lowest, where work of a few benefit the many, that is the route that leads
to best results -on average-, and that's what .NET has chance of delivering.
If certain company plays it's cards right and does it's job well enough.
Meanwhile, this thread I am replying to, for some odd reason make me think
that 64-bit adoptation rate will be increased, which is not the part that
makes the developer inside me smile, it's the fact that there will be MORE
REGISTERS, which shows as much as 15% average performance increase with only
recompilation, and this is with early versions of compilers for the new,
improved ISA. :) IA32e, AMD64, whatever it's being called at the time.. :)

Ofcourse I could be fucking totally wrong, in that case forget it, I'm just
trolling anyway. If I was right, please worship me.. I was ofcourse serious.
Right.

[gaffo]

Black Jack wrote:
Regarding whether Intel is going to be using the AMD64 language or not, and answer is not, it's using the IA-32e language. Other than the name it's exactly the same as AMD64, right down to the number of registers, and lack of support for Virtual-8086 mode, etc. Here is AMD's AMD64 documentation: http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html Here is Intel's IA-32e documentation: Vol 1: http://www.intel.com/technology/64bitextensions/300834.htm Vol 2: http://www.intel.com/technology/64bitextensions/300835.htm It doesn't even look like Intel did much to change the formatting of their PDFs from AMD's. :-) Yousuf Khan


Virtual-8086 mode?........what is that?

so the AMD64 chip will not be able to run 16-bit XT programs natively?

--





RUSSERT: Are you prepared to lose?

BUSH: No, I'm not going to lose.

RUSSERT: If you did, what would you do?

BUSH: Well, I don't plan on losing. I've got a vision for what I want to
do for the country.
See, I know exactly where I want to lead.................And we got
changing times
here in America, too., 2/8/04


"And that's very important for, I think, the people to understand where
I'm coming from,
to know that this is a dangerous world. I wish it wasn't. I'm a war
president.
I make decisions here in the Oval Office in foreign policy matters with
war on my mind.
- pResident of the United State of America, 2/8/04


"Let's talk about the nuclear proposition for a minute. We know that
based on intelligence, that he has been very, very good at hiding
these kinds of efforts. He's had years to get good at it and we know
he has been absolutely devoted to trying to acquire nuclear weapons.
And we believe he has, in fact, reconstituted nuclear weapons."
- Vice President Dick Cheney, on "Meet the Press", 3/16/03


"I don't know anybody that I can think of who has contended that the
Iraqis had nuclear weapons."
- Defense Secretary Donald Rumsfeld, 6/24/03


"I think in this case international law
stood in the way of doing the right thing (invading Iraq)."
- Richard Perle


"He (Saddam Hussein) has not developed any significant capability with
respect to weapons of mass destruction. He is unable to project
conventional power against his neighbours."
- Colin Powell February 24 2001


"We have been successful for the last ten years in keeping
him from developing those weapons and we will continue to be successful."

"He threatens not the United States."

"But I also thought that we had pretty
much removed his stings and frankly for ten years we really have."

'But what is interesting is that with the regime that has been in place
for the past ten years, I think a pretty good job has been done of
keeping him from breaking out and suddenly showing up one day and saying
"look what I got." He hasn't been able to do that.'
- Colin Powell February 26 2001

[Rob Stow]

gaffo wrote:
Black Jack wrote: Regarding whether Intel is going to be using the AMD64 language or not, and answer is not, it's using the IA-32e language. Other than the name it's exactly the same as AMD64, right down to the number of registers, and lack of support for Virtual-8086 mode, etc. Here is AMD's AMD64 documentation: http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html Here is Intel's IA-32e documentation: Vol 1: http://www.intel.com/technology/64bitextensions/300834.htm Vol 2: http://www.intel.com/technology/64bitextensions/300835.htm It doesn't even look like Intel did much to change the formatting of their PDFs from AMD's. :-) Yousuf Khan Virtual-8086 mode?........what is that? so the AMD64 chip will not be able to run 16-bit XT programs natively?

I'd hate to generalize from one very limited test, but about a
week ago I was unable to boot an Opty dualie or an Athlon64 from
a MS-DOS 3.3 floppy. No problems with MS-DOS 6.22.

I would have tried an even earlier DOS, but 3.3 was the oldest
disk image we could find - not that we tried too hard :-)

[Alex Johnson]

gaffo wrote: Black Jack wrote: Regarding whether Intel is going to be using the AMD64 language or not, and answer is not, it's using the IA-32e language. Other than the name it's exactly the same as AMD64, right down to the number of registers, and lack of support for Virtual-8086 mode, etc. Here is AMD's AMD64 documentation: http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html Here is Intel's IA-32e documentation: Vol 1: http://www.intel.com/technology/64bitextensions/300834.htm Vol 2: http://www.intel.com/technology/64bitextensions/300835.htm It doesn't even look like Intel did much to change the formatting of their PDFs from AMD's. :-) Yousuf Khan Virtual-8086 mode?........what is that? so the AMD64 chip will not be able to run 16-bit XT programs natively?

Do a google search for "virtual 8086" (not quoted). You will find
plenty of explanations in the first page.

V86 allows a 32-bit protected processor to emulate multiple 8086
processors by restricting access to some instructions, changing fault
behavior, and locking down translation and addressing to a special
subset of what the chip normally allows.

You might be able to run real mode (DOS for example) but you will not be
able to run 64-bit OS or programs that put the processor into extended
mode and then use V86 mode access to BIOS. Through "legacy mode" you
can still do 32-bit OS + V86, if I understand correctly.

Alex
--
My words are my own. They represent no other; they belong to no other.
Don't read anything into them or you may be required to compensate me
for violation of copyright. (I do not speak for my employer.)

[jack]

Black Jack <news.yaya.bbbl67@spamgourmet.com> wrote:
<snip>

OT to your post, but did you find yerself a new alias, Yousuf? ;-)

J.

[gaf1234567890]

gaffo <gaffo@usenet.net> wrote in message news:<EZVYb.852$BK3.811@newssvr22.news.prodigy.com>... Virtual-8086 mode?........what is that? so the AMD64 chip will not be able to run 16-bit XT programs natively?

From what others have written, you should have no problems in Real
Mode (ie actually booting to DOS), or V86 Mode under 386 Mode (ie
running 32 bit Windows).

But apparently in 64 bit extended (long?) mode it drops V86 Mode.

So you can run 32bit and 16bit apps together, or 32bit and 64bit apps
together, but not all three at once.

I think.

[spinlock]

Wow, those guys at AMD sure are smart.

They created x86-64 before Intel.

Who would have thought to extend the EAX register
from 32 to 64 bits! And then they extended all the
other registers to 64 bits. Infuckingcredible!!!!

Wow, that was real genius! AMD engineers sure
deserve a lot of credit for beating Intel to the 64bit punch.

I am really surprised that no one at Intel thought of this
before the AMD guys did!

"Black Jack" <news.yaya.bbbl67@spamgourmet.com> wrote in message
news:d8bc87ef.0402181141.7159b0fa@posting.google.com... Regarding whether Intel is going to be using the AMD64 language or not,
and answer is not, it's using the IA-32e language. Other than the name it's exactly the same as AMD64, right down to the number of registers, and lack of support for Virtual-8086 mode, etc. Here is AMD's AMD64 documentation:
http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html Here is Intel's IA-32e documentation: Vol 1: http://www.intel.com/technology/64bitextensions/300834.htm Vol 2: http://www.intel.com/technology/64bitextensions/300835.htm It doesn't even look like Intel did much to change the formatting of their PDFs from AMD's. :-) Yousuf Khan

[Rob Stow]

spinlock wrote: Wow, those guys at AMD sure are smart. They created x86-64 before Intel. Who would have thought to extend the EAX register from 32 to 64 bits! And then they extended all the other registers to 64 bits. Infuckingcredible!!!!

Ignoring your sarcasm, the extended registers are only
half the register story for AMD64 - they also doubled the
number of registers.

I think most of the performance gains we are seeing with the
limited amount (so far) of 64-bit optimized software are due
to having more registers than to any other single factor except
the integrated memory controller.
Wow, that was real genius! AMD engineers sure deserve a lot of credit for beating Intel to the 64bit punch.

You bet they do. Intel really screwed the pooch by not
jumping on the AMD64 bandwagon a few years ago.

And Intel's AMD64 clone looks like it will be handicapped by
1.) Memory latencies because they are still going to rely on
external memory controllers.
2.) Inability to do cheap, fast, and easy SMP because they will
still rely on the chipset to provide the glue logic instead
of building it into the processors like AMD did.

AMD will now, with good justification, be able to say that
they are the "real thing", while Intel's johnny-come-lately
chip is merely a cheap clone that omits a couple of very
important features.

Remember how AMD was mocked when the first started making
clones of Intel chips ? I'll bet you there is a lot of
glee at AMD now that Intel is the one doing the cloning.
I am really surprised that no one at Intel thought of this before the AMD guys did!

Who says they didn't ? But /if/ they did think of it first,
then the Intel execs really screwed the pooch by not
pursuing the idea.
"Black Jack" <news.yaya.bbbl67@spamgourmet.com> wrote in message news:d8bc87ef.0402181141.7159b0fa@posting.google.com...Regarding whether Intel is going to be using the AMD64 language or not, andanswer is not, it's using the IA-32e language. Other than the name it'sexactly the same as AMD64, right down to the number of registers, and lackof support for Virtual-8086 mode, etc.Here is AMD's AMD64 documentation: http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.htmlHere is Intel's IA-32e documentation:Vol 1: http://www.intel.com/technology/64bitextensions/300834.htmVol 2: http://www.intel.com/technology/64bitextensions/300835.htmIt doesn't even look like Intel did much to change the formatting of theirPDFs from AMD's. :-) Yousuf Khan

[RusH]

news.yaya.bbbl67@spamgourmet.com (Black Jack) wrote :

http://www.eetimes.com/semi/news/OEG20040217S0033

"The big databases have already been converted over to Itanium, and
they will be on Itanium forever," Fister added.

Define "forever" heheheheheh.

Pozdrawiam.
--
RusH //
http://pulse.pdi.net/~rush/qv30/
Like ninjas, true hackers are shrouded in secrecy and mystery.
You may never know -- UNTIL IT'S TOO LATE.

[Robert Myers]

On Thu, 19 Feb 2004 18:30:10 -0600, Rob Stow <rob.stow@sasktel.net>
wrote:

<snip>I think most of the performance gains we are seeing with thelimited amount (so far) of 64-bit optimized software are dueto having more registers than to any other single factor exceptthe integrated memory controller.

How would you tell the difference?

The across-the-board winner, practically all problems, practically all
coding styles, has almost got to be reduced latency. In the same
category as increasing the size of the cache, only much better,
because you don't have to work so hard to suck stuff into the cache.

More register names. My guess is that the biggest benefit is to
compiler writers and hand coders.

RM

[Robert Myers]

On Fri, 20 Feb 2004 01:36:13 +0000 (UTC), RusH <rush@pulse.pdi.net>
wrote:
news.yaya.bbbl67@spamgourmet.com (Black Jack) wrote :http://www.eetimes.com/semi/news/OEG20040217S0033"The big databases have already been converted over to Itanium, andthey will be on Itanium forever," Fister added.Define "forever" heheheheheh.

I suppose that Intel has done so well out of just dumb, blind luck,
and that given the same dumb, blind luck, you could do just as well.

Intel has a strategy here. These are not stupid people, and the
strategy may be working better than you think.

Your belief, I suppose, is that Intel management is whistling past the
graveyard. Their strategy was to get big customers locked into an
absolutely unique architecture. To the extent that Intel has
succeeded, those customers are not going back to x86.

Intel's strategy is built more on human psychology than it is on any
principal of engineering. Once people have made a major move, they
have an emotional investment in the decision they've made and will
reconsider only faced with overwhelming evidence.

While Opteron may have tremendous appeal to companies trying to do
things on the cheap, those weren't the customers Intel was after in
the first place, and the fact is that Itanium outperforms the
competition on the applications that matter to those customers.

RM

[gaffo]

G wrote:
gaffo <gaffo@usenet.net> wrote in message news:<EZVYb.852$BK3.811@newssvr22.news.prodigy.com>...Virtual-8086 mode?........what is that?so the AMD64 chip will not be able to run 16-bit XT programs natively? From what others have written, you should have no problems in Real Mode (ie actually booting to DOS), or V86 Mode under 386 Mode (ie running 32 bit Windows). But apparently in 64 bit extended (long?) mode it drops V86 Mode. So you can run 32bit and 16bit apps together, or 32bit and 64bit apps together, but not all three at once. I think.


I see - so Real Mode is still supported.

thats what i as wondering about - thanks!........................so i
can run Moslo and play Digdug on my new shiny Opteron monster ;-).


if I had one.............

--





RUSSERT: Are you prepared to lose?

BUSH: No, I'm not going to lose.

RUSSERT: If you did, what would you do?

BUSH: Well, I don't plan on losing. I've got a vision for what I want to
do for the country.
See, I know exactly where I want to lead.................And we got
changing times
here in America, too., 2/8/04


"And that's very important for, I think, the people to understand where
I'm coming from,
to know that this is a dangerous world. I wish it wasn't. I'm a war
president.
I make decisions here in the Oval Office in foreign policy matters with
war on my mind.
- pResident of the United State of America, 2/8/04


"Let's talk about the nuclear proposition for a minute. We know that
based on intelligence, that he has been very, very good at hiding
these kinds of efforts. He's had years to get good at it and we know
he has been absolutely devoted to trying to acquire nuclear weapons.
And we believe he has, in fact, reconstituted nuclear weapons."
- Vice President Dick Cheney, on "Meet the Press", 3/16/03


"I don't know anybody that I can think of who has contended that the
Iraqis had nuclear weapons."
- Defense Secretary Donald Rumsfeld, 6/24/03


"I think in this case international law
stood in the way of doing the right thing (invading Iraq)."
- Richard Perle


"He (Saddam Hussein) has not developed any significant capability with
respect to weapons of mass destruction. He is unable to project
conventional power against his neighbours."
- Colin Powell February 24 2001


"We have been successful for the last ten years in keeping
him from developing those weapons and we will continue to be successful."

"He threatens not the United States."

"But I also thought that we had pretty
much removed his stings and frankly for ten years we really have."

'But what is interesting is that with the regime that has been in place
for the past ten years, I think a pretty good job has been done of
keeping him from breaking out and suddenly showing up one day and saying
"look what I got." He hasn't been able to do that.'
- Colin Powell February 26 2001

[Felger Carbon]

"Rob Stow" <rob.stow@sasktel.net> wrote in message
news:103akv655f4dha1@corp.supernews.com... I think most of the performance gains we are seeing with the limited amount (so far) of 64-bit optimized software are due to having more registers than to any other single factor except the integrated memory controller. And Intel's AMD64 clone looks like it will be handicapped by 1.) Memory latencies because they are still going to rely on external memory controllers.

Correct. Don't forget the constipated Intel FSB, esp. in SMP
configurations. This is a problem that the Opteron doesn't have.
2.) Inability to do cheap, fast, and easy SMP because they will still rely on the chipset to provide the glue logic instead of building it into the processors like AMD did.

You got it right, Rob. Just thought I'd toss in my two cents. ;-)

[Samuel Barber]

"spinlock" <NullVoid@att.net> wrote in message news:<c13hce$1e9veo$1@ID-173638.news.uni-berlin.de>... Wow, those guys at AMD sure are smart. They created x86-64 before Intel.

Yep.
Wow, that was real genius! AMD engineers sure deserve a lot of credit for beating Intel to the 64bit punch.

AMD does deserve credit. And so does Intel for quickly following AMD's
lead.
I am really surprised that no one at Intel thought of this before the AMD guys did!

Don't be. Intel thought of it, but didn't implement it - probably
because management didn't want to "confuse" the market with an Itanium
competitor.

Sam

[lyon_wonder]

>I am really surprised that no one at Intel thought of thisbefore the AMD guys did!

blind loyalty to Itanic and it's IA64 ISA:)

[Tony Hill]

On Wed, 18 Feb 2004 22:51:29 -0600, Rob Stow <rob.stow@sasktel.net>
wrote: Virtual-8086 mode?........what is that?

One of the MANY legacy modes available in x86. In particular it was
used to run 16-bit real-mode code while the processor as a whole was
running under a 32-bit protected mode operating system.
so the AMD64 chip will not be able to run 16-bit XT programs natively?

When operating in 64-bit long mode, no. If it's operating in 32-bit
protected mode it can still do Virtual-8086 mode. Basically it just
means that if you want to run old 16-bit code while running WinXP
64-bit Edition you need to emulate things.
I'd hate to generalize from one very limited test, but about aweek ago I was unable to boot an Opty dualie or an Athlon64 froma MS-DOS 3.3 floppy. No problems with MS-DOS 6.22.

That's an unrelated problem, there's no way in hell MS-DOS 3.3 was
booting up in 64-bit Long Mode! :>

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

[Tony Hill]

On Thu, 19 Feb 2004 21:00:54 -0500, Robert Myers <rmyers@rustuck.com>
wrote:On Thu, 19 Feb 2004 18:30:10 -0600, Rob Stow <rob.stow@sasktel.net>wrote:<snip>I think most of the performance gains we are seeing with thelimited amount (so far) of 64-bit optimized software are dueto having more registers than to any other single factor exceptthe integrated memory controller.How would you tell the difference?The across-the-board winner, practically all problems, practically allcoding styles, has almost got to be reduced latency. In the samecategory as increasing the size of the cache, only much better,because you don't have to work so hard to suck stuff into the cache.More register names. My guess is that the biggest benefit is tocompiler writers and hand coders.

I think he means 64-bit code on Opteron/Athlon64 vs. 32-bit code on
Opteron/Athlon64, ie identical hardware, only differences is the
software. He's also almost certainly right, since 64-bit should, if
all else were equal, be slower than 32-bit. However because AMD
doubled the number of registers we sometimes (~70-80% of the time from
what I've seen so far) see a performance benefit.

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

[steve harris]

Robert Myers wrote:
On Fri, 20 Feb 2004 01:36:13 +0000 (UTC), RusH <rush@pulse.pdi.net> wrote:news.yaya.bbbl67@spamgourmet.com (Black Jack) wrote :http://www.eetimes.com/semi/news/OEG20040217S0033"The big databases have already been converted over to Itanium, andthey will be on Itanium forever," Fister added.Define "forever" heheheheheh. I suppose that Intel has done so well out of just dumb, blind luck, and that given the same dumb, blind luck, you could do just as well. Intel has a strategy here. These are not stupid people, and the strategy may be working better than you think. Your belief, I suppose, is that Intel management is whistling past the graveyard. Their strategy was to get big customers locked into an absolutely unique architecture. To the extent that Intel has succeeded, those customers are not going back to x86. Intel's strategy is built more on human psychology than it is on any principal of engineering. Once people have made a major move, they have an emotional investment in the decision they've made and will reconsider only faced with overwhelming evidence. While Opteron may have tremendous appeal to companies trying to do things on the cheap, those weren't the customers Intel was after in the first place, and the fact is that Itanium outperforms the competition on the applications that matter to those customers. RM

How about Intel is about making money and Merced is nothing but a money
making proprietary processor that AMD would not be allowed to produce?

Rambus was an Intel opportunity to corner the market. Intel's Rambus
shareholdings came back to bite them in the butt.

Intel could care less what the customer wants IMO.

[Alex Johnson]

Samuel Barber wrote: "spinlock" <NullVoid@att.net> wrote...I am really surprised that no one at Intel thought of thisbefore the AMD guys did! Don't be. Intel thought of it, but didn't implement it - probably because management didn't want to "confuse" the market with an Itanium competitor.

Are you guys all too young to remember the 1990s? In 1994 intel
announced they were doing the 786 which would be a 64 bit processor. At
the time it was exactly what Opteron and Prescott are, an extension on
top of x86 (probably excluding the extra registers and including V86
mode). Intel wanted to grab the big money for selling servers and this
strategy was deemed a dead end. Why would that be? Because every fancy
server feature put into their 64b server would be cannibalized by the
desktop line to eek out that little percent improvement to sell another
chip. Once that happened there would be no reason anyone would pay
server prices for the server chip. So they went looking for alternative
architectures and found HP waving its EPIC flag. They made a deal in
1997 and intel dropped the idea of x86-64 in favor of Itanium. Intel
left the x86-64 openning and AMD struck against them.

Alex
--
My words are my own. They represent no other; they belong to no other.
Don't read anything into them or you may be required to compensate me
for violation of copyright. (I do not speak for my employer.)

[chrisv]

Robert Myers <rmyers@rustuck.com> wrote:
Your belief, I suppose, is that Intel management is whistling past thegraveyard. Their strategy was to get big customers locked into anabsolutely unique architecture. To the extent that Intel hassucceeded, those customers are not going back to x86.

Both of them? 8) In any case, even if true, it doesn't mean they'll
stay Intel customers...

[Robert Myers]

On Fri, 20 Feb 2004 04:53:28 GMT, Tony Hill <hilla_nospam_20@yahoo.ca>
wrote:
On Thu, 19 Feb 2004 21:00:54 -0500, Robert Myers <rmyers@rustuck.com>wrote:On Thu, 19 Feb 2004 18:30:10 -0600, Rob Stow <rob.stow@sasktel.net>wrote:
<snip>More register names. My guess is that the biggest benefit is tocompiler writers and hand coders.I think he means 64-bit code on Opteron/Athlon64 vs. 32-bit code onOpteron/Athlon64, ie identical hardware, only differences is thesoftware. He's also almost certainly right, since 64-bit should, ifall else were equal, be slower than 32-bit. However because AMDdoubled the number of registers we sometimes (~70-80% of the time fromwhat I've seen so far) see a performance benefit.

There is no pure way that I can see to measure the performance benefit
of having more register names.

If you take 32 bit code and rewrite it so that it can take advantage
of the extra registers, you're looking at a performance increase
that's roughly equivalent in its root cause to the better SPEC numbers
going from Northwood to Prescott. Going from Northwood to Prescott,
the compiler got better and/or the architecture became more tolerant
of the infirmities of the compiler for SPEC benchmarks.

You don't know, and you'll never know, exactly what the benefits of
having more named registers is except that, since you are solving a
problem with fewer constraints, it will always be easier to write code
that is near optimum if you have more named registers. The only
indisputable benefit is to compiler writers and hand coders, who
plainly don't have to work as hard.

You give the compiler or hand-coder more optimization space, and he
comes up with a better result. Is that because the compiler or
hand-coder found a solution that doesn't exist in the smaller
optimization space, or because the compiler or hand-coder more
frequently came up with a solution that was near optimum because the
set of near-optimum solutions is much larger? There is no way that I
can see to tell for sure.

Let me propose another way to frame the question so it might not seem
like such a silly cavil to you. If doubling the number of registers
is good, wouldn't tripling or quadrupling the number be even better?
We both know very well that there is a cost to more registers: more
die area, more transistors, more complicated control circuitry, more
power, longer traces. We also know that having more register names
makes it easier to find near-optimal coding solutions.

Six apples >= three oranges? Six apples = three oranges? Six apples
<= three oranges?

RM

[Robert Myers]

On Fri, 20 Feb 2004 07:31:26 -0600, steve harris
<steveharris1@hotmail.com> wrote:

<snip>How about Intel is about making money and Merced is nothing but a moneymaking proprietary processor that AMD would not be allowed to produce?

That's about the size of it. Fortunately, we live in a free-market
economy, so you will have the option of buying something you like
better from IBM, AMD, or perhaps Transmeta, or even Via, if you don't
care for what Intel makes.

No one will sell competing products because Intel is all-powerful?
Doesn't even pass the laugh test. Even if Intel gets out of hand in
the high end, which would happen only if IBM threw in the towel and
left the processor part of that market to Intel, such a move would
only open an opportunity for someone else to come up with a clean RISC
design that's suitable for mainframes. Who knows, maybe AMD could
invent something of its own (for once...he mutters. AMD is capable of
*much* better than more me-too chips).
Rambus was an Intel opportunity to corner the market. Intel's Rambusshareholdings came back to bite them in the butt.

Intel's mistake was in not understanding or forseeing the effects of
the rage of the memory industry at Rambus' overreaching patent claims.

If Rambus had stuck to RDRAM, we might be using RDRAM today, and we
might be better off for it. Intel surely was told how the memory
manufacturers felt, and it's clear that their response was, "That's
nice. We're going to do this, anyway. We can because we're Intel."
That's a mistake I don't think they're likely to make again.
Intel could care less what the customer wants IMO.

On that point, I must beg to differ. Intel doesn't score well on
balance with Usenet posters, but they do manage to sell more
processors than anybody else. Do you really think they manage to do
that without taking into consideration what customers want? Could
you entertain the possibility that they understand the market better
than you do? Could you entertain the possibility that they understand
the market better than the average Usenet poster?

RM

[steve harris]

On that point, I must beg to differ. Intel doesn't score well on balance with Usenet posters, but they do manage to sell more processors than anybody else. Do you really think they manage to do that without taking into consideration what customers want? Could you entertain the possibility that they understand the market better than you do? Could you entertain the possibility that they understand the market better than the average Usenet poster? RM

Robert,
I believe DELL could sell a box with a Via processor in it. DELL's
reseller ratings are horrible, they moved their service and support
offshore for home customers. I do think Intel believes perception is
cheaper than reality and 90% of consumers could care less who made the
processor in their computer. It will catch up with Intel if Intel
doesn't respond. It appears Intel is responding with Banias and AMD64.
DELL will change or their problems will catch up with them. We saw it in
the American automotive companies in the 70s and 80s.

I think Banias will kill off the current P4 processors and it will not
be long before the Banias will have AMD64 built in.
Steve

[Robert Myers]

On Fri, 20 Feb 2004 08:47:59 -0600, steve harris
<steveharris1@hotmail.com> wrote:

<snip>
I believe DELL could sell a box with a Via processor in it.

Not too sure about that, but Walmart obviously can. Dell ordinarily
charges a large fraction of the price of Walmart's box just to ship
one of theirs.
DELL'sreseller ratings are horrible, they moved their service and supportoffshore for home customers.

I'm the guy that trashes Dell regularly. Despite my advice to
consumers, they just keep buying. (I hope that concession makes you
happy, Felger).
I do think Intel believes perception ischeaper than reality and 90% of consumers could care less who made theprocessor in their computer.

Intel's "Intel Inside" campaign was a shrewd and very successful
campaign to get customers, especially corporate customers, to be aware
of what processor is in the box. The guy with the big desk doesn't
shop in the brand x aisle at the supermarket, and he doesn't expect to
find brand x beside his desk at the office.

Opteron is a *huge* credibility breathrough for AMD...maybe. We'll
see. Markets change.

As to perception and reality...that's just the way it goes. As it
happens, that nostrum is working in AMD's favor just at the moment.
Sixty-four bits must be twice as good as thirty-two, wouldn't you
think?
It will catch up with Intel if Inteldoesn't respond. It appears Intel is responding with Banias and AMD64.DELL will change or their problems will catch up with them. We saw it inthe American automotive companies in the 70s and 80s.

Intel has managed to stay on top of this wave for a long time, and
they have never had the opportunity to develop the complacency of the
post-WWII American automobile manufacturers.
I think Banias will kill off the current P4 processors and it will notbe long before the Banias will have AMD64 built in.

Wow! Don't waste your time talking to me. Go buy some AMD stock.
;-).

RM

[Robert Myers]

On Fri, 20 Feb 2004 07:44:36 -0600, chrisv <chrisv@nospam.invalid>
wrote:
Robert Myers <rmyers@rustuck.com> wrote:Your belief, I suppose, is that Intel management is whistling past thegraveyard. Their strategy was to get big customers locked into anabsolutely unique architecture. To the extent that Intel hassucceeded, those customers are not going back to x86.Both of them? 8) In any case, even if true, it doesn't mean they'llstay Intel customers...

The cost of retooling a major database to new software has got to
exceed the cost of the hardware it runs on. How transparent is
database software to the hardware it runs on? I suspect that Itanium
scores in this department have been Oracle scores. If you call Oracle
as a prospective customer, they will, after having spoken with you
about your needs, offer to connect you directly with a corporate
account executive at Dell.

Oracle software isn't going to run on IBM boxes. AMD and Opteron
aren't going to help Oracle compete with IBM. You can add this up
horizontally, vertically, or diagonally. It doesn't spell AMD. I
would hesitate to call this a conspiracy, but it is clear that some
vendors are more, er, comfortable working with some partners than with
others.

RM

[Wolfgang S. Rupprecht]

Robert Myers <rmyers@rustuck.com> writes: There is no pure way that I can see to measure the performance benefit of having more register names.

Couldn't you just tell the compiler to not use half the registers?

If my understanding of how gcc does things is correct, it already
compiles things to some virtual machine with an infinite register
space. Then in a subsequent pass it assigns data to either real
registers or stack depending on the lifetimes of the variables etc.

One would still take the (slight) hit of having an extra register
selection bit taking up space in the instructions themselves, possibly
slowing things down by increasing the size of the instructions a tiny
bit. So like you said, it won't be a pure test, but one could get a
darn good idea of how register starved the architecture really is.

Perhaps a good thesis topic for some bright young student?

-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
The above "From:" address is valid. Don't mess with it.
Gripe to your senators about spam: http://www.wsrcc.com/spam/senators.html

[joe smith]

> >I think most of the performance gains we are seeing with thelimited amount (so far) of 64-bit optimized software are dueto having more registers than to any other single factor exceptthe integrated memory controller. How would you tell the difference?

Easily. Most software use int, not "long long" or __uint64, so the
additional optimization opportunities compiler could possibly fathom from
the availability of wider registers is limited. The number of possibilities
to organize code so that it has less dependencies on previous instructions
w/o read/write to memory are more numerous, even if the L1 cache is 'fast',
and even if the code is dynamically translated to the 'micro-ISA' (for lack
of my mind to recall a better term for what is being done at this time) the
ALU's internally process.

Avarage speed differences from one batch of tests ran on AMD64 (X86_64 for
GCC terminology) did show up average 15% speed increase with mere
recompilation with early versions of GCC for X86_64. As time goes by, the
optimizations the compiler can employ are propably going to be increased,
but that's what early tests show. I can't recall the link, could be I picked
it from slashdot.org a while ago. Could remember wrong.

I don't have AMD64 at this time, but I _do_ develop for MIPS IV ISA and X86
at this time and have some little practical knowledge to come to the above
educated guess (yup, I don't claim it's the Truth or that I have the
ultimate clue, but base the opinion to previous experience in general in the
field of programming and micro-architechture and what effect is has on C/C++
code generation -- yes, I do check compiler output and adjust the sourcecode
accordingly to segments of code which are important, which are not very
many, but still puts me up to this particular job now and then even as of
2004).

The across-the-board winner, practically all problems, practically all coding styles, has almost got to be reduced latency. In the same category as increasing the size of the cache, only much better, because you don't have to work so hard to suck stuff into the cache.

L2 cache avoids very expensive reads, but as long as the working set fits
into L2 anyway, the way L1 is implemented can have 1-2 clock cycle
improvement in latency for VERY *TOIGHT* innerloops. P4's latest incarnation
does appear to favour more (space) over less (latency), though.

Having cache efficiency is not just merely fitting the working set into the
cache, but for dataset which DOESN'T fit there is still all-important issue
about cache which DEFINITELY DOES NOT guarantee acorss-the-board win for all
coding styles. First, merely having cache does help, on average, that has
been demonstrated and that's why there IS cache on modern systems. But using
it in specific ways goes the extra mile. First, how many ways the cache has
has effect on how many working sets the code can use at one time w/o
performance dive. Secondly, the pattern of storing data can have a
substential effect on AVERAGE performance. FATMAP2 is a classic document on
the issue, showing how storage pattern can improve performance by average of
50% (and even more). Infact, tiling is a VERY COMMON pattern for storing
texels in modern 3D accelerators. It's not black magic or mystery why this
is being done. Same technique benefits applications written for
generic-purpose CPU.

More register names. My guess is that the biggest benefit is to compiler writers and hand coders.

Hand coders are a dying breed, but coders who do think a bit what they want
the computer to do, rather than what they want abstract virtual language to
do, are sometimes the concept which separates a good implementation from the
bad. Some program "C++", some program machine code USING C++, even if they
use templates, partial specialization, namespaces, inheritance, etc.etc. A
subtle difference in theory, but can lead to more efficient code in
practise. However, dwelling too much on the performance issues ALL THE TIME
is waste of time, and therefore waste of money and brainpower, life and all
that naturally results from that. Whenever given choise, I'd write clear and
easy-to-read solution rather than obfuscated one even if it were 50% faster.
The chances are that this code is easier to refactor and take appropriate
measures to switch between algorithms which result ORDER OF MAGNITUDE better
performance in a long haul anyway, when wrote "slow code", but, it doesn't
mean I'd go writing code I know to be crappy just because it gets the job
done, the point I had in mind was that experience leads to automaticly
writing things the 'right way'..

Experience in programming is proficiency in applying 'patterns' you've
learned to practical problems you are solving at the time. Programming is
problem solving and pattern matching at the same time. I don't care if
someone disagrees this is just my opinion. And I am taking drugs and
unemployed so perhaps anyone should not take my advice afterall, see what it
would get you?

But I hope the regulars here got a good chucles out of this and I hope even
more satisfaction in claiming how clueless git I were. This one's on me.
Enjoy.

[Jan Panteltje]

On a sunny day (Fri, 20 Feb 2004 10:24:09 -0500) it happened Robert Myers
<rmyers@rustuck.com> wrote in <g29c30p5phs282vudda3fo9elegrie3f0v@4ax.com>:
On Fri, 20 Feb 2004 07:44:36 -0600, chrisv <chrisv@nospam.invalid>wrote:Robert Myers <rmyers@rustuck.com> wrote:Your belief, I suppose, is that Intel management is whistling past thegraveyard. Their strategy was to get big customers locked into anabsolutely unique architecture. To the extent that Intel hassucceeded, those customers are not going back to x86.Both of them? 8) In any case, even if true, it doesn't mean they'llstay Intel customers...The cost of retooling a major database to new software has got toexceed the cost of the hardware it runs on. How transparent isdatabase software to the hardware it runs on? I suspect that Itaniumscores in this department have been Oracle scores. If you call Oracleas a prospective customer, they will, after having spoken with youabout your needs, offer to connect you directly with a corporateaccount executive at Dell.Oracle software isn't going to run on IBM boxes.
I think you are plain wrong about that, 3 years ago RedHat gave
free PC Oracle CDs away with Linux.
I asked for one, but it was only for the US :-(
Anyways, these days if CEOs can save some $$$$$$ they will HAVE
to change, else those shareholders (who all run AMD PC hehe), will ask
many many questions.
JP

[Jan Panteltje]

On a sunny day (Fri, 20 Feb 2004 08:55:44 -0500) it happened Robert Myers
<rmyers@rustuck.com> wrote in <642c30d01a65hbm30prq485cohbmukgqi3@4ax.com>:
On Fri, 20 Feb 2004 04:53:28 GMT, Tony Hill <hilla_nospam_20@yahoo.ca>wrote:On Thu, 19 Feb 2004 21:00:54 -0500, Robert Myers <rmyers@rustuck.com>wrote:On Thu, 19 Feb 2004 18:30:10 -0600, Rob Stow <rob.stow@sasktel.net>wrote:<snip>More register names. My guess is that the biggest benefit is tocompiler writers and hand coders.I think he means 64-bit code on Opteron/Athlon64 vs. 32-bit code onOpteron/Athlon64, ie identical hardware, only differences is thesoftware. He's also almost certainly right, since 64-bit should, ifall else were equal, be slower than 32-bit. However because AMDdoubled the number of registers we sometimes (~70-80% of the time fromwhat I've seen so far) see a performance benefit.There is no pure way that I can see to measure the performance benefitof having more register names.If you take 32 bit code and rewrite it so that it can take advantageof the extra registers, you're looking at a performance increasethat's roughly equivalent in its root cause to the better SPEC numbersgoing from Northwood to Prescott. Going from Northwood to Prescott,the compiler got better and/or the architecture became more tolerantof the infirmities of the compiler for SPEC benchmarks.You don't know, and you'll never know, exactly what the benefits ofhaving more named registers is except that, since you are solving aproblem with fewer constraints, it will always be easier to write codethat is near optimum if you have more named registers. The onlyindisputable benefit is to compiler writers and hand coders, whoplainly don't have to work as hard.You give the compiler or hand-coder more optimization space, and hecomes up with a better result. Is that because the compiler orhand-coder found a solution that doesn't exist in the smalleroptimization space, or because the compiler or hand-coder morefrequently came up with a solution that was near optimum because theset of near-optimum solutions is much larger? There is no way that Ican see to tell for sure.Let me propose another way to frame the question so it might not seemlike such a silly cavil to you. If doubling the number of registersis good, wouldn't tripling or quadrupling the number be even better?We both know very well that there is a cost to more registers: moredie area, more transistors, more complicated control circuitry, morepower, longer traces. We also know that having more register namesmakes it easier to find near-optimal coding solutions.Six apples >= three oranges? Six apples = three oranges? Six apples<= three oranges?RM
It is not a linear increase I think.
how many extra variables you need to declare 'register' to still get useful
speed increase.
These will be mainly in inner loops, and maybe not that many.
Main point of having enough registers is not having to go to memory / stack.
Hey, I am coding asm, several days now.
But not for x86 ....
So it also depends on how the algos are done, maybe things could be more
'unraveled' and spread over more registers, but the performance versus
register curve will flatten out real soon I think.
JP

[Never anonymous Bud]

While still snuggled in a 'spider hole', Robert Myers <rmyers@rustuck.com>
scribbled:
On Fri, 20 Feb 2004 08:47:59 -0600, steve harris<steveharris1@hotmail.com> wrote:<snip>I believe DELL could sell a box with a Via processor in it.Not too sure about that, but Walmart obviously can. Dell ordinarilycharges a large fraction of the price of Walmart's box just to shipone of theirs.

A friend called Dell about a system.
They wanted $119 just for shipping, on a $700 system!

When he questioned that,the order-taker hung up on him.

He came out ahead, I found him a better system at a lower price
right here in town, and I'll take care of any software installation
he needs help with.





To reply by email, remove the XYZ.

Lumber Cartel (tinlc) #2063. Spam this account at your own risk.

This sig censored by the Office of Home and Land Insecurity....

[Tony Hill]

On Fri, 20 Feb 2004 08:55:44 -0500, Robert Myers <rmyers@rustuck.com>
wrote:On Fri, 20 Feb 2004 04:53:28 GMT, Tony Hill <hilla_nospam_20@yahoo.ca>wrote:I think he means 64-bit code on Opteron/Athlon64 vs. 32-bit code onOpteron/Athlon64, ie identical hardware, only differences is thesoftware. He's also almost certainly right, since 64-bit should, ifall else were equal, be slower than 32-bit. However because AMDdoubled the number of registers we sometimes (~70-80% of the time fromwhat I've seen so far) see a performance benefit.There is no pure way that I can see to measure the performance benefitof having more register names.

Of course not, but can you think of any other performance enhancements
that would explain it? The only real differences between IA32 and
AMD64 code are the extra registers and the ability to use more native
64-bit integers. The latter can improve performance in rare cases,
but long long ints are pretty darn rare.
You don't know, and you'll never know, exactly what the benefits ofhaving more named registers is except that, since you are solving aproblem with fewer constraints, it will always be easier to write codethat is near optimum if you have more named registers. The onlyindisputable benefit is to compiler writers and hand coders, whoplainly don't have to work as hard.You give the compiler or hand-coder more optimization space, and hecomes up with a better result. Is that because the compiler orhand-coder found a solution that doesn't exist in the smalleroptimization space, or because the compiler or hand-coder morefrequently came up with a solution that was near optimum because theset of near-optimum solutions is much larger?

Perhaps a more important question here is "does it matter?" When you
get right down to it, AMD64 has more registers and often AMD64 code is
faster than IA32 code, despite the fact that 64-bit code is normally
slower if everything else were equal.
Let me propose another way to frame the question so it might not seemlike such a silly cavil to you. If doubling the number of registersis good, wouldn't tripling or quadrupling the number be even better?

It would be. Why do you think damn near every other ISA out there has
32 GPRs (or more in the case of IA64).
We both know very well that there is a cost to more registers: moredie area, more transistors, more complicated control circuitry, morepower, longer traces. We also know that having more register namesmakes it easier to find near-optimal coding solutions.

My understanding is that for AMD64 the maximum number of registers AMD
could use while still keeping the instruction set basically unchanged
was 16. The costs associated with the extra registers would seem to
be rather small given today's transistor budget, but changing all the
op-codes around would make things tricky on the software side.

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

[Samuel Barber]

Alex Johnson <compuwiz@acm.org> wrote in message news:<c152t0$2or$1@news01.intel.com>... Samuel Barber wrote: "spinlock" <NullVoid@att.net> wrote...I am really surprised that no one at Intel thought of thisbefore the AMD guys did! Don't be. Intel thought of it, but didn't implement it - probably because management didn't want to "confuse" the market with an Itanium competitor. Are you guys all too young to remember the 1990s? In 1994 intel announced they were doing the 786 which would be a 64 bit processor. At the time it was exactly what Opteron and Prescott are, an extension on top of x86 (probably excluding the extra registers and including V86 mode). Intel wanted to grab the big money for selling servers and this strategy was deemed a dead end. Why would that be? Because every fancy server feature put into their 64b server would be cannibalized by the desktop line to eek out that little percent improvement to sell another chip. Once that happened there would be no reason anyone would pay server prices for the server chip. So they went looking for alternative architectures and found HP waving its EPIC flag. They made a deal in 1997 and intel dropped the idea of x86-64 in favor of Itanium. Intel left the x86-64 openning and AMD struck against them.

Your history is very flawed. In 1994 Intel was already working with HP
to define IA-64. The development of IA-64 had little to do with
64-bitness, actually; it was motivated by a desire for higher
performance. At the time, x86 performance lagged the RISCs, and this
was viewed as a barrier to entering the high-end markets. HP's
architectural ideas seemed to offer a way to leapfrog the RISCs in the
performance race.

As it happens, architecture has proven not to be a significant
performance lever. The irony is thick. If only Intel had believed its
own anti-RISC propaganda, it would be better off.

Sam

[Rob Stow]

Never anonymous Bud wrote:
A friend called Dell about a system. They wanted $119 just for shipping, on a $700 system! When he questioned that,the order-taker hung up on him.

Doesn't surprise me at all - mirrors an experience I've
had:

Call Dell about again about a system. Ask how much for
an upgrade from 256 MB to 512 MB (or from 512 to 1024).
Then ask why it costs about twice as much as if you just
bought a DIMM at the local computer store. CLICK.


I've long thought that Dell makes no money - perhaps even
takes a loss - on their basic systems. Where they make
their profits are on the shipping, "upgrades", extended
warranties, etc.

[George Macdonald]

On Fri, 20 Feb 2004 08:55:44 -0500, Robert Myers <rmyers@rustuck.com>
wrote:
On Fri, 20 Feb 2004 04:53:28 GMT, Tony Hill <hilla_nospam_20@yahoo.ca>wrote:On Thu, 19 Feb 2004 21:00:54 -0500, Robert Myers <rmyers@rustuck.com>wrote:On Thu, 19 Feb 2004 18:30:10 -0600, Rob Stow <rob.stow@sasktel.net>wrote:<snip>More register names. My guess is that the biggest benefit is tocompiler writers and hand coders.I think he means 64-bit code on Opteron/Athlon64 vs. 32-bit code onOpteron/Athlon64, ie identical hardware, only differences is thesoftware. He's also almost certainly right, since 64-bit should, ifall else were equal, be slower than 32-bit. However because AMDdoubled the number of registers we sometimes (~70-80% of the time fromwhat I've seen so far) see a performance benefit.There is no pure way that I can see to measure the performance benefitof having more register names.

You're right of course - no way to come up with a general rule... but it
won't stop some from trying.:-)
If you take 32 bit code and rewrite it so that it can take advantageof the extra registers, you're looking at a performance increasethat's roughly equivalent in its root cause to the better SPEC numbersgoing from Northwood to Prescott. Going from Northwood to Prescott,the compiler got better and/or the architecture became more tolerantof the infirmities of the compiler for SPEC benchmarks.You don't know, and you'll never know, exactly what the benefits ofhaving more named registers is except that, since you are solving aproblem with fewer constraints, it will always be easier to write codethat is near optimum if you have more named registers. The onlyindisputable benefit is to compiler writers and hand coders, whoplainly don't have to work as hard.

If you add the fact that you now have named FP registers, the extra named
integer registers come in awful handy for things like loop unrolling -
something which just did not really work with the FP stack. Even for hand
coding, the FP stack was a royal PITA. I expect to see some benefit and
I'll maybe even try to measure it for my stuff.:-)
You give the compiler or hand-coder more optimization space, and hecomes up with a better result. Is that because the compiler orhand-coder found a solution that doesn't exist in the smalleroptimization space, or because the compiler or hand-coder morefrequently came up with a solution that was near optimum because theset of near-optimum solutions is much larger? There is no way that Ican see to tell for sure.Let me propose another way to frame the question so it might not seemlike such a silly cavil to you. If doubling the number of registersis good, wouldn't tripling or quadrupling the number be even better?We both know very well that there is a cost to more registers: moredie area, more transistors, more complicated control circuitry, morepower, longer traces. We also know that having more register namesmakes it easier to find near-optimal coding solutions.

It's *more* than doubling the integer register count though. With IA32 you
basically have 6 registers to fiddle with, once you take away the EBP and
ESP - now you have 14... I think. DEC once did a universal optimizing
compiler - carried registers across function/subroutine calls - for a VAX
and it had less registers available than AMD64: 16 integer overlapped with
the FP registers - stupid design... almost as bad as the page size blunder.

Rgds, George Macdonald

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

[George Macdonald]

On Fri, 20 Feb 2004 10:24:09 -0500, Robert Myers <rmyers@rustuck.com>
wrote:
On Fri, 20 Feb 2004 07:44:36 -0600, chrisv <chrisv@nospam.invalid>wrote:Robert Myers <rmyers@rustuck.com> wrote:Your belief, I suppose, is that Intel management is whistling past thegraveyard. Their strategy was to get big customers locked into anabsolutely unique architecture. To the extent that Intel hassucceeded, those customers are not going back to x86.Both of them? 8) In any case, even if true, it doesn't mean they'llstay Intel customers...The cost of retooling a major database to new software has got toexceed the cost of the hardware it runs on. How transparent isdatabase software to the hardware it runs on? I suspect that Itaniumscores in this department have been Oracle scores. If you call Oracleas a prospective customer, they will, after having spoken with youabout your needs, offer to connect you directly with a corporateaccount executive at Dell.

Are you sure about that? Michael D and Larry E seems to me to be the
immutable force meeting the immovable object. I'd be surprised if Oracle
is all that enchanted with Dell. Oracle has already been ported to AMD64
anyway - took 2 days according to the "reports".
Oracle software isn't going to run on IBM boxes.

Of course it does. IBM is diviisionalized enough that those kinds of
issues don't arise. Ya think that SAP - bless its cotton socks - doesn't
run on IBM and interface to Oracle?
AMD and Opteronaren't going to help Oracle compete with IBM. You can add this uphorizontally, vertically, or diagonally. It doesn't spell AMD. Iwould hesitate to call this a conspiracy, but it is clear that somevendors are more, er, comfortable working with some partners than withothers.

You know, if you call up IBM Consulting Services (whatever its actually
called) and tell them you need some *BIG* help with your IT solutions, show
them a fistful of $$ and say you're committed to Oracle as a database,
they'll say "yessir - we can do that".

Rgds, George Macdonald

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

[Robert Myers]

On Sat, 21 Feb 2004 08:33:46 -0500, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:
On Fri, 20 Feb 2004 10:24:09 -0500, Robert Myers <rmyers@rustuck.com>wrote:On Fri, 20 Feb 2004 07:44:36 -0600, chrisv <chrisv@nospam.invalid>wrote:Robert Myers <rmyers@rustuck.com> wrote:>Your belief, I suppose, is that Intel management is whistling past the>graveyard. Their strategy was to get big customers locked into an>absolutely unique architecture. To the extent that Intel has>succeeded, those customers are not going back to x86.Both of them? 8) In any case, even if true, it doesn't mean they'llstay Intel customers...The cost of retooling a major database to new software has got toexceed the cost of the hardware it runs on. How transparent isdatabase software to the hardware it runs on? I suspect that Itaniumscores in this department have been Oracle scores. If you call Oracleas a prospective customer, they will, after having spoken with youabout your needs, offer to connect you directly with a corporateaccount executive at Dell.Are you sure about that? Michael D and Larry E seems to me to be theimmutable force meeting the immovable object.

In this case, I wasn't speculating, but reporting actual experience.
I mentioned that I wasn't all that enchanted with Dell, and the rep
asked me what I thought would be a better vendor. I mentioned IBM and
the rep's response was something to the effect that I would just be
paying a needlessly higher price for the same hardware.
I'd be surprised if Oracleis all that enchanted with Dell. Oracle has already been ported to AMD64anyway - took 2 days according to the "reports".

Enormous egos aside, why would Dell and Ellison not be natural allies?
IBM, OTOH, has its own software it wants to sell you.

As to what it actually takes to move a database from one hardware
vendor to another, I have no experience. What I do have experience
with is a database project that turned into a financial hole in the
bottom of the boat.
Oracle software isn't going to run on IBM boxes.Of course it does. IBM is diviisionalized enough that those kinds ofissues don't arise. Ya think that SAP - bless its cotton socks - doesn'trun on IBM and interface to Oracle?

The statement as I made it is preposterous. I meant to say that
Oracle wouldn't be ported to the Power architecture, but even on that
point I would have been wrong:

http://www.oracle.com/partnerships/campaigns/ibm/powerlinux/intro.html?src=1952614&Act=7&kw=powerlinux

AMD and Opteronaren't going to help Oracle compete with IBM. You can add this uphorizontally, vertically, or diagonally. It doesn't spell AMD. Iwould hesitate to call this a conspiracy, but it is clear that somevendors are more, er, comfortable working with some partners than withothers.You know, if you call up IBM Consulting Services (whatever its actuallycalled) and tell them you need some *BIG* help with your IT solutions, showthem a fistful of $$ and say you're committed to Oracle as a database,they'll say "yessir - we can do that".

You're right, of course. The strategic focus of IBM is software, but,
as you correctly point out, the new IBM is divisionalized to the
extent that corporate strategic focus is subordinate to the divisional
bottom line. Doesn't sound like a very smart way to run a company,
but what do I know?

RM

[Robert Myers]

On Fri, 20 Feb 2004 23:31:27 -0600, Rob Stow <rob.stow@sasktel.net>
wrote:

<snip>I've long thought that Dell makes no money - perhaps eventakes a loss - on their basic systems. Where they maketheir profits are on the shipping, "upgrades", extendedwarranties, etc.

Yes, and a very nice scam they have going there, too. My war with
Dell started over a non-Dell network card. No matter what I tried,
the system blew up. Dell's position: if it works the way we delivered
it to you, it works.

The only reason Dell *ever* backed down is that it became impossible
even to reinstall the operating system--without any offending non-Dell
equipment in the box. Were it not for that, I probably would have had
to take them to court.

If you can get past *that* reality, and the thought of having
motherboard with a non-standard power connector, there are bargains to
be had from Dell, but you won't get one by logging into their system
and custom-ordering a box because the fancy strikes you.

You have to check the web-site frequently and scan all their #&!%*
print ads. Sooner or later, the system you want or something very
close will turn up at a price that seems unbelievable. As Dorothy
Bradbury has pointed out, the wild price fluctuations are probably the
result of Dell being an aggressively opportunistic buyer and seller.
If they get a good deal on something, they don't want to hold onto it
for more margin. They want to get rid of it, and they're happy to
pass the savings on to whoever is lucky enough to happen along at the
right moment.

Or you could just skip the whole Dell thing and purchase from a vendor
that doesn't have the corporate mentality of a used-car salesman.

RM

[Grumble]

Robert Myers wrote:
Steve Harris wrote: I think Banias will kill off the current P4 processors and it will not be long before the Banias will have AMD64 built in. Wow! Don't waste your time talking to me. Go buy some AMD stock.

Why do you say that?

Why would AMD's stock rise if the Pentium M microarchitecture replaced
the NetBurst microarchitecture? Why would AMD's stock rise if Intel
implemented AMD64 in the Pentium M processor family?

Regards,

Grumble

[Bill Davidsen]

Robert Myers wrote:
Oracle software isn't going to run on IBM boxes. AMD and Opteron aren't going to help Oracle compete with IBM. You can add this up horizontally, vertically, or diagonally. It doesn't spell AMD. I would hesitate to call this a conspiracy, but it is clear that some vendors are more, er, comfortable working with some partners than with others.

Okay, your technical credibility just dropped below the Register. Hell,
below the National Enquirer. Orqacle does most nicely run on IBM, AIX
and Linux, and I believe S390 but can't check today.

As for ports to 64bit, any software which has been ported to Alpha,
Power, and S390 machines is not likely to have issues porting to
anything else. Good code needs no porting, code with assumptions of 32
bittedness, or signed vs. unsigned characters will have issues, but once
you do the first 64 bit port the other are unlikely to be an issue.

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

[Bill Davidsen]

Bill Davidsen wrote:
Okay, your technical credibility just dropped below the Register. Hell, below the National Enquirer. Orqacle does most nicely run on IBM, AIX and Linux, and I believe S390 but can't check today.

My humble apologies for this post, it was supposed to be a note only to
the author, and I left it in a postponed queue because I wanted to check
the facts before sending it. Unfortunately, with a browser I use only
occasionally, I managed to send this and several other things in
postponed when an option didn't do what I expected.

The technical point I believe to be true, but Robert caught that himself
later. The personal comment was undeserved, and a reflection of my mood
at the time I wrote it, rather than an opinion I wanted to share with
the world. I thought I had canceled that article before it left the
internal server, but as it escaped I am sorry for the tone of the post
and wanted to say so immediately.

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

[Robert Myers]

On Fri, 27 Feb 2004 15:40:36 -0500, Bill Davidsen <davidsen@tmr.com>
wrote:

<snip>
The technical point I believe to be true, but Robert caught that himselflater. The personal comment was undeserved, and a reflection of my moodat the time I wrote it, rather than an opinion I wanted to share withthe world. I thought I had canceled that article before it left theinternal server, but as it escaped I am sorry for the tone of the postand wanted to say so immediately.

That's okay. It was a pretty silly thing to say, even without
checking the web. Gears grinding together in brain. There is no
interpretation of the world in which the comment made any sense at
all, either the way I wrote it or the way I intended it.

RM

[Robert Myers]

On Fri, 27 Feb 2004 10:29:10 +0100, Grumble <invalid@kma.eu.org>
wrote:
Robert Myers wrote: Steve Harris wrote: I think Banias will kill off the current P4 processors and it will not be long before the Banias will have AMD64 built in. Wow! Don't waste your time talking to me. Go buy some AMD stock.Why do you say that?Why would AMD's stock rise if the Pentium M microarchitecture replacedthe NetBurst microarchitecture? Why would AMD's stock rise if Intelimplemented AMD64 in the Pentium M processor family?
Well, you did drop my ;-).

Leaving aside a multitude of imponderables: Intel looking like it had
made a mistake going with NetBurst in the first place, eroding
prospects for Itanium even further, and leaving a ton of code
optimized for NetBurst high and dry, the thing I can't imagine Intel
doing is ratifying the future of x86 that way.

From a technical point of view, a multicore Banias-style processor has
alot to say for itself even as a server chip, and I'd be surprised if
the possibility hadn't been at least discussed inside Intel. If Intel
has to go there, though, it has either the appearance, the reality, or
both of Intel being forced to change its plans. Not beyond the
capacities of the spinmeisters at Intel, but still good news for AMD
stock.

RM

[Tony Hill]

On Fri, 27 Feb 2004 16:27:35 -0500, Robert Myers <rmyers@rustuck.com>
wrote:From a technical point of view, a multicore Banias-style processor hasalot to say for itself even as a server chip, and I'd be surprised ifthe possibility hadn't been at least discussed inside Intel. If Intel

Interesting you should mention that, I just saw a new unofficial Intel
roadmap over at some Japanese site:

http://pc.watch.impress.co.jp/docs/2004/0227/kaigai01l.gif

Well looky here.. 2H of 2005, a little chip called Jonahs, a dual-core
Pentium-M processor. Apparently the chip is designed with two
complete processors (including L2 cache) on a single die, with one
processor turning itself off when the thing is running off a battery.

What is perhaps most interesting is that this chip is the first
dual-core x86 chip that Intel has scheduled. Coming out at about the
same time as the first dual-core Itanium and 3 to 6+ months before the
first dual-core Xeon (assuming that this roadmap is accurate of
course, roadmaps has a nasty habit of changing often).

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

[Robert Myers]

On Sat, 28 Feb 2004 08:48:38 GMT, Tony Hill <hilla_nospam_20@yahoo.ca>
wrote:
On Fri, 27 Feb 2004 16:27:35 -0500, Robert Myers <rmyers@rustuck.com>wrote:From a technical point of view, a multicore Banias-style processor hasalot to say for itself even as a server chip, and I'd be surprised ifthe possibility hadn't been at least discussed inside Intel. If IntelInteresting you should mention that, I just saw a new unofficial Intelroadmap over at some Japanese site:http://pc.watch.impress.co.jp/docs/2004/0227/kaigai01l.gifWell looky here.. 2H of 2005, a little chip called Jonahs, a dual-corePentium-M processor.

Thanks. Amazing what this idle chit-chat turns up.
Apparently the chip is designed with twocomplete processors (including L2 cache) on a single die, with oneprocessor turning itself off when the thing is running off a battery.

Or when the demands on the server are light. That would be a nice
touch.
What is perhaps most interesting is that this chip is the firstdual-core x86 chip that Intel has scheduled. Coming out at about thesame time as the first dual-core Itanium and 3 to 6+ months before thefirst dual-core Xeon (assuming that this roadmap is accurate ofcourse, roadmaps has a nasty habit of changing often).

Notice that it's slotted as a "mobile" processor <giggle>. I wonder
if HP has the corresponding blade pencilled into its lineup yet?

Since the processors don't share L2 cache, it will be interesting to
see if any facilities other than the FSB are available for
processor-to-processor communication. Probably not, which is a shame.

RM

[Tony Hill]

On Sat, 28 Feb 2004 11:32:35 -0500, Robert Myers <rmyers@rustuck.com>
wrote:On Sat, 28 Feb 2004 08:48:38 GMT, Tony Hill <hilla_nospam_20@yahoo.ca>wrote:Interesting you should mention that, I just saw a new unofficial Intelroadmap over at some Japanese site:http://pc.watch.impress.co.jp/docs/2004/0227/kaigai01l.gifWell looky here.. 2H of 2005, a little chip called Jonahs, a dual-corePentium-M processor.Thanks. Amazing what this idle chit-chat turns up.

Yup, sometimes Usenet really is good for something other than
flamewars! :>
Apparently the chip is designed with twocomplete processors (including L2 cache) on a single die, with oneprocessor turning itself off when the thing is running off a battery.Or when the demands on the server are light. That would be a nicetouch.

Definitely! I don't know if turning cores on/off is dynamic though or
if it requires the thing to be powered down first. Details on the
chip are REAL slim right now, only a few rumors based off a couple
pictures on some Japanese site.
What is perhaps most interesting is that this chip is the firstdual-core x86 chip that Intel has scheduled. Coming out at about thesame time as the first dual-core Itanium and 3 to 6+ months before thefirst dual-core Xeon (assuming that this roadmap is accurate ofcourse, roadmaps has a nasty habit of changing often).Notice that it's slotted as a "mobile" processor <giggle>. I wonderif HP has the corresponding blade pencilled into its lineup yet?

Hehe, I don't know. Knowing Intel they will probably try to force
companies to only use this chip in mobile applications, or possibly
even require that it be purchased as part of a Centrino bundle. WiFi
on a server blade? More useless things have happened before I guess.
Since the processors don't share L2 cache, it will be interesting tosee if any facilities other than the FSB are available forprocessor-to-processor communication. Probably not, which is a shame.

Hmm, interesting thought, I hadn't really considered that. I'm sure
that it would be possible to by-pass the main bus and have a cache
coherency short-cut of sorts between the two chips. Of course, that
sort of thing comes down to a money decision, is the performance gain
worth the extra cost? My guess is probably not, at least from Intel's
perspective.

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