AMD's x86-64 Moves Forward

MBCook writes "AMD Hammer line is definatly moving forward. The Inquirer has a supposidly leaked memo from MS saying that they have working x86-64 silicon that runs both 32 and 64-bit Win XP. Van's Hardware is reporting that MS is backing x86-64 over Intel's IA-64, and that MS has apparently convinced Intel to move to x86-64! There is an article over at Ace's Hardware from CeBIT that includes some coverage of AMD's Hammer line (including its NUMA). Last but not least is News.com's report that MS is preparing Windows to support NUMA." And it looks like the line will be named Opteron.

Comments

What about Linux?

[WetCat]

Will Linux support NUMA in AMD?
Will there be any AMD 64bit variant of Linux?

Re:What about Linux?

[bonzoesc]

Oh come on. Linux will support whatever those kooky kernel programmers want it to. Hell, I remember a few months ago some article said that AMD already ported it so they could test it, but I haven't got the link handy.

Re:What about Linux?

[Anonymous Coward]

AMD has partnered with SuSE to produce 64-bit linux. They demonstrated it in February on hammer silicon.

Re:What about Linux?

[jaywhy]

Check out, http://zdnet.com.com/2100-1103-847712.html and SuSe already supports it, http://www.suse.com/us/press/press_releases/archiv e02/x86_64.html -Jason Yates

Re:What about Linux?

[Anonymous Coward]

Was it thislink?

Re:What about Linux?

[rafelbev]

I suppose you are referring to something like this link

Just a quick rant...

What I would like to see from AMD is more in the way of compiler support for x86-64. The demo in the link above showed how it was already possible to run 32bit and 64 bit compiled applications already simultaneously. We need huge support from the chip makers to pull this off as an important evolutionary step in computing. At least if talking about enterprise computing.

Re:What about Linux?

[Anonymous Coward]

suck my ass, linux fags!

Careful, there, Skippy! You don't actually want to have 10,000 people trying to suck your ass all at once, do you?

Re:What about Linux?

[dfiguero]

They only love M$.

AMD is selling is soul for gold...

Re:What about Linux?

[baptiste]

What I would like to see from AMD is more in the way of compiler support for x86-64.

I think AMD did pretty well with promoting and supporting x86-64. The x86-64 website has soeme decent stuff including emulator, experimental compiler, etc. It was a smart move and got the developers on board early.

Re:What about Linux?

[ParisTG]

Check out http://www.x86-64.org/. It's AMD's site dedicated to porting Open Source software to x86-64. This includes the Linux kernel.

Uhmmm ... Ok ...

[Anonymous Coward]

The idea behind Opteron is to build off of the Latin root optimus meaning best or if you play with the translation a bit you get optimal unit or flagship.

To me it sounds like a dinosaur ... look ma, all those wild Opterons running around.

Hmmm ... like a bunch of cows is a "herd" ...
Will a bunch of Opterons be called a "beowulf"?

Re:Uhmmm ... Ok ...

[Gibbys Box of Trix]

Out of all the rumoured names for this chip: Forton; Metaron; Multeon; Vanton; and Opteron I like Opteron best of all, but not by much.

I suppose as we hear it more and more it will become more palatable, just like Athlon and Duron.

Re:Uhmmm ... Ok ...

[einer]

Opteron? Wasn't he an Autobot? ;)

Re:Uhmmm ... Ok ...

[Anonymous Coward]

For some reason that name makes me think of the bird from the BC comic strip "Hi, I'm an Apteryx, a flightless bird with hairy feathers." That's not a good thing.

Re:Uhmmm ... Ok ...

[Anonymous Coward]

Yeah but what about the others?

Forton? A fort.
Metaron? A baddie transformer.
Multeon? Who knows... sounds like a supermarket.
Vanton? A heavy van.

Surely a kiwi bird is better than any of the above, even barely?

Re:Uhmmm ... Ok ...

[Anonymous Coward]

nope. just the 'nickname' of optimus prime's pecker.

Re:Uhmmm ... Ok ...

[dirty]

muletron

Re:Uhmmm ... Ok ...

[connorbd]

Opteron is a Light Pokemon. It evolves from a pretty much garden variety Eevee with the help of a Prism stone and it has a unique Laser Attack that is especially useful against Ground Pokemon that are safe from the attacks of other Eevee-derived forms.

It also tastes really good spitroasted after a day or two in a sushi vinegar and olive oil marinade.

/Brian

Re:Uhmmm ... Ok ...

[Anonymous Coward]

pokemon is sooooo 20th century...

Re:Uhmmm ... Ok ...

[Anonymous Coward]

Actually a little known fact is there was a transformer named Opteron, or rather, in the Japanese Transformer cartoons his name was Opeteron which was sounded fairly close to Opteron. Yes he was an autobot, he transformed into a wrecking ball construction vehicle if I recall correctly. His most deadly attack form was "Smashing Lead Ball of Steel!" (you know how anime are).

Re:Uhmmm ... Ok ...

[Anonymous Coward]

It should have been Oberon... ;)

Oberon n.
The king of the fairies and husband of Titania in medieval folklore.
The satellite of Uranus that is 15th in distance from the planet.

[French, from Old French Auberon, of Germanic origin. See albho- in Indo-European Roots.]

Re:Uhmmm ... Ok ...

[jo42]

I just want a 42-bit processor.

The bit stuff, explain to a layman. TIA

[Typingsux]

Anyone here to give a good reason not to have 128 or 256 bit processors? Video game consoles have them. Wouldn't it be kickass?

Re:The bit stuff, explain to a layman. TIA

[bonzoesc]

The console numbers are mostly fluff; nobody judges consoles by bits anymore, and for good reason. Bit numbers aren't as closely tied to real performance as MhZ (which is still not really close, either) and other figures. The XBOX, with a 32-bit CPU, is faster than the Nintendo 64, which had a 64 in the name.

Re:The bit stuff, explain to a layman. TIA

[sQuirlbuz]

Most current systems don't have a memory size large enough to utiltize something like a 128bit processor. You'd just be throwing around empty bits. it takees time to move bits around, memory to cache, cache to processor.

Re:The bit stuff, explain to a layman. TIA

[Sebastopol]

Anyone here to give a good reason not to...

Intel MMX/SSE are 128-bits already.

But here are a few arguments against it--

1. bus widths at 256-bits are a friggin nightmare to design to run at multi-GHz...

2. To support 256-bits, every path needs to be this wide, which would blot the die so much that you couldn't meet gigahertz timing, not to mention how poor the yeilds would be

most game architectures pump graphics data around at 256,512,even 1k-bit wide busses... not the CPU core. But that kind of precision for the geometry processed in the CPU core is not necessary.

Re:The bit stuff, explain to a layman. TIA

[Waffle Iron]

Your PC already has a 128-bit processor in the same sense as a game box (MMX and friends). In fact, the multiple ALUs in modern CPUs can give you 128 x N bits per clock for N ALUs.

64-bit in the context of this discussion means address bits. It'll be a long time before console games need 64-bit addressing.

Re:The bit stuff, explain to a layman. TIA

[Stonehand]

*shrug*

You'd drive up your processor-memory bandwidth requirements, since presumably you'd want to keep those larger registers fed. You might also require more silicon, and a physically larger processor creates issues of its own like how fast a signal can propagate on it, which will influence how much you can drive up clock speed. You'd then have to justify the increased bits.

IA64 goes a bit of the way there, via design features like EPIC, but it'll be *cough* interesting *cough* to see how well the compiler authors do in creating good optimizers that can take advantage of it.

Re:The bit stuff, explain to a layman. TIA

[xkenny13]

• Anyone here to give a good reason not to have 128 or 256 bit processors?

Sure ... there's nothing out there to take advantage of it. How quickly will we see 128 or 256 bit compiliers and applications? Or is it just wasted dollars on R&D and beefy hardware since most people would rather spend less IT dollars buying 32 bit processors that are plenty powerful to do the job.

Seriously, way-back-when, my company outfitted the management staff with the 386/SX-16 desktop models, while reserving the more powerful 386/DX-25 machines for the development staff.

The majority of the business world (you know, Email, word processing) doesn't even need a 64-bit processor, much less 256-bit.

• Video game consoles have them. Wouldn't it be kickass?

It probably depends on your application. Simply having them for the sake of having them isn't enough.

Do you have a good reason to have them, aside from bleeding edge video games?

Re:The bit stuff, explain to a layman. TIA

[tc]

The "bit stuff" is often marketing, especially in the case of game consoles. The problem is how to decide what makes a system x bits long. In the case of, say, the PlayStation 2, the CPU has a basically 32-bit architecture, with 32-bit address bus, and 32-bit standard registers. So maybe it's 32-bit. On the other hand, they have a big fat 2560-bit (sic) data channel to feed the graphics processing. So maybe it's 2560 bit. Or perhaps it's 128- or 256-bit because some internal operations in the graphics/vector unit are done on that many bits at once. Which number you pick is just marketing spin, and doesn't really mean much.

In the case of PC processors, thing are a little more sane, in that we're generally talking an x-bit processor to mean it has x-bit general purpose registers and an x-bit address space. Sometimes these processors use more bits in other places, like wider registers for SIMD operations, or wider data busses. No doubt if the Pentium was used in a game console, it would be described as 64- or 128-bit (hmm...just like the Xbox), to keep up with the marketing spin from the other consoles.

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

How about price ... If the come out with them now nobody is going to buy them because they are going to be too damn expensive.

Re:The bit stuff, explain to a layman. TIA

[scotch]

The XBOX, with a 32-bit CPU, is faster than the Nintendo 64, which had a 64 in the name

And a 64 in the processor. IIRC, the processor is based on the Alpha core. And when the alpha came out, it was faster than anything 32 bit. But comparing the X-box and the Nintendo 64, which were released many years apart won't buy you much of a conclusion other than current processors are generally faster than older processors.

All other things being equal, a processors with larger word size (instruction sizes and address sizes) will be faster than those with smaller, though, depending on application, the results can be negligible or even worse, especially if compilers and programs aren't properly optimized.

Of course, I don't really know, I'm just guessing, just like the rest of you ;).

Re:The bit stuff, explain to a layman. TIA

[Machuidel]

No they don't,the gfx cards are 128bit,
and even that is not always true.

It's just marketing that
let people think they have.

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

a) They don't.
b) It wouldn't.

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

except that these AMD processors only have 48 address bits :)

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

Anyone here to give a good reason not to have 128 or 256 bit processors?

Because the publicity for it would look like this:

New 256-bit processor! Compute everything down to 1e-50 precision!

Save money while doing income taxes!

old 64-bit processor:
$128.26500000000 gets rounded to $128.27

our new 256-bit processor :
$128.264999999992894091187420293811829392010192 gets rounded to the more accurate figure $128.26 !!!

(tiny letters: 300% more power necessary to run the 256-bit processor. Everything subject to change, blah blah, do not use as a floatation device.)

Re:The bit stuff, explain to a layman. TIA

[scotch]

I don't think there are any current systems with memory size large enough to utiltize something like 128bit processors. Though that just means that a 128bit address space isn't useful right now. The bitsize of a processor (can) also refer to the instruction and word sizes, which can buy you peformance by allowing you to do things in a vector fashion.

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

2^48 bytes ought to be enough for anybody!

Re:The bit stuff, explain to a layman. TIA

[petis]

Hmm. Well. This kinda sums it up:

1) Cost.

If you have to make everything X times wider (eg registers, buses..) you will use approx X times more chip area -> Higher cost. So to keep a constant cost, you have to wait until the silicon guys come up with some process that can make your chip X times smaller.

2) Power consumption (heat dissipation)
A wider bus will need more current to charge it's capacitive load. If the load gets higher your only options to keep a constant power consumption and keeping your processor from melting are these:

* lower probability for bitchange (smarter coding)
* lower frequency (not desired, right?), or
* lower voltage (1990: 5V, 2002: 3.3V. 2010: 1.5V?)

Perhaps 2) is not a real issue wrt bus sizes, I haven't investigated it. Take it for what it's worth; a semi-educated guess.

I guess that in video game consoles they have either the margins to take the higher cost, or they use 128-bits only in parts of the processor and didn't tell the marketing department. ;-)

Re:The bit stuff, explain to a layman. TIA

[bentini]

In fact, I'm fairly sure you're wrong. Well, sort of. You're probably right when you say that a processor with larger word size will be faster than those with smaller. However, it will also be more expensive.

Equivalently, you could have, for the same price, a 64 bit processor or a 32 bit processor which has more functional units, more cache, a faster clock, etc. What this means is that if you need 64 bit, it's better. If you don't, it probably isn't. Why do we need 64 bits? That, my dear friends, is the 64-thousand dollar question.

To deal with (precise) numbers larger than 4 billion. Do we need to? Well, sort of. It can be useful for polygons and stuff, but the "32-bit" architectures, largely, already have the SIMD instructions (MMX, Altivec, etc.) which will do this.

Basically, I think that the reason that many people are moving to 64 bit is that it doesn't cost much, and you could conceivably use it. Also, it makes compiling easier if everybody has the same processor. But by and large, I don't really think most people should care.

BTW, if anybody gets on my ass for this, 64 bits can't be for that much performance. If you want real performance, you have to go to some other model of computation at this point, so... yeah.

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

bits are moved in parallel... 128bits don't necessarily mean 2x the latency. Usually less.

Re:The bit stuff, explain to a layman. TIA

[copec]

heres a wierd question...Why dont they put some sort of optical controller and coupler between chips? The core of a fiber is small and I'm sure it would be easier and cheeper to 'cast' that into a motherboard then the X layers of X many connections they now have everywhere.

The sockets would just be some pins to hold the cpu in place and to power it, then the motherboard and silicon would have couplers that would be cast into both of them that would click into one another. I would think the trade off in transistors to add something like that, or to change the system interface part of the cpu would be well worth it.

On AMD's point to point bus it could make profound differences in being able to build multiprocessor systems.

As the saying goes though. Experts see few answers, and beginner's see many. Maybe I'm missing something?

Re:The bit stuff, explain to a layman. TIA

[scotch]

Hmmm, thanks for the clarification. It is a 64 bit mips though, so I'm not completely off my rocker. I remember when it came out that certain people were excited because the 64 meant what we thought it should mean.

Re:The bit stuff, explain to a layman. TIA

[bentini]

Yes. I can give you an excellent reason. The upper 50 or so bits of a 64 bit processor's words are largely 0. Except for addresses, in which cases they're still mostly the same. Basically, you don't need a 64 bit address space for most applications, but the (growing) number of exceptional apps make it worth it. But when was the last time you heard of an application needing 16 Billion GB of data on hand? It's been a while.

Those 16 Billion GB of data fill up 64-bit. Say you had a 256-bit processor? You could count to a LARGE number. Whoop-de-frickin'-doo. When was the last time you needed to count to that large a number? Or one of your programs did? Probably very rarely.

SIMD uses aside (which have been mentioned elsewhere in responses to this), you don't need that much. In fact, 256 bits would decrease performance. Why? Because when you tried to pull that information in out of memory to the cache, or from disk to the memory, you'd have more time spent waiting for these bits to be transferred around. In fact, this sucks the most because almost all of those bits will be 0 (unless you're dealing with small negative numbers, in which case they'll all mostly be 1).

Numbers that are this big are used so infrequently that you can use bignums (used in lisp, for example) to represent them without taking much of a performance hit at all in the common case, and the exceptional case (VERY rare) will only be maybe twice as slow, which makes the average case faster.

Thus, if you want a slower computer, go design a 256-bit processor, by all means.
-Dan

Re:The bit stuff, explain to a layman. TIA

[scotch]

Yeah, I didn't mean to bring price into it - that will of course change everything. That's why I said "all things being equal" - assume that applies to price too ;) The most important part of "64-bit" for most people is address space. There can be some performance benefit as well, but as you say, they're not worth the cost considering alternative ways to get the same raw horsepower. The address space increases exponentially, but the performace gains from parallelism increase only linearly. This cost increase is probably somewhere in between.

Re:The bit stuff, explain to a layman. TIA

[nrosier]

64-bit processors tend to be slower than there 32-bit counterparts. One of the only advantages they have is the 64-bit address space which is necessary for very large databases. 64-bit instructions usually are slower than there 32-bit brothers because of the overhead. 64-bit also means you'll have to read twice the data of a 32-bit instruction.

To me, it's all just a marketing hype.
In the Unix world, there are already many 64-bit processors and OS'ses (e.g. SPARCv9 and Alpha and Solaris and Tru64). The x86 chip-makers haven't been able to get foot in that market of large datacenters because of the lack of 64-bit address spacing.

Microsoft, Intel and AMD seem to want us to believe they are the 1st ones and if they'll make enough noise, people will start to believe it.

Re:The bit stuff, explain to a layman. TIA

[Rorschach1]

Just as a historical footnote... it doesn't always pay to try to jump too far ahead. Check out the history of the Intel 432... ahead of its time, but not exactly a success.

Re:The bit stuff, explain to a layman. TIA

[maraist]

Note I'm replying several sub-posts all at once here.

All other things being equal, a processors with larger word size (instruction sizes and address sizes) will be faster than those with smaller, though, depending on application, the results can be negligible or even worse, especially if compilers and programs aren't properly optimized.

I disagree from an architectural standpoint. In an ideal world, we'd all have 8-bit machines. All our arithmatic would be insanely fast; we'd be able to use combinational logic to allow two probagation levels for ANY operation (add, sub, mul, div, sqrt, log, etc). That's because it's cost effective to do so; a minimal set of possible outcomes. I'm not completely sure, but I'll speculate that it's possible to arbitrarily generate an arbitrarily sized number from just these 8 bits; though most likely it would be programatically (even if done via micro-code), and thus would be non-optimal for larger than 8-bit data-sets. So obviously, as we've been able to, we've increased the data-length throughout history as we've demonstrated a need.

Contrary to the impression that's given in these posts, a larger word size fundamentally is slower in calculating smaller values. Sticking with higher performance two-stage combinational logic requires an exponentially increasing number of transistors. Breaking the logic up into tiers allows designers to trade the number of transistors for the number of probagation delays. The more delays, the slower the clock; the more transistors, the less practical the design (due to heat, cost, and feasibility of fabrication). Pipelining somewhat helps aleviate the issue of extreme probagation delay, but it's impossible to achieve 100% efficiency, and thus you're practically garunteed slower operation for deeper pipelines. What's more, pipelining requires additional probagation layers for buffering, so you take an immediate performance hit; speculating that you'll achieve greater over-all performance.

In an ideal architecture, you'd minimize the probagation delays for each instructional unit, but practical measures say you must group most, if not all, of the CPU such that the slowest part drives the system. (P4's are nice in that they sub-divide the clock for the simpler integer units).

Combining the two ends, we can better appretiate the trade-off.. If we're performing large-valued arithmetic which is slow programatically (emulated 64bit), then it's worth the extra cost (towards the speed of each operation, and in terms of the number of transistors). In other words, one hardware 64bit add is most certainly faster than than several assembly language instructions that piece together 32bit values. BUT, now all your 32bit arithmetic is slower (unless you have separate 32bit/64bit logic cores).

It's possible to design 32/64bit cores that only take as many clock-ticks to complete as necessary, and thus 32bit arith isn't horribly slower, but there are definately additional probagation delays. The augmentation to 64bit can never increase the speed of a 32bit operation. (Any speed ups must be due to over-all advances in computational efficiency, which should benifit a pure 32bit core even more).

The trade-off must then be a statistical one. We cost out the largest word size that provides benifit. You're going to have arbitrarily large ALU operations (just look at encryption), so choose a cutoff where a certain percentage of all operations occur at that high of a word size. This is how we moved from 8 to 16 bit, and then the painful shift from 16 to 32 bits. And for server-targeted machines, the shift has already been cost-out to adopt 64bits. The desktop has not yet made sufficient requirements to adopt 64bits, though the underlying x86 CPUs are being shared in server-space which is nudging 64bit's acceptance.

Another important factor (which is presumably obvious in concept) is that a higher word-size has a greater probability of wasted space. A 1-bit boolean, for example, wasts 63bits.. Booleans are very common, and though they can easily be consolidated in c-struct's, such is rarely the case, since there are memory alignment issues (and flat-out laziness on the part of programmers). The wasted word-space also affects the instructions. Rarely do you actually see 64bit aligned CPU-instructions (except in VLIW or in places that the data-word-size was irrelevant). Such a situation would have massive implications towards performance. But one serious consideration is that the population of 64bit constants using a 32bit instructional word is expensive. Now you have to perform at least 3 (probably 4 or 5) instructions just to load a constant. Suddenly "a++" starts to look scary (at least when non-optimal compilers are used). In all cases sub-word-size'd instructional arguments are permissable to the delight of compiler designers, but there are still classes of problems that thwart this.. Namely memory addressing...

Memory addressing is arguably the strongest supporter of 64bit architectures. The 4GB limit is already apon us on desk-top machines (I have half a gig on all my home machines, and I don't need it). When you add swap-space, it's entirely possible for modern desk-tops to run enough apps to desire 4+Gig of memory. (Especially considering that large chunks of the address space are wasted). Aside from the various tricks designers have employed over the years to avoid augmenting the address space (8086's segment-registers, 80386's segment-selectors, OS's swapping out apps completely from memory, etc), it's arguably slower to emulate larger address spaces.

In addition to the above arguments against larger address spaces, there is massive cache polution; doubling the word-length, literrally halves the usefulness of a cache-line-load, unless you were previously emulating a larger word-size. You can only load 4 words on a pentium-class cache-line-fill instead of 8. Your bandwidth requirements litterally double (unless you don't standardize at one word-length).

Now in contrast, there are a few advantages. If your minimal word-size is larger, then the number of address pins that you need are reduced. But this is really independent of the core word-size. Pentiums have long required 64bits for their external bus, and use even larger cache-line sizes. Thus most of the advantages attributed to this argument are moot.

Theoretically, an architecture can be designed to split an ALU such that it acts as either 1 64bit unit or 2 32bit units. This is especially true for vector-cores (which are already up to 128bits for main-stream processors). In general, however, there is still the trade-off here, since additional logic-probagations are required which slow down the general case of only a single But comparing the X-box and the Nintendo 64, which were released many years apart won't buy you much of a conclusion other than current processors are generally faster than older processors.

I'd like to address the nature of large bit-sizes with respect to graphics. While this isn't my expertise to the extent of the above, this primarily affects the bus width. In graphics, you commonly have multi-integer structures (red, blue, green, alpha (opacity), Z-depth (the depth into the screen the geometrical object that drew this dot is), stencil, etc). The entire structure is usually just 16bits, 32bits, 64bits, etc. The larger the structure, both the more features you can pack into it, and the more accurate each individual number can be. Thus saying that an architecture is 128bits purely based on this is very misleading. What's even worse are labeling the bus-width numbers (e.g. 128, 256). That's like calling the Pentium I a 64bit CPU, just because it has a 64bit bus (used purely for cache-line burst fills). Yes it makes it go faster, but so does shortening the length of each wire; it's not really innovative. I'll throw this in, but I'm starting to get in over my head; Graphics units (especially the filtering parts) make heavy use of hard-wired combinational logic units. The number of bits going into these units is really meaningless (how many thousands of wires go into the control logic portion of a CPU?). Thus the ability of a custom pieces of hardware to utilize larger bit-depths is unimpressive. What would be impressive would be to say that a Graphics unit does it's integer / floating arithmetic in 128bits so as to minimize error (even though the input/output might only be 8 or 16bits per atomic unit).

-Michael

Re:The bit stuff, explain to a layman. TIA

[printman]

The N64 uses a MIPS processor, not an ALPHA processor. MIPS processors have been 64-bit capable for a very long time...

Re:The bit stuff, explain to a layman. TIA

[bentini]

The cost, in fact, will be in the middle. The cost will be on the order of n^8 or so, I think. Where n is the number of bits.
-Dan
PS: That is, in fact, huge.

Re:The bit stuff, explain to a layman. TIA

[d.valued]

It may be 'kick ass', but the utility as of right now is pretty limited.

Consider: To process any character in the English language, you need only eight bits. That's it. That's one-quarter a register in a 32-bit machine.

And, unless you or the assembler uses a decent amount of technical trickery, that's all you can get in there.

(Case: Intel processors have four main registers: EAX, EBX, ECX, and EDX. These have a high word and a low word (the low words are AX, BX, CX, DX for reverse compatibility with 16 bit code). Each low word has a high bit [ABCD]H and a low bit [ABCD]L. )

Addionally, for numbers.. There ain't too many folks that need to process numbers on the order of 2 to the 128th power, or floats that have, what? twenty digits? thirty digits of precision?

When the numbers get that detailed, you're better off with a quantum system anyway.

Re:The bit stuff, explain to a layman. TIA

[Sebastopol]

heres a wierd question...Why dont they put some sort of optical controller and coupler between chips?

Cost. The bill of materials on a motherboard is insanely tight -- they count resistors, remember! All of the fancy interconnect to go optical is way to expensive, and has very little benefite: aka, ROI.

Beside, what good does it bring? I agree that copper limits on a motherboard are approaching rapidly: anyone who has ever tried to debug a RAMBUS implementation knows how painful it is to build interface hardware to debug a 1ghz strobed differential bus. However, I would think that until the b/w at the CPU and DRAM _PINS_ vastly exceeds what is possible with a copper trace, the ROI on optical would be nonexsitant.

I need to re-read AMDs point-to-point proposal, I'm not sure I buy their claim that adding additional CPUs doesn't decrease bandwidth.

As for symmetric-MP, et al: there are lots of weird topologies for MP out there in server-land. The first teraflop machine was PentiumPro bus architecture, which is only 4P scalable on Intel arch, but custom chipsets can do anything! ...but we know most about Intel and AMD's because they need the marketing gee-whiz factor to sell their crap.

And when I say "crap", I mean, "crap". I firmly believe that if both giants were not chained to their product roadmap and stock-holders, aka profits, then we would see some truly efficient high-performing architectures. A giant can't take a 90-degree turn... that's why all x86 architectures are basically suped up jalopies -- making too sudden a change can be devastating if you don't have the capital. Look at Itanium -- if AMD spent the resources Intel did, it would have broken their bank like the Cold War broke Russia's. Look at AMD bolting on *-64, it's basically a blower on a Chevette!!!

I'm _really_ rambling, I'll stop now.

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

I like Linux. It is the best. I think that everybody should use Linux.

Re:The bit stuff, explain to a layman. TIA

[bentini]

Wow.

I disagree from an architectural standpoint. In an ideal world, we'd all have 8-bit machines. All our arithmatic would be insanely fast; we'd be able to use combinational logic to allow two probagation levels for ANY operation (add, sub, mul, div, sqrt, log, etc). That's because it's cost effective to do so; a minimal set of possible outcomes. I'm not completely sure, but I'll speculate that it's possible to arbitrarily generate an arbitrarily sized number from just these 8 bits; though most likely it would be programatically (even if done via micro-code), and thus would be non-optimal for larger than 8-bit data-sets. So obviously, as we've been able to, we've increased the data-length throughout history as we've demonstrated a need.

8 bits?! Why 8 bits? You make it sounds like this is atomic, when it's not. At all. If you're going to go for the theoretical minimum, go for 1 bit. The CM-1 used 1 bit processors, and could do everything. But why 8 bit?! That's sort of whack.

Another important factor (which is presumably obvious in concept) is that a higher word-size has a greater probability of wasted space. A 1-bit boolean, for example, wasts 63bits.. Booleans are very common, and though they can easily be consolidated in c-struct's, such is rarely the case, since there are memory alignment issues (and flat-out laziness on the part of programmers). The wasted word-space also affects the instructions. Rarely do you actually see 64bit aligned CPU-instructions (except in VLIW or in places that the data-word-size was irrelevant). Such a situation would have massive implications towards performance. But one serious consideration is that the population of 64bit constants using a 32bit instructional word is expensive. Now you have to perform at least 3 (probably 4 or 5) instructions just to load a constant. Suddenly "a++" starts to look scary (at least when non-optimal compilers are used). In all cases sub-word-size'd instructional arguments are permissable to the delight of compiler designers, but there are still classes of problems that thwart this.. Namely memory addressing...

A) consolidate in c-structs? Programmer laziness?
Don't bash the programmer, at all. That's just cruel. The programmer shouldn't have to. That's the compiler's job. However, that can often slow down the code, when it has to mask all the bits, op, then mask all the bits again. So, just using one word for a boolean makes sense. Surely, though, a compiler could do what it wans.
B) Constants get loaded into a different segment than the code, so they won't be in the code, most likely. Unless they're ints or somesuch, in which case you can just use an add-immediate to move them in, and in almost all cases (as you YOURSELF very specifically state) they won't take up more than one immediate.
C) "a++ looks scary"? Umm, a++ will still take one operation (add $rx, $rx, 1). What are you even talking about? Not to mention that compilers optimize.
D) You can still have 32 bit data values in a 64 bit computer by loading the words from memory differently, so don't think that suddenly EVERYTHING has to be in memory as a 64 bit value just because your architecture is that.
E) On a 32 bit architecture (at least, real ones), the 4 gig memory limit (2 on certain ones, e.g. MIPS) is per process, not per system. Thus, you can have many processors, each of which have 4 gigs of memory allocated and using running on a computer with 512K of memory. It would be slow, but that's the beauty of software.

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

Nope... It has a 128 bit wide register, by coupling 2 64bit FP registers. MMX/SSE work on 8-bit pieces of data.

So what you have is a SIMD processor, that can work on 16 8-bit operands at the same time (same opeartion, parallel data). The MMX/SSe ALU is 8-bit wide, not 128bits!!!!

Then again most people here have no frigging idea about CPU design, and they speak from their asses.

Re:The bit stuff, explain to a layman. TIA

[banka]

ehh..thanks for giving a correct reply to the prior posts. i don't have mod points so i can't hook you up any furhter, but compared to the posted under you, which should have been modded (Score, 5 Wrong) if anything, you certainly made saved my fingers from a beating!

Re:The bit stuff, explain to a layman. TIA

[Waffle Iron]

Nope... It has a 128 bit wide register, by coupling 2 64bit FP registers. MMX/SSE work on 8-bit pieces of data.

So what you have is a SIMD processor, that can work on 16 8-bit operands at the same time (same opeartion, parallel data). The MMX/SSe ALU is 8-bit wide, not 128bits!!!!

The original post asked for wider buses like game consoles. Are you under the impression that game boxes are multiplying 128-bit long numbers together? No. They're working on little pixels and single-precision floating point coordinates.

Very few people need 64-bit integers for math, either. As I said, the big deal is longer address pointers.

Then again most people here have no frigging idea about CPU design, and they speak from their asses.

Rest assured, I know plenty about CPU design.

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

"Basically, I think that the reason that many people are moving to 64 bit is that it doesn't cost much, and you could conceivably use it. "

I think you are talking about the typical AMD fanboi here, and not someone who has 4GB of RAM in their x86 server and is out of headroom.

Your beefed up 32-bit CPU would probably be better for the traditional desktop user than the Hammer.

Re:The bit stuff, explain to a layman. TIA

[maraist]

You had several valid points, some of which I even acknowledged.. But still felt the need to further comment.

8 bits?! Why 8 bits? You make it sounds like this is atomic, when it's not. At all. If you're going to go for the theoretical minimum, go for 1 bit.

Nothing magical about 8bits, except that we like multiples of 8. An 8bit add requires two 8bit numbers = 16input bits, and 8 output bits. Ignoring optimization and implementation complexities, that's on the order of 65 thousand transistors for a two-level adder. That's definately do-able in today's technology.

Two 16bit numbers on the other hand, would likewise require on the order of 4 billion transistors, which it not currently possible with today's technology (my guess is that by the time it is, we'll be using 128bit ALU's).

My point was to find the most practical pure combinational logic unit. Thus to suggest a 1-bit machine implies that we miscommunicated.

Point A)consolidate in c-structs? Programmer laziness? .... However, that can often slow down the code...

An alpha has a nice little byte-swapper which relatively efficiently extracts a byte out of a multi-byte word. It's computationally slower to work with than just testing the whole word, but when you take into account bandwidth / cache-space considerations, it's a boon. It can't be easy for a compiler to optimize away:
struct {
int f_flag1, f_flag2;
} ...

Can it drop the flags down to 1 byte?

While it's not always true for each architecture, you should find higher performance swapping out the int's with char's.

I'm not familiar enough with the state-of-the-art in compiler technology, so perhaps this can be determined. I was just generalizing on this type of point, nothing more.

Point E)

The points you mentioned here would be included in the sort of tricks that have been devised over the years to avoid upping the word. It just furthers the idea that larger word-sizes are expensive and worth side-stepping.

-Michael

Re:The bit stuff, explain to a layman. TIA

[spiro_killglance]

"64-bit processors tend to be slower than there 32-bit counterparts"

Depends on the Architecture, if the instruction
sizes are the same, and the 64-bit chip can
also run 32-bit code, then clearly the 64-bit
one will be faster.

Best guesses so far, reckon
that x86-64 code should be about 15% faster than
x86 code, mostly due the doubling of the number
of registers from 8-int 8-fp (SSE) to 16-int
16-fp. This is in additional to a estimated
25% gain in speed over the Athlon at the same
clock speed and however many, more GHz AMD can
squeese out the new core.

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

The Nintendo64 uses a 64-bit MIPS RISC 93.75MHz CPU (customized R4300i series) and was developed closely with SGI.

For more info:
http://www.futuretech.vuurwerk.nl/sysdesc.h tml

Re:The bit stuff, explain to a layman. TIA

[Weasel Boy]

I'd like to take issue with some of things you say (especially about so-called two-level structures), but I don't have time right now. So I'll make it simple:

proPagation

aaaargh!

I feel better now.

Re:The bit stuff, explain to a layman. TIA

[bentini]

Umm, adders are actually linear in size of transistors (at least without special logic). I think that a 16 bit adder would take on the order of 500 transistors, not 4 billion. No chip, yet, has 1 billion transistors (that I know of).
B) That's why people have bool's already. Also, if you only assign 1's or 0's to the ints, then it can drop them down. This is how auto-vectorization works.
E) This isn't a matter of upping the word, it's a matter of virtualization, which is a useful abstraction.

Re:The bit stuff, explain to a layman. TIA

[Hoser McMoose]

Reasons against 128 or 256-bit computers? Here are the three important ones:

1. These machines would be slower then 32 or 64-bit machines

2. These machines would expensive.

3. It wouldn't help anything except in extremely rare cases (some have suggested some crypto stuff as an example)

Having more bits in a computer system is useful for two main reasons, one is to deal with larger numbers without resorting to some funny math (eg. combining two 8-bit numbers toghether to make a 16-bit number if you need a range of values greater then 256). The other is to support large amounts of memory.

The first reason used to be quite important. Back in the day of 8-bit computers, most systems used a 16-bit or greater memory bus, but could only deal with data in 8 bit chunks. As a result, if you wanted to do anything at all complicated, you needed at least two variables together. Faster forward to 32-bit data though, and the range of numbers you can deal with is now 4 billion, ie more then enough for all but the most extreme situations, and for those situations you now have floating point units (which can deal with much larger numbers), as well as MMX, SSE/SSEII, etc., which can sometimes be used instead.

Therefore, the only real benefit of going to 64-bits is to access larger amounts of memory. 32-bit processors can only access 32-bits worth of memory directly, ie 4GiB. Actually, usually you end up with a limit of only 2GiB since you can have relative pointers (ie a pointer can be +/- 2GiB from the current location). There are some ways around this, ie Intel's PEA, but this gets into the same kinda of ugliness we had back in the old DOS segmented memory days. It was an ugly kludge back then, and if anything it's even worse now. With 64-bit chips, you can have pointers to access 10^19 bytes of memory directly.

So, going to 128-bits would buy us what? The ability to access more then 10^19 bytes of memory? That isn't likely to be an issue for quite some time, even if memory use continues to double every 18-months or so. It also doesn't help for accessing larger values, because it's quite rare to need more then 32-bits integers, let alone 64-bit integers, and for those extremely odd cases, there are potential workarounds.

The downside of going to wider CPUs though is that, all else being equal, they're slower. A 64-bit CPU needs to get twice as much data from memory as a 32-bit CPU, and a 128-bit CPU would need twice as much data again, for each and every variable! Now, those who look at computer performance today will probably already know that memory bandwidth is a potentially major bottleneck. Making a system require twice as much data from memory can place even greater restrictions on memory bandwidth.

So, for today, the advantages of 64-bit CPUs tend to outweight the disadvantages, at least for the high-end. However a 128-bit CPU makes no sense at all, since it offers no advantages but lots of disadvantages.

As for the game consoles, don't get confused by the terminology. Their "128-bit" and "256-bit" chips are for the video portion of their systems. Virtually all current graphics chips for PCs are 128-bit or 256-bit in much the same way. However this is a whole other ballpark from the general purpose CPUs being discussed here.

Re:The bit stuff, explain to a layman. TIA

[Hadlock]

i know this goes against the great slashdot blackout, but this story was too big to miss out on.

disclaimer aside, intersting theroy on 8 bit processors. i have 0 education on processor design other than some extremely basic knowledge - bear with me- paralell processing can be *very* fast and *very* efficnet, otherwise sony wouldn't be using it to develop their PS3...would it be possible to run, say, eight 8086's (or 4004's?) in paralell, for essentially 64 bits or processing, run the production @ .13 microns, put them all on one wafer, conenct them to 512k of L1 and/or L2 cache, and clock the whole thing @ 1.5 Ghz or so? you'd need a processor controller to divy up the various instructions between the processors, maybe a pentium or somthing - i dunno, somthing more efficent, most likely ;). how would that fare?

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

Hey, I have a vette---not blown but turbo--- and it will kick the ass of any of thoes other vettes (at least street vettes) any day.

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

Hey that is only about 200 tera bytes of address space. We will have to replace thoes in less than 5 years.

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

I can just see geeks fifteen years ago sitting around a shiny new 32 bit amiga when one starts dissing it as overkill; "16 bit processors are more efficient and who will ever need that much ram in a flat address space." Today that geeks son is doing the same thing, only he is praising the efficency of his 32 bit box and dissing the upcoming 64 bit pcs.

Re:The bit stuff, explain to a layman. TIA

[Emil Brink]

The PS2's CPU, the Emotion Engine, has 128-bit wide general registers, 32 of them to be specific (GPR00-GPR31). It has a 128-bit wide internal bus. However, most common MIPS-inherited instructions only act on the lower 32 bits of the registers; there is a special class of "parallel" instructions that work much like MMX, i.e. they act on parts of each register in parallel. Clear?

And the 2560-bit wide thing is inside the Graphics Synthesiser, between the rasterizer and the memory. It has 4 MB of frame buffer, implemented on the same chip (embedded DRAM), which is why the bus can be that big. It gives for nice-looking bandwidth numbers, if nothing else. ;^)

Re:The bit stuff, explain to a layman. TIA

[-douggy]

[i] When was the last time you needed to count to that large a number[/i]

Prime numbers, large numerical simulations of gas glouds (yes I know there are other ways of doing this....)

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

I'be been thinking about that fibre concept too.

You could use a serial bus and some tricky encoders/decoders.

Or you could use it as a replacement for tracks. You'd need a bi-directional signallight device (um, led + photovoltaic? i dunno - IANAEE) in a pad size component. Maybe that could be (or has been) developed. Might be a candidate for a nanotech approach.

Better would be having these devices chipside, and keeping the mobo simpler.

Re:The bit stuff, explain to a layman. TIA

[mochan_s]

Probagation delays.

Modern processors have multiple units that do the same thing. Like multiple adders, multipliers etc so that unrelated operations can happen in parallel.

But you have to avoid the hazards of doing something like that.

Re:The bit stuff, explain to a layman. TIA

[PianoMan8]

About the bandwidth...

They're playing a little game here. It's numa. Every CPU gets full bandwith to its local memory. So if you have an app that has 4 threads, one on each processor, then each gets the full bandwitch to it's local memory. Add another 4 processors, and another 4 threads, and you get "double the bandwidth" because all 8 processes get the full bandwidth on thier local CPU.

Now, bandwidth -between- processors, that's another story... Sicne the Hammer has only 3 links, you can only do a 2D mesh....so the more processors you add, the more demand there is on the HT bus. That's why, for the current generations planned, they're only looking at most 8-way.. In reality, now that there at HT switches, you could scale almost infinitely higher.. but the more you add, the higher the latency, and the lower the bandwidth..

god i'm a geek... i love this stuff...

pm.

Re:The bit stuff, explain to a layman. TIA

[Anonymous Coward]

I imagine that floating point intensive operations on a 64 bit cpu really rock.

Re:The bit stuff, explain to a layman. TIA

[TheLink]

Personally I think we've been trolled :).

I went halfway through all of his words before I realized...

Excuse me??!!!

[lynuhx]

I find it highly unlikely that _anyone_ could convince Intel (or any company, for that matter) to switch to a competitors architecture. Hammer will remain at AMD and IA-64 will stay on course with Intel. I'd need to hear it directly from both BODs to believe otherwise. Then again... I've been wrong before. :)

Re:Excuse me??!!!

[caspper69]

They have been working on it. It's called "Yamhill" and is an implementation of AMD's public extention to x86 called x86-64.

Contrary to popular belief, IA-64 is a dead architecture as it stands. They made some very poor decisions (and some very good ones) with the architecture, and AMD executed flawlessly with the x86-64. That is MORE than evidenced by the email (why it took /. so long to run this story I don't know. I was going to submit it yesterday, but my submissions are always rejected anyway) in which MS got 64-bit XP up and running within 2 hours of having final silicon. That's a hell of a feat (especially for MS!)...

Re:Excuse me??!!!

[Anonymous Coward]

i hear yamill will not be all that compatible.....possibly and embrace and extend plan by intel?

Re:Excuse me??!!!

[Anonymous Coward]

The hammer will be a fraction of the price of the Itanium, and will generally outperform it. I've heard rumours about SUN micro looking to adopt it. These hammers will ramp up to clock at ~2GHZ pretty quick here. At those speeds, they will likely outperform every other chip 64 bit chip out there( if the cache is big enough). And they wont cost much more to fab than a Palomino. Intel's Itanium is a complete disaster, they spent billions to develop it, and years of their best design effort on it.

Re:Excuse me??!!!

[Anonymous Coward]

there are still some specialized stuff that itanium will do better than hammer, but that's niche anyway.

Re:Excuse me??!!!

[archen]

I find it highly unlikely that _anyone_ could convince Intel (or any company, for that matter) to switch to a competitors architecture.

um... DDR RAM?

I think Intel is already pretty annoyed because they can't control everything like they used to...

Re:Excuse me??!!!

[Ryokurin]

and AMD and Intel does have a standanding agreement that they can share each others instruction sets but the one thing that AMD cannot do is make a processor that is compatible with an Intel bus. It last until 2010

Re:Excuse me??!!!

[Hoser McMoose]

Knowing Intel, I'd be fairly certain that they will do everything that they can to avoid using x86-64. However, their hand might be forced.

As it stands right now, IA-64 is hurting REAL bad. The Itanium is quite possibly the biggest flop in recent history of all technology flops out there (and it's got some tough competition from products that really failed miserably!). If Intel's next generation of IA-64 chips (McKinley), to be released late this year, doesn't improve things DRAMATICALLY, it will probably be the final stake in IA-64. Intel will be forced to drop the architecture and will need to play catch-up real fast with AMD.

Now, the interested rumor that just came out though is that Microsoft may be refusing to support any 64-bit architecture from Intel that is different from AMD's x86-64. If that's the case, Intel may be forced to use AMD's instruction set.

As I said, I'm sure that this isn't something that Intel wants, but unless the McKinley is a HUGE improvement over the Merced/Itanium, then they might well be forced to.

hmmm .. sounds fishy

[Frag-A-Muffin]

that would explain why AMD is backing M$ in the M$ trial that's going on!

It scares me to see huge companies like this, conspiring in court.

Honestly though, I thought it would have been Intel, not AMD doing this.

Re:hmmm .. sounds fishy

[Daniel Dvorkin]

Well, who knows, maybe this is the Big Crack in the Wintel monolith that we've all been waiting for. It will be ironic if AMD turns out to be Microsoft's best buddy and Intel ends up as the chipmaker of choice for Linux users, though ... Of course, it wouldn't be the first time Microsoft has suddenly parted company with an industry giant when it looked convenient for them.

Re:hmmm .. sounds fishy

[Dalroth]

It makes perfect sense though...

Everybody knew Intel wanted to introduce a new instruction set with the Itanium and retire the x86 instruction set for good. It was a noble effort on Intel's part.

AMD saw an oppurtunity. They knew that software development is slow and painful, and porting software form one architecture to another (especially when you never planed for it in the first place) is a long agonizing process. Most windows software is written for x86 32, there is a lot of it, and even with good tools it would take a long time to port everything to IA64. So, AMD did the next best thing and built 64bit extensions on top of the x86 instruction set (still some work to do, but a lot less).

Microsoft of course, not being in this for the higher noble cause, realizs that it is cheaper, quicker, and easier to just extend their tools to use the x86+64 instruction set rather than redoing everything in IA64.

Now, Microsoft, having the power it has tells Intel they don't want to port to the IA64. Intel panics, Microsoft gets its way (again), and we have yet another example of how Microsoft has too much power (when they can strongarm Intel like this, things have gone WAY too far).

Just another day in cyberspace...

Re:hmmm .. sounds fishy

[Anonymous Coward]

Heheh. "strongarm Intel". That is funny on SO many levels.

Re:hmmm .. sounds fishy

[MonMotha]

"strongarm Intel" eh? I thought Intel was the one with the strongarm, not Microsoft applying it against Intel. Oh wait, that was the StrongARM processor...

It's funny, laugh!

--MonMotha

Re:hmmm .. sounds fishy

[Quikah]

Intel panics, Microsoft gets its way (again), and we have yet another example of how Microsoft has too much power

So you would rather that Microsoft be forced to port windows to IA64? What about PowerPC, how about Alpha, should we force them to support those again too?

Re:hmmm .. sounds fishy

[Anonymous Coward]

Actually, it's only funny on two levels. One if you take it literally, and one if you realize Intel makes StrongARMs.

Re:hmmm .. sounds fishy

[Mr 44]

Microsoft of course, not being in this for the higher noble cause, realizs that it is cheaper, quicker, and easier to just extend their tools to use the x86+64 instruction set rather than redoing everything in IA64.

Except for the minor fact that Microsoft already ported everything to the itanium. See this press release from last year...

Re:hmmm .. sounds fishy

[afidel]

Funny except .Net server already runs on IA64, it's called win64 and has been running since slightly after the linux port to IA64 was completed.

Re:hmmm .. sounds fishy

[Dave_bsr]

well...except...almost everyone agrees that right now, IA-64 is not a step up, but a step back...but its all rumor for now anyways.

Re:hmmm .. sounds fishy

[jmauro]

Yes we should force them to support those platforms. If the OS is designed well it really shouldn't be that big of a problem. I thought that was the purpose of the HAL anyway.

Re:hmmm .. sounds fishy

[56ker]

I'm really not bothered who supports Microsoft at their trial. As long as Intel and AMD are in competition with each other - I'll be happy.

Re:hmmm .. sounds fishy

[Anonymous Coward]

Well, Intel knew that too. That is why they had a hardware x86 emulation effort. However, when they realized it's speed was at the level of a Pentium 100 MHz things started to hurt. The word 'kludge' was around. But, in all honesty, Intel was definitely aware of the process you describe.

Re:hmmm .. sounds fishy

[csbruce]

that would explain why AMD is backing M$ in the M$ trial that's going on!

Hopefully the Judge will be made aware of the back-scratching that is going on and will discount AMD's testimony appropriately. BTW, has there been any pro-Microsoft testimony that hasn't been paid for?

Re:hmmm .. sounds fishy

[Ayende Rahien]

You *do* realize that the reason that there isn't ports to those systems is not that they can't do it.
There *were* ports to Alpha & PPC, (as well as MIPS), the problem is that they didn't *support themselves*, so they had to be canceled.
MS has to support everything that they make, and that cost money, if a product isn't making money for them, or isn't going to, they will can it, and move to the next thing.

Re:hmmm .. sounds fishy

[Zigurd]

StrongArm(tm) is an Intel trade mark.

Well as the saying goes

[A_Non_Moose]

When all you have is a Hammer(TM)...yadda yadda

Re:Well as the saying goes

[froseph]

Ahh I was hoping that they would keep the name of the chip Hammer so in the commercials I would hear "It's Hammer time!" or have some old MC Hammer vids

Looks like the gambit paid off.

[b0r0din]

I can't wait for one of these to be benchmarked against the current Intel line. But Opteron? Reminds me of Optimus Prime from Transformers. Then again, you may need a transformer just to run one of these :)

Re:Looks like the gambit paid off.

[bonzoesc]

If my CPU can become a giant robot that beats up other giant robots, it's all the better.

Re:Looks like the gambit paid off.

[Ksop]

Soooo will the mobile version be called the GoBot?

Re:Looks like the gambit paid off.

[aussersterne]

But Opteron? Reminds me of Optimus Prime from Transformers.

I think Megatron would have been a cooler name.

Re:Looks like the gambit paid off.

[Razor Sex]

In related news, Intel has just announced a new family of chips called the Decepterons. They are set to compete with the Opteron family.

Re:Looks like the gambit paid off.

[ZaMoose]

If that comment's "insightful", then I'm a supervillain's sidekick, made entirely of butter.

I want some of the dope the moderator was smoking.

Re:Looks like the gambit paid off.

[bonzoesc]

Yeah - I was kind of hoping for a Funny there myself.

Re:Looks like the gambit paid off.

[Anonymous Coward]

I use Linux and I love it. Give it a try. You'll really dig it. It is the best.

AMD vs Sun?

[Kenja]

Has anyone done a good comparison of what the new AMD chips promise VS what Sun has already delivered? I've been toying with getting a Sunblade 1000 for some time now, if AMD can provide me with a lower cost system with comparable performance I may hold off a but longer.

Re:AMD vs Sun?

[Steveftoth]

The SunBlade 1000 is not a very fast machine, it's ok for desktop use, but it's no speed demon. It's really for those people who NEED to develop on a Sparc Solaris machine but cannot afford a fully loaded Workstation. x86 will always give you more bang for the buck since there are more companies making hardware for it. It's just a simple economy of scale.

However, I do believe it's the best deal for a Unix only workstation on the market today. I don't think that you can get an IBM AIX machine for less.

Re:AMD vs Sun?

[Anonymous Coward]

Yes. The Opteron will blow Sun out of the water. I would not want to be a Sun shareholder right now.

Re:AMD vs Sun?

[chill]

You mean, besides the ability to run all those existing Intel apps?

Re:AMD vs Sun?

[Kenja]

I think you are thinking of the Blade 100. A dual 750mhz Ultra III with 8megs of cache per CPU is in no way "slow".

Re:AMD vs Sun?

[Hoser McMoose]

The Sunblade gets you a system that's great for I/O stuff, but not raw processing power. In terms of actual processing power, current x86 chips have Sun beat rather solidly, and that gap is only going to widen with the above-mentioned Hammer chips. However raw processing power has never been Sun's strength. Their strength is in I/O and in their software (not to mention support).

Nice. M$ once again stifles innovation ...

[jkujawa]

MS is backing x86-64 over Intel's IA-64, and that MS has apparently convinced Intel to move to x86-64!

x86-64 is much closer to the old x86 architecture than IA64. x86 SUCKS. It has sucked for years. Moving to IA64 would mean trashing a bunch of legacy code, but it also means that new applications wouldn't be saddled with 25 years of architectural baggage from an architecture that should have been taken out and shot 20 years ago. So once again, by chosing backwards-compatibility over everything, Microsoft is holding back the industry.

Re:64-bit Win XP?

[caspper69]

troll. Why not just be happy. Even though it is MS, this is a big win for AMD. They have kicked Intel's ass into high gear, and for that ALL pc users should be happy.

And we all know 2k/XP are *real* operating systems. If you've got it crashing, you should be able to resolve it (you're on /., so you *should* be computer competent). Not like back in the 95/98/Me days when it may just be that a butterfly flapped its wings in Bangkok, so your computer crashed...

Ads

[bci10]

I really like that Intel add on the CNet page, it really makes me think twice about getting an AMD powered chip ;-)

Re:64-bit Win XP?

[Daniel Dvorkin]

It will crash either twice as fast or twice as hard, but not both. For crashes that are both twice as fast and twice as hard, you'll need the 128-bit version. ;)

Re:64-bit Win XP?

[Anonymous Coward]

XP hasn't crashed on me yet...

my math is fuzzy how much faster is twice as fast as never?

I think it should be called....

[Anonymous Coward]

Megatron ;)

Anyone remember the villan Megatron from Transformers?

Re:things i hate about slashdot 1.0

[Anonymous Coward]

what i like about slackware is that you have to compile the applications by yourself. You can use -O2 -m586 and skip the silly -g and have 500% faster and smaller programs.

too big for anal and too small for oral.

Re:Nice. M$ once again stifles innovation ...

[caspper69]

Microsoft is holding back the industry

And I'm sure it has nothing to do with the fact that every man, woman, child and manager on the earth doesn't want to re-purchase every piece of software and hardware they own.

AMD is officially announcing this

[Utopia]

I wonder why this is listed as a leak.
When AMD announced this at a press conference a few hours ago.

AMD nails Microsoft backing for Hammer-CNET
MS to confirm Hammer support-The Register, UK
Microsoft to Support AMD's Hammer-eWeek

Webcast of today's conference call

[Mark_Hopkins]

A webcast of today's conference call announcing Opteron is available here

-Mark

Re:definitely is definitely not spelled definatly

[Anonymous Coward]

Technically it's not the editor's spelling but the submitters. I'd have thought that 'editing' implies they have the right to 'edit' the submission before slapping it on the front page. But that would be a little too much work for these monkies... Right Chrisd?

Re:64-bit Win XP?

[Anonymous Coward]

Bits don't equal speed nitwit. More bits give you more memory addressing space. That's why the 64 bit processors are targeted at servers first (think big-ass databases).

AMD and MMX

[Roadmaster]

Well, back when AMD bought NexGen, they trashed NexGen's plans for intel-incompatible dsp-like instructions for their next processor (what was to later become the AMD K6) and licensed Intel's MMX instruction set instead. While not a complete architecture, AMD did choose to license a competitor's instructions.

Re:AMD and MMX

[emir]

yeah but back than amd had probably something like 5-6% of the market while intel had probably over 85% of the market. AMD had to be compatible with intel to survive.

its highly unlikely that market leader intel would switch to competitors architecture.

Re:AMD and MMX

[Anonymous Coward]

Guess what? AMD still has about 5-6% of the server / high-end workstation market, which is who they are selling hammer to.

I was a little disappointed that their announcement didn't include IBM, Compaq, HP, or Dell. It doesn't matter how cool it is, if they can't find a brandname to sell it.

Re:AMD and MMX

[nelsonal]

Most likely it will be Sun. They are planning to introduce a X86 linux workstation/entry level server, in May. This leaves AMD, Intel and Via, since Intel is their main rival, and via's chips are better suited for other purposes, AMD has to be the likely company, for this contract. I would guess that it will be introduced on athlon MP first, but hammer has to be on the roadmap for these systems.

It's A.M.D. Hammer time!

[Anonymous Coward]

Can't touch this.

Re:Nice. M$ once again stifles innovation ...

[Anonymous Coward]

IA64 isn't even in competition with x86.
Intel wasn't planning to target the IA64
to consumers at all for several years.
If you're lusting for IA64 you might as
well just switch to UltraSPARC, because
the IA64 chips are so enormous they'll
never be economical.

Re:Nice. M$ once again stifles innovation ...

[LordSah]

I'm gonna hold off on thinking that MS is supporting x86-64 completely. They already have code that works in IA-64. If I had to guess, I would say that MS will release products for both architechtures. The source code for Windows or office is the same for either 64-bit platform, and all it takes is compiling for one or the other. They already have tools that works for IA-64, and I read somewhere they have x86-84 stuff in the works. It won't cost them any money to publish both versions.

They'll probably push one or the other once the market starts leaning in a particular direction. I really hope it's IA-64. I want x86 to die as soon as possible.

Re:things i hate about slashdot 1.0

[Anonymous Coward]

interesting, all so true indeed.

but you left something out, you have ignored the idiocy of the bsd people...

You forgot, any story posted about a new feature in linux well get bsd zealot replies saying "but bsd has done this since 1973!"

or a company chooses to role out redhat for its systems and a bsd zealot says "why do these stupid companies always go with redcrap, i mean freebsd rocks 1 cpu i386 systems! i use it for my mp3 server in my dorm and it has an uptime of 30000 days!"

and don't forget this classic, this one from the linux zealots:

"redcrap sucks ass i hate them they are the m$ of linux! debian is the best!" while totally failing to realize that redhat has done more to promote open source to businesses and advance linux technically than some peice of shit no market share distro thats developed by high school drop outs in between dragonballZ episodes.

PowerPC

[Anonymous Coward]

Considering what AMD has managed to do for an old war-horse like x86, I wonder what they could do for PPC? I'd heard a rumor that there were some talks with Apple about becoming a second source since Motorola couldn't get their yeilds up. And doesn't the new CEO come from Motorola? If they're concerned about market share, a PPC venture could help them grab an additional 5% of the market becoming Apple's supplier.

Re:PowerPC

[binaryDigit]

I'm not so sure here. Remember that the number one area that AMD trails Intel is in clock speed. Hey sound familiar, that is the exact same problem that Mot is having, trying to convince people that clock speed is not the end-all be-all of performance.

Also, keep in mind that AMD has been in the x86 market for a great many years now and have much experience with the architecture. They'd be coming into the PPC cold (barring any behind the scenes development that may have occured). Their only experience with RISC was the ill fated 29000 (which they quickly dropped the general purpose cpu market and focused on the embedded market). Not exactly a strong track record there (though AMD has done quite well in that market with the 29K, at least they were doing quite well).

And thirdly, there already is a second source for PPC chips, and that's IBM. As a matter of fact, one contenteous point between IBM and Mot was over AltiVec, IBM wanted to focus on higher clock rates, whereas Mot wanted to accelerate certain operations. Funny how Apple still does not use IBM designed (not necessarily fabbed) PPC's.

Re:PowerPC

[mallie_mcg]

I think you will find that the PPC 750cx (G3 used in the iMac CRT / current iBooks) was designed and manufactured by IBM, and is capable of scaling beyond what it currently runs at.

I was under the impression that Motorola would not allow IBM access to the AlitVec without significant cost.

David Cutler has reportedly voiced ...

[Anonymous Coward]

"As we reported yesterday, Microsoft is committed to supporting AMD's x86-64, the open standard instruction set native to Hammer. Key decision makers inside the software company have been so enamored with x86-64 that the software giant persuaded Intel to adopt the Hammer language.

One of most avid proponents of x86-64 is the legendary Microsoft programmer responsible for the NT kernel. David Cutler, formerly of DEC, has reportedly voiced inside Microsoft extremely strong preferences for x86-64 over Intel IA- 64. Allegedly, Cutler and Microsoft do not want to expend the extra resources to produce ongoing support of IA-64, an instruction set Cutler and others inside the software giant reportedly disdain as inferior."

Got to:

http://www.vanshardware.com/

Re:David Cutler has reportedly voiced ...

[MtViewGuy]

I think the problem with IA-64 is the fact in order to take advantage of the CPU you have to essentially write every application program from scratch. That is quite expensive, given the costs of development hardware and programming time.

With x86-64, you can jump to 64-bit computing without having to dump your legacy code altogether. With some careful recompiling, just about all Microsoft apps today should run in 64-bit mode on the x86-64 platform fairly quickly.

Also, Linux support for x86-64 has been around for some time. I'm sure that it wouldn't take much to release an x86-64 compliant version of every major Linux commercial distribution within one year anyways.

Besides, the cost of IA-64 hardware is still somewhere in the stratosphere, to say the least.

Re:David Cutler has reportedly voiced ...

[NutscrapeSucks]

Why should MS recompile anything? They can just translate the binary from 32-bit to 64-bit opcodes. That is how they ported 8-bit 8080 BASIC to the 16-bit 8086 after all.

Re:David Cutler has reportedly voiced ...

[spiffy_guy]

It's interesting to speculate that Intel might lose the processor war because Compaq bought DEC.

When DEC folded many of its employees (who really knew their stuff) bailed and went to Microsoft and AMD. The AMD x86-64 movement is run by mostly former DEC Alpha engineers. No suprise that former DEC software engineers at Microsoft prefer the design of former DEC hardaware engineers now at AMD.

I know Intel owns the Alpha technology now, but really that doesn't mean much. They bought the tech after they already had the Itanic at full steam so the Alpha hasn't affected the Itanic much. Besides, by the time they bought the tech all the good chip designers were at AMD. The reason Compaq gave the Alpha the ax is that they had already lost all the good chip designers to AMD.

The IA-64 came straight from the PA-RISC chip designers at HP, with some help from Intel. Nobody defected from HP to Microsoft, so nobody at Microsoft is partial to the Itanic.

Re:64-bit Win XP?

[DrStrangeLoop]

i think a 64bit windows XP would actually crash your machine 2^32 times as hard and fast. ^_^

Re:things i hate about slashdot 1.0

[Anonymous Coward]

You can compile the applications yourself on any distro fucktard.

A bit late?

[DragonWyatt]

This info sounds about 23 days late to me.

Slashdot's queue must be way deep.

Re:A bit late?

[EastCoastSurfer]

Nah, stories only get posted once a "cool" person submits it. I used to submit stuff all the time and get rejected in around an hour. Then, a few days later the same story would be posted submitted by someone else.

A 64 bit architecture...

[Anonymous Coward]

Is first off going to allow me to address a significantly larger main memory which is a good thing (tm) because in the near future I see many people (not average consumers) needing more RAM than the 32 bit x86 architecture can provide.

Second, it allows me to run all of my existing software which is also a good thing... but, will they eventually phaze out the need for 32bit support? I for one hope the 32 bit era is phazed out quickly... that way the extra die space can used for something like more cache.

Once the GCC team has all of the bugs worked out for the Hammer platform I will personall recompile all my apps for the 64 bit architecture (that is when I get a hammer).

I don't know about everyone else, but as soon as these things hit the street, and a good motherboard comes along (first run AMD boards are usually horrible, and I have had first hand experience with them several times ;>) You know, I don't think anyone ever got the slot-a boards just right....

Anyways... just my 2 cents

Now we understand the testimony

[Anonymous Coward]

MS: I'll suck yours if you suck mine first, and I
promise to warn you when I'm ready.

AMD: Ok.

P.S. The IA64 is a threat to MS domminance because
there are already several UNIX variants for it including the latest version of HP-UX. MS has been illegely fighting the HP-Compact merger partly because of this. BTW most attitudes about the merger originate from the MS FUD machine. Collage students are so easy to manipulate!

Most realize that MS is attempting to take over the imbeded market, but what most do not realize is that they realy plan on taking over all Tst& meas. My co is already bending over nicely for them.

Re:Now we understand the testimony

[Anonymous Coward]

Yes.. but are college students easy to manipulate? :)

Re:Fantasitc.

[Anonymous Coward]

How can the first reply to the second post in a story be redundant?

Taco et al need to get off their fat septic arses and track down these rogue moderators and ban _them_ instead of the poor bastards $rtbl'd for modding an interesting comment interesting.

This place makes me vomit.

Mascot

[Enonu]

The mascot for AMD's Hammer needs to be that guy from Scryed.

Re:things i hate about slashdot 1.0

[Anonymous Coward]

i hate the people that take slashdot seriously. This site is a fucking joke where you go to joke aruond and talk shit.

Half the news is pro-linux fud and the rest is etiher just fake or a thinly veiled marketing plot.

Re:Nice. M$ once again stifles innovation ...

[Anonymous Coward]

And I'm sure it has nothing to do with the fact that every man, woman, child and manager on the earth doesn't want to re-purchase every piece of software and hardware they own.

Well, I wouldn't have to ... of course I might have to recompile. Some of those recompiles might have to wait some weeks or months till developers put in some new #ifdef's, but that's really not a big deal if there's some sort of advantage to the new hardware, like cheaper/faster/lower power/easier to write software for. It's probably the shortage of compelling examples of reasons like these that have caused folks to stay away from Itanic, in droves. [snaggletooth] And herds, and flocks, even. [/snaggletooth]

Not the same bits.

[Weasel Boy]

When a graphics processor is 128-bit, it means you can work on 128 pixels at once, basically doing the same thing to each one in parallel. Or, alternatively, 16 pixels at once, operating on an 8-bit color channel, still doing essentially the same operation to each one at the same time, in parallel.

When a CPU is 64- or 128-bit, that means its computational units can crunch on integers 64 bits in size. Roughly speaking, a 32-bit processor can work on integers between 0 and a few billion (2^32 is around 10^9), and a 64-bit processor can work on integers between 0 and a billion billion (2^64 is around 10^18). Think of a pocket calculator with twice as many digits across the display, and you have the right idea. Same old calculator, bigger numbers.

Opteron meaning...?

[doorbot.com]

Anandtech said:
The name is Opteron and although it somewhat reminds us of the pain we went through when the Duron was announced, it's here to stay. The idea behind Opteron is to build off of the Latin root optimus meaning best or if you play with the translation a bit you get optimal unit or flagship.

Well, that's quite a stretch. Wouldn't "Octeron" or "Octalon" be better? That O-P-T doesn't go with the E-R-O-N.

Re:Opteron meaning...?

[Anonymous Coward]

They should have called it the Model One.

Re:things i hate about slashdot 1.0

[Anonymous Coward]

i hate the fake know it alls. The people that just regurgitate the semi-true techno fud crap they read in a karma whore. Most people on this site have no clue whatsoever.

I hate tech support flunkies that try and act like they have a clue, go help the dumb suits format a memo you stupid fucks.

I hate to admit

[nusuth]

...but having owned a first gen. athlon classic on a first generation mobo (using a first gen. AMD chipset), and two first gen. Athlon XPs on a first gen. Tiger S2460 mobo (using a first gen. AMD MP chipset), I recommend you to stay away from anything from AMD before its second incarnation. And that will be 2003H1 for hammers, can you wait that long? BTW in both cases problems were related to the chipset, BIOS and lack of workarounds for discontinued motherboards; all 3 cpus were excellent.

Opteron

[Sivar]

My perception of "Opteron" was being derived from "optical"
For example, using optical chip technology.
I guess that's entirely forgiveable as Intel's "coppermine" implied using copper interconnects.

Re:Opteron

[Konster]

That would be the Opticon, not the Opteron.

Re:Opteron

[_Knots]

"Message from Opticon, news from the fassion bomb..." -- Orgy, Opticon.

This has been a randomness attack.

-Knots

Re:Tenchi

[Anonymous Coward]

no one gives a fuck about your stupid cartoons you dumb fucka.

Re:hmmm .. and yet....

[Anonymous Coward]

hmmm... and yet noone has seemed to put much merit on the idea that AOL/SUN/Oracle/states may conspire in the MS trial... hmmm

I really don't buy some of this

[Glonk]

Much of the stuff mentioned in the article is confirmed and true, but this is a blatant lie to me:
Van's Hardware is reporting that MS is backing x86-64 over Intel's IA-64

Windows XP has been running on IA-64 for ages now, Nvidia's got drivers for it, why would they support x86-64 OVER IA-64? Why not both? It appears they're doing both, and I've seen absolutely nothing to say otherwise.

It wouldn't make any sense for MS not to support both ISAs. It's entirely possible (it's been done already), so why not keep them out there?

I think Van Smith's a little off here. :)

Re:I really don't buy some of this

[morbid]

"why would they support x86-64 OVER IA-64? "

Because if you knew anything aboutr processors, you'd realise that itanic is a turkey.

Re:I really don't buy some of this

[PurpleFloyd]

While MS may support both ISAs, they will almost certainly push one over the other. Perhaps they're looking to the future, and which architecture will work best with their plans a few years down the road.

Re:I really don't buy some of this

[Anonymous Coward]

MS has two considerations here:

1) Which horse(s) can we ride to compete with Sun and IBM in the datacenter?
2) Wouldn't it be nice if we could play someone against Intel for political reasons?

MS heavily backed Alpha, don't forget. I think their ideal situation is 50/50 marketshare between AMD and Intel. But either way, they are stoked because they just got two new chips given to them.

Hmmm. quid pro quo.

[7-Vodka]

Does anyone remember the story earlier this month about AMD CEO testifying in favor of M$? linkSaying all these ridiculous things about how the tech industry would be nowhere w/o M$'s INNOVATION and how making windows modular was impossible and would set the computer industry back 20 years...

Looks like AMD is getting their end of the bargain. Whether windows will even run on intels new chips or not, AMD looks like they have a headstart and the backing of M$.

I suppose I should have expected this. AMD was staking it's whole future on their 64 bit solution support for which might have been iffy. With this they practically guarantee their future, maybe even take the lead from intel. We'll have to see how well prepared intel was with plan B (copying AMD if plan A failed).

Now we can re-do those bill gates phonecalls in the last story and fill in the proper information.

Bill Gates: Hello mr Sanders, I need a favour. How would you like M$ to back amd-64 over intel-64?
Sanders: Ok Bill. What can I do for you?
Bill Gates: We would like you to be our witness in this pesky antitrust trial. What do you think you could say in our support?

Re:Hmmm. quid pro quo.

[Anonymous Coward]

How about:
BG: Hello, Mr. Sanders, this is Bill Gates. Would it be possible for you to be a witness for us in our pending antitrust trial?
S: Why sure Bill I think I can do that.
BG: Great!
S: Hey Bill, while I've got your ear can we talk about some ideas I have about AMD's new processors.
BG: Sure...

Collusion versus Opportunism - it's a fine line.

Re:Hmmm. quid pro quo.

[Anonymous Coward]

the dates of the leaked memos clearly tell us that microsoft has been working with AMD long ago to get xp-64 ready when silicon came out. You don't think they could port a compiler, and then port windows in a matter of weeks? Linux took a couple of months. This announcement was going to come regardless of whether Sanders testified or not. He probably did it for keeping their long term relationships healthy, but definitely not for something as short term as K8 support.

Re:Hmmm. quid pro quo.

[small_dick]

yes. i read that story, too. in return for statements supporting MS in the trial, MS would announce support for AMD64 ahead of intel.

the prosecution was aware of the communications and it's in the court records.

Re:Hmmm. quid pro quo.

[NorthDude]

Looks like AMD is getting their end of the bargain. Whether windows will even run on intels new chips or not, AMD looks like they have a headstart and the backing of M$

Reminds me of 3dFx and nVidia... The day that MS started to back nVidia was the day 3dFx started to disapear... I'm still running with my 3dFx voodoo 2000, very happy with it but I'll have to switch one day... Makes me sad because it was an independant api, not standard I must admit, but was a nice try to competition with directX...

Re:Hmmm. quid pro quo.

[Anonymous Coward]

OK, Microsoft announced IA64 support for Windows something like 5 years before the hardware shipped.

SuSe Linux support was announced back in Feburary, the same time as the davec@microsoft.com memo. Why would MS hold the official announcement until 1 week after Sanders took the stand?

Re:Hmmm. quid pro quo.

[haggar]

I know I'm daydreaming, but I really wish something like this would happen 1 year from now, when the Windows line is ported to x86-64, Itanic is in the ditch and it all can't be reversed anymore:

Prosecutor: So, your support for Microsoft wasn't honest, was it?
AMD: I regret to say, it wasn't. It was a difficult moment for us, our whole future, the very existence of our company depended on Microsoft supporting the x86-64 architecture.
Prosecutor: Damn you, you'll be fined 10.000 $ !!
AMD: er.. poor us.
Prosecutor: I think we can now nail Microsoft

:o)

4-level page tables

[p3d0]

One thing that worries me about x86-64 is the page tables. They're 4 levels deep, and that still only gives a 48-bit address space. They stick with 4k pages. I guess they had to do it for backward compatibility, but to me this is clearly not the best approach.

Though, IA-64 is pretty questionable too. The VLIW aspect is cool, but the compilers are a nightmare. Nobody knows how to write compilers to take advantage of speculative execution, for one thing.

I'm not familiar with any other 64-bit architectures, but surely they're better than both of these?

Re:4-level page tables

[dhovis]

Supposedly the PowerPC spec was written with both 32 and 64 bit processors in mind. I think IBM even uses some 64-bit variants for some of their "big iron".

From what I understand, the 32->64 PPC transition will be seamless, and 32-bit programs will run without a performance hit.

Re:4-level page tables

[anpe]

There's something strange with what you say, as with Pentium you can use 4K or 4M pages.

Re:4-level page tables

[p3d0]

I don't follow. What's your point?

Re:4-level page tables

[anpe]

Maybe I'm missing your point but I've thought that you were regretting that 4K pages were still proposed with the Hammer. That sounded strange to me as I thought that 4M pages were available.

Re:4-level page tables

[p3d0]

They are available, but 4K pages are still supported, which is what requires the 4-level page tables.

Plus, it seems to me that 4M is too big for a lot of work. Having to page out entire 4M chunks every time paging occurs would kill performance. With today's hard drives, the delay to write 4M to disk is still observable by humans.

I have no experience with 4M pages, but it seems to me that they are not a general solution.

This is great news for developers...

[JanusFury]

Using x86-64 is great. It means that people used to coding in 32-bit x86, will be able to easily adapt their codebases to 64-bit, all the while learning about 64-bit coding and preparing their code. Then when the time comes to move to IA64, their code will already be prepared, and they'll have the necessary skills to make it work great on the new platform.

Every time a complete and total change is made, developers have to spend forever re-learning - but take Win32 for example. Win32 was similar enough to Win16, that Win16 developers were able to easily port their code, and then learn how to write good Win32 code. Now they are writing pure Win32 from the start, and they never had a problem, because it was an incremental step up instead of an enormous change all at once.

Re:Nice. M$ once again stifles innovation ...

[mark_space2001]

Well, that may be true, but the article at Van's Hardware says AMD's architecture is actually better:

Our sources also allege that top Microsoft decision makers view x86-64 as the clearly superior solution over IA64, an underperforming VLIW architecture widely judged as Byzantine.

It goes on to point out that AMD has filed more patents in the last 3 years than Intel, and that AMD is widely seen as the true inovator between the two companies.

I can't say what's correct myself, but I think you may be jumping to conclusions.

In the next version of windows

[Anonymous Coward]

Welcome To Microsoft Windows XP.net 2005 SE

! Found linux! Automaticly deleting and using properity linux blocking technology!

Not only 64 bit - Opteron offers 8 new registers!

[Anonymous Coward]

X86-64 defines new integer registers r8-r15.
Less register pressure == much faster software!
This chip is awesome! I can't wait to run Linux
on it!

Intermediate?

[Decimal]

I've come across a lot of people saying that x86 is outdated, but people aren't willing to move to the next level. Isn't there some way to cut out old instructions slowly? Say make some new instructions to replace certain ones and then promote a standard where the software is labeled "exclusive version X support" and those instructions are used instead. Applications could run both at once but those "exclusive" applications could still run once another processor is released supporting the rest of the updates and dropping the rest of the originals. I'm not all that familiar with CPU workings, but tell me, is it possible upgrade a CISC chip line by replacing the codes in two stages?

Re:Intermediate?

[Anonymous Coward]

Dropping even one instruction is going to cause a massive amount of compiler work. I suspect in ten years we will see x86-256 or some other such thing before we see an entirely new instruction set.

Of course the underlying processors are not x86 based processors. They all have a microcode morphing layer, though none are as advanced as transmeta's (though that appears to be a good thing on all accounts seeing as the crusoe's performance sucks ass).

Re:Intermediate?

[Decimal]

Dropping even one instruction is going to cause a massive amount of compiler work. I suspect in ten years we will see x86-256 or some other such thing before we see an entirely new instruction set.

Even when you're placing new ones alongside a redundant one? (Say a 64-bit operation of the same type instead of the 32)

Re:Intermediate?

[johnnyb]

Open-source really helps this issue, because all you applications are just a recompile a way, or asking your vendor to do a recompile.

Re:Intermediate?

[Harbinjer]

I think that this is AMD's goal in the long run. It would seem to be able to work this way. From what I've heard, x86-64 may be able to work efficiently by itlself, without older x86 instructions, so apps compiled for it could be legacy-free. THis is just hearsay, but it seems very logical. If Intel is supporting them, that is, builing its own x86-64 chip, then this could really take off. They could also start shipping x86-64 chips without the x86 instructions in a couple years, along with the ones with legacy support as more expensive versions or something. THey could even emulate the old isntructions once chips get fast enough.

Re:Intermediate?

[Anonymous Coward]

Isn't there some way to cut out old instructions slowly?

Intel is currently trying to do exactly that with the FP stuff in the Pentium 4. They basically legacied the much hated 387 and encourage you to use SSE.

Note that they've been flamed from here to eternity by AMD fans for this decision.

i386 Redhat RPMs for Hammer

[tucay]

I can hardly wait for the Redhat i386 RPMs for Hammer so I can really enjoy its performance.

Re:i386 Redhat RPMs for Hammer

[Anonymous Coward]

Well according to the debian developers "64 bit binaries are actually slower than 32 bit ones, so we won't be making any 64 bit version of our distros".

Re:i386 Redhat RPMs for Hammer

[tucay]

How would they know if the hardware isn't even available to anyone except Microsoft. Do Debian developers have the x86-64 hardware yet?

Re:i386 Redhat RPMs for Hammer

[Anonymous Coward]

No but that doesn't mean they can't get a head start on making excuses...

Re:i386 Redhat RPMs for Hammer

[Anonymous Coward]

Nice joke. They don't even do i686 RPMs

Re:i386 Redhat RPMs for Hammer

[Anonymous Coward]

Sure they do. They are for things that really benefit from it: kernel, C library, etc. They have althlon specific RPMs too.

Re:i386 Redhat RPMs for Hammer

[ksheff]

Maybe it's from their experience with Sparc hardware?

Re:i386 Redhat RPMs for Hammer

[baptiste]

You don't need the hardware. There has been an AMD produced emulator for x86-64 available for some time so people could work on ports. See AMD's x86-64 website. Linux (and/or a BSD variant) got ported to x86-64 some time ago - all without hardware. It was a front page story on Slashdot when it was announced.

Re:i386 Redhat RPMs for Hammer

[Hoser McMoose]

I doubt that Debian would have the hardware yet (though they might), but SuSE probably does. AMD has been teamed up with SuSEE for quite some time in their x86-64 endeavors.

Ohh, and I really HOPE that the original post was supposed to be a joke, though no one seems to have gotten it. i386 binaries for x86-64 architecture? yeah, it'll work, but it won't help you much!

cool

[Anonymous Coward]

you can run word without crashing! you rock! what progress!

How Fast is It?

[4of12]

Given how well AMD designed and executed the K7 (Athlon) my expectations are to see some seriously good performance for their follow-on chip.

But, past performance is no guarantee of future results. Intel's IA-64 is evidence of that.

Does anyone have any idea how fast the K8 will be in real life?

Everywhere I've looked I haven't seen any performance numbers for the Hammer. How does it compare to say, the Power4?

Re:How Fast is It?

[Anonymous Coward]

Does anyone have any idea how fast the K8 will be in real life?

Somewhere in performance between a 6502 and that Japanese super computer announced a few days ago.

Re:Nice. M$ once again stifles innovation ...

[mikefoley]

The Alpha proved that the MARKET is not ready for a non-backwards compatible chip.

It's not what I want, it's not what you want, it's what the MARKET wants. I know. I used to work at DEC/Compaq and API. The market drives technology, not the other way around.

If you read about the architectures, you'll see that when you compare x86, x86-64, IA-64, and Alpha, that -technically-, the Alpha was the best. However, it's applications that call the shots. x86 might not be as "elegant" solution as IA-64, but it allows easy migration to 64-bit computing without the expense of moving to a totally different architecture. It's a low risk solution. You can convince your boss to update your servers to these new fast AMD systems and run your apps as is, then be a hero when you migrate some big database to use 64-bit addressing and memory management without buying a new server!

I fully expect to see Clawhammer-based motherboards and CPU's at around $300 or so LONG before you'll see IA-64 at that price point. That alone will push x86-64 from the ground up.
(And because of architectures like Alpha, Linux will be ready to roll, fully 64-bit) Not to mention laptops running on Clawhammer!

Re:things i hate about slashdot 1.0

[serial frame]

Why did you post anonymously? At least show some spine in your arguments.

Intel's arrogance will be their undoing

[Anonymous Coward]

AMD has clearly trumped Intel today with their x86-64 chip (Opteron?) - and Intel's development is 6 months to a year behind AMD.
Only a few _thousand_ Intel Itanic-based machines have been sold. That's a complete disaster for Intel!
The reason why Microsoft hates the chip so much is due to the fact that it is extremely difficult to write compilers for (freaking impossible if you ask me). Also the Itanic does not lend itself well to JIT compilers (.Net or JVM).
The x86-64 architecture is not revolutionary - it just is the right technology at the right time.

Re:Nice. M$ once again stifles innovation ...

[Anonymous Coward]

... and who are you and what work have you done with x86 instructions to hate it so much... and do you have a reason for hating it so much, other than the usual rant you have heard? Most modern compilers don't even touch the legacy instructions.

Noooooooo!

[Burgundy Advocate]

Dear God! How fucking lame!

Another hacked on extention to the same old architecture that we've been using since the 4004 and 8080 (no, seriously). The basic 8-bit core, the bizarrely segmented registers, the warped-ass extentions, and the CISC instruction set... it all makes me sick. Not to mention that we're still using a fucking BIOS.

Have you ever used something with OpenBoot? It's incredibly nice.

But no, we're still using a system that's basically an overglorified 386DX.

Despite the speed hit, the IA64 architecture was a step in the right direction. A big step. In this case, AMD is going to be setting the industry back.

Re:Noooooooo!

[zapfie]

From a technology standpoint, you're right. From a market standpoint, you're wrong. Backwards compatibility is almost always going to take precendence over new, incompatible technology.

Re:Noooooooo!

[Burgundy Advocate]

Indeed, but for a while there it looked like they were finally going to admit that it's a dead end. I'm just depressed that it looks like x86 is here to stay for years more.

Also, IA64 does x86 compatibility. Just rather awkwardly.

Re:Noooooooo!

[Anonymous Coward]

i <3 u.!!

Re:Noooooooo!

[Anonymous Coward]

When Intel went and developed its 64-bit solution, Intel made it proprietary so AMD had to come up with something else. AMD wasn't big enough to try to come up with its own proprietary solution so it had really no choice but to extend their 32-bit solution to 64-bits. So Intel is both to blame for AMD keeping an outdated technology alive and Intel's woes in having a product that not many want. Intel would have been smarter to co-develop a new processor architecture with AMD, many people will only buy Intel anyway and having AMD along would make their joint solution the only solution. Intel should have been more like Coke or Pepsi and used their reputation to beat AMD at making essentially the same thing.

Re:Noooooooo!

[zapfie]

I will be glad when we move to something other than x86, as well.

Re:Noooooooo!

[Anonymous Coward]

That's another reason I don't like the X-box. Bad enough that the X86 architecture has so much cruft on our PC's, but I'd at least like to support some architecture innovation on a different platform.

Re:Noooooooo!

[banka]

quoted: "Intel should have been more like Coke or Pepsi and used their reputation to beat AMD at making essentially the same thing."

right --- just like how coke keeps its formula secret...

Re:Noooooooo!

[Anonymous Coward]

The core assumption of your argument is that AMD is a bunch of pitiful boneheads, and Intel should pity their pathetic asses and give away all of their technology.

Can Intel also take the credit that x86-64 is going to be much more popular than IA64?

Re:Noooooooo!

[Anonymous Coward]

>Can Intel also take the credit that x86-64 is going to be much more popular than IA64?

Intel should atleast get 1/2 credit, they are the ones that made IA64 so stinky.

Re:Noooooooo!

[Enthrad]

That is the implementation.

Re:Noooooooo!

[NorthDude]

The basic 8-bit core, the bizarrely segmented registers

When I was pursuing my assembly class, I remember a student asked wy it was the way it is... And the prof answered that it was because at the time, 64k ough to be enough...
I quoted the wrong guy in the wrong place, but the speech was the same anyway. Lack of vision or they didn't know at the time what they trully had in their hand?

Re:Noooooooo!

[connorbd]

And what exactly is wrong with a BIOS? Open Firmware is nicer, yes, but at the end of the day you still need something to get up and running.

You're correct about the overglorified 386DX thing, though. That's why there are a large number of /.ers who would wet their pants if a cheap PowerPC mobo went on the market tomorrow.

What bothers me more is this: AMD appears to be on the verge of taking over the standards war from Intel. Fine. It's about time Intel got smacked down by the market instead of the courts. But they're doing it with a hand up from M$... that doesn't bode well for the future, I think.

That said, I won't turn down an Opteron box if I have the opportunity to build one (wouldn't take an Itanic if you paid me though), but I'm running Intel Inside because it cost me $200 when I bought it... moreover, I'm typing this on an iMac.

/Brian

Re:Noooooooo!

[Ars-Fartsica]

Whats the issue? It doesn't look like other vendors get appreciably greater performance out of "cleaner" architectures. Yes the Power4 is faster, but take that off of the list and you'll see AMD and Intel all over the performance charts.

Re:Noooooooo!

[sean23007]

Yes the Power4 is faster, but take that off of the list and you'll see AMD and Intel all over the performance charts.

I don't want to be an ass, but you can say something like that for a lot of things. Sure, Microsoft has a lot of marketshare, but if you take them off the list, it sure makes Linux and BSD seem a lot better...

Do you see what I mean?

Re:Noooooooo!

[mandolin]

But they're doing it with a hand up from M$... that doesn't bode well for the future, I think.

If you visit www.x86-64.org, you'll see AMD's efforts to garner open-source support. AMD is relying on MS for an x86-64 port of windows. It's a make-or-break deal for AMD, it helps them tremendously for MS to "validate" their version of 64-bit x86. Whether this relationship continues in the future remains to be seen, especially if Linux ever fulfills its destiny and makes MS irrelevant. Intel and MS were once favorite bed partners.

Re:Noooooooo!

[Anonymous Coward]

BUY A SUN SYSTEM THEN!!!! Its not like they couldn't use your money. They're only $1000 now, stick Linux on it if you want instead of Solaris.

Re:Noooooooo!

[drinkypoo]

I call bullshit! let's see your dice...

Just treat it like a 64 bit chip. You don't ever have to treat it like anything other than a 64 bit chip, if I understand this pdf correctly.

64 bit mode adds the following features:

• 64 bit virtual addresses
• Register extensions through a new prefix (REX):
  • Adds eight GPRs (That's general purpose registers, folks) (R8-R15)
  • Widens GPRs to 64 bits.
  • Adds eight 128-bit Streaming SIMD Extension (SSE) registers (XMM8-XMM15)
• 64-bit instruction pointer (RIP).
• New RIP-relative data addressing mode.
• Flat address space with single code, data, and stack space.

The PDF also says

The default address size is 64-bits, and the default operand size is 32-bits. These defaults can be overridden on an instruction-by-instruction basis by using a new REX prefix, which has been introduced for specifying 64-bit operand size and for the new registers. The mode is enabled by the operating system on an individual code-segment basis."

So in other words, you can just treat it like 64 bit, all the time. You will never need to use any 32 bit code. But you CAN, which is of course the strength, as you well know, but have chosen to disregard.

If you have not gotten tired of my examples yet:

In 64-bit Mode, General Purpose Registers (GPRs) are extended to 64-bits. The 64-bit registers are called RAX, RBX, RCX, RDX, RDI, RSI, RBP, RSP, RIP and RFLAGS. These new 64-bit registers overlay and extend the existing registers. In addition, eight new 64-bit GPRs are added for a total of 16 GPRS. These new GPRs are called R8 through R15.
The register extensions also add eight new streaming SIMD registers for a total of 16 SIMD registers. These new SIMD registers are called XMM8 through XMM15.
Segment registers (ES, DS, FS, GS and SS) are ignored in 64-bit Mode although code segments still exist in 64-bit Mode. The CS is needed to encapsulate the default mode of the processor (16- , 32- or 64-bit mode) as well as the execution privilege level. As noted above, the D bit and L bit are used to specify the default address and operand sizes. The DPL is used for execution privilege checks. Base and limit fields are ignored.
When performing 32-bit operations and the destination register is a GPR, the 32-bit value will be zero-extended into the full 64-bit GPR. 8-bit and 16-bit operations on GPRs preserve all unwritten upper bits. This preserves the 16- and 32-bit semantics for partial-width results. The final step is to simply define a set of instruction prefixes that specify a 64-bit operand size and allow access to the new registers. This is similar to the method used to extend the x86 architecture for other functionality, such as AMD's 3DNow!(TM) technology. With this strategy, AMD makes it possible for platform suppliers, developers, and other users to use existing toolsets, applications, and knowledge, while providing a smooth migration to 64-bit enabled applications as hardware and software support becomes available.

Still worried?

Re:Noooooooo!

[akuma(x86)]

Do you program in assembly? Does anyone program in assembly anymore? Why should anyone care what the low level addressing modes are?

Modern computer architectural techniques have diminished the importance of instruction sets. Trace caches (P4) and/or pre-decoded instruction caches (Athlon) translate the "cruft" into risc ops.

Go to www.spec.org and look at what the fastest computers are. They happen to be x86 these days.

Re:Noooooooo!

[Anonymous Coward]

The fastest computers are IBM servers with Power4 chips.

Re:Noooooooo!

[homerj79]

Yes, IA64 was a big step, but one that was too big for most companies. Most people weren't too excited about recompiling their software to work as fast as Intel claimed they would. In the case of AMD, their making that step easier for people. Because you don't take a performance hit when running 32-bit software, more people will want to embrace it. And when the time comes to write your software to 64-bit's, you can do so and run it on the same chip. The simple fact is that Hammer makes the transition to 64-bit easier on companies already running 32-bit x86 software without a large performance hit AND allows for a 64-bit upgrade

Re:Noooooooo!

[cheetah]

Ahh someone has seen the power4 spec benchmarks, I am not going to disagree that the power4 is a badass processor but you need to understand how that benchmark was performed. First, you can't buy the configuration that was tested (and you would be stupid if you did) let me explain, power4 chips come in MCM's. Each MCM has four cpu dies, each cpu die has two processor cores. So each MCM has eight cpu's in it, if you are having problems envisioning the MCM think back to the pentium pro it was one module but it had two silicon chips in inside. So each power4 chip has two cpu's it also has 1.5meg(I think this is the right size) of integrated L2 cache. And each MCM has 128meg of high speed L3 cache. So now that you understand how the power4 is normaly sold let me explain how the spec benchmark was performed. They took a standard MCM and disabled three of the Power4 chips and then they disabled one of the two processor cores on the remaining chip. So, they had a single processor power4 with 1.5meg of L2 cache and 128meg of L3 cache. No wonder it has the fastest spec benchmark! Many other processors would recive much higher ratings with half the cache that the power4 had in this test... but as I started out saying at the top of this post the Power4 is a badass cpu. I just don't feel that the spec benckmark was 100% fair( seeing how you can't even get the config that was tested ). And even if you could get it you would be paying for 8 cpu's and getting one...

Re:Noooooooo!

[akuma(x86)]

On FP. On the integer side, they are 2.4GHz Pentium 4s.

Re:Noooooooo!

[Ars-Fartsica]

Your post makes no sense. Look at the top ten best performing CPUs on the market. Now tell me what happened to all of these clean architectures that were supposed to destroy x86.

Re:Noooooooo!

[dasunt]

But obviously, given your convictions, you wouldn't be using an operating system that was derived from something called 'Quick and Dirty Operating System (QDOS)', so why don't you take your *n[i|u]x of choice and use your preferred cpu?

Unless you think that x86 & x86-64 are the best cpus when compared to the competition.

Myself, I'll stick to windows on big fast (very, very warm) athlons as my gaming platform, and linux on older, but fast enough for me, intels for my personal servers. That works out well for me, so I can't bitch.

Re:Noooooooo!

[Yunzil]

Why should anyone care what the low level addressing modes are?

Well, it helps if you're writing a compiler.

Re:Noooooooo!

[cobar]

At one point Alpha stomped all over the Pentium series clock for clock, as did the other architectures. I'm not informed enough to know for sure, but I think that if SGI, Compaq, etc.'s research funding were still there and they were on a .13 micron process, they could still be winning the performance war. I mean, the Alpha was the performance king for a long time without having a new chip come out for 2 years, for crying out loud. If they hadn't killed it, they could be running EV8 Alpha's at 1.5Ghz+ that stomp all over everything.

However with x86-64, you get twice as many registers, so that's got to help one of the x86's performance bottlenecks.

Re:Noooooooo!

[akuma(x86)]

My point was that the majority of developers don't write compilers or anything else that is dependent on knowing the low level details of the instruction set.

I would imagine that the vast majority of developers use either VC++ or gcc when programming in C/C++.

Re:Noooooooo!

[sean23007]

Actually, I was pointing out the fact that your post makes no sense, and the fact that you are unable to recognize that even still. You basically said "Yes, there are things that are better, but if you take them away, look at how great this is!" That doesn't seem to be what you wanted to say, but that is exactly parallel to saying what I said in my post about Microsoft and its competitors. Granted, many may or may not agree that Windows is better, but it is the concept that counts.

And you said nothing about what happened to all those cleaner architectures that you speak of so vaguely, so I see no reason why I should be required to tell you anything about what you care about not nearly enough to speak on. x86 may suck, and there may be better architectures, but your post skirts the subject, and I was merely pointing out a fault in your argument that you missed. There is no need to get embarassed about your mistake, most of us make them, and what is important is that we learn from them. Learn.

Re:Noooooooo!

[Anonymous Coward]

But obviously, given your convictions, you wouldn't be using an operating system that was derived from something called 'Quick and Dirty Operating System (QDOS)'

And what about people who use W2K or XP?

Re:Noooooooo!

[mikefoley]

FWIW, Alpha isn't completely dead. The EV7 systems are being tested right now and by the end of the year, you'll see some amazing numbers. Google EV7 and Alpha and you'll find the specs. It's pretty impressive and will hold HPaq until IA-64 gets out of diapers.

Google EV7+Alpha

Re:Noooooooo!

[TheLink]

If you don't like the old architecture why get fixated on IA-64? Why not Alpha, PowerPC, MIPS, StrongARM etc? I really never understood that. VLIW all you want but the performance must be an order of magnitude better for people to switch, if not they would have switched from x86 to RISC a long time ago. Whereas in practice we've seen x86 actually beat RISC in performance for lots of stuff, and with the x86-64 math things might just get even better.

Humans have stupid blind spots in their eyes amongst other old hacked on extensions. Whereas a lowly octopus doesn't have blind spots. No fear though I figure we can just fix that later when it's cheaper and no trouble to fix and more are ready for it.

Don't get me wrong, I'd have preferred the 68xxx processors to have won (Apple 68k vs Msoft x86), but that's now history.

Cheerio,
Link.

Re:Noooooooo!

[dasunt]

W2K and XP are closely related to Win9x and Win3.11, to the extent of the code being derived and shared between the branches of the MS family. Some of the NT code is new, but I'm guessing a lot of it was modified and reused from the non-NT line.

They might as well call it the Enron

[Anonymous Coward]

But since that name is trademarked, just go with eneron, or opteron or epsilon...

Why doesn't Intel just ....

[binaryDigit]

Pull a M$ and just come out and "embrace" AMD's 64bit technology. The first family of chips will be directly compatable, but then starting with the next wave, they slowly start introducing Intel Only (tm) features and once again force AMD to play catch up. How many people believe that Intel will play in the sandbox with AMD's shovel for a second longer than they have to.

x86-64 assembly rocks! 8 more integer registers

[Anonymous Coward]

Take a look for yourself.

Re:x86-64 assembly rocks! 8 more integer registers

[nusuth]

I remain unconvinced that they will noticably increase performance. It doesn't really matter how many registers are avaliable to the programmer, the only important thing is how many registers are actually used. Athlon cores already have dozens of extra registers utilized by register renaming; making some of them visible will remove them from the renamer's pool. Any possible performance increase is due to compiler's ability to use registers better than CPU but you should not take that for granted, CPU might make better use of those registers when they are internal. After the x86-64 compilers have matured somewhat, we will most probably see a performance increase due to reduced cache/memory load, but don't expect that to be spectecular.

Re:x86-64 assembly rocks! 8 more integer registers

[Anonymous Coward]

All the new registers will be used - don't worry.
The Opteron will kick Itanic's butt without breaking a sweat. The GCC compiler already has a Haifa register scheduler that can take advantage of all extra registers immediately. In fact - it is already working great. In many ways the new CPU is a typical CISC CPU that GCC is well suited to. Download the latest GCC and cross compile code to the x86-64 and see for yourself. It's awesome. Suse (specifically Jan Hubica) did all the porting work. He actually made normal Athlon code faster in the process while changing the i386 backend.

Re:hmmm .. and yet....

[Anonymous Coward]

Thats because everyone here are close minded MS haters. The only thing MS is guilty of is playing the game well. Passing judgment on MS actions is the same as passing judgment on capitalism. I am not saying there is anything wrong with this, pure capitalism pretty much sucks (which is why we are not a purely capitalistic society).

In my mind AOL is far more evil then MS, Sun is just bitter that they aren't MS and Oracle doesn't want a fair fight, they want one that's stacked in their favor.

Re:Nice. M$ once again stifles innovation ...

[purrpurrpussy]

Hmmm... that's half an argument....

What do you suggest replacing it with???? There's always going to be 1 dominant force in any industry. I don't see what other architecture you could replace it with.

Even if you spent gazillions of $$$$$$s to fab something twice as fast for the same price the competition would catch up within 18 months anyway and there's no way your gonna get all those x86 binaries recompiled in time.

The nearest anyone got was Alpha with FX!32 recompling those x86 binaries on the fly. On the other hand how much faster is it now.... (please factor in cost) and where's that chip designer fellow gone... Hmmmmm....

There are many architectures to be chosen from - for now we have a clear winner - hyper pipelined CPUs with a huge instruction decoder chopping up the x86 instruction format. Perhaps stack machines or some kind of programmable logic perhaps logic in memory. 1 thing is clear - it had better be able to keep up with the best x86 CPU whilst running x86 code. It is the dominant binary format.

Matthew

Re:things i hate about slashdot 1.0

[Anonymous Coward]

Why did you log in to post? At least show some spine in your arguments.

Re:things i hate about slashdot 1.0

[Anonymous Coward]

Why do you post with a fake nickname instead of using your real name? At least show some spine in your arguements.

Wasn't there a..

[Steveftoth]

Transformer named Opteron? If there wasn't then that would make a good name for one. He could he Optimus' cousin, and kick Hot Roddie's little butt.

Can anyone comment on 64bit w/ IPv6?

[gatekeep]

Does anyone know how 64bit processors might play into IPv6 conversion?

My thinking here is that with a 64bit data path, the processor would be able to examine IPv6 addresses in one cycle, thus improving performance.. is it reasonable to think that 64 bit processing could make IPv6 faster?

Re:Can anyone comment on 64bit w/ IPv6?

[Anonymous Coward]

Why don't you ask the 1,000s of people already using ipv6 with 64bit processors. Just becuase the ms sheeple are finally getting hurded on to the 64bit wagon doesn't mean the rest of the world hasn't already been using 64bit for ages now.

Re:Can anyone comment on 64bit w/ IPv6?

[orz]

IPv6 addresses are 128 bits, not 64. God knows why.

And I guess theoretically it would speed it up, but I doubt that looking at IP addesses is a limiting factor on performance.

Re:Can anyone comment on 64bit w/ IPv6?

[Anonymous Coward]

Right, the biggest problem with IPv6 is that the protocol overhead is much bigger than IPv4 (unavoidable with the larger addresses) and that it ends up eating some noticeable fraction of bandwidth especially on networks with limited frame sizes, on when transmitting packets with small payloads (telnet being the prime example).

Re:Can anyone comment on 64bit w/ IPv6?

[Anonymous Coward]

"IPv6 addresses are 128 bits, not 64. God knows why. "

Gee, i have no fucking idea why the would ever do that!

Maybe so they don't ever have to worry about running out of addresses again in this lifetime. Duh dumb ass.

Re:Can anyone comment on 64bit w/ IPv6?

[orz]

Um... you do realize that 64 bit IP addresses allow 18,446,744,073,709,551,616 IP addresses? And that each IP address could have many devices on it, since UDP & TCP both add another 16 bits to the source & destination size? That's enough for 500 IPs per person, for 10 billion people per planet for 10 planets per solar system, for 9000 solar systems per galaxy, for 10 galaxies. By the time we come close to running out of 64-bit IP addresses, we'll be more worried about running out of galaxies than some archiac network protocal.
The "reason" why they chose 128-bit IP addresses was so that 64-bit MAC addresses could be used as subnet addresses, slightly simplifying DHCP & the like. Well, they also wanted to have enough bits in the upper portion to make routing simpler. But in they process they double the amount of bandwidth used by small packets, like games.
IPv4 is already kinda bloated, but 128-bit IPs is moreso.

What about PPC?

[ink]

How on Earth did Apple manage the migration from 68k to PowerPC then? I can even run my old 68k applications under _classic_ under OSX.

Re:What about PPC?

[maraist]

How on Earth did Apple manage the migration from 68k to PowerPC then?

Very simple. Lack of competition.. They held a monopoly on ALL OS / motherboards. The only real competition that I'm aware of were the 3'rd parties that sold the various chips / expansion cards.

When you have a vertical monopoly like that, you can coordinate an architectural shift. If Intel decided to start a new CPU line, and it turned out to not provide the best bang-for-the-buck, then AMD/Cyrix competitors could supply legacy and current MS-products a better alternative. Intel would have lost all that money. From the other side, MS is spread so thin that they don't have the time to rework their core to be optimal on multiple platforms (look at the death of NT on any non x86 platform). The lack of a compelling reason for someone to purcase the alternative platform says that MS shouldn't devote too many resources in that direction, which of course kills it off. Hense platform architects are at the mercy of software people, who must provide killer apps for that platform.. If any major killer app isn't immediately available, then a domino effect of lost support will occur; and more importantly, business people understand this a priori.

This is actually a lot more exciting then it might first appear. On the one hand, you have a controlling hand-of-God who enforces their will. So long as they can project a bottom line that benifits their customer, they can make radical changes (shedding virtually all of it's former self). On the other hand, we have multiple independant organizations, who each act in their own best interest. In monopolized environments, changes are swift and clean (but not always in the best interests of everyone). In independent environments, no organization can squander or otherwise take too great a risk. Efficiency is upheld, since only rational decisions can be made (involving the mutual benifit of progress). The side effects are a slowing of evolution, and an accumulation of "useless appendages". On the other hand, it provides an incredible level of trust on everbody's part that the architecture has staying power; that it'll weather the storm of change, instead of flippantly changing with the current mood; throwing 3'rd party interests aside when it's convinient (read Apple's resinding licences over the years).

Personally, I think an architecture that has "grown" over the years is more remarkable then one that simple borrows the best ideas that come out of universities.

Note that I'm not really advocating x86's. I'm just admiring it's successful history. The proliferation of UNIX and the general ability to recompile source could theoretically alleviate a "better" platforms' lack of killer apps, and thus perpetuate a radical acceleration of architectural designs.. Go Linux!!

-Michael

Re:What about PPC?

[Anonymous Coward]

" I can even run my old 68k applications under _classic_ under OSX."

Maybe you were lucky, but there were a large number of Mac apps that didn't survive the transition. Certain users never bought another Mac again after the transition, and Apple's marketshare numbers reflected that.

For a business platform, that's the kiss of death. They have to be 99% compatible.

Re:Hoax

[Anonymous Coward]

Why do i think someone at the "Enquirer" and/or "van's hardware" has a bunch of AMD stock and is getting nervous that AMD is about to lose the battle for the 64bit space?

AMD to produce *more* chips?

[Anonymous Coward]

I understand that AMD can't even meet the demand for the K[67] chips (and hasn't been able to for quite a while now).

a port in 2 hours?

[e40]

2 hours after they got the hardware the memo says they had 64-bit Windows XP running. Sounds fishy to me. I'm sure they had simulators, but they did a perfect port with the simulator? I have trouble believing this.

I think the memo is fake.

how sad

[athlon02]

intel being outclassed with their own architecture... they start something over 20 years ago, drop it to do something new, and end up watching AMD's success or failure on x86-64 to see if they should ride AMD's coat-tails. i love it :)

Re:Nice. M$ once again stifles innovation ...

[rant-mode-on]

• • Microsoft is holding back the industry
  
  And I'm sure it has nothing to do with the fact that every man, woman, child and manager on the earth doesn't want to re-purchase every piece of software and hardware they own.

Yes, you're absolutely right, but Microsoft are masters at getting people to constantly buy upgraded software and hardware. Everytime they release a new OS, you have to get an upgraded firewall, upgraded anti-virus, upgraded system tools etc etc. If you don't want to upgrade your software, don't upgrade the hardware. If you're forced into getting new hardware, stump up for the software.

Or get Linux.

Re:hmmm .. and yet....

[Anonymous Coward]

*cough*54billion*cough*
*cough*chargeoff*cough*

Re:Nice. M$ once again stifles innovation ...

[LordSah]

Just your average computer science senior. I like doing assembly work for something like MIPS, and I don't like doing it in x86. The "usual rant" is that x86 is a very old architechture, with ad-hoc features added every so often to let it keep up. As usual as that rant may be, it's quite true. 8 general purpose registers suck. We can do a lot better nowadays.

The engineer in me doesn't like x86 because it's kludgy, and overly complex (has 4 operating modes of which most folks use 2, for example). Intel and AMD have to waste a lot of silicon that translates x86 instructions into their internal instructions. Seems like it's about time to start using something modern, not built on a legacy ISA.

Admittedly, I haven't done too much assembly work. Perhaps x86 is great. But most of the reading I've done and the system architechture classes I've taken lead me to believe that x86 is just a little too dated.

Success

[Veteran]

When the 8086 processor debuted it was by far an inferior processor to both the Zilog Z8000 and the Motorola 68000. It wound up dominating the market place for several reasons.

1. Software - the 8086 had a leg up on everyone because it had a translator which allowed the thousands of CP/M applications to be ported to it easily. The killer ap at the time was WordStar.

2. The 8086, and in particular the 8088, were less expensive to build machines around.

3. The 68000 and the Z8000 were comparatively elegant and beautiful designs; the 8086 was strong and ugly. Pick Mike Tyson over Cindy Crawford in a fight. Intel was able to turn marketing from a engineering and software beauty contest into a fight - and it came out on top.

Today the shoe is on the other foot.

1. The Opteron does a much better job of running 32 bit aps than either Merced or Mckinley - similar to advantage 1 above.

2. The Amd processor will be a lot less expensive to build for - reason number 2 above.

3. The Intel processor has the beautiful new architecture - the Opteron the good old strong and ugly one.

The only way Intel is going to come out on top this time is to make an even stronger and uglier 64 bit version of the X86; something which looks like a 64 bit version of the current Pentium 4 - ridiculous pipeline for super high clock speeds etc.

Right now things don't look very good for Intel.

Re:Success

[Veteran]

Sorry for the typo - it was supposed to be: an engineering...

At the time that the 8086 came out Intel also produced a 32 bit processor which was going to use Ada as its 'assembly' language. It was a complete and total failure. No one ever bought any to speak of - it was actually slower than an 8080 eight bit machine!

That older 32 bit flop kind of reminds me of Itanium; a grandiose architecture with no performance and no software; other than those minor flaws they are both fine machines. I expect the Itanium to have about the same level of success in the market place as it did.

Re:Success

[drinkypoo]

The only way Intel is going to come out on top this time is to make an even stronger and uglier 64 bit version of the X86; something which looks like a 64 bit version of the current Pentium 4 - ridiculous pipeline for super high clock speeds etc.

I disagree - But what they DO have to do is work out a better compatibility layer. That is not negotiable. You must have 100% compatibility at the hardware level or you are proverbially screwed, blued, and tattooed. Or however that goes.

You're right about the cost thing though. If it's not dramatically better at being a server (which it could be; Anything pushing a lot of data will benefit greatly from 64 bit registers) then it will have NO purpose at all, wither, and die the death of a thousand dogs, amen.

Re:Success

[Anonymous Coward]

I had the feeling it wasn't so much Intel's marketing but rather IBM selling a machine that you could afford which ran *Multiplan* on it - it was the *serious* machine, not like the ornamental Mac/68k combo which you couldn't even *expand*. And it was a damn ugly machine first of all, including the shitty little OS. Yuk.
But hey, it's the numbers! And they have so far outnumbered everything else and probably (by virtue of AMD's cheapo x86-64) will keep doing this for a long time to come - kind of a grassroot revolution. In the end the instruction set doesn't seem to matter to anyone else but the assembler programmers and the hardware aesthetes... . I'm curious how Intel will respond, considering the amount of cash they put into the Itanic (and probably will demand for it).

licensing

[Citizen of Earth]

and that MS has apparently convinced Intel to move to x86-64!

So Intel gets to license the x86-64 instruction architecture from AMD. Har! Har! Revenge is sweet.

Opteron is optional?

[j09824]

The idea behind Opteron is to build off of the Latin root optimus meaning best or if you play with the translation a bit you get optimal unit or flagship.

The first thing that comes to my mind is "optional", which is perhaps not so good for the company holding the second place in the market. Maybe they should have called it the "Superon".

Incidentally, I wonder how many people relalize that "durus" means "hard" in Latin, so "Duron" was kind of suggestive...

Re:Nice. M$ once again stifles innovation ...

[Dr. Awktagon]

Aren't these are the same men, women, and managers (children, managers, whatever ;-) who buy new computers and apps every 1.5 years anyway because their previous computers die of Old Windows Disease/Planned Obsolescence/Lack of Support/etc? They re-buy most of their hardware and software over and over again.

Re:64-bit Win XP?

[archen]

Actually, probably the only difference most users will see will be longer numbers in the blue screen of death.

Does X86-64 do anything at all better?

[zerofoo]

Besides a larger memory address space, does this 64-bit architecture do anything significantly better than the 32-bit stuff out there now?

-ted

Re:Does X86-64 do anything at all better?

[orz]

A little, but not much. It keeps most of the ugly instruction decode of tradition x86, but adds an extra 8 GPRs (accessed via an additional opcode prefix). It also does a few minor other things, like I think it adds IP relative addressing.

Basically, they did what they could to make it better while still using the same hardware to decode instructions. I'd have preferred it if they had a second, simpler decode unit to handle the new stuff so that the overcomplicated x86 decode could eventually be phased out, but it didn't make sense business-wise for them to do so.

Re:Does X86-64 do anything at all better?

[Paul Komarek]

I've been working with Alphas for scientific computation. I'm not really aware that their 64-bitness has helped us in any way besides the huge address space. That said, other aspects of the Alpha are wonderful and glorius.

Actually, there is another benefit to 64 bit cpus: punishing programmers who make *stupid* assumptions about pointers =-).

-Paul Komarek

Re:Does X86-64 do anything at all better?

[dlapine]

The Itaniums we use in the titan linux cluster for NCSA are about 3.5 times faster using 64 bit code than the Pentium III's we use in the platinum cluster. This is despite a 200 MHZ advantage for the PIII's (1000MHZ vs 800MHZ for the Itaniums). This is for the benchmark used in the Top500.org tests, so its conclusions are valid only in the supercomputing realm.

I wouldn't get one for my desktop. Now, AMD's hammer is another story... :)

Because they have versions of linux running in native mode for both the Hammer and Itanium, I would like to see a comparison of speed between the two. I know that the compilers for Hammer will be weak, and I know that the silicon is only A0, but hey, I expect great things from AMD. :)

Re:Does X86-64 do anything at all better?

[David Greene]

More registers.

This will be a big win because the performance curve at the 8 register --> 16 register point is pretty steep.

Of course, all of those x86 compilers tuned for 8 registers will have to have some of their transformation throttles removed. :) This is an important secondary effect of adding registers. Not only is spill code decreased, but the efficacy of compiler transformations such as partial redundancy elimination and function inlining increases because values can live longer in their registers.

Jeez that name..

[distributed.karma]

reminds me of an ornithopter. It's the idea played around by Da Vinci et al. that you could wield mechanical wings and flap around in the sky. Some people tried those things and crushed down pretty badly... just like this fscking processor that's yet another extension to sux86!

Re:64-bit Win XP?

[scot4875]

For "either twice as fast or twice as hard," you'd only need a 33-bit architecture.

For both, you need 34-bit.

"1 bit is to 2 bits" is not the same as "32 bits is to 64 bits."

Using a better analogy, we get a system that crashes 2^32 times as hard/fast, in any combination of the two.

And, for the record, No: I'm not dumb enough to think that a 64-bit processor will be 2^32 times as fast as a 32-bit one.

--Jeremy

Re:Nice. M$ once again stifles innovation ...

[Anonymous Coward]

> cheaper/faster/lower power/easier to write software for

Which the itanic is NOT.

Re:Nice. M$ once again stifles innovation ...

[Kunta Kinte]

It goes on to point out that AMD has filed more patents in the last 3 years than Intel

number of patents filed does not equate to level of innovation.

How many of them were "sideways swing" type patents?

sheesh, this is slashdot, you'd think we could at least agree on that.

Re:Nice. M$ once again stifles innovation ...

[Anonymous Coward]

> The engineer in me doesn't like x86 because it's kludgy, and overly complex (has 4 operating modes of which most folks use 2, for example). Intel and AMD have to waste a lot of silicon that translates x86 instructions into their internal instructions. Seems like it's about time to start using something modern, not built on a legacy ISA.

Yes, but x86 is practical.

> Admittedly, I haven't done too much assembly work. Perhaps x86 is great. But most of the reading I've done and the system architechture classes I've taken lead me to believe that x86 is just a little too dated.

Working with x86-asm is horrible!

The best way to break up a monopoly...

[Anonymous Coward]

...Is to convince another monopoly to 'convince' them (for the slow thinkers here I'm referring to microsoft 'convincing' intel to go with AMD's standard.)

PS Nice to see that slashdot's subscription service is screwed up, NOT a good way to do business. Thats why I'm AC.

Re:things i hate about slashdot 1.0

[Anonymous Coward]

Yeah, but you have to use the -g. You are such an idiot!!

Possible ground for Linux?

[labratuk]

IMHO...

This looks like a good thing for open source software / free software.
When 64bit x86-type chips are common, there is going to be a huge confusion in the Windows world.

"Is this application / that application / this doodad ported to the 64bit arch yet? no? Well we can't move over yet, the performance will suck."

"Why is your department still running on 32bit machines?"
"Because there isn't a new version of legacy application xyz..."

I can just see the massive muddle with windows admins. Whereas, a program with source available, simply recompile. Simple. Should work in most cases."

Of course, this may all become irrelevant if the 32bit backwards compatibility of x86-64 is any good.

Re:Nice. M$ once again stifles innovation ...

[LordSah]

Yes, but x86 is practical.

So is driving your 20 year-old Pinto because you don't want to pay for a new car. Cars have since improved, and if you can afford a better car, then you'd probably get one.

Working with x86-asm is horrible!

My point exactly. Intel put a lot of work into IA-64 to make it superior to what's currently available. Definitely better than x86. That's why I hope that x86 eventually gets canned. If x86-64 takes off as the next "standard", then we'll be stuck writing crappy x86 for another 10 or 15 years.

I have a question

[G00F]

Is it posible to drop the 16 bit and lower, and only have the 32 bit with the new 64 bit?

Oh, and what happens with the bios/cmos and all that, those are all 8 bit arn't they?

I admit I haven;t read up, but I have always wondered about why not just dropping the older stuff and keep maybe 1 or 2 generations of this crap to lesson the lead while making it easier for people with backward compatiabilty.

Why nobody loves me?

[Carly Fiorina]

What is bad with dear Itanium? It got better name?

Re:fp?

[Anonymous Coward]

you forgot camel jockey..

this reminds me of

[i_have_no_name]

the 64bit pci slots.
jeebuz they are huge. and all because of backwards compatibility...

Rumors Rumors..

[Ogerman]

So big bad Intel is going to face even more competition. Boo Hoo. Competition is good. My only concern in all this is that AMD being in bed with M$ will mean they won't be as inclined to say.. help tweak gcc for their new architecture. Intel would be smart to fully embrace the Open Source community at this time.

Idiot ...

[Anonymous Coward]

You have not actually looked at the extension have you? They've actually *CLEANED UP* the instruction set by removing numerous esoteric old instructions that nobody needs to use any more, and re-invests the opcode space into larger register indexing.

Its better -- its better in every way to the previous x86 instruction sets.

We need a new moniker

[kaygee]

Well, it looks like Wintel is no longer sufficient to describe the hardware/software monopoly. With MS throwing their support behind AMD we need a new moniker for the combo. I vote AMDows.....any other suggestions?

"Opteron"?!?

[bbc22405]

"The idea behind Opteron is to build off of the Latin root optimus meaning best or if you play with the translation a bit you get optimal unit or flagship." Wrong root, guys. Here's a quiz. What are the following? Isoptera, Orthoptera, Hemoptera, Heteroptera, Homoptera, Neuroptera, Coleoptera, Lepidoptera, Hymenoptera, Ephemeroptera, Mecoptera, Trichoptera, Diptera, Siphonaptera, Thysanoptera, Paleoptera, Strepsiptera Answer: They are kinds of bugs. Yeah, "Opteron" is a GREAT name for something computer-related.

Re:"Opteron"?!?

[bbc22405]

Apparently, I should have selected "Plain Old Text" instead of HTML Formatted. But shouldn't we judge content, rather than style, especially for my first post?

Re:64-bit Win XP?

[bcjanes]

That, and spyware and viruses will be able to execute twice as fast and compromise your box twice as quickly!

Imagine, if a virus like code red spread around the world in a matter of hours, this could potentially make viruses spread in a matter of minutes, overloading bandwidth and really bringing the internet to it's knees!

Quick, let's set up a subnet so that when these processors running windows hit the market, we'll be ready for the bandwidth overload that is sure to follow when virus writers realize how quickly they can r00t every MS box on the planet!

Unusual for MS

[drinkypoo]

This is actually something of a unique situation, because microsoft rarely enters into a business deal with someone with whom they cannot reasonably compete. For example, the whole Sega Dreamcast evolves into Xbox at the cost of Sega, one of the big three console organizations.

But microsoft can't compete with AMD. It would take them too long to spin up, and they don't know shit about that industry. AMD, on the other hand, could EASILY compete with microsoft, by the simple expedient of hiring some programmers to work on linux, or some other open source operating system. I just used linux as my example to yank your chain. They contribute code, gain cred, and make a whole bunch of crap work beautifully with their equipment.

Won't happen though, because business as usual is good for everybody - Well, if everybody's a big company. It sucks for us, good thing competition isn't going to go away any time too soon. Even if AMD or intel went under, there would still be other CPUs in the world. But anyway, intel and AMD could conceivably swap places - over time, and they are getting closer, you must admit - but it would just end up being AMD vs. intel with AMD in the position of power. We can play musical chairs, but the tune stays the same.

Re:Unusual for MS

[Paul Komarek]

One doesn't compete with Microsoft by hiring programmers. One competes with Microsoft by creating the best Marketing department the world has ever seen. AMD knows nothing about that.

In fact, the only marketing leg-up for GNU/Linux over Windows is the cute Penguin. Everybody loves my Linux Fund credit card, regardless of what they (don't) know about GNU/Linux. =-)

-Paul Komarek

Re:Unusual for MS

[drinkypoo]

Well, taking a page from apple's book, the way to get your system accepted is to make the leaders of tomorrow accept it. Once upon a time, that was college students. Now, it's script kiddies.

Frightening thought, eh?

Intel Wasn't ''Convinced''

[kirn_malinus]

Intel wasn't ''convinced'' to switch, they've been planning it. It's public knowledge that they probably had a team of engineers working on building their own implementation of x86-64 for quite some time now.

Re:Nice. M$ once again stifles innovation ...

[Anonymous Coward]

To continue your analogy, Ford kept modifying the Pinto design and currently sells it as the Mustang. Sure the Pinto sucks, but wouldn't you get the chicks in a 2002 V8 Mustang convertable?

Funny, I just see Itaniums in the lab....

[grimtoothe]

You know, no matter how fat they get the processors or how wide the bus gets, Windows is still going to act like a punch-drunk sow on valium. I slap the Os on a P166 and on a p4-2.2g and boot them - I still have time to get coffee before they're finished booting. What's the point?

Don't LAHF

[XNormal]

LAHF = Load AH with flags

The LAHF instruction loads some of the condition flags into the AH register. The bit positions emulate the flags register of the 8008 processor so LAHF+PUSH AX is equivalent to PUSH A. This instruction was designed to support automatic translation of 8085 code to 8086.

All x86 processors still support this instruction (yes, that includes your latest Pentium)

The devil you know...

[Hoser McMoose]

vs. the devil you don't?

This is sort of what is happening with x86. x86 is a VERY well known entity. All it's ins and outs have been thoroughly explored a thousand times over. If you want to replace it, you should do so with something that you KNOW will be better in every way. IA-64 is almost certainly not it. Actually there are a LOT of people saying that IA-64 sucks worse then x86, and it's starting from scratch. Ditching x86 for IA-64 would be ditching the 20 years of work that hundreds of people have spent getting x86 to be the one of the fastest architectures on the planet (like it or not, right now the IBM Power4 is the ONLY chip out there with more raw processing power then an AthlonXP or P4).

Besides, the weaknesses of x86 have been known for ages and are slowly being worked around. Think SSE/SSEII/3Dnow! to replace that ridiculous stack-based floating point unit? And now with x86-64, not only is AMD extending the architecture to 64-bits, but they're also doubling the number of general purpose registers that can be used, thereby reducing another major weaknesses in x86. So what are we left with? An architecture that has TONS of funding and support, more then 10x as much software as the next closest competitor, compilers that have been optimized VERY well optimized, and to top it off, you can still run 20 year old applications on the thing if you so desire.

And you want to replace this beast? You better have a REAL good alternative lined up! IA-64 just isn't going to cut it!

NOT good news.

[texatut]

After comparing the IA64 to x86-64, it is pretty obvious that IA64 is the superior architecture. Intel actually has a pretty damn good design on their hands, where as AMD is still sticking to the dying, x86 ISA.

Increasing register size/number thereof is NOT the answer. Intels idea of packing multiple instructions into a block is excellent. Predictive instructions? Not in x86-64.

I agree that Intel might be a "big bully," and AMD CPUs certainly perform on par, if not better than Intels, but it REALLY is time for a new architecture.

Re:NOT good news.

[mikefoley]

Intels solution puts a huge responsibility on the compilers to "get it right".

Then again, alot of former Alpha compiler folks are now working for Intel. They are probably the best compiler engineers on the planet.

64-bit PPC

[Anonymous Coward]

Yeah, they exist, and one of the OS's that run on them is IBM's K42, which I think p3d0 has heard of. Right now most of the RISC architectures are clearly superior, PPC and Alpha in particular, but in the future who knows. IA64 is a huge question mark; in a generation or two it could turn out to be a really good thing, particularly if those compiler blokes can get their act together on it.

Re:64-bit PPC

[p3d0]

Who are you?? COWARD!

MS .NET

[makkverk]

If I've understood it correctly: IA-64 and x86-64 are not binary compatible.

If so, then I'm not at all surprised that M$ has decided to create its own version of windows for x86-64.

Programs written in .NET and compiled down to IL-code should run equally well on both platforms.

It would seems that it was a good idea to rip off javas "compile-once-run-everywhere" technology, M$!

{Ø}

I want this architecture to die...

[juggy]

Don't get me wrong- I have an AMD myself and I am quite satisfied with it (though they just could produce a little less heat).
But what I'm afraid of is the way the 64bit-extensions seem to be done: The same way 32bit-extensions came to the x86 architecture - using special opcode/address bytes, nested addressing and such. Anyone who ever implemented an emulator for the x86-Architecture knows what a pain in the ass this is -_-.
I'd really wish for a clean cut: Throw out that old garbage and give me registers, all opcodes should have the same length, a standard address size... If we're going to be extending our old architectures like this forever, we'll finally end up with CPUs spending 80% of their time (OK, maybe a bit less ;) decoding what they're supposed to do!
Now, if I mistook AMDs approach somehow and they found some really great way to keep this backward compatibility without all the crap I mentioned above, I'll take everything back - but that would be just too good to be true...

Re:fp?

[Anonymous Coward]

And that folks, is the reason everyone hates the US.

Dumbass

[Anonymous Coward]

He said CHEVETTE, not CORVETTE. Learn to read and stop bragging about your penis extension.

Name Suggestion

[apt-get]

Don't you think something like "Glorious War Hammer of Alacrity" would be preferable to the tragically generic "Opteron?"

I've needed a 64 bit OS

[hawk]

Well, at least I need 64 bits of addressing space.

One of the bugs I found in Absoft's compiler came when I made an array too large: in a derived type in a copiler of Cray lineage, the resulting array is bit-addressed. I had the physical memory for the array I needed, but couldn't adress it in 32 bits . . .

hawk, who had more memory than any of absoft's test machines at the time

Re:I've needed a 64 bit OS

[Paul Komarek]

Heh, and all this time I thought you were a lawyer! ;-)

We do lot's of big-memory data-mining type stuff, to be somewhat crass about it. Even with byte addressing, 32 bits is too small. Our favorite machine is a Compaq ES-40 Model II, which has 32 dimm sockets. With educational pricing, it starts at a reasonable $20K; with third party memory at about $2K for a 4G kit, you can fill it up at a total cost of $36K.

-Paul Komarek

Re:I've needed a 64 bit OS

[hawk]

I'm a recovering lawyer--next month marks eight years since I've sued anyone.

My new machine still doesn't work (I'll do another round with the vendor tomorrow before sending it back to purchasing as not conforming with the purchase order), but I have 2G, 2 Atlhons, and it ran $5300 or so. It doesn't need to have *all* the power itself; it's sufficient to be fast and check models on multiple processors before sending them to the heavy iron on main campus (either the clusters or one of the SP2's).

I squeaked out a lot of startup money for a small campus, but $20k for a personal machine . . .

:)

hawk

Re:I've needed a 64 bit OS

[Paul Komarek]

I don't even have a personal machine on campus, much less is one of the Alphas I tend one of my personal machines. =-) These machines come from big grants awarded to multiple CS and AstroPhys profs. Myself (and now two others, thankfully) are the sysadmins and chief bottle washers. Sometimes I have enough time left over to do some research using one of the Alphas. ;-)

-Paul Komarek

Re:I've needed a 64 bit OS

[hawk]

There are three machines running *nix on this campus. Two are within arm's reach of me and under my absolute control :)

hawk

Re:I've needed a 64 bit OS

[Paul Komarek]

That's really depressing. If I were to ever visit PSU, I alone would nearly double the total (laptop and iPAQ). ;-)

-Paul Komarek (at CMU)

Re:I've needed a 64 bit OS

[hawk]

Oh, there's rooms with many times this on main campus. There's only 1000-1200 full-time-equivalent students here.

hawk

but why just 8 more?

[hawk]

I was expecting these designs to be register-rich. My favorite 8-bit (the 1802) had 16 GPR's, each 16 bits. The 68000 started with 16.

hawk

Re:but why just 8 more?

[orz]

I said "an extra 8 GPRs", meaning that it now has 16 (there were already 8 GPRs in traditional x86).

Re:but why just 8 more?

[hawk]

yes, but why still so few? I would have expected a total of 32 or 64, to catch up with what competitor's had in the '80's. . . .

hawk

New Architecture

[cd-w]

I see a lot of postings here complaining that it is simply a hack on the old x86 architecture. However, history shows that it really has to be this way to succeed.

Many people will remember when the Alpha and PowerPC were released (at roughly the same time). Both offered a clean new architecture and both could emulate x86 legacy code. Indeed, Windows was also ported to both of these architectures, and yet they still failed to make a dent in the x86 userbase! There are various reasons for this (e.g. high costs, the PREP/CHRP fiaso, lack of native apps, and more) but primarily the "buyer in the street" is not willing to give up any x86 performance regardless of how clean they are told that the underlying architecture.

Therefore, it seems that the only way to succeed is to offer fast native execution of x86 code while providing something new. Initially I was scheptical of the AMD approach, but they have addressed the two main problems with the x86 architecture (lack of registers and 2-bit limitations) yet retained full (and native) backward compatibility and performance.

Re:things i hate about slashdot 1.0

[eno2001]

Lern 2 spel troll.

Re:hmmm .. and yet....

[bfree]

More likely 'cause MS are the proven abusers of a monopoly position. Each of the others are big players but none have the power of Microsft (who are the only people I can think of that they gang up on!).

hmmm

[Anonymous Coward]

A pity no one is showing much interest in the x86-64 port over at FreeBSD. IA-64 is in good shape though. Just how backwards compatible is Hammer? Does that hamper it with overly-complex instruction sets and bottlenecks at all?

Re:Nice. M$ once again stifles innovation ...

[TheLink]

Point is IA-64 is so different Microsoft might as well go PowerPC/Alpha - they did try that out and it didn't pay off. IA-64 isn't really superior to those, and for practical purposes it isn't better than x86 either.

Personally I think x86-64 is the way to go. x86 has improved slightly over the years - the 32 bit stuff isn't as terrible (not great but, erm ok not terrible :) ). AFAIK asm coders write a bit of crappy x86 to switch to the less crappy x86 :). The new x86-64 stuff allow even nicer behaviour. If things go well, the old x86 codes will be vestigial stuff. Evolutionary.

Microsoft is good at knowing what people want and what they will put up with.

Cheerio,
Link.