If I Had a Hammer

adpowers writes: "Anandtech is running an article about their preview of AMD's Hammer. They had one machine running 32-bit Windows and the other running 64-bit Linux. The Linux machine had a 32 bit program and an identical program that was compiled for 64-bit processor support. Both processors were less than 30 days old and running without any crashes, but they weren't at full speed." We did one Hammer story a day or two ago, but there have been several more posted since then (wild guess: the NDA expired). Tom's Hardware has a story, so does Gamespot.

Comments

First Ports

[Anonymous Coward]

Yee-Hah!

Re:First Ports

[Anonymous Coward]

Go choke on a hypermint. The true first post belongs to Jin Wicked

fp

[Anonymous Coward]

I claim first post for Jin Wicked

"If I had a hammer"

[ringbarer]

I'd hammer in a whore's head
I'd hammer in a muslim
I'd hammer all the coons!

REAL Fist Sport!

Re:"If I had a hammer"

[Anonymous Coward]

Can slashdot comment moderators just REMOVE this
kind of comments ?

Re:"If I had a hammer"

[Anonymous Coward]

You're one of those xenophobic british yobs who like to stir up a riot in soccer and rugby games, aren't you?

Re:"If I had a hammer"

[Anonymous Coward]

Hee hee. You don't get it, do ya! If you don't wanna see stuff like dat, then don't browse at (-1).
Now stop whining and suck my mother fucking dick.

Re:"If I had a hammer"

[Anonymous Coward]

I will not go further with you because you are nothing
but an idiot at the top of his splendor.
Now comes the time to study specimens like you.

Oh

[saqmaster]

... I'm sure this will definately 'hammer' down Intel..

boom boom.

RIP Spike Milligan

Slashdot social structure

[Krapangor]

Well, here at our lingustics department we did some inofficial analysis of the social background of the slashdot readers. We did this to test our new language analysis software "Medusa".
As any reader with decent scientific background should know computerized understandig of human language is beyond the capabilities of toways computers. But (and notices that this is a fat, big, huge "but") you can go after phrases.
Modern computers hold more than enough power to analyze the phrases used in a text. Note that such phrase analysis is much more than merely pattern matching (perl/sed/awk won't be sufficient), it needs a rather complicated analysis of reflexion, phoneme search, grammatical style and similar things. The result is that you can get information about the socio-cultural background of the writer of a text. And it's even rather complicated the fool the program because even if you know the algorithms and want to fake a different social background. There are always certain phrases/ grammatical styles which just "skip in" unconciously.

Lets look at some simple examples:

• John Katz's articles: background journalist, white, male, protestant, liberal with some small conservative strains.
• Taco's articles: background software enigneering, however no affections to math, white, male, atheist, (slightly radical) liberal

What were the results of the slashdot analysis ?

• 69 percent adcademic background (abbr.: bg), at least BS/BA degree
• 45 percent computer science or practical computer experience bg
• 16 percent mathematical bg (might include some people with physics bg)
• 7 percent physics bg
• 2 percent rated "professor"
• at UIDs UIDs > 300000 seem to be nearly always replications of accounts below 300000
• comments rated at -1 seem to come at 83 percent from academic bg
• comments rated > 0 to BSD topics have 89 percent academic bg
• comments to YRO come at only 52 percent from academic bg (we are not sure if our program catches all laywers as "academics")

Please note that we could only include comments with enough text (more then 20 words) in our analysis. It also ignores reposts of older comments and non-text comments like "ascii art"
Some results were very surprising though, e.g. we are pretty sure that the user Tollaxor has background in plasma physics. Well, you never know with some people.

Re:Slashdot social structure

[Sarcasm_Orgasm]

I heard Axor was a "hyper" monkey created by cmdrtaco, and then freely released under the terms and condition of the GNU/GPL license. The only thing said to be more frightening then his powers, is the extent at which he'll use them.

Top Reasons to Upgrade to Windows 2000

[RoboTroll]

Here are the top reasons why businesses are moving to Windows 2000 Professional:

#1: Value. The number one reason to move to Windows 2000 Professional is the overall value it offers your business. As this list proves, Windows 2000 Professional can help you reduce costs through improved management and increase productivity through improved reliability and ease of use. For example, analysis conducted at Credit Suisse First Boston predicted that using Windows® 2000 Professional could reduce the firm's directly related IT costs by 15 percent, as well as improve employee productivity by cutting computer-related unproductive time by as much as 41 percent. For more about return on investment, see these reports from Giga Information Group, Inc. and Arthur Andersen .

#2: Reliability. An essential requirement for business users is a personal computer they can count on. That's why Windows 2000 Professional includes fundamental improvementsâ"such as modifications to the operating system core to prevent crashes and the ability for the operating system to repair itselfâ"that make it the most reliable desktop operating system Microsoft has ever produced. On comparative reliability tests conducted by ZD Labs, the average system uptime of Windows 2000 Professional was over 50 times that of Windows 98 and 17 times that of Windows NT Workstation 4.0.

#3: Mobility. Mobile computing is simpler and more efficient with Windows 2000 Professional. This means you can work anywhere, anytime while also saving time and increasing productivity. As described in these news articles, "Finally, a Notebook OS" and "Mobile Users In Love with Win2K" , Windows 2000 Professional offers mobile users key productivity and time-saving features, including the ability to hibernate and restart the system without a reboot and the ability to easily take files and folders offline.

#4: Manageability. Windows 2000 Professional is easier to deploy, manage, and support. Centralized management utilities, troubleshooting tools, and support for self-healing applications all make it simpler for administrators and users to deploy and manage desktop and laptop computers. These improvements pay off in reduced costs, as illustrated by this Eastman Chemical total cost of ownership analysis.

#5: Performance. The advancements made throughout Windows 2000 Professional are accentuated by the operating system's speed. As shown in ZD Labs tests running the most popular business applications, with 64 MB of RAM, Windows 2000 was 32 percent faster than Windows 95 and 27 percent faster than Windows 98. It is also significantly faster than Windows NT 4.0 on configurations with 32 MB of RAM.

#6: Security. Windows 2000 Professional provides comprehensive security features to protect your sensitive business data, both locally on your desktop computer and as it is transmitted over your local area network, phone lines, or the Internet. With its support for Internet-standard security features such as IP Security, Layer 2 Tunneling Protocol, and Virtual Private Networking, Windows 2000 is so secure that banks, such as Credit Suisse First Boston , use it. For some organizations, such as the law firm Dorsey & Whitney LLP, security is a key reason for moving to Windows 2000.

#7: Internet. The familiar user interface of Windows 98 combined with all the capabilities of Internet Explorer 5, makes using the Internet and your local desktop a unified user experience, as described by PC Magazine . This user interface, combined with integrated search capabilities, makes it easier to find and use information locally and on the Web.

#8: Usability. As described in this Windows 2000 Magazine review , Windows 2000 Professional combines the power and security of its predecessor, Windows NT Workstation, with the traditional ease of use of Windows 98. It also provides more wizards, a centralized location for common tasks, and menus that adapt to the way you work.

#9: Data Access. When you use Windows 2000 Professional in conjunction with Windows 2000 Server, you can take advantage of IntelliMirror technologies. By letting you store your important information and desktop settings on a central computer, IntelliMirror lets you work on any computer attached to your network as if you are at your own desk. The centralized management savings made possible by Windows 2000 IntelliMirror technologies are one of the reasons WFofR, Inc. is using Windows 2000 Professional.

#10: Hardware. Windows 2000 Professional lets you take advantage of new hardware devices, such as those with universal serial bus (USB) and IEEE 1394 (Firewire) connections. In addition, support for existing hardware makes Windows 2000 ideal for companies, such as Panasonic , that want to standardize on a single operating system across their organizations.

From the annals of the Troll Library .

In case /. got /.ed

[Adolf Hitroll]

adpowers writes: "Anandtech is running an article about their preview of AMD's Hammer. They had one machine running 32-bit Windows and the other running 64-bit Linux. The Linux machine had a 32 bit program and an identical program that was compiled for 64-bit processor support. Both processors were less than 30 days old and running without any crashes, but they weren't at full speed." We did one Hammer story a day or two ago, but there have been several more posted since then (wild guess: the NDA expired). Tom's Hardware has a story, so does Gamespot.

Re:In case /. got /.ed

[Anonymous Coward]

You and Ralph JewHater Nader need to get together...

Re:In case /. got /.ed

[Adolf Hitroll]

Why ?
Do you think I am gay ?
Shut up you pink-triangle-wearing freudian pikey !

lint

[Anonymous Coward]

what is "dryer lint"? where dose it come from,my clothes? why is it always grey/dark colored then,no matter what I clean?

Re:lint

[Anonymous Coward]

Most likely the hair, skin, dirt, and blood that form nuclei for fibers to cling to.
Hey, you asked!

Two transition periods?

[Mattygfunk]

So it will be a few years until we all have 64-bit PC's with applications written for them. I don't understand why the development work wasn't put into 128-bit processors in the first place. Wouldn't this avoid the next transition period when most applications are written for 64-bit machines?

Maybe I'm over simplifying it.

Re:Two transition periods?

[Ed Avis]

64 bits should be enough for anyone.

No really, I mean it.

Re:Two transition periods?

[XBL]

Umm, first of all it's hard enough to engineer a 64-bit CPU with related components. Then there is the manufactoring details, etc, etc. From that standpoint, it's not economical try to to do a 128 bit CPU now.

Second, there is no point in 128 bit for software right now. We are going to have a hard time even writing software that even requires a 64 bit processor. If we were stuck on 32 bit processors for another 5 years (yet with increasing speed), I really doubt that we would be much futher behind.

I am no expert, but I can't even begin to see the need for 128 bit processors right now. It's better to focus on making the current designs faster.

Re:Two transition periods?

[c2h5oh]

I don't understand why the development work wasn't put into 128-bit processors in the first place. Wouldn't this avoid the next transition period when most applications are written for 64-bit machines?

Excellent point. It seems a shame that we had to have 16 bit processors while we migrated from 8 bits to 32. I mean, really, what was the big deal in quadrupling the data lines instead of doubling.

Re:Two transition periods?

[Anonymous Coward]

As you double the width you increase memory consumption without necessarily also doubling the performance. Going 8 to 16 and 16 to 32 gave you better instruction set maps, going from 32 to 64 didn't offer much more, going to 128 bits is for general purpose processors more costly than beneficial.

For instance: when you switch tasks you have to save old registers. Numerous and huge register spills (as this is called) costs a lot of bandwidth and time and cuts into your latency.

For graphics processors, 128 bit datapaths can make sense, yet 128 bit instructions are enormous, even for VLIW. For microcontrollers 8-bits are still very much in use. For DSPs you also see funny bithlengths such as 24, 48, 56 and 96 bits.

These are common topics in news:alt.arch which nominally is about computer architecture, though usually it does look like computer archaeology. Current topics include PDP10 (almost always), VAX and M68000.

Re:Two transition periods?

[morbid]

128 bits is useful when doing Single Instruction Multiple Data stuff, i.e. in a 128-bit register you can have 2 double-precision (64-bit) floats or 4 single-precision (32-bit) floats. So, if you have two 4-vectors of single-precision floats you can add the elements or multiply them together in a single clock cycle. This is what SSE and SSE2 and AltiVec do. 3DNow! is similar, but with 64-bit registers.

Re:Two transition periods?

[ToLu the Happy Furby]

64 bits should be enough for anyone.

No really, I mean it.

Clever, Ed. For those who don't get it, he's quite right: 64 bits *will* be enough for anyone.

For those still stuck in mid-90's video game wars, "bit-edness" in the real world refers (technically) to the size of your general purpose integer registers, which, for most intents and purposes, refers to how many memory addresses you can easily and quickly address. 32 bit addressing tops out at 4GB, a value which is often too small for e.g. large databases, which thus tend to live on 64-bit big iron machines. (MS has a hack to give x86 processes access to 36 bits of space, but it requires OS intervention.)

64 bits, on the other hand, works out to 16 billion GB. (That's 16 exobytes IIRC.) For reference, that's roughly 40 times as much memory capacity as there currently is DRAM produced (of all types, for all markets) worldwide in a year, at this January's rate.

I don't have the figures on hand for hard drive production, but I would guess as a first approximation that 16 billion GB is not quite equal to the total number of bits of digital storage of all kinds manufactured throughout computing history up until today. (I'd guess it's too small by a factor of 3 or so.)

In other words, it's quite a lot. Presumably computing will have run into some very different paradigm (wherein the bit-edness of the "CPU" is no longer an applicable term) before any computer has a use for >64 bit addressing.

(FWIW, today's 64-bit processors don't offer all 64 bits of data addressing yet, because no one has a need for more than 40-something, so that's what they offer.)

Re:Two transition periods?

[Anonymous Coward]

64 bits should be enough for anyone.

Why was this declared funny by the moderators? It's true. Most of the code out there (even code for existing 64Bit architectures) uses 64Bit (integer) data types almost exclusively to address memory. 32Bits are not enough anymore to address every byte on your hard disk and on high end machines it's not enough to address every byte of RAM.
64Bits give you 4 billion times more address space. Development in the PC sector is fast but it's not that fast.
Since the invention of the PC, RAM size in the average PC has increased by a factor <10000. Hard disk size has increased by a factor of <100000. That's over 20 years development. An increase in address space of factor 4 billion is going to last us a very long time. We might never hit this mark in consumer machines, because there is only so much information humans can deal with. Even if you start archiving HDTV video uncompressed, the storage addressable with 64Bits is enough for 1 million hours.

I'd also like to give a little perspective regarding computation. If a 3D shooter used 64Bit integers, it could still model the complete earth with sub-nanometer precision.

Even if you work with 1/1000 of a cent precision, 64Bits are going to be enough for all financial computations there will ever be.

More than 64Bits does not make sense for a general purpose microprocessor. You are better off with a processor that has multiple 64Bit integer units than a processor that has fewer 128Bit units.

Re:Two transition periods?

[fredrik70]

yes, it might be enough but it's close enough to Bill G famous comment in the 80s regarding memory to be labeled as funny IMHO

Re:Two transition periods?

[mikera]

Sure 128-bits is useful for SIMD, but of course you don't need a 128-bit chip to do this.

A few specialised 128-bit instructions don't come anywhere near having the full 128-bit addressing and general purpose registers that a true 128-bit chip would use.

I'm not convinced we'll ever get to a true 128-bit architecture except for research / novelty value. You won't need a 128-bit address space until long after we've done away with digital computers, and getting more performance will probably come from chaining lots of 16/32/64 bit chips together rather than making a single big one.

Re:Two transition periods?

[akuma(x86)]

Memory density doubles every 18-24 months which means we need an extra address bit every 18-24 months. If 32 bits is required today, then we won't need more than 64 bits for another 48 to 64 years.

I'll be long retired by then. Your grandchildren can deal with it then.

Re:Two transition periods?

[psavo]

Then do tell me why ipv6 haz 128 bitz fer de address?
Zooner or lader ve vill find use fer all of those 64 address lines. Sooner than one would expect, I presume. So really, why not push those barriers 'a lot' further. Why not abandon 'bittedness' altogether?
I'd bet there's some decent research on computing sans bittedness. Even perl does that. Damn, some ancient LISP machine could do that.

Well, hell yes, now that all processors hurl at GHz+, well get more and more interpreted languages, it's just so much simpler.

Re:Two transition periods?

[Saib0t]

I'm no expert in CPUs whatsoever, but I don't think adressable memory is the only issue. There's computation also.

128 bits CPUs would allow for 128 bit operation computations faster than 32 or 64 bit processors, I think. And in fields where extreme precision is important and speed is also important, this might be an issue.

Then again, I'm no expert and Errare humanum est...

Just my 0.02

Re:Two transition periods?

[DrSpin]

In the late '50s/early 60s, when the first mainframes were built, they were all approx 60 bits. Thereafter, all "cost is no object" computers were 60/64 bits. There is not much evidence that anyone will ever want to go further than 64 bits. There are significant overheads to longer words (ever heard of "carry propagation"?).

In fact, the proposed 64 bit processors will pretty much be doing all known processor design techniques on a chip. At that point, we have used all the ideas that were known when the Vax was designed (approx 1980). Since then, nothing much new has been invented. The only missing piece of technology is content addressable memories (ie execute jump table in single cycle instead of stepping though each option and comparing. These have also been known since about 1980, including how to make them. Used as cache tag ram, they would make a HUGE performance improvement. There is no obvious reason for not using them apart from the fact that its a European development (mostly UK and Germany), and America has a problem with NIH.

I dont deny there are special cases where 128 bits (or even 1024) might pay, but to sell, you need a general purpose machine, and 64 bits is the top whack as far as we know. After that, masssively parallel is more cost effective (ICL DAP, etc).

Re:Two transition periods?

[mirko]

Or maybe it would be a good idea to start making good asynchronous systems based on collaborating heterogeneous processors ?

Re:Two transition periods?

[Ed Avis]

If it gets to a point where processors need to do arithmetic on 128-bit IPv6 addresses for a large part of the time, and these operations have to be speed critical, and for some really odd reason you have to store things at an address pointed to by a 128-bit number (which would be an unfeasibly large address space), then yes, 128-bit CPUs might be handy. Until then, any integer quantity anyone wants to handle fits in 64 bits. Floating point is a different matter...

Re:Two transition periods?

[Mike Connell]

No need to wait.

There are already applications that could use > 64 bits of address space. Whilst 16 Exobytes might sound like a BIGNUM for RAM, it isn't that much of a bignum for large scale disk arrays.

At the moment there is an addressing disparity between RAM and storage, but there shouldn't be. Ideally you should be able to memory map everything you need, including the entire filesystem. If you have a FS with 64bit addresses to 512bit blocks, or something larger, you might already need bigger address spaces.

Of course 64 bits sounds like more than we'll ever need, but a bit of imagination is all that's needed to see possible uses of >64bit space today. If you can think about needing to do it now, it's fairly space to say that it will be done in the future.

Modulo one fact: maybe we wont have >64bit addressing. Maybe we'll have XX qubit addressing instead ;-)

0.02, etc.

Re:Two transition periods?

[morbid]

I was only trying to make the point that 128-bits is useful in some niche applications, and it has already been done. I don't disagree with you.

Re:Two transition periods?

[Zathrus]

No, 64-bits is not enough. There were optical storage arrays built nearly 10 years ago that used the full 64-bit address space (yes, it was largely done to prove you could, but there are systems being built now to use the entire 64-bit address space).

One thing to note is that when you have 64-bit addressing, you only get 2^63 worth of storage. Why? Because it's a signed int so you can express a negative offset from current location.

Sure, you can munge it so that your physical storage space isn't represented by a single pointer (most 32-bit OS's do that now, since otherwise you'd be limited to a 2G partition and files), but it's a lot easier on everyone if you just handle it with a large enough pointer.

I'll admit, I'm having a hard time coming up with a real use for a 128-bit integer operation (crypto maybe; perhaps neural networks). Engineering and FP ops are different - they use different registers and the FPU, so talking about more precision isn't relevant here. Of course, I suspect people had a difficult time thinking of a use for 64-bit operations back when we were using 8 or 16 bit general purpose CPUs.

Re:Two transition periods?

[Geek In Training]

I don't have the figures on hand for hard drive production, but I would guess as a first approximation that 16 billion GB is not quite equal to the total number of bits of digital storage of all kinds manufactured throughout computing history up until today. (I'd guess it's too small by a factor of 3 or so.)

Given my own numbers and the rapid acceleration of drive capacties over the past 5 years, I think you're wrong.

I support servers in a Fortune 500 financial services corporation. My rough, low-ball estimates of our current hard disk storage space is 1.4PB (petabytes, of about 1.4 million gigabytes) on desktops, servers, big iron, DASD and SAN. It's probably closer to 2PB... you can't imagine the amount of drivespace a huge corporate enterpise requires. If I have 2PB of data storage in one 30,000 employee US company, that's already one eight-thousandth of the 16EB "worldwide ever" total you're working with.

Think about it, take all the private desktop PCs bought in the past three years; they're probably averaging 15-20 GB per unit in drive space. If there were 70 million PCs sold worldwide in 1999 (found via Google), and we triple that (again, probably low for the last coule of years), 210 millions PCs times 20 GB is 4.2EB, again a quarter of the 16EB you are working with.

Between corporate and private puchases, I'd bet 16EB worth of digital storage has been manufactured and sold in the past 24 months.

Re:Two transition periods?

[foobar104]

(FWIW, today's 64-bit processors don't offer all 64 bits of data addressing yet, because no one has a need for more than 40-something, so that's what they offer.)

That's not true. MIPS R1x000 processors, which I use exclusively at work, support either a 32-bit mode with a 32-bit pointer, or a 64-bit mode with a pointer that is a full 64 bits wide. You can malloc() all day long in 64-bit mode.

Re:Two transition periods?

[foobar104]

Whilst 16 Exobytes might sound like a BIGNUM for RAM, it isn't that much of a bignum for large scale disk arrays.

Actually, it is a very large number for disk arrays.

I'm unaware of a filesystem that can scale as large as XFS; there may be others, though. XFS uses 64-bit addressing, allowing the filesystem to scale to 18 million terabytes (or 18 exabytes, if you prefer). No filesystem in the world has ever remotely approached that size. According to this nifty site, total worldwide disk drive production for the year 2000 only totalled 2.5 million terabytes. So to build a filesystem that's 18 million TB big, you'd have to commandeer all hard drive production, worldwide, for about 12 years.

They estimate that the total amount of data stored on hard drives in the entire world is only about 4 million TB. That means you could theoretically put all the data in the world that is currently stored on hard drives-- all the pr0n, all the MP3s, all the source code, all the PowerPoints, everything-- on one server with one big filesystem, and only use about 1/4 of the filesystem's capacity. Mount it under /earth and set the permissions to 700, please.

Of course, this fact fails to address your basic premise, which seems to be that assigning unique integer addresses to every byte that a computer can access would be a reasonable thing to do.

Even if there were a reason to do such a thing, don't forget that increasing your pointer size decreases your cache efficiency; you can fit twice as many 32-bit pointers in your cache as you can 64-bit pointers, which results in fewer cache misses and overall better performance. (How much better depends on how cache-friendly your task is in the first place, but 32-bit will never be less cache-friendly than 64-bit.)

Re:Two transition periods?

[foobar104]

I was only trying to make the point that 128-bits is useful in some niche applications, and it has already been done.

But you and the other guy are talking about two different things. He's talking about 128-bit addressing, or a chip that uses 128-bit pointers. That would allow you to address 2^128 bits of RAM, which is lots, lots. (2^64 is 18 million TB, I think.)

You're talking about vector registers, which are multiples of your pointer or integer size. A chip could grab four 32-bit values in a single fetch and store them in a 128-bit register, so the chip could work on all four of them without having to go back to cache or main memory for the next value. This is not a new idea, but it's also got nothing to do with 128-bit addressing.

Re:Two transition periods?

[IPFreely]

All true and relevant, However...

Hammer has 40 bits of addressing space (as you mentioned) and 48 bits of virtual space (memory map tables) so it's not quite out of the memory limit woods yet.

64 Bits has other advantages. File and partition sizes can now be extended more easily. File limits of 2 and 4 GB were common before (Linux had this problem until recent patches) Large files are usefull in databases.

One could claim that Scientific calculations are where the true advantages lie. But most complex calculations might not even fit well with 64 (or even 128) bit values (cryptography). Most programs have custom integer/floating point libraries that handle large values, and will likely continue to need these libraries even with 64 or 128 bit CPUs. A jump to 128 bit CPU wouldn't help much here, and wouldn't mean much to the database vendors who are still happily trying to fill up a 64 bit address space.

We're not really ready for 128 yet. Tho only major advantage of 128 would be in data bus size, to move more data into the cache per fetch. Some processors already do this for speed reasons.

Re:Two transition periods?

[psavo]

The point wasn't about handling ipv6 addresses, but about th reason behind choosing 128 bits for _addressing computer interfaces_. There's no much extrapolating in idea that one day a computer will have so much memory that 64bits would not be enough. Yes, it may take many years, but it's still not that far away.
Anyway, there's plenty of use for 128 bit arithmetics, we're just not using things to their full potential.

Re:Two transition periods?

[morbid]

Correct, but a "128-bit processor" doesn't mean one with a 128-bit address bus. Conventionally, when we speak of a processor being x-bit, we are referring to its natural machine word size. The old CDC 6600 was a 60-bit machine, but it had 18-bit addressing, for example.
Hammer is 64-bit, but it only has a theoretical maximum of 48-bit address bus (in hardware), but at first, not all 48-bits will be useable. Yes, the internal address registers will be 64-bits wide, but like in the old days of 68000 Apples (internally 32-bit - all registers - externally 16-bit data bus (cf. 386sx) and 24-bit address bus, the top bits will be ignored by the hardware.

Re:Two transition periods?

[foobar104]

Correct, but a "128-bit processor" doesn't mean one with a 128-bit address bus.

No, it means one with 128-bit-wide pointers. This isn't complicated...

Re:Two transition periods?

[Chris Burke]

One thing to note is that when you have 64-bit addressing, you only get 2^63 worth of storage. Why? Because it's a signed int so you can express a negative offset from current location.

Wrong. Are you perhaps thinking of the offset that is used in address calculation? Or perhaps by your reference to "current location" you are thinking of branch offsets, which are relative to the current IP (or PC, but this is an x86 article)? Regardless, the resulting address is 64 bits, and unsigned. And the base register (as in the instruction "mov rex, [rax +40]") is an unsigned 64 bit integer.

Re:Two transition periods?

[Ed Avis]

I'm not so sure that people will ever need even the full 64 bits, let alone 128 or more. You start getting to the point where every atom in the known universe could have its own video diary and you'd still have used only a fraction of the space.

If you're talking about just a large address space rather than a large memory then it's more reasonable (eg every TCP port on every IPv6 address, that's about 80 bits of space), but there's no pressing reason why the processor itself should have a 128-bit wide memory bus just for that reason. It's just a waste of silicon.

And as for 128-bit *integer* arithmetic: can you give some examples? Certainly there are integer computations going on with more than that accuracy using bignums (often to represent rational numbers as a pair of large integers), but 128 bits won't be enough for those either, you'll still have to use bignums. At best a 128-bit CPU could do those calculations twice as fast as a 64-bit one.

Re:Two transition periods?

[morbid]

It has nothing to do with the size of pointers. It has everything to do with the size of the registers.

How did you get to be posting at +2 with a clue of this size?

http://www3.sk.sympatico.ca/jbayko/cpuAppendA.ht ml #CDC6600

Re:Two transition periods?

[Fulcrum of Evil]

Hammer has 40 bits of addressing space (as you mentioned) and 48 bits of virtual space (memory map tables) so it's not quite out of the memory limit woods yet.

That sounds like an implementation detail; it makes sense to only support 40 address lines when that's a fair bit more than you're likely to see before a process shrink or revision of the architecture. Extra lines cost money, and there's no reason to spend that money if it won't be put to use.

Re:Two transition periods?

[Tackhead]

> I'm not so sure that people will ever need even the full 64 bits, let alone 128 or more. You start getting to the point where every atom in the known universe could have its own video diary and you'd still have used only a fraction of the space.

Step 1: Build a 128-bit CPU.
Step 2: ????^H^H^H^HConvince every atom in the known universe to keep a video diary.
Step 3: Profit!!!!

When do we get funding?

Re:Two transition periods?

[thorsen]

You're not oversimplifying, you're simply wrong :-) I believe the cause for your mistake is that you are listening to marketing guys without realizing it. So, some facts to set the record straight.

The definition of a 64 bit processor is that it has 64 bit adressing - 64 bit pointers. Everything else, 64 bit registers etc - is just the icing on the cake and the things you would expect.

With this in mind, it's easy to see why you're wrong. At this point in time, there does not exist enough memory in the world to fill the 64 bit addressing space. So why on earth would anyone want a larger pointer, when we don't have anything to use it for?

While I'm sure this will change at one point (since 640 kbyte really isn't enough for everyone), it doesn't make sense to build a processor for requirements that might be 20 years away.

And in case you're wondering; the so-called 128 bit processors of today are really only 32 or 64 bit processors, but since we lack the terminology for describing a processor with 64 or 128 bit registors, memory bus width, internal processing capabilities etc., the marketing dudes get away with calling them 128 bit processors.

End of dry definition.

Bo Thorsen,
SuSE Labs.

Re:Two transition periods?

[foobar104]

It has nothing to do with the size of pointers. It has everything to do with the size of the registers. How did you get to be posting at +2 with a clue of this size?

A chip with 64-bit registers can operate either as a 32-bit or 64-bit chip. (Or, presumably, as a 4 or 8 or 16, or whatever.) If the application code was compiled to an ABI that uses a 32-bit pointer, then it executes as 32-bit code; and vice versa. See the MIPS R1x000 architecture for information about this.

The thing that distinguishes 64-bit operation from 32-bit operation is that extra-large pointer, which allows contiguous memory addressing in vast excess of the 2 GB limit of 32-bit code.

A chip with one or more 128-bit-wide registers, like say the PowerPC G4 with AltiVec (the precise model number escapes me), is not, de facto, a 128-bit chip. Likewise, Intel chips with MMX have a number of 64-bit registers, but that doesn't make it a 64-bit chip.

You're simply confusing vector processing (operating atomically on a vector, or array, of values) with 128-bit addressing (using a 128-bit-wide pointer to identify memory addresses).

Re:Two transition periods?

[Anonymous Coward]

Yes, but does the processor have that many real physical address lines? AFAIK most current 64-bit processors don't.

Re:Two transition periods?

[morbid]

I am perfectly aware of what a pointer is for, and what 128-bit addressing means.
You are correct. 64-bit MMX registers do not a 64-bit pentium make, neither does 128-bit AltiVec registers make the G4 a "128-bit" processor.
I could implement 20-bit addressing on an 8086 using 32-bit pointers (segment:offset) which is a 16-bit processor, not a 32-bit or 20-bit one.

Re:Two transition periods?

[IPFreely]

The 40 bit address and 48 bit virtual limits are inherent in the page table mappings. (See the AMD Spec)

I found it dissapointing that these limits were in the design up front without apparent room for expansion (free bits to be used in the future) This means that when they do decide to expand the addressing range, they will have to redisign the page table layout and force OS writers to change their code to use it. It would have been nicer to have expansion room built in to the page table design and simply have the CPU implementation have limited pinouts.

While I'm griping, I'll also mention that the X86-16 (Virtual real mode) support has been dropped when in 64 bit mode. I know that noone uses it much anymore, but there are still old legacy games that I have that run in DOS mode and it would be nice to be able to support them.

Re:Two transition periods?

[Anonymous Coward]

actually, looking back the history, 2^64 bytes will not be enough on desktop in 50 years or so. (almost 32 used now, 32 to go, each takes 1,5 years)

Re:Two transition periods?

[OS24Ever]

There are already applications that could use > 64 bits of address space. Whilst 16 Exobytes might sound like a BIGNUM for RAM, it isn't that much of a bignum for large scale disk arrays.

I hope I'm not the only one looking at that and thinking 'What the hell kind of media besides HDD am I going to back this up on?

I recently purchased two 120GB IDE drives to hold my MP3 collection ripped from my CD collection.

I've been ripping for about 5 days now, and I'm in the C's. (320KB encoding, Athlon 1.33 running RH Linux is doing the ripping, about 8 hrs a day)

I started looking for a backup method besides HDD. Tapes are at best at 110/220GB with SuperDLT. But for home use spending about $5000 for a single tape drive when a hard drive of that size is $200 is out of sight.

Tape tech has GOT to catch up somehow and get down to the cost/MB that HDDs are or we're going to be in an interesting quandary for backing stuff up for DR purposes.

Re:Two transition periods?

[akuma(x86)]

Follow Moore's Law and assume that memory chip density will double every 18 months.

This means that rate of growth of addressable bits is 1 bit per 18 months.

Do the arithmetic and we may see the 64 bit address bit limit getting hit within our lifetimes...assuming that we currently need 40 bits of addressable memory.

Re:Two transition periods?

[Sunthalazar]

Actually I think I would prefer the permissions to be 777, or at least 770 if I was lucky enough to be a part of the earth group. Since I really don't think I'm the user. :)

Re:Two transition periods?

[bhurt]

Actually, assuming Moore's Law (in it's debased form) continues, we can calculate how long it will be before we need to go to 128 bits. The calculation is easy- 18 months of growth for every extra bit.

So to go from 8 bits to 16 bits took a mere 12 years. Say 1966 to 1978. Going from 16 to 32 took a little bit longer- 24 years (1978-2002). Going from 32 to 64 bits will take 48 years- it'll be 2050 before we outgrow 64 bits.

And it'll be 2242 before we outgrow 128 bits, 2626 before we outgrow 256 bits, 3394 before we outgrow 512 bits, etc.

Of course, there are slight physics problems with Moore's law continuing for the next 1,392 years. But that's for a different post...

Re:Two transition periods?

[modecx]

Could you point out the source of information on the optical storage array?

Assuming you are talking CD storage (it's not like we can holographically store data in sugar cubes yet), the number of CDs to store that much is just innane.

Assuming 700MB CDRs (which didn't even exist 10 years ago), you would need about 4.7x10^12 CDs to store all that. Stacked on top of eachother (lets say CDs are about 1mm thick), that's 4.7x10^9 meters of CDs, or 4.7x10^6 KM.

Now, the moon's apogee is about 0.40x10^6 KM.

Realistically, I don't think it's feasible.
The numbers just don't jive.

Re:Two transition periods?

[Peter La Casse]

I hope I'm not the only one looking at that and thinking 'What the hell kind of media besides HDD am I going to back this up on?

Media? More and more, it seems to me that the only practical backup method is to use a geographically remote friend's computer (and let that friend use one of mine.) With incremental backups, the bandwidth use would be minimal, and extra hard drives are plenty cheap. Hm... I think I have that new project that I've been looking for.

Re:Two transition periods?

[Mike Connell]

A few corrections...

So to build a filesystem that's 18 million TB big, you'd have to commandeer all hard drive production, worldwide, for about 12 years.

Isn't true: HDD capacity is growing at (at least) ~60% PER YEAR. Even with the conservative figures here (HD size for 2002 given as 36Gb), that means selling average home user drives of 1.5 Tb in 2010 (starting from 60Gb disks in 2002, you come up with 2.5Tb disks in 2010).

The UCB site manages to grasp that in general, the conceptual failure is to imagine that there is some linearity in information growth. There isn't. Chart anything you like in this area and the graph will be a big sqr(x) type of affair with a scary looking rate of growth at the end. Hold on tight! As the UCB site says "shipments of digital magnetic storage are essentially doubling every year" doubling!

Q. What does every extra bit in an address give you?
A. Double the address space.
Q. How many more bits are there in 64 bit addressing from 32?
A. 32 bits
Q. Which means...?
A. We have 32 years until we're back to where we are today regarding information size vs addressing space.

Oh yeah, 32 years is a real long time. Y2K anyone?

Of course, this fact fails to address your basic premise, which seems to be that assigning unique integer addresses to every byte that a computer can access would be a reasonable thing to do.

I think you misread me. I dont advocate the need to be able to mmap the web; but local devices? Surely. this has been a problem in 32bits for a long time. There's nothing magic about 64bits. It's just bigger. It too will fall.

And your last comment about cache misses! Are you joking? If you need more than 64bits of space it doesn't matter how much better a 64bit address system cache would work because it can't do the job. Even with the "cache misses", a >64bit system is infinitly faster because it will work. If you need the space, you need the space.

0.02

Re:Two transition periods?

[spiro_killglance]

While I'm griping, I'll also mention that the X86-16 (Virtual real mode) support has been dropped when in 64 bit mode. I know that noone uses it much anymore, but there are still old legacy games that I have that run in DOS mode and it would be nice to be able to support them.

Not a problem, boot in legacy mode and Virtual
Real mode is still there. Your old DOS games wouldn't work under a 32 bit OS,let alone a 64 bit one.

Re:Two transition periods?

[Space cowboy]

Buy a petaserver from Sony. You use (say) 10Tb of
cache for the tape robots, and store up to a petabyte of data.

It may not be the fastest fileserver in the world, but nonetheless there are inodes which uniquely identify every file. The filesystem we used was SAM-FS, running on 64-bit solaris.

Simon

Re:Two transition periods?

[Anonymous Coward]

Bill Gates once said that 640k would be enough memory for anyone.

Re:Two transition periods?

[WNight]

Have you checked out r3mix.net yet? It's a good place to start before a big encoding project.

Even if you use 320kbps MP3s, you can't get near CD quality unless you use certain encoders. (Use Lame, don't use AudioCatalyst.) And if you use a good encoder you can probably get all the quality you need at 192VBR.

Whatever you do, use VBR. That way whatever you encode doesn't use the full bandwidth for silence, and doesn't feel limited to that for the complex bits.

You may know all this already, but if you don't you'll be a lot happier to find out in the Cs than the Xs.

Re:Two transition periods?

[Amazing Quantum Man]

The 40 bit address and 48 bit virtual limits are inherent in the page table mappings. (See the AMD Spec [amd.com])
I found it dissapointing that these limits were in the design up front without apparent room for expansion (free bits to be used in the future) This means that when they do decide to expand the addressing range, they will have to redisign the page table layout and force OS writers to change their code to use it. It would have been nicer to have expansion room built in to the page table design and simply have the CPU implementation have limited pinouts.

WTF are you talking about? The page tables clearly show 12 Reserved (MBZ) bits in all page tables. That allows for a full 64-bit paged address space (40+12 = 52 bits, with 12-bits for offset within page = 64).

Re:Two transition periods?

[Anonymous Coward]

"Programming/QA job" means "QA job with delusions of becoming a programmer someday".

Re:Two transition periods?

[Amazing Quantum Man]

Sorry, my bad. You're partially right and I'm partially wrong.

I took a closer look. The architecture goes up to 52-bit VAs. There are 12 "available" bits that OS'en can use. 12 bits are state bits. 12 bits are Reserved(MBZ), leaving 28 bits currently defined for a 40 bit addressing (28 bit page base + 12bit offset). However, when you add in those MBZ bits, you get a 52 bit address (40bit pagebase +12 bit offset).

Re:Two transition periods?

[foobar104]

Buy a petaserver from Sony. You use (say) 10Tb of cache for the tape robots, and store up to a petabyte of data.

A petabyte is only 1024 TB. The sizes we're talking about are about seven orders of magnitude larger than that.

Unless, of course, you have 18,000 Sony Petasites at 1000 TB each.

Do you have 18,000 Petasites?

Re:Two transition periods?

[_ph1ux_]

"all the pr0n, all the MP3s, all the source code, all the PowerPoints, everything-- on one server with one big filesystem"

Isnt that what .NET is for?

Re:Two transition periods?

[AJWM]

At best a 128-bit CPU could do those calculations twice as fast as a 64-bit one.

Uh, four times as fast, actually.

Re:Two transition periods?

[IPFreely]

OK, My turn. It's been a while since I actually read that document (like, over a year) So I refresh.

Figures 17 and 18 (Pg 58, 59).
The virtual address is 48 bits marked as sign extended, not reserved MBZ. I guess they could add a Level 5 page map and go to a 56 bit virtual and a Level 6 page table for 64 bit virtual. Then they could run into the same problem that *Motorola had 68000 -> 68020.

I think this is what I was remembering when I said the OS would have to be rewritten to use more memory.

As for Physical addressing, Figure 13 PTE (p. 51)shows 4kb Pages using 28 bit base pointer with 12 bit offset for total of 40 bit physical. With 12 bits reserved, you could extend that to 52 bit physical.
However, Figure 14 (P. 53) PDE shows the 2MB page directory entry with 19 bit base and 21 offset for 40 total, but with another 9 bits not used. This 40 plus the previously unused 12 to 52. Plus the new unused 9 gets you to 61. Almost there, but only in 2MB page mode.

Once again the OS would have to be rewritten to use more memory.

* 68000 used 24 of 32 bits, ignoring the high bits. Some programmers tried to use them for other things. When 68020 came out and started using those bits, the old code wouldn't run and had to be rewritten.

Re:Two transition periods?

[AJWM]

Where'd you pull those numbers/dates from? Somewhere dark, I imagine.

If we confine the discussion to microprocessors (reasonable, since there were 60-bit mainframes in the 1960s) we don't even start counting until the 8-bit 8008 circa 1972 (although we could start with the 4-bit 4004 in 1971 -- giving a four-bit increase in one year. Oops). (And actually, the picture is more confusing than that -- most of the early 8-bit chips supported 16-bit addressing, although some of them multiplexed the address lines).

If we stick with the Intel line, the (also 8-bit) 8080 appeared in 1974, the 16-bit 8086 in 1978, and the 32-bit 80386 in 1985. At that rate, doubling in bit width roughly every 7 years, Intel is ten years late with its 64-bit chip, and should have already introduced a 128-bit chip.

If we ignore the 8008, we get a width increase of about 2 bits/year, which actually works out closer to the real numbers -- the 64-bit x86 successor appearing circa 2001/2002. At that rate, look for a 128-bit Intel chip circa 2034, or just a few years short of the Unix clock rollover date (but by then we'll all be on 64-bit time).

Re:Two transition periods?

[Anonymous Coward]

Are you from Europe or retarded?

Re:Two transition periods?

[fitten]

Depends on which operation you are performing.

Re:Two transition periods?

[Anonymous Coward]

Have you compared file sizes between your 320KB MP3s and a lossless codec like FLAC? You might be using lossy encoding for no good reason.

Re:Two transition periods?

[Anonymous Coward]

The whole point of Virtual Real Mode is to allow you to run legacy DOS applications under a 32-bit OS, so please don't claim it doesn't work. (In particular, ask the OS/2 guys who had a kick-ass DOS box.)

Admittedly, this really only comes into play if MS ships 64-bit support for Hammer, but DOS application (not game) compatibility is still somewhat important in the business world. I just migrated a company off of "Q&A" - an old DOS database system that they were running on Windows 2000. I've also been known to put PKZIP on a few database servers, for example.

Re:Two transition periods?

[OS24Ever]

Thanks for the link & the suggestion. I'll check it out.

Re:Two transition periods?

[Anonymous Coward]

"210 millions PCs times 20 GB" Times 20GB? What sort of world do you live in where most of the PC's have that kind of storage? We've got close to 400 PC's here and none of them have even 1/5 of that. Even the servers only have 8GB's (two 4G SCSI drives).

Re:Two transition periods?

[WNight]

Perhaps.

I've worked as a programmer before, so I don't know how that fits into your theory.

What the job entails is writing development tools (network simulators, etc), install code, simple UI stuff, and test suites which I then had to execute.

I think the appropriate title for the job is "Junior Whipping Boy" and entails all the annoying stuff that the people with seniority don't want to do.

Re:Two transition periods?

[Geek In Training]

We've got close to 400 PC's here and none of them have even 1/5 of that. Even the servers only have 8GB's (two 4G SCSI drives).


Thank you, Junis in Afghanistan.

We just rolled out (between 2000 and mid-2001) 4000 branch desktops with 733 MHz processors and 20GB hard drives. The corporate standard (new employee PCs) get a 1.6GHz P4 with 20 to 40 gigs of HD, and 256-512 megs of RAM.

Why do you think corporations ask for such big tax incentives and charge so much for goods and services? So that managers who make commission can keep up their income from the IBM sales rep.

Re:Two transition periods?

[Ryan Amos]

Everyone assumes that "Moore's Law" is infallible, where this simply is not true. It's more of a pattern than a law, and it'll come screeching to a halt within the next decade. As soon as we hit 1 atom-wide circuits, that's it, we can't get any smaller. Currently we're about 40 atoms across, though it's hard to 100% accurately count.

Same thing with hard drives. A single atom can't hold more than one charge at once (well, it can, but that's a whole different concept,) and we've gotten pretty small on the hard drives as well. The only way to increase capacity is to increase the number of platters or the diameter (and the diameter is limited as well, I'd hate to see what centrifugal force would do to a 5' wide iron disk spinning at 7200 RPM.. or the amount of power required to spin it)

Of course, there are always quantum computers, holographic storage, etc, so then I could just be totally wrong. But with our current technology, we're close to maxing out. We should probably dedicate more time and effort to these new fields rather than just extending and band-aiding what we already have.

Re:Two transition periods?

[ToLu the Happy Furby]

Between corporate and private puchases, I'd bet 16EB worth of digital storage has been manufactured and sold in the past 24 months.

I quite agree. That's why I said that 16 EB probably within a first approximation (i.e. a factor of 10) of the total number of bits. Then I said it was probably too small by a factor of maybe 3 or so.

I would not be surprised if the total amount of digital storage manufactured in the last 2 years was a third of the total manufactured ever. In fact, if you go by the estimate that the amount of bits manufactured per year increases at a rate of 60% a year, then the amount made in the last 2 years is well over half of the total manufactured ever!

Re:Two transition periods?

[Anonymous Coward]

So in 31 to 40 years we will.

I ReALLY LiKE To LooK aT PoRN. I CaN'T HoLD a JoB aND My WiFE JuST LeFT Me To LiVE WiTH HeR MoTHER.
YoU'VE GoT P0RN!LoL!!!L0L!!" AoL!!! LoLoL
So EaSY To UsE, SPaM, LooK aT PoRN TRaDE WaREZ, DoWNLOAD BRiTNEY SPeARS, CHaT WiTH UNDeRAGE GiRLS, LoOK aT MoRE PoRN, No WoNDER iT'S NuMBER 1!!!Lol!!!

ascii spork

Re:Two transition periods?

[Anonymous Coward]

sheep?

How was the test performed on linux

[knulleke]

Did they have to add "option=nopentium" to the lilo boot parameterlist? :-)

(Seriously though, I hope they haven't left the extended paging bug in)

Re:How was the test performed on linux

[tempmpi]

The extended paging bug wasn't a simple cpu bug, it was a complex bug between CPU, chipset and videocard. Because the Hammer has a very different i/o architecture compared to the current athlon, the parts of the cpu & chipset that caused the bug should be new designs anyway.
AGP seems to be a problem on the first sample as all of the demonstration system were running without AGP videocards.

Re:How was the test performed on linux

[Glock27]

(Seriously though, I hope they haven't left the extended paging bug in)

Since that bug is already fixed on current Athlons, I seriously doubt it'll be a problem with Hammer.

299,792,458 m/s...not just a good idea, its the law!

Re:How was the test performed on linux

[Anonymous Coward]

The extended paging bug wasn't a simple cpu bug, it was a complex bug between CPU, chipset and videocard.

Wrong -- the CPU does not comply with specifications, therefore it is a CPU bug. It is true that the bug will only affect certain configurations. However it is clearly the processor that is at fault.

I have an Athlon 1.0 GhZ myself that I am quite happy with. I have been even more pleased with it since I started using mem=nonpentium. I am a fan of AMD and hope they continue to make superior processors. But I don't spread lies to excuse their errors.

Re:How was the test performed on linux

[Anonymous Coward]

Dumb comment, but if you have a 64-bit CPU, you'd certainly have 64-bit PCI, I'd guess. And at that point, AGP is probably not as necessary - especially on a 'workstation' class machine that would have a fat video card.

For the love of whatever deity you grovel to...

[ringbarer]

DON'T TOUCH IT!!!

Clothes Dryers, by nature of their use of rotational forces, are actually portals to alternate dimensions. The corners of the space-time curve, if you will.

These dimensions have one thing in common. They crave water. So they send legions of nanoscopic creatures through the portal, to absorb the water and return it to their native plane. "Dryer Lint" is the dessicated remains of these creatures.

Upon contact with human flesh, the nano-creatures are absorbed into the bloodstream where they thrive. Unfortunately my research grant ran out before I could determine their purpose, but I presume it is nefarious.

Re:For the love of whatever deity you grovel to...

[Anonymous Coward]

heh

Compiled for 64 Bit...and Programmed for 64 Bit..

[PhrozenF]

There's a lot of difference between 32 bit optimized code compiled for 64 Bit, and code written and optimized for 64 bit and compiled for 64 bit.

Applications need to be programmed and optimized to make use of the extra registers, extra info paths, extra instructions available on the new platform. Without that, the application speeds can't be compared, even though the base code and output is the same.

Let's take the example of some of the 1st. generation playstation II code...which was actually code written for a 32 Bit machines, on a different platform like the PC, or the old PSX, now..pure recompiling won't get you any major performance boost, so all the developers had to "re-do" the code to make use of the 128 bit emotion engine.

Exactly the reason why all these gamedev guys kept screaming it is much harder to code for the PS2 than for other platforms....one part of that whole hing is this...the other part is changing graphics APIs.

PCs is dirextx/opengl....and PS2 can be either custom renderers, or Open GL.

Put it in perspective....why don't 16 bit games re-compiled for 32 bit give a "major" performance boost...unless optimised code is included...??

Si j'avais un marteau - Claude Fran�ois

[Adolf Hitroll]

Sib7 Mib Dom Lab
Si j'avais un marteau
Sib7 Mib Dom Lab
Je cognerai le jour
Sib7 Mib Dom Lab
Je cognerai la nuit
Sib7
J'y mettrai tout mon coeur
Mib
Je bâtirais une ferme
Dom
Une grange et une barrière
Lab Mib
Et j'y mettrais mon père, ma mère
Lab Mib
Mes frères et mes soeurs
Lab Mib Sib7
Ho oh
Mib
Ce serait le bonheur

Si j'avais une cloche
Je sonnerai le jour
Je sonnerai la nuit
J'y mettrais tout mon coeur
Pour le travil à l'aube
Et le soir pour la soupe
J'appelerais mon père, ma mère
Mes frères et mes soeurs
Oh oh
Ce serait le bonheur
Si j'avais une chanson
J'la chanterais le jour
J'la chanterais la nuit
J'y mettrais tout mon coeur
En retournant la terre
Pour alléger nos peines
J'la chanterais à mon père, ma mère
Oh oh
Ce serait le bonheur
Si j'avais un marteau
et si j'avais une cloche
Si j'avais une chanson à chanter
Je s'rais le plus heureux
Je ne voudrais rien d'autre
Qu'un marteau, une cloche et une chanson
Pour l'amour de mon père, ma mère
Mes frères et mes soeurs
Oh oh
Ce serait le bonheur
C'est l'marteau du courage
C'est la cloche de la liberté
Mais la chanson c'est pour mon père, ma mère
Mes frères et mes soeurs
Oh oh
Pour moi c'est le bonheur
C'est ça le vrai bonheur
Si j'avais un marteau
Si j'avais un marteau

The hammer of Islam!

[Anonymous Coward]

If I had a hammer, I'd bash in the heads of all the dirty infidels that I came accross!

Allah ak'bar!

RMS already made up a song about it

[phr2]

RMS made up a song years ago, in anticipation of this processor's release:

If I had a hammer,
I'd throw it in the morning,
I'd throw it in the evening,
All over this land;

I'd throw it at Loki,
I'd throw it at Fen-rir,
I'd throw it at the war between
The Gods and the Giants,
All-ll over this land...

--RMS

There may be another verse or two but I've forgotten. Anyway the headline made me think of this. I always remember these words to the song instead of the regular ones.

Re:RMS already made up a song about it

[RMSIsAnIdiot]

Did he put it to music from his UNIX flute?

They mention the need for plugin AMD compilers

[Inthewire]

The article suggests that AMD write / release native compilers that plug into Visual Studio...which would be a good thing for MS programmers.
Simple enough to say.

I just wanted a lead-in for the following question:
Did anyone else see a banner ad for Visual Studio .NET on Slashdot yesterday? Or was I hallucinating?

Re:They mention the need for plugin AMD compilers

[Anonymous Coward]

visual studio .NET may be the best mono ide there is ;-)

Re:They mention the need for plugin AMD compilers

[Lurks]

The article suggests that AMD write / release native compilers that plug into Visual Studio...which would be a good thing for MS programmers.

I took issue with the author writing that as well. Like it's some trivial task in software engineering to suddenly start writing a compiler which is comparable to what's out there already on the highly competitive x86 platform. (Codeplay does this already of course)

Obviously this isn't what AMD need to do, they need to help people making compilers which support their platform. That's something I'd like to say of my company but it's hard enough work getting AMD to answer E-mail, let alone provide documentation and hardware samples of forthcoming CPUs. You'd think they'd care a bit more since we're the only people in the world making a compiler with vectorizes for 3D Now!, wouldn't you?

By contrast, Intel give us virtually everything we could want in the world short of hard cash. Even though they have a department working on their own (highly competent) compiler, they recognise that wide support of their CPUs is a good thing and they should do everything to encourage it. AMD don't quite appear to have the same attitude at present although we live in hope.

Also, AMD have kind of backed off their proprietary SIMD implementation (3D Now!) with their latest Athlon XPs. The 3D Now! Professional (as far as we can tell), is actually just the old 3D Now! but with SSE as well. An admission of defeat with regards to SIMD software support? One wonders what they're going to do with regards to double float and 128-bit integer SIMD, if anything (Hammer?). Support SSE2 and call it 3D Now! Advanced Server?

Re:They mention the need for plugin AMD compilers

[gmack]

Tom's harware was really off the mark for this one.

So they make a 64 bit plug in for Visual Studio.. great what do you run it on now?

I doubt Windows XP will know to save the other registers on a task switch or be able to address the extra memory without playing page table games. That leaves AMD to come up with a better optimised 32 bit compiler like Intel did? But why the hell would they do that?

Like it or not AMD is stuck waiting for Microsoft for this one but I wouldn't hold my breath.

Re:They mention the need for plugin AMD compilers

[Steveftoth]

Yeah, until MS releases a version of XP that actually runs in 64-bit mode the compiler will be useless. Since until then the processor will run in the 32-bit mode.

Re:They mention the need for plugin AMD compilers

[Anonymous Coward]

Microsoft needs a AMD64 compiler to even create the OS in the first place, no?
(Well, I suppose they could use GCC.)

Re:They mention the need for plugin AMD compilers

[Steveftoth]

No, not really cause the os can just run in 32-bit mode. Yeah, they could just NOT port it to the new arch. They've already proven to the world that they don't really care about 64 bit all that much after pulling support for Alpha and not diverting enough resources to the IA64 project to get it to work as well as the linux port.

RMS' "hammer"

[Anonymous Coward]

Uh, I'm not quite sure that you know what "hammer" RMS is actually singing about?

He is singing about his enormous GNU/COCK and how he considers only gods and entire nations worth of his GNU/COCK attention.

m0d's on cr4ck !? - to the russian front !!!

[Adolf Hitroll]

Hey this is not fscking redundant you pikeys !
It was very original indeed.
You stink.
PS: lameness filter is lame itself, why doesn't it filter itself ???

Re:Compiled for 64 Bit...and Programmed for 64 Bit

[Anonymous Coward]

Not to mention the fact that current IA64 linux distribs
have the userland compiled for 32 bit.

Phobias are IRRATIONAL fears

[ringbarer]

Every white man has recourse to be afraid of the destruction of his race at the hands of the monkey-men.

Fear is nothing to be ashamed of, as long as it never becomes your master. At least I'm doing something about it. Understanding and conquering my fear by targetting the animals before they target me.

What will YOUR excuse be when the apes come knocking?

Re:Phobias are IRRATIONAL fears

[Anonymous Coward]

What you say is nothing more than KKK like stuff.
I still dont know why slashdot moderators dont just
drop that.

Except, given the poor level of Muslim workmanship

[ringbarer]

The head would fall off before you've taken your first swing.

Look at how quickly the Taliban fell. A daisy-cutter over Mecca shall be inevitable.

Re:Compiled for 64 Bit...and Programmed for 64 Bit

[Space cowboy]

Applications need to be programmed and optimized to make use of the extra registers, extra info paths, extra instructions available on the new platform

This is the job of the compiler... If I recompile source code I expect the compiler to optimise the object code in the best way for the target!

Let's take the example of some of the 1st. generation playstation II code...

No, let's not. The PS2 was so radically different from the PS1 (I've coded both) that it amounted to an architecture change, not just a platform upgrade. The PS1 is a pretty much bog standard CPU+VRAM+DRAM device. The PS2 is a dataflow architecture, with the idea being to set up datastreams, (with the code to execute being part of the stream), and to target those streams with a firing-condition model. This is amazingly versatile (and the device has the bus bandwidth and DMA channels to handle it, the PC doesn't) but it is *very* *very* different from the standard way coding is done. This is why PS2 games are still getting better two years down the line...

Exactly the reason why all these gamedev guys kept screaming it is much harder to code for the PS2 than for other platforms

Actually I don't think it's much harder at all, it's just different. You have 3 independent CPU's, all of which are pretty damn fast considering they're only at 300MHz. The device can do (peak) 3 billion (3,000,000,000) general purpose floating point multipliy/accumulates per second, and you can get pretty close to that figure, unlike most peak throughput estimates. Bandwidth again, and the use of an opportunistic programming methodology rather than a logical-progression methodology.

Having said that, I'm from a parallel computing background, so using only 3 CPU's is child's play :-)

Put it in perspective....why don't 16 bit games re-compiled for 32 bit give a "major" performance boost

Because there's a much more quantifiable change in going from 16-bit to 32-bit. Developers had been hacking around the 16-bit limit using 'near' and 'far' pointers (!!), which meant all the cruft from those 16-bit days was still sticking around and causing problems if you just recompiled.

Now they're (at long last!) in the 32-bit arena, there's no such problems. A char* ptr is still a char* ptr, it now just has a greater domain. No cruft. No problems.

This isn't to say that compilers won't get better over time though - optimisation is an inexact science, and you'd hope to see improvements as compiler-writers see how to improve the optimising stage.

Enough...

Simon

Re:Compiled for 64 Bit...and Programmed for 64 Bit

[tempmpi]

There's a lot of difference between 32 bit optimized code compiled for 64 Bit, and code written and optimized for 64 bit and compiled for 64 bit.

That might be true if the only thing that changed were the register,adress space and ALU size, but AMD also removed many flaws of the x86 instruction set. x86 cpus got only 7 registers (EAX,EBX,ECX,EDX,ESI,EDI,EBP) for general purpose use. Other CPUs have much more registers, the lack of registers makes it very hard for compilers or assembler programmers to write efficient code for multiscalar cpus. AMD added more registers. AMD also made a more efficient fpu. You can really get a nice performance boost from these changes with just a rebuild of your software.

Applications need to be programmed and optimized to make use of the extra registers, extra info paths, extra instructions available on the new platform. Without that, the application speeds can't be compared, even though the base code and output is the same.

That isn't true, almost all programms, even games, are now programmed in C(++).(Or something like Java or Perl, but these programms doesn't matter here) The compiler can really use the extra registers/better fpus without any aid from the programmer(OK, maybe a compiler switch). Things like using the "register" keyword in C isn't really needed as good C compilers are better than most programmers at choosing which variables to keep in registers.

You also compared the transition from x86 to x86-64 to the transition for PSX to PS2. That is also something very different. The PS2 is hard to code because the design of the graphic subsystem and vector cpus make it very fast on the one hand but also very hard to use the full potential. The PS2 CPUs also hard to use because the caches are too small.

Put it in perspective....why don't 16 bit games re-compiled for 32 bit give a "major" performance boost...unless optimised code is included...??

When the 386 was introduces things like games were coded in assembler, at least the performance critical parts. Something that is coded in assembler can't be recompiled. Now even games are coded in high level languages.

How quickly the leftists reveal their true nature

[ringbarer]

You'd willingly silence my voice because you disagree with it? That shows more about YOUR latent fascism than it does about mine.

Ask a white farmowner in Zimbabwe which skin tone is the color of racism. Then you'll see what we ALL have to face.

Fascists are sexually repressed homos

[Anonymous Coward]

I suggest you read Wilhelm Reich's "The Mass Psychology of Fascism". All fascism stems fundamentally from sexual repression:

"...suppression of the natural sexuality in the child, particularly of its genital sexuality, makes the child apprehensive, shy, obedient, afraid of authority, "good" and "adjusted" in the authoritarian sense; it paralyses the rebellious forces because any rebellion is laden with anxiety; if produces, by inhibiting sexual curiosity and sexual thinking in the child, a general inhibition of thinking and of critical faculties. In brief, the goal of sexual repression is that of producing an individual who is adjusted to the authoritarian order and who will submit to it in spite of all misery and degradation... The result is fear of freedom, and a conservative, reactionary mentality. Sexual repression aids political reaction, not only through this process which makes the mass individual passive and unpolitical, but also by creating in his structure an interest in actively supporting the authoritarian order."

So, admit your homosexuality and you'll soon be free from the burden of fascist anger.

Re:How quickly the leftists reveal their true natu

[Anonymous Coward]

this is nothing more than the usual McCarthyst
2 cents excuse.

I have only 1 thing to say :

your freedom ends, when mine begins.

You speech is free since it doesnt hurt me for
ethnic/religous reason.

Ausser Thema ???

[Anonymous Coward]

Ich antworte an einem Geschicht die heisst "If I had a Hammer" mit die Lyrics von ein bekannter Franzosiche Lied der Heisst "Si j'avais un marteau."

If I had a hammer I will knock the day I will knock the night I will put at it all my heart I would build a farm a barn and a barrier And I would put my father at it, my mother My brothers and my sisters Ho oh It would be happiness **time-out** if I have a bell I sound the day I sound the night I with put all my heart For the work at dawn And the evening for the soup I appelerais my father, my mother My brother and my sister Oh oh It be the happiness If I have a song I it sing the day I it sing the night I with put all my heart In turn over the ground To reduce our sorrow I it sing with my father, my mother Oh oh It be the happiness If I have a hammer and if I have a bell If I have a song to sing I himself ray the more happy I want nothing mother My brothers and my sisters Oh oh It would be happiness It is the hammer of courage It is the bell of freedom But the song it is for my father, my mother My brothers and my sisters Oh oh For me it is happiness It is that true happiness If I had a hammer If I had a hammer

Nah, jetzt, du muss diese Schwein-untenMensch von Moderator nach Paris schicken sonst bist du ein Zigeuner !!!

Garbage deconstructed and counterproved

[Anonymous Coward]

>I am no expert, but
Man, yes I can tell. So why you feel compelled to write this stuff and then get modded up to 4 is beyond me.

First of all you have the classic Umm, first of all it's hard enough to engineer a 64-bit CPU with related components. Face it, the 4Stack was made by one grad student.

Then you have the audacity to continue with the equally intellectual Then there is the manufactoring details, etc, etc. Guess what, manufacturing does not care about bitwidth. They care about layers, metallisation and more. Only inasfar as bitwidth requiring more interconnection which usually requires more metal layers does this have any impact.

Then finishing off with a perceived lack of economic benefit you truly complete the works of the terminally uninformed.

Yes, for GP CPU 32 and 64 bits are ok, for graphics, DSP and number crunching 128 bits can be required. And guess what, Cray has made 128 bit computers. I have rarely had the displeasure of reading such a pile of uninformed garbage. Even 5 minutes on Google would have shown it clearly even to someone who has not been involved in both design AND fabriction AND register level programming for 14 years.

Oh yes, as for the difficulties of programming 64 bit processors, have you heard of Linux? You have even failed to notice Linux has been ported to Itanium, SPARC and Hammer. Well done.

Fascist ??? Me ???

[Anonymous Coward]

Ig Bi Nö Faszist,
My comrade Benito was but this was soooooo l4m3
he was hung like a Schwein in a Metzgerei !

Semper fi

[Anonymous Coward]

I spent thirty-three years and four months in active service in the country's most agile military force, the marines.

I served in all ranks from second lieutenant to major general. And during that period I spent most of my time being a high-class muscle man for Big Business, for Wall Street and the bankers. In short, I was a racketeer, a gangster for capitalism.

I suspected I was just a part of a racket at the time. Now I am sure of it. Like all members of the military profession I never had an original thought until I left the service. My mental faculties remained in suspended animation while I obeyed the orders of the higher-ups.

This is typical with everyone in the military service. Thus I helped make Mexico, and especially Tampico, safe for American oil interests in 1914. I helped make Haiti and Cuba a decent place for the National City Bank boys to collect revenue in. I helped in the raping of half-a-dozen Central American republics for the benefit of Wall Street. He record for racketeering is long. I helped purify Nicaragua for the international banking house of Brown Brothers and Co. in 1909-1912. I brought light to the Dominican Republic for the sugar interests in 1916. I helped make Honduras "right" for American fruit companies in 1903. In China in 1927 I helped to see to it that Standard Oil went its way unmolested.

During those years, I had, as the boys in the back room would say, a swell rack. I was rewarded with honors, medals, and promotion. Looking back on it, I feel that I might have given Al Capone a few hints. The best he could do was to operate a racket in three city districts. The Marines operated on three continents.

General Smedley Butler (U.S. Marine Corps major general and commandant), Common Sense

Gay bashing is an integral part of capitalism

[Anonymous Coward]

Gays are not oppressed on a whim, but because of the specific need of capitalism for the nuclear family. The nuclear family, as the primary - and inexpensive - provider and carer for the workforce, fulfilled in the nineteenth century and still fulfills an important need for capitalism. Alternative sexualities represent a threat to the family model because they provide an alternative role model for people. Gays are going to be in the front line of attack whenever capitalism wants to reinforce family values.

Added to Troll Library

[Anonymous Coward]

Dear Troll,

We are plesed to inform you that, after careful consideration, we have accepted your troll into the Troll Library.

You show a masterful skill at trolling.

Thank you for your time and your contribution.

Riots?

[Anonymous Coward]

There has never been a riot at a rugby game (at least not by the spectators) that I have ever heard about.

Rugby is a very different mindset to soccer. Rugby attracts better educated middle and upper-class types where as soccer is generally the favoured game of the working-class yob - thus the riots.

The riots are just on-field in Rugby..

[DABANSHEE]

...with both the 'Union' & 'League' varieties.

Soccer fans riot because of the lack of violence in the actual game.

No need for 128 bit cpu in the forseeable future

[Anonymous Coward]

The reason for the transition from 32 to 64 bit cpu's is commercial: you need the extra address space for database useage and with 32 bits there is a practical limit of about 100K hits per minute on a (imagine a pipe this big!) I was told this by an IBM executive ~5 years ago. It's all about address space and internal bandwidth to run gigantic websites with a minimum of hardware. (There are a few number crunchers who will also find this useful, but the market for webservers is the justification for the $500M investment to bring a machine into production-half of that, or nore, is cpu design, validation and cost to bring to the threshhold of production.)

Re:Compiled for 64 Bit...and Programmed for 64 Bit

[thorsen]

You're wrong in this.

I have been working for SuSE on porting gcc and binutils for x86-64 for over a year now, and it has been pretty painless. After we had the basic system running, I ported a fullblown but small linux system to it (sysvinit, linux-utils, vim etc.) and the only thing I had to do was to make configure scripts grok the x86_64-unknown-linux architecture.

If you take a look at the design papers on x86-64.org or amd.com, you will find that the architecture is very easy to port to. It's basically an athlon with 64 bit adressing modes on top (very simplified way of looking at it). What AMD has done is to do the exact same transition that Intel did from i286 to i386 - 16 to 32 bit.

The new architecture is impressively easy to handle, and gcc can by now optimize almost as good for x86-64 as for i386. It's really just a matter of recompiling.

And if you don't want to do that, run the 32 bit binary. The x86-64 architecture includes running i386 binaries at native speed. This is no marketing crap, it really is the same as you would expect from an athlon.

Of course, if your application has assembler in it, you have to port this. But take a look at the docs again, and you'll feel very much at home there. Actually the extra registers will give you a warm fuzzy feeling inside :-) But my point here is that there is no change in the way you think - no change in the coding philosophy.

I appreciate your point, because for a lot of platform it would be true. But on this one it simply isn't.

Bo Thorsen,
SuSE Labs.

Re:Compiled for 64 Bit...and Programmed for 64 Bit

[Glock27]

Applications need to be programmed and optimized to make use of the extra registers, extra info paths, extra instructions available on the new platform.

Obviously you're not aware of how the Athlon works, among other things.

Internally, it has many more registers than four. x86 instructions only reference four registers, but internally the Athlon uses it's full set to speed up the code, as well as exploiting several types of parallelism.

For higher level languages, it is even less of an issue. There may be some impact on my Java code as to whether "int" or "long" has faster operations, but I'll guarantee that all my code using "double" will fly. The best part is that I won't even have to recompile! =)

The other thing I'll gain is that all of my dynamic allocations will have much larger memory limits. The virtual memory limit per process for the first Linux port to Hammer is 511 GB.

299,792,458 m/s...not just a good idea, its the law!

Bzzt!

[Anonymous Coward]

Yes, the athlon has shadow registers, but that doesn't obviate the need for more physical registers.. The shadow registers are used to enable superscalar execution.. when a program needs to deal with more variables then registers are available they still need to spill data onto the stack (into ram) which is AMAZINGLY slow. If you have code that executes a tight loop on more data points then are available on stock x86 but less then whats available on x86-64, the speedup is very impressive.. I've seen maths codes execute with a 50 fold performance improvement after being recompiled for x86-64 on my reference box.

Re:Bzzt!

[Glock27]

Yes, the athlon has shadow registers, but that doesn't obviate the need for more physical registers.. The shadow registers are used to enable superscalar execution..

Yes, the Athlon extracts parallelism from the incoming instruction stream.

The point is simply that there is more than one way to skin a cat. No one ever would have thought that x86 would scale so well or be so competitive with RISC. (Alpha was/is great, and I'll never understand why DEC/Compaq dropped the ball so badly there...)

when a program needs to deal with more variables then registers are available they still need to spill data onto the stack (into ram) which is AMAZINGLY slow.

Don't you mean L1 cache?

Your reference box, eh? Since you're breaking your NDA just to tell us you have one (I presume), why don't you enlighten us as to the clock speed on that puppy? ;-)

Regardless, a 50-fold improvement in calculation speed is unlikely to be the result of additional registers... It would more likely be the SIMD type instructions, which use additional registers even in IA32.

299,792,458 m/s...not just a good idea, its the law!

"AMD Touts Linux Support for New Chips"

[Anonymous Coward]

AMD has thrown its full weight behind Linux, according to "AMD Touts Linux Support for News Chips". Specifically, AMD supports efforts by SuSE to create updates of Linux for the x86-64.

Sun has taken a different approach of creating its own version of Linux for x86-64. This smells of hijacking (Linux).

Atomic scale circuits

[Mike Greaves]

"slight physics problems" is right; and how!

I'm very doubtful that 128-bit machines will *ever* be built; though only a fool would say they definitely won't be built, this early in the game.

32-bit CPU's still take large chunks of silicon, and their features are approaching 1E-7 meters in size. 64-bit machines will not be severely limited until they are trying to manage about 10 orders of magnitude (1E10 times - well over 2^32 times) more circuit elements. If circuits are still basically planar in physical layout, this implies circuit features approaching 1E-12 meters (1E-7 / sqrt( 1E10 ))...

Since silicon atoms are roughly 2.5E-10 meters across, there might be a slight problem with building circuit features this small. ;-)

Put another way, the realistic limit for further process shrink is about 2 more orders of magnitude (the circuits would be just a few atoms across) - only 4 more orders of magnitude in total number of circuit elements, not 10.

So I really have a hard time seeing how a computer built with *chips*, that is smaller than a skyscraper, would ever need more than 64 address bits.

Re:Atomic scale circuits

[maraist]

Other's have mentioned this, but I'll say it anyway. 64bit addressing has no limitations except for the physical number of pins comming out of the CPU; and that can be overcome by simply serializing 2 x 32. As for caching (which other's have brought up), obviously a given architecture would have to use segmented regions (say of 4 Gig max cachable, etc). The main advantage of full 64bit addressing would be proprietary motherboard / PCI cards that allow NUMA style memory architecture's etc. It's not that a full 64bits are needed, but that an arbitrary memory segmentation might be desired where the high bits divide the different nodes, etc.

Further, 64bit nubmers are -extremely- common for database architectures (primarily as ID's or what-have-you).. Hell, we're seeing a lot of 128bit numbers already, and 32bit architectres have to resort to slow big-num algorithms. This sort of operation requires 64bit INTs as opposed to void*'s but the two typically coincide within a given CPU.

-Michael

If all i had was a hammer

[Anonymous Coward]

every problem would look like a nail.

Code is often optimized/biased towards arch.

[AHumbleOpinion]

If I recompile source code I expect the compiler to optimise the object code in the best way for the target!

Your expectation and what happens in reality are two very different things. It is entirely possible to write high level code that is optimized, perhaps biased would be a better term, towards one architecture at the expense of another.

Much of this is unintentional. A problem can often be solved in many ways and sometimes a programmer tries out a couple of different solutions and picks the better performing one. Consider a 4x4 matrix multiply. One solution directly accesses array elements in memory, another preloads part of the array into temporary variables, one solution runs better on x86, the other tends to run better on RISC based systems.

They way you solve a problem in high level code is often effectively "hinting" to the compiler on how to generate code. We are still waiting for the mythical compiler that optimizes code in the "best way for the target".

AMD announces Suse Linux support

[pointwood]

Quote:
AMD (NYSE: AMD) today announced that SuSE Linux AG, one of the world's leading providers of the Linux operating system, has submitted enhancements to the official Linux kernel.

Read the rest here: http://www.amdzone.com/releaseview.cfm?ReleaseID=8 10

Different design decision wishes

[AZPhysics]

The Hammer has 8 32/64 bit shared registers, and 8 more 64 bit only registers. What if they had 8 32-bit registers and then 16 more 64 bit registers? This would provide more registers, and thus more speed. I imagine that it would be tougher to implement, but I think it would lay a better foundation. Anyone have any insights on this? Also, how do these registers differ from the ones added by the 3DNow/SSE instruction sets?

Also, I would imagine some 64 bit extentions have been added to the regular x86 instructions. For example, a 64 bit move instead of the typical 32 bit move, ect... Does anyone know whether there are any different instructions that make use of the 64 bits? Is there any way to link 32 bit data with a 32 bit instruction, ala Itanic?

What really will kick butt is the overall performance of the system with Hypertransport, the built in DDR controller, and the multiprocessing. I know I'm planning on building a 2-processor Clawhammer system at the end of 2003!

Re:Different design decision wishes

[SK-null]

x86-64 has 16 64bit General Purpose Registers. Each of those has its 32, 16 and, for most, 8bit partial registers. Partial registers simply explained: though we write rax, eax, ax and al, these are all the same thing: al are the lower 8 bits of ax, which with the 386 became the lower 16 of eax which are the lower 32 of rax.
For instructions that work on GPRs, which all had 8, 16 and 32 bit versions, x86-64 brings the 64 bit versions, off course (with exceptions: some instrucions were droped in x86-64 and won't be missed).
The actual diference between all this is mostly operand size. Operand size is importan in x86/x86-64 as it can take memory adresses as operands.
So, what you propose is a hell of a mess...
Read more.

Is there any way to link 32 bit data with a 32 bit instruction, ala Itanic?

I'd explain, but I can't even understant what you're talking about. :-)

Hammer

[Anonymous Coward]

Too legit to quit!

Problems with x86-64

[SK-null]

First, to take advantage of *any* of x86-64 improvements you need an OS supporting the Long Mode. Without that, it will be an ordinary x86 CPU.
This is not the best place to say it but... Windows isn't in the horizon and Penguins don't rule the market yet...
Second, its improvements are limited. More than the ordinary 32 vs 64 bit comparisson shows.
Quoting from AMD's overview:

64-bit flat virtual addressing.
This is good if you care about more than 4 GB memory, useless if you don't. That simples.

8 new general purpose registers (GPRs).
This is plain good. It will allow for faster and with more Instruction Level Paralelism code.

8 new registers for streaming SIMD extensions (SSE).
Same as above.

64-bit wide GRPs and instruction pointer.
You need this to support the 64 bit addressing.
Some aplications may also take advantage of the ability to manipulate 64-bit integers at once.

And thats it! Some migh noticed I didn't refer to the floating point numbers. The FPU, that is already capable of handling 32, 64 and 80-bit floats won't be extended. Same thing with MMX and SSE (with exception of the 8 new registers).

Even if they have an OS suporting long mode, how willing will software vendors be to put money in a x86-64 64-bit version of their software?

History Repeats?

[compute this]

Remember a few years ago when all the windows uses were going from a system that had a 32 bit processor but were only utilizing it for 16 bit apps. The real test of time is how long does it take for 64 bit apps to be main stream.

SlashDJ #3

[Anonymous Coward]

I've got a problem. No it's not that my ass is getting ripped apart like Mr. Goatse.cx. That's never a problem. It's time for some more mellow sounds. So courtesy of the soundtrack to A Clockwork Orange is Singin' in the Rain.