CASTalk.com

No real details here, just a "stay tuned" message, but that should be
enough to start wild speculations running.

"One strategic path that will knock you for a loop, and which I'll
detail soon, is AMD's coming escape from the confines of Intel's
x86 instruction set. To this point, AMD has resisted the temptation to
overhaul the x86, even though it sorely needs it. When Fab 36 cranks
up, AMD will overcome that fear. AMD64 processors will take on
performance, scalability, resource management, and availability-related
instruction set extensions that will be proprietary to AMD CPUs.
Don't freak out: AMD will keep its contract to be 100 percent
compatible with Intel-standard processors. But the idea of seeing
"optimized for AMD64" stamped on software boxes delights me. "
http://www.infoworld.com/article/05/10/ ... url=http:/
/www.infoworld.com/article/05/10/26/44OPcurve_1.html

or, http://tinyurl.com/cvvwn

I'll start off with my own wild speculation. There was word that prior
to choosing SSE2/SSE3 as its AMD64 floating point instruction set, AMD
was investigating going its own way. So I'm going to speculate that AMD
will extend floating point out with its previously abandonned
instruction set. I'm going to speculate that this instruction set will
be a full scientific functions instruction set, just like the old x87
FPU was, except without the stack-based register system. And let's say
it'll have 32 FP registers instead of just 16 like SSE does.

Yousuf Khan

In article <1130339837.841405.53060@g47g2000cwa.googlegroups.com>,
yjkhan@gmail.com says...

<snip>

I'll start off with my own wild speculation. There was word that prior
to choosing SSE2/SSE3 as its AMD64 floating point instruction set, AMD
was investigating going its own way. So I'm going to speculate that AMD
will extend floating point out with its previously abandonned
instruction set. I'm going to speculate that this instruction set will
be a full scientific functions instruction set, just like the old x87
FPU was, except without the stack-based register system. And let's say
it'll have 32 FP registers instead of just 16 like SSE does.

You mean like PowerPC has had for years? ;-) Maybe they'll do
VMX. Wouldn't that be a kick! ;-))

--
Keith

Keith R. Williams wrote:

You mean like PowerPC has had for years? ;-) Maybe they'll do
VMX. Wouldn't that be a kick! ;-))

That would certainly make it very appealing to Apple all of a sudden, I
would guess.

However, the real kicker here is that AMD is attempting something here
that only Intel or Microsoft usually ever try to do, which is embrace,
extend, and extinguish.

Another wild possibility is that AMD might open up its internal RISC
implementation to direct access by applications. They used to allow
that sort of thing on the K5 processor, but stopped it as of K6
onwards.

Yousuf Khan

On 26 Oct 2005 08:17:17 -0700, "YKhan" <yjkhan@gmail.com> wrote:

No real details here, just a "stay tuned" message, but that should be
enough to start wild speculations running.

"One strategic path that will knock you for a loop, and which I'll
detail soon, is AMD's coming escape from the confines of Intel's
x86 instruction set. To this point, AMD has resisted the temptation to
overhaul the x86, even though it sorely needs it. When Fab 36 cranks
up, AMD will overcome that fear. AMD64 processors will take on
performance, scalability, resource management, and availability-related
instruction set extensions that will be proprietary to AMD CPUs.
Don't freak out: AMD will keep its contract to be 100 percent
compatible with Intel-standard processors. But the idea of seeing
"optimized for AMD64" stamped on software boxes delights me. "
http://www.infoworld.com/article/05/10/ ... url=http:/
/www.infoworld.com/article/05/10/26/44OPcurve_1.html

or, http://tinyurl.com/cvvwn

I'll start off with my own wild speculation. There was word that prior
to choosing SSE2/SSE3 as its AMD64 floating point instruction set, AMD
was investigating going its own way. So I'm going to speculate that AMD
will extend floating point out with its previously abandonned
instruction set. I'm going to speculate that this instruction set will
be a full scientific functions instruction set, just like the old x87
FPU was, except without the stack-based register system. And let's say
it'll have 32 FP registers instead of just 16 like SSE does.

Yousuf Khan

Not sure if it will fly. Remember 3dnow and lowly K6/2 beating
then-top of the line P2 at Quake because of 3dnow optimization? Then,
about a year later, came out P3 with SSE, and everyone started doing
SSE optimization. 3dnow was forgotten quite soon, even though both
instruction sets were pretty similar, and AMD was about a year ahead.
As long as AMD market share stays where it is now (just under 20%
overall IIRC) few will bother to do AMD optimization. Besides, Intel
might counter this move with another installment of SSE that
essentially copies AMD instructions but is different enough to make
SSEx optimized code not compatible with AMD. _If_ AMD market share
goes above 30% as it is hoped, and also _if_ AMD will be significantly
ahead of Intel releasing it, and also _if_ the new instruction set
gets the backing of some software heavyweights (just as MS put its
weight behind x86-64), then it might happen. But then Intel today is
not as strong as Intel back in 1998, and if the chain of major
screw-ups by Intel continues, AMD may get a fighting chance.

NNN

nobody@nowhere.net wrote:

Not sure if it will fly. Remember 3dnow and lowly K6/2 beating
then-top of the line P2 at Quake because of 3dnow optimization? Then,
about a year later, came out P3 with SSE, and everyone started doing
SSE optimization. 3dnow was forgotten quite soon, even though both
instruction sets were pretty similar, and AMD was about a year ahead.

There really wasn't much effort put into either 3DNow or SSE, until
Microsoft announced who would produce the Xbox CPU, at which point the
eventual winner was clear. I remember at that time people were putting
out both SSE and 3DNow-enabled executables.

As long as AMD market share stays where it is now (just under 20%
overall IIRC) few will bother to do AMD optimization. Besides, Intel
might counter this move with another installment of SSE that
essentially copies AMD instructions but is different enough to make
SSEx optimized code not compatible with AMD. _If_ AMD market share
goes above 30% as it is hoped, and also _if_ AMD will be significantly
ahead of Intel releasing it, and also _if_ the new instruction set
gets the backing of some software heavyweights (just as MS put its
weight behind x86-64), then it might happen. But then Intel today is
not as strong as Intel back in 1998, and if the chain of major
screw-ups by Intel continues, AMD may get a fighting chance.

That actually is now looking like a remote possibility. Also there are
pockets where AMD's influence might be greater than the overall market,
such as in servers. Perhaps a server-oriented language extension? Or
maybe a gaming-oriented extension?

Yousuf Khan

In article <1130345907.617734.87220@o13g2000cwo.googlegroups.com>,
YKhan <yjkhan@gmail.com> wrote:
...

Another wild possibility is that AMD might open up its internal RISC
implementation to direct access by applications. They used to allow
that sort of thing on the K5 processor,

Can you speak a little more to how this was done? IIRC (and my
recollection isn't too good), the K5 used a similar core to the AMD29000.
I didn't know there was a way for it to run code for the 'other'
instruction set.

Thanks,
Mike
--
http://www.mschaef.com

MSCHAEF.COM wrote:

Can you speak a little more to how this was done? IIRC (and my
recollection isn't too good), the K5 used a similar core to the AMD29000.
I didn't know there was a way for it to run code for the 'other'
instruction set.

Yeah, they called them the macro-ops, and they could only be accessed
by writing to specific model-specific registers, as I recall. But I
might be wrong about how they were implemented.

Yousuf Khan

"YKhan" <yjkhan@gmail.com> wrote in message
news:1130345907.617734.87220@o13g2000cwo.googlegroups.com...

Another wild possibility is that AMD might open up its internal RISC
implementation to direct access by applications. They used to allow
that sort of thing on the K5 processor, but stopped it as of K6
onwards.

That would be *very* interesting. It doesn't seem that it would be that
difficult to do, and it would be very difficult for Intel to copy because it
would be tightly tied to the AMD microarchitecture.

One problem I see with doing this, precisely because it is so tightly
tied to the chip's specific microarchitecure, is that it might limit what
directions AMD can go in the future. Having to continue to support or
abandon this microarchitecture could cripple AMD's subsequent processors.
Future Intel CPUs would only have to support legacy x86 and x86-64 while
future AMD CPUs would have to continue to support legacy x86, x86-64, and
this new RISC thing.

DS

YKhan wrote:

No real details here, just a "stay tuned" message, but that should be
enough to start wild speculations running.

"One strategic path that will knock you for a loop, and which I'll
detail soon, is AMD's coming escape from the confines of Intel's
x86 instruction set. To this point, AMD has resisted the temptation to
overhaul the x86, even though it sorely needs it. When Fab 36 cranks
up, AMD will overcome that fear. AMD64 processors will take on
performance, scalability, resource management, and availability-related
instruction set extensions that will be proprietary to AMD CPUs.
Don't freak out: AMD will keep its contract to be 100 percent
compatible with Intel-standard processors. But the idea of seeing
"optimized for AMD64" stamped on software boxes delights me. "
http://www.infoworld.com/article/05/10/ ... url=http:/
/www.infoworld.com/article/05/10/26/44OPcurve_1.html

or, http://tinyurl.com/cvvwn

I'll start off with my own wild speculation. There was word that prior
to choosing SSE2/SSE3 as its AMD64 floating point instruction set, AMD
was investigating going its own way. So I'm going to speculate that AMD
will extend floating point out with its previously abandonned
instruction set. I'm going to speculate that this instruction set will
be a full scientific functions instruction set, just like the old x87
FPU was, except without the stack-based register system. And let's say
it'll have 32 FP registers instead of just 16 like SSE does.

What's the market for this? Gamers maybe, engineering probably. Gamers
buy because of the numbers, in most cases what they have generates more
fps than the human eye can detect and the monitor can display, but a lot
of people want a faster system for a better DSI.

I think a lot will depend on the next Intel memory system, if bandwidth
is the limit rather than CPU it might not be worth the chip area to do
something else.

AMD will check before going with this I'm sure, once it's out they have
to support it, and if Intel comes up with something with the same
performance AMD won't have the advantage as a selling point. Very
interesting topic, could be more long term downside than upside if it
isn't a huge win.

--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

"Bill Davidsen" <davidsen@tmr.com> wrote in message
news:FxS7f.2577$Y61.881@newssvr33.news.prodigy.com...

I think a lot will depend on the next Intel memory system, if bandwidth
is the limit rather than CPU it might not be worth the chip area to do
something else.

Intel seems to keep talking about Fully Buffered Dimm, wonder what's up

with that? And Micron just demonstrated a 4GB FBDimm. Didn't say what
speed the links run at.

del

On Wed, 26 Oct 2005 17:17:17 +0200, YKhan <yjkhan@gmail.com> wrote:

I'll start off with my own wild speculation. There was word that prior
to choosing SSE2/SSE3 as its AMD64 floating point instruction set, AMD
was investigating going its own way. So I'm going to speculate that AMD
will extend floating point out with its previously abandonned
instruction set. I'm going to speculate that this instruction set will
be a full scientific functions instruction set, just like the old x87
FPU was, except without the stack-based register system. And let's say
it'll have 32 FP registers instead of just 16 like SSE does.

And who will optimize? What was the name of AMD compiler again? what, no
compiler? .. great idea
AMD pouring money to GCC guys would be a different story. Thats where AMD
is becoming bigger now, in small linux server boxes.

--
I really have no idea what this means. And since I can't install linux on
it, I'm gonna go back to surfing pr0n.
the penguins are psychotic / just smile and wave

hackbox.info wrote:

And who will optimize? What was the name of AMD compiler again? what, no
compiler? .. great idea
AMD pouring money to GCC guys would be a different story. Thats where AMD
is becoming bigger now, in small linux server boxes.

Well as I said, it was wild-assed speculation on my part. However, I'm
not so sure these instructions would be anything like that anymore.

AMD has been demonstrating a penchant for earthy thinking recently. So
it wouldn't surprise me if the instructions it comes up with are
designed for practical housekeeping rather than performance glory.
Especially in the server realm. Perhaps instructions to explicitly
share memory and cache contents between processors/cores? Instructions
for optimizing multiple Hypertransport links. This is apparently as a
result of requests by Sun Microsystems for future feature directions of
Opterons. Of course, none of this would be relevant to stone-age Intel
processors -- they don't have anything like this.

Not sexy performance stuff, but probably much more important.

Yousuf Khan

In article <4360c6c9$0$11072$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:

"hackbox.info" <hackbox.info@gmail.com> writes:

And who will optimize? What was the name of AMD compiler again? what, no
compiler? .. great idea

The Sun compilers are seeing a lot of AMD64 specific work because of
Sun's investment in Opteron boxes.

Casper

The OP might also be aware that there are also other vendor compilers
available for AMD64/Opteron, such as PGI, Absoft, and Pathscale.

On Thu, 27 Oct 2005 07:29:36 +0200, YKhan <yjkhan@gmail.com> wrote:

Not sexy performance stuff, but probably much more important.

You mean like Pacifica? Intel plays this drum for over 2 years now
(Vanderpool/Silvervale) and nothing comes out of that big cloud of smoke.
They (x86 boys) want to roll into IBM territory (Hypervisor in Power5
boxes).

--
I really have no idea what this means. And since I can't install linux on
it, I'm gonna go back to surfing pr0n.
the penguins are psychotic / just smile and wave

hackbox.info wrote:

You mean like Pacifica? Intel plays this drum for over 2 years now
(Vanderpool/Silvervale) and nothing comes out of that big cloud of smoke.
They (x86 boys) want to roll into IBM territory (Hypervisor in Power5
boxes).

No, not Pacifica, though likely it will integrate in with Pacifica at
some level, since virtualization is at some level affected by
multiprocessing.

Yousuf Khan