A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » Processors » General
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

AMD to leave x86 behind?



 
 
Thread Tools Display Modes
  #11  
Old October 27th 05, 04:48 AM
hackbox.info
external usenet poster
 
Posts: n/a
Default AMD to leave x86 behind?

On Wed, 26 Oct 2005 17:17:17 +0200, YKhan 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
  #12  
Old October 27th 05, 06:29 AM
YKhan
external usenet poster
 
Posts: n/a
Default AMD to leave x86 behind?

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

  #13  
Old October 27th 05, 10:59 AM
hackbox.info
external usenet poster
 
Posts: n/a
Default AMD to leave x86 behind?

On Thu, 27 Oct 2005 07:29:36 +0200, YKhan 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
  #14  
Old October 27th 05, 01:20 PM
YKhan
external usenet poster
 
Posts: n/a
Default AMD to leave x86 behind?

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

  #15  
Old October 27th 05, 01:23 PM
Casper H.S. Dik
external usenet poster
 
Posts: n/a
Default AMD to leave x86 behind?

"hackbox.info" 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
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
  #16  
Old October 27th 05, 01:32 PM
George Macdonald
external usenet poster
 
Posts: n/a
Default AMD to leave x86 behind?

On 26 Oct 2005 08:17:17 -0700, "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/...rss&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.


I'd be interested as to how this plays with the AMD/Intel cross-license
agreement: at what point are new extensions not subject to free exchange
between the two?... and not subject to royalty payments by AMD to Intel?

--
Rgds, George Macdonald
  #17  
Old October 27th 05, 03:59 PM
Jason Lee Eckhardt
external usenet poster
 
Posts: n/a
Default AMD to leave x86 behind?

In article ,
Casper H.S. Dik wrote:
"hackbox.info" 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.

  #18  
Old October 27th 05, 05:59 PM
Tim McCaffrey
external usenet poster
 
Posts: n/a
Default AMD to leave x86 behind?

In article . com,
says...

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.


[snip]

Performance doesn't necessarily mean FP performance. For instance, the
x86 interrupt model really needs a re-think (especially since x86-64
doesn't really support the segmentation model). Something like
the ARM's register sets would be nice.

Instructions that load/store/copy memory that control how much
cache pollution is done and/or communicate to the bridges and
I/O devices how much data is being loaded/stored could improve
efficiency on the I/O (PCI) and memory busses.

Scalability could be addressed by, for instance, adding registers
that an external device or another processor could store to
(mailbox registers or FIFOs). This could reduce memory contention.

etc. etc.

This stuff isn't new, embedded I/O processors, such as Intel's StrongArm
IO processors (80331, etc), have provided similar mechanisms for years.

- Tim

NOT speaking for Unisys.

  #19  
Old October 29th 05, 01:33 PM
Jim Brooks
external usenet poster
 
Posts: n/a
Default AMD to leave x86 behind?

On Wed, 26 Oct 2005 08:17:17 -0700, 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/...rss&url=http:/
/www.infoworld.com/article/05/10/26/44OPcurve_1.html

or, http://tinyurl.com/cvvwn



A sharp barb the subject "AMD to leave x86 behind?" is.
Very good.
A rising star among us trolls Khan is becoming.


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



SIMD FP is a bad idea. Think of it as CISC FP.

Dunno about AMD's SSE implementation.
But Intel P6 treats SIMD FP as CISC FP in some sense.
P6 decomposes a 4-way PADD into two 2-way PADDs
and sends the pair down Port 0 and 1
(or sequentially to one port if the other is busy).

Most 3D apps calculate (X,Y,Z) rather than (X,Y,Z,W).
So a FPU with 3 pipes, not 4, is more appropriate.
And don't tell me I must "swizzle" my vertex arrays.

  #20  
Old October 29th 05, 04:45 PM
Mark Hahn
external usenet poster
 
Posts: n/a
Default AMD to leave x86 behind?

They (x86 boys) want to roll into IBM territory (Hypervisor in Power5
boxes).


nonsense. virtualization was popular in the mainframe world precisely
because mainframes were a huge investment. of course it made sense to
virtualize them, purely in order to make time-slicing more seamless.

killer micros changed all that - a very fast cpu now costs 3 digits,
not 7, and virtualizing it doesn't make much sense, at least not
virtualizing it much. yes, there will probably always be mainframe
recidivists who want to be able to partition a nice 256-core NUMA box
into piddly little chunks for each department (which could have been
bought as separate machines for 99% less cost). but that kind of inane
PHBism will always exist.
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Should I leave my printers on? OM Printers 22 August 8th 05 10:50 PM
Please leave in garage? John Hardaker UK Computer Vendors 1 May 14th 05 07:34 PM
Leave Dell 4600 PC Always On? Filipo General 6 September 15th 04 01:21 AM
Turn printer off or leave it on? Walter R. Printers 4 February 29th 04 09:18 PM
Should I leave well enough alone? Ken Fox Overclocking 1 January 25th 04 01:34 AM


All times are GMT +1. The time now is 10:07 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.