Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
AMD Hardware

Introduction to 64-bit Computing and x86-64 259

Posted by michael from the peace-love-and-understanding dept.
James writes "Ars Technica has an article up explaining 64-bit computing from the x86 angle, specifically from the angle of AMD's Hammer. The article explains the details in that usual Ars style, and I found it very useful for thinking about what kinds of applications I may want to put to the test on one of these when we get a box in the office. Even non-x86 freaks may appreciate this, since it breaks down some of the basic advantages of 64-bit computing, and just who can expect to see gains in the near future."
This discussion has been archived. No new comments can be posted.

Introduction to 64-bit Computing and x86-64 More

Introduction to 64-bit Computing and x86-64

Comments Filter:

  • Looking forward to it (Score:5, Interesting)

    by dreamchaser ( 49529 ) on Thursday March 13, 2003 @08:54AM (#5502071) Homepage Journal
    While IA-64 isn't as bad as many here like to paint it, I'm looking forward to x86-64, if for no other reason than the continued pressure and competition for Intel.

    We've all heard the rumors that Intel has a 'secret' project to produce a P4 that executes x86-64. I have a feeling that they might have to unveil it, if only for marketing reasons. Wouldn't it be ironic, Intel adopting AMD's extensions to the x86 instruction set!
    • I'd hope so for intel that they do this, and yes, it is a bit ironic, I agree.

      The AMD x86-64 is the kick in the arse that Intel desperately needs. We all know Linus hates Itanium with a passion too. It's good for competition. Since x86 is almost a commodity, it should be good if Intel adopts somebody else's "standard" for a change. The whole IA-64/x86-64 split reeks a bit of NIH syndrome.

    • Re:Looking forward to it (Score:5, Interesting)

      by MSTCrow5429 ( 642744 ) on Thursday March 13, 2003 @09:01AM (#5502094)
      InStat/MDR thinks that Intel will adopt x86-64. As an AMD shareholder, I think that would be great, but I'm not sure I share InStat/MDR's optimism. Athlon 64 will not only have to be equal to the P4, it will have to blow it out of the water. Maybe InStat/MDR knows something I don't.

    • Re:Looking forward to it (Score:4, Interesting)

      by e8johan ( 605347 ) on Thursday March 13, 2003 @09:03AM (#5502098) Homepage Journal
      It would be truly ironic if Intel adopted AMD's extensions, but it would only show that AMD dared to go against Intel and do the right thing. From a business point of view, it was a brave move and I believe that it will be the best move that they have made in a long time.

  • What to use that for (Score:3, Funny)

    by teaserX ( 252970 ) on Thursday March 13, 2003 @08:57AM (#5502083) Homepage Journal
    > "...thinking about what kinds of applications I may want to put to the test on one of these when we get a box in the office.
    I bet it rips mp3s like a motherscratcher. Oh, you said "office"...

  • Cost advantage? (Score:2, Flamebait)

    by Anonymous Coward
    I've read up on AMD's and Intel's 64 bit computing and its improvements over 32 bit. But the improvements over 32 bit just aren't worth the extra cost and administration time that home and small business users can afford. Lets wait until most large businesses that can afford the extra cost and hassle adopt 64bit before we home users do. Just wait and look for real advantages over 32 bit before we all jump on the 64 bit bandwagon.

    • Bull (Score:2)

      by p3d0 ( 42270 )
      What are you talking about? Name one extra item of "cost" or "administration" or "hassle" that comes from using a 64-bit machine versus a 32-bit one.

  • Mix code in long mode? (Score:5, Interesting)

    by SynKKnyS ( 534257 ) on Thursday March 13, 2003 @08:58AM (#5502088)
    After reading the topic article (of which I saw on HardOCP yesterday), I was left with one question. Can you mix 32 bit and 64 bit code inside of ONE process? I know the OS can support 32 bit and 64 bit processes under Long mode, but can you mix code in a single process? It would be nice to know if you could build an application, query the CPUID feature flags, and then produce optimized code paths for both 32 bit and 64 bit. This would be nice because you can just supply one set of binaries to your customers instead of two seperate binaries. Anyone have any experience with the Opteron who can answer this?

    • Re:Mix code in long mode? (Score:5, Insightful)

      by CoolVibe ( 11466 ) on Thursday March 13, 2003 @09:02AM (#5502096) Journal
      Well, the industry can always revert to what Apple did if it isn't possible. Make "Fat" executables. ia-64, ia-32 and x86-64 in one executable. Sure, the binaries will be bigger, but with harddisk prices nowadays I don't believe disk space is really an issue :)

    • Re:Mix code in long mode? (Score:4, Informative)

      by darkov ( 261309 ) on Thursday March 13, 2003 @09:09AM (#5502125)
      From the article:

      These modes are set for each segment of code on a per-segment basis by means of two bits in the segment's code segment descriptor.

      So you just get your compiler to generate two segments. You'd have to figure out how to call one or the other, but there is the basis for it.
      • Yeah, I thought that too when I read the question, but the I remembered that segmented mode was dropped in 64-bit mode. 64-bit apps run in flat space. To mix different code segments in there, it would have to be through a gate. So whatever software you run would have to be at least partly in the kernel.
      • "Calling a function" requires more than just generating a legal address. You have to map data segments, perform whatever loading/relocations (you know, like for calls back into the OS) as necessary, allocate a stack etc. You also have to create a convention for sharing some address space between the 64 and 32 bit mechanisms.

        I.e., you need something akin to the 32-bit DOS extender, as well as some kind of "super-loader" that can load both 32 and 64 bit code.

        On the other hand, if the OS can load the two s
    • My understanding of the situation is that in long mode all your pointers etc are 64bit values and you don't get the extra registers without being in long mode. This means that unless you have compiled for 64bit pointers your code won't run in 32bit mode because the size of the pointers will be wrong. AFAIK the 64bit mode isn't a cpu flag which can be tested for like the SSE/SSE2 instructions, but a mode like Real/Protected mode. Perhaps your process may be able to switch mode but I doubt it. The other possi
    • The CPU supports it, so I think it depends on the OS. AFAIK x86-64 Linux adopts one address-size per process, but I'm fully prepared to stand corrected.
    • Since your address word-size changes in 64bit mode, imagine the horrors of having different sizeof(void*) from function to function.

      I can't imagine this something you'd ever want to do (what size would malloc return?).

      Still, I can see a potential problem. If you have a Linux distribution, some binaries will want to be 32bit, and some will want to be 64bit (what other purpose would there be to having such a compatibility mode). But shared libraries (libc.so) would be really nasty.

      I've read here that ELF

  • Coding styles (Score:5, Interesting)

    by ultrabot ( 200914 ) on Thursday March 13, 2003 @09:07AM (#5502113)
    The main perk of popularization of 64 bits is, if we think of the future, that more source code will be written with 64 bit capability in mind. Long ints will be used where they seem to be needed, etc. Open source movement is probably the most obvious benefactor, considering how harnessing that extra mile is/will be a trivial matter of recompiling. If we get a fast, cheap, non-x86 64 bit system in the future, all the better. But 64 bit capability should definitely be available on the desktops of the masses also, whether they needed 10 gig databases or not! More power for AMD!

    I'm looking forward to industrial strength, rock solid Opteron servers to finally put to rest all the speculation how Linux on x86 machines is not up to all the tasks of Solaris/HP-SUX systems...
    • will be a trivial matter of recompiling
      You have too much confidence in the coding style/quality of coders. eg: what happens when you put an int into a pointer or vice-versa
    • A couple of months ago I bought used Digital AlphaServer 2000 5/250. I am running Tru64 5.1B(former Digital Unix) on it. I really like Tru64. It is very reliable, efficient, has great administration tools and excellent documentation.

      The best thing however is that Tru64 and Alpha hardware are very well integrated. OS can detect and configure hardware automatically. It can also (together with the great SRM firmware) monitor various components in case of a (very rare) hardware failure.

      One of the worst th

  • plenty of potential customers (Score:5, Interesting)

    by g4dget ( 579145 ) on Thursday March 13, 2003 @09:10AM (#5502128)
    Just about anybody who runs Beowulf clusters or does scientific computing on Linux is a potential customer for these. Many people run into the dreaded 4G barrier, but Itanium is too costly and too much of a jump. With the x86-64, moving to 64bit is essentially no-risk--you know that at worst, you just get a really fast x86 machine.

    But what will be really interesting is when operating systems will be specifically designed for this. With 64bit, a lot of the cruft in 32bit operating systems can finally go away. For example, memory mapped I/O finally becomes useful again, shared libraries don't clash as easily, etc.

  • Wrong about underflow (Score:5, Informative)

    by stewartj ( 525869 ) on Thursday March 13, 2003 @09:10AM (#5502129) Homepage

    a small point, but the author is wrong about underflow. from the review:

    you get a situation called either overflow (i.e. the result was greater than the highest positive integer) or underflow (i.e. the result was less than the largest negative integer)

    underflow is when you're trying to represent a fractional number smaller than the smallest floating point number available. ie: you went too close to zero.

  • intel hack (Score:4, Insightful)

    by avandesande ( 143899 ) on Thursday March 13, 2003 @09:25AM (#5502188) Journal
    Furthermore, Intel supposedly has a fairly simple hack that they could implement to allow their 32-bit systems to address up to 512GB of memory. Still, the cleanest and most future-proof way to address the 4GB ceiling is a larger pointer
    They forget to mention that even if you can have more than 4gb on xeon machine you cannot address any single block of more than 4gb. Forget about putting your oracle db into memory.

    • Re:intel hack (Score:5, Informative)

      by bunyip ( 17018 ) on Thursday March 13, 2003 @09:36AM (#5502232)
      They forget to mention that even if you can have more than 4gb on xeon machine you cannot address any single block of more than 4gb.

      True

      Forget about putting your oracle db into memory.

      Not true

      On a Xeon machine, Oracle will let you put up to 62GB in memory. The trick is an operating system call that fiddles the page table and "swaps" pages from areas you can't see to areas inside your address space. It works well for applications that aer conscious of 4K pages and not page thrashing. Databases are the prime example, executing a few dozen privileged instructions and changing the page tables is much faster than going to disk.

      Here's a description [oracle.com] of how to do it on Linux:

      For Windows, it's called Address Windowing Extensions (AWE).

      I think MySQL supports these tricks too

      Alan.
      • I think MySQL supports these tricks too

        MySQL does most certainly NOT support these tricks.

        In fact, without kernel hacks MySQL won't use any more than 2gb of ram regardless of your settings. Even with those hacks, you're only looking at 3gb instead of 2. Woo Hoo. This is the biggest drawback, IMO, to the threaded module. A fork()ing system still has the problem but it's MUCH more managable.

  • Why NOT? (Score:3, Insightful)

    by gspr ( 602968 ) on Thursday March 13, 2003 @09:31AM (#5502210)
    "Why not do it?" is usually a bad question, but in this particular case, I think it's a good one. If there is no performance penalty when running in Legacy Mode, and if the Hammer is going to be cheap (read: reasonably priced compared to the P4), why NOT buy it?
    It doesn't hurt, and it prepares you for the future, a future that will come, now or later. This way there'll at least be a chicken... then we can just wait for the eggs to appear. It's foolish to think that any eggs will appear before the chickens do. Afterall, the only place you can get a chicken from before there are eggs, is from AMD's chicken replication facility.
  • Has anyone noticed how processors are getting to be like businesses and governments? I'm serious, and I don't think it's off-topic.

    Businesses, as they develop, tend to end up supporting more and more legacy products and services, and relying on structures that have got stretched and stretched but actually changed as little as possible. Governments are held back by the weight of their Civil Services.

    Back in the 70s and 80s, we had a completely new architecture every week (felt like..) and there was some real

    • What will make it collapse? [..] A completely new, simpler software design paradigm?

      Exactly. OpenSource.

      Linux runs on all major and most minor CPU-architectures out there. With Linux rapidly emerging as the standard (just forget about your stupid Winmodem, take a step back, take a deep breath and look at the big picture: *ALL* major chipmakers are supporting Linux from day 1. (IBM, AMD, Intel) Linux runs on everything from mainframes to embedded systems. Microsoft is still dominating the desktop, but on

  • Possible x86-64SX (Score:2, Interesting)

    by zubernerd ( 518077 )
    I remember when I got my first 386 based computer, it was a 386SX (40 MHz - by AMD); which used a 16-bit data bus on the "outside" and 32-bit internally. Do any of you think there will be a x86-64SX, that will work on today's 32-bit motherboards, while giving some of the advantages of 64-bit computing?

    • Re:Possible x86-64SX (Score:3, Interesting)

      by Psiren ( 6145 )
      Do any of you think there will be a x86-64SX, that will work on today's 32-bit motherboards, while giving some of the advantages of 64-bit computing?

      Nope, what would be the point. Motherboards are not really that expensive, you can pick up a high-end board for less than £100. If you can afford to buy a 64bit CPU, you can afford to buy a board to put it in.
    • Motherboards aren't really '32-bit'. On most x86 systems the memory bus is 64 bits (or greater?) wide already.
    • In a word, no.

      First off, every x86 chip since the original Penium have used 64-bit buses anyway! ie they reversed the old 386SX, using 32-bits internally, but 64-bits externally.

      The next problem in your theory is that the Hammer completely changes all the rules about buses anyway (at least the x86-rules of buses). The processor will have an on-die memory controller, which basically eliminates most of the traffic that went over a traditional bus. In current x86 systems, there is only one bus that transp

  • Will Microsoft survive the 64-Bit transition? (Score:5, Insightful)

    by RoLi ( 141856 ) on Thursday March 13, 2003 @09:51AM (#5502317)
    The 64-Bit transition comes with a lot things, all bad for Microsoft:

    • For the first time in computing history AMD and Intel no longer see Microsoft as the sole software provider. Both Intel and AMD support Linux from day 1 on their 64-chips. I repeat: That did not happen before. So far, Linux was never available on a chip's introduction.
    • On Operon and Itanium, Linux is available before Windows.
    • In the first 1 or 2 years, 64-chips will be mainly used on servers, where Linux is already strong.
    • To use the additional features/registers, a recompile is neccessary - OSS will use those features right away, while CSS vendors will take quite some time to release a 64-Bit version and will probably want some money for the upgrade.
    • The traditional Windows-on-servers customer is a very conservative market segment not likely to jump on the 64-Bit bandwagon very early.

    To summarize, Microsoft might run into a chicken-and-egg problem on 64-Bits: Nobody runs Windows on 64-Bits because it's not faster -> Nobody makes Win64 software -> Nobody runs Windows on 64-Bits.

    Add into that the fact that Microsoft is traditionally very incompetent and slow when it comes to adopting new architectures and you get the idea.

    I think that Microsoft will lose the majority of their server marketshare and a large chunk of their desktop marketshare during that transition. Simple market inertia will prevent Microsoft to be thrown out of the desktop market, but because of the 64-Bit transition, the Linux desktop market might finally gain critical mass and endanger the Windows domination in the long term.

    • I think Microsoft will survive the 64-bit transition.

      After all, Microsoft HAS developed a version of Windows XP Professional that works on the Itanium CPU in IA-64 mode, for gosh sakes! I'm sure that Microsoft is right now working a version of Windows XP Home/Professional that works on the AMD Athlon64/Opteron CPU's in x86-64 native mode, so when the Athlon64 is finally released an x86-64-native version of Windows XP will be available for these new machines.

      • Re:Will Microsoft survive the 64-Bit transition? (Score:4, Insightful)

        by RoLi ( 141856 ) on Thursday March 13, 2003 @10:14AM (#5502448)
        After all, Microsoft HAS developed a version of Windows XP Professional that works on the Itanium CPU in IA-64 mode, for gosh sakes!

        Well, although I have never seen a review about that, never seen a Wintel64 system on sale and don't know what dirty hacks and workarounds are in the package, let's assume that's true.

        Now look at my post again: All the points I made are still valid, the most important one being that Linux is being supported right from the start for the first time.

        I'm sure that Microsoft is right now working a version of Windows XP Home/Professional that works on the AMD Athlon64/Opteron CPU's in x86-64 native mode

        While I'm also sure that they are working on it, I'm not about their ability to ship a working product on time. On the other side, SuSE has already successfully ported Linux to mainframes for IBM (something I don't think MS could do with Windows in a timely manner) and they are now porting Linux to Opteron - or better have already ported it as Beta-systems are already out there. - Where is the Windows-Operon Beta? I don's see it.

        In case you forgot, Microsoft was YEARS late in finally adequately supporting 32-Bit (actually, Intel was already quite angry at MS that their chips were still used in 16-Bit mode almost exclusively for so long). Of course by that time, there was no alternative, so Microsoft got away with their incompetence, but now there is not only an alternative, it is also supported officially by AMD and Intel.

        • Quoth MtViewGuy:

          After all, Microsoft HAS developed a version of Windows XP Professional that works on the Itanium CPU in IA-64 mode, for gosh sakes!

          To which RoLi replied:

          Well ... let's assume that's true.

          A safe bet. It even has an official web site [microsoft.com] linked fom the windows home

          Quoth MtViewGuy:

          'm sure that Microsoft is right now working a version of Windows XP Home/Professional that works on the AMD Athlon64/Opteron CPU's in x86-64 native mode

          To which RoLi replied:

          While I'm also sure that they a

          • Given the fact that Anandtech's web site showed pictures of motherboard prototypes that will use the Hammer-class CPU's like late last fall, I'm sure that prototype machines with the Athlon64/Opteron CPU's are already delivered to Microsoft by last fall so they can write a version of Windows XP Home/Professional and Windows 2003 Server that works in the x86-64 native mode.

            My personal guess is that when the Athlon64 CPU is finally released commercially, Windows XP and Windows 2003 Server versions that work
      • Though the 64-Bit Windows does not have all the features [microsoft.com] of the 32-Bit version...
    • Of course it will. Native 64-bit Windows XP will be out in several months. It's cool that Linux is ready right now but quite frankly - there will not be such amount of Hammer chips on the market to make it a large difference.

      And your first summary implication ("it's not faster on win -> nobody makes win64 sw") is illogical. Nobody would if there wasn't big market already. But there is. Thus all that must be done is to generate enough marketing hype about a brand new, faster, shiny, ... (the same recompi
    • That strange noise you heard was a monkey flying out of Bill Gates's butt.
    • Add into that the fact that Microsoft is traditionally very incompetent and slow when it comes to adopting new architectures and you get the idea.

      Add to that the fact that since Windows has been a single platform for so long that there is lots of software written for it that is horrible-hack-hardwired for 32 bits only.

  • 64-Bit: The "Torque" of a Processor? (Score:5, Insightful)

    by Spencerian ( 465343 ) on Thursday March 13, 2003 @10:04AM (#5502400) Homepage Journal
    I'm not an engineer.

    What I got from this article (well written, BTW) is that 64-bit processors provide more processing power--a concept different from speed. For instance, a Porsche can fly down the highway, but its engine has insufficent power to tow a 5th wheel RV. A Mack truck isn't speedy, but has a strong engine that can tow the heaviest loads up the same speed--more work is performed.

    That would be why Apple's PowerPCs are still in the running, despite their clock slowness. They are falling behind fast as, after a point, speed does matter, in combination with improved processor power in the latest 32-bit Pentiums, and certainly the Xeon. Vector processing, such as Altivec, helps keep Apple competitive with their current chips--just barely. Many in the PC community await AMD's offering while IBM works on blending its POWER chip technology into a 64-bit PowerPC, with Altivec.

    Imagine making the Porsche's engine more powerful but maintaining its speed advantage so it can haul ass as well as tow. Add nitro for extra ooompf (vector processing) and you have a dream machine. That's why it seems that 64-bit apps and processors seem to be such a holy grail.

    That's my take on it. Clarification is always appreciated.

    • For instance, a Porsche can fly down the highway, but its engine has insufficent power to tow a 5th wheel RV.

      Actually, with a few hundred bhp, the Porsche in not lacking in power. Consider this though: if I had a large van, I could transport my sofa all in one go. My Golf doesn't have the space, so I'd have to break up the sofa and make the trip more than once.

      If you don't need to transport a sofa, you might as well stick with the Golf, as both go the same speed.

      -- Steve

      • As an engineer:

        Torque is a measure of the ability to do work. Foot-lbs means how many lbs of Force is applied at a leverage point of 1 foot.. It's the same as force, but in an angular orientation instead of a straight one.

        Horse Power is the measure of Torque at a given RPM. Force in a given time is called power; the ability to do work "quickly".

        Thus a truck have enormous torque and thus can have a really high horse power at low RPMs (namely lugging tons of material from a complete stop where RPMs are b

    • Key benefit is... (Score:3, Insightful)

      by Goonie ( 8651 )
      The key benefit of 64-bit architectures is that you can address much more than 4 gigabytes of memory without having to deal with funky segmentation tricks. As servers are running hard up against this barrier, and desktops are not that far off it, *that* is why the impetus for 64-bit processors is happening now.

      Because the machine code *has* to change in the process, you can take the opportunity to redesign your instruction set to make it possible to design faster chips that use it. In AMD's case, they've

  • PPC (Score:5, Insightful)

    by Duncan3 ( 10537 ) on Thursday March 13, 2003 @10:15AM (#5502458) Homepage

    "Should Apple move from 32-bit PPC to 64-bit PPC, Mac users should not expect the same kinds of performance gains that x86 software sees from the jump to x86-64. 64-bit PPC gives you larger integers and more memory, and that's about it. There are no extra registers, no cleaned up addressing scheme, etc."

    Well yea, they already have more then 0 general purpose registers, and a flat memory space, like every other chip besides x86 has had for the last 20 years now. The embedded chips I've used on projects that cost $7 a piece even have more registers then x86 does.

    64bit is about the memory, and using that memory, plain and simple. x86 just happens to be using this as a chance to catch up with the cutting edge concepts of the 1980s.

    As for x86 needs to die once and for all, it's hacked, hacked again, and hacked yet again. x86 was and is a 16bit system. And now AMD wants to hack it yet again. Can anyone doubt that 80% of the silicon is for supporting legacy apps at this point? Are people that damn lazy they can't type 'make' on a new system? It's not like anyone uses "int" anymore and assumes it's N bits long.

    • Re:PPC (Score:2, Interesting)

      by arthas ( 654815 )
      I agree. X86 should be dead by now. Why can't Intel or AMD build something like Alpha? It is very clean and efficient 64-bit architechture and it has been around from 1992.
    • Yeah I have to agree, while I think AMD's x86-64 chips doing better because of the backward compatibility, I would rather see the IA-64 one succeed because of the lack of backwards compatibility.

    • Re:PPC (Score:4, Insightful)

      by pjl5602 ( 150416 ) on Thursday March 13, 2003 @01:11PM (#5504125) Homepage
      As for x86 needs to die once and for all, it's hacked, hacked again, and hacked yet again. x86 was and is a 16bit system. And now AMD wants to hack it yet again. Can anyone doubt that 80% of the silicon is for supporting legacy apps at this point? Are people that damn lazy they can't type 'make' on a new system? It's not like anyone uses "int" anymore and assumes it's N bits long.

      Legacy X86 is dying. But really, how much die space does the 386 real mode take up? A few hundred thousand transistors? That's nothing these days so it's worth keeping it around even if only 0.001% of your customers make use of it simply from a marketing perspective.

      Then, from the article:
      When AMD's engineers started looking for legacy x86 features to jettison, the first thing to go was the segmented memory model. Programs written to the x86-64 ISA will use a flat, 64-bit virtual address space. Furthermore, legacy x86 applications running in long mode's compatibility sub-mode must run in protected mode. Support for real mode and virtual-8086 mode are absent in long mode and available only in legacy mode. This isn't too much of a hassle, though, since, except for a few fairly old legacy applications, modern x86 apps use protected mode.

      So the X86-64 mode will be fairly cruft free.

      Pat

      • Legacy X86 is dying. But really, how much die space does the 386 real mode take up? A few hundred thousand transistors? That's nothing these days so it's worth keeping it around even if only 0.001% of your customers make use of it simply from a marketing perspective.

        Sorry - I don't buy that. You're talking about an industry that has prospered over the past 20 years largely by creating the perception that there is a continual need to upgrade. They'd probably be quite cheerful as they sold 0.001% of thei

    • As for x86 needs to die once and for all, it's hacked, hacked again, and hacked yet again. x86 was and is a 16bit system.

      Yeah, I used to think the same thing. And I think most people will agree that the x86 ISA is nasty compared to other modern processors like Sparc or PPC. But I eventually got over that (about the time Be Inc. "dropped" PPC and x86 Linux really started to shine) The simple fact is that nothing has the same level of price performance. Not by a long shot. There is every reason to believe t
    • The embedded chips I've used on projects that cost $7 a piece

      Must have been pretty small projects.

  • DOH! (Score:2)

    by Andy Dodd ( 701 )
    I'm still reading the article, but too bad the vector registers are still only 128 bits.

    Doubling the vector registers would nearly double performance for applications designed to make use of SIMD instructions (MMX, SSE, 3DNow!, etc.) New instructions would be needed to support the new wider VRs, but that hasn't stopped AMD or Intel in the past as far as adding SIMD capabilities and it shouldn't stop.
    • But I read the remainder of the article.

      The 64 bit registers won't be very useful to most of us for a long time. I'm an engineer and I don't think I've ever overflowed a 32 bit integer, ever.

      Most of us won't need the address space of x86-64 for 2-3 more years at the very least.

      But doubling the number of GPRs and more importantly, doubling the number of vector regs... WOW.

      Doubling the number of vector registers will increase throughput significantly for apps that use the vector regs and are recoded to

      • Re:I shouldn't reply to my own posts... (Score:4, Informative)

        by p3d0 ( 42270 ) on Thursday March 13, 2003 @11:36AM (#5503167)
        Yep, the extra registers are fantastic. It's about time.

        There's more to this chip than that, too. The HyperTransport bus architecture they have created is very cool. Cheap, fast, and scalable for medium-sized SMP boxes. And 64-bit addressability, despite your assertion, is indeed useful today for servers, which routinely hit the 4GB barrier.

        Backward compatibility is important, not only for existing software, but for existing compilers. Supporting long mode is nearly trivial. Just add the REX prefix in the appropriate places, remove deprecated instructions, support RIP addressing, and implement the ABI. Ok, that sounds like a lot, but compared to IA64 it's a cinch.

        I'm under NDA, so I can't say much more, but I really like this architecture, and I want to get a dual myself for home use.

        • Well if you have so much info about x86-64, perhaps you can answer this.

          mips64 chips can support an ABI called n32 in which the 64-bit registers are exposed, but things still basically run in 32-bit mode. Pointers, ints, and longs are 32-bit, but long long is a native 64-bit.

          This gives a speed boost for any proggy that could use a real int64 and (more importantly) common functions that would like to move 64 bits at a time, like memcpy() etc. All this w/out the 64-bit address bloat. The tradeoff is ext

        • HyperTransport - Don't Athlons already have this? (i.e. it's nothing new)

          I wouldn't consider servers to be "most of us" - Servers are a minority of users, the 64-bit improvements will be of little benefit to the majority of users, most of whom are likely to have one gig or less of memory for the next year or so, and probably no need for more than 4 gigs for the next 2-4 years. It's only the big servers that have the need for it now/short-term.

          But the other architectural improvements are going to make x8
  • From the article:

    If we think realistically about most of the world's commercial software not as "software" in the abstract but as x86 binary code, then it becomes apparent that improvements to the x86 ISA represent one of the most practical and cost-effective ways to advance and expand the x86 software market.

    If you think of existing software as 386 binary code, then obviously it's not going to benefit from any improvements to the x86 architecture. Moving to Athlon 64 will not magically make Windows 9

  • How does Intel currently kludge around the 4Gb memory limit on 32bit processors? The article alludes to a feature in the Xeon line that does this, but a quick Google didn't turn anything up. I assume it's some virtual memory style hack, where the pointer indexes into a table rather than directly into memory.

    Chris
    • Since the Pentium Pro, there's been a feature called PAE (Physical Address Extensions) that allow for up to 64GB of memory to be supported on a system. The logical address space is still 4GB (typically 2GB of user space). Essentially there is an additional level of page translation which tends to slow things down somewhere between a lot or a little depending upon the application. It's never been all that popular -- supposedly because the applications that can use a lot of memory (e.g. large databases) tend
  • The article mentions 2 clear benefits of x86-64.

    First, we have more addressable memory, which could help performance by running entire cached databases.

    Second, he says for applications that do math on very large numbers (that need larger than 32bit numbers) there would be a performance increase because 64-bit cpus could do it in one register, instead of ia32 having to split it up.

    However, he states that regular apps that donot require larger than 32-bit ints will see no performance increase on x86-64. My
    • However, he states that regular apps that donot require larger than 32-bit ints will see no performance increase on x86-64. My question is this: Would it be possible to "double up" the calculations by cramming more data into a single instruction if one were only using 32bit ints?

      Not really. Say you wanted to do two 32-bit additions, adding 0x00000001 to 0x00000002 and 0x00000005 to 0x00000004. Theoretically, you could combine this into one 64-bit addition, adding 0x0000000100000005 to 0x0000000200000004
    • Yes, there are programs that do this. One interesting thing is fixed floating point. It's basically where you say one integer register can hold enough significant digits to emulate a floating point in limited situations (games, some rendering types, etc)

      The big advantage is that integer operations tend to get ganged through the ALU at a high rate (and on some cpu's simultaniously.. i.e. alpha).

      This could also be useful for brute-force cracking on RSA, etc..

      Anyhow.. YMMV, limited liability, and always
  • I don't think AMD has even realized the benefit they will get in benchmarks just from the addition of SSE2 instructions. Barton isn't even feature complete in this regard. They're 32bit offerings will never catch up because of this.

    I just want to malloc a terabyte. Even if I don't use it for a little while (4GB is a limitation to me now).

  • What about tcpa (Score:3, Insightful)

    by OeLeWaPpErKe ( 412765 ) on Thursday March 13, 2003 @02:22PM (#5504786) Homepage
    Does this chip support tcpa (and thus palladium) ? I think this is a kind of an important detail on the new cpu.
  • The only good reason to switch to 64-bit computing is *memory*. The 4GB limit is a real problem for modern CAD tools.

    Where I work (a semiconductors company) we use Sparc64 systems exactly for that reason.

    In fact, the CAD tools manufacturers admit that their 64bit versions are *slower* than their 32bit software. The only reason a 64bit version is available is because a lot of customers are hitting the 4GB limit.

    The reasons for the performance loss? Well, 64bit software may address more memory but it also

    • The only good reason to switch to 64-bit computing is *memory*. The 4GB limit is a real problem for modern CAD tools.

      Since the Pentium, there's an extension called PAE (Physical Address Extension or something like this) which overcomes this limit and allows to use up to 64GB (IIRC) on x86 platforms.

      Don't ask MicroSoft about it, they don't support it in their normal products, AFAIK you have to buy their ultra-expensive high-end server products.

      But Linux supports it just fine, of course ;-) I know th

  • Long mode and vm86 mode? (Score:3, Interesting)

    by frohike ( 32045 ) <bard.allusion@net> on Thursday March 13, 2003 @02:52PM (#5505105) Homepage

    Maybe I missed it somewhere in the article, but I was kind of disturbed by the diagram showing what's possible in what modes. What it looks like they are saying is that in "legacy" mode, you can only run 32-bit code, and you must run a 32-bit OS. And in "long" mode, you must run a 64-bit OS, and v86 mode is not supported at all.

    If a new x86-64 OS that takes advantage of the 64-bit extensions can no longer run v86 code, then this is going to be a serious hamper on adoption! There are still tons of reasons to run 16-bit code, like the BIOS-init in XFree86, DOS emulators, and of course we all know about Windows (though that is changing mostly with the adoption of NT as a home platform). I mean over time things are going to support 32-bit/64-bit code more and more (in the bios and such) but I thought the compatability was the whole point here...

    Is this going to require some sort of trick like IBM used on the 286 with OS/2?* Can someone in the know post about this?

    * Back when the 286 was brand spanking new and IBM was developing OS/2, they of course wanted to use the new protected mode. Only problem was, Intel didn't build in a way to switch out of protected mode! So if they wanted to run an old fashioned 8086 task (or any 8086 code) they ended up doing something that was described by the developers as "turning off the engine at 60mph" -- they'd actually completely reset the CPU and put in some glue to make it jump back into the OS image instead of the BIOS. Which is how it exited 286 protected mode :)

  • When I was an intern at Intel (summer 2000), I attended a small presentation at the end of the summer where they pitched 64-bit computing. One of the questions at the end was when it will be available on the desktop, and the answer, amazingly enough, was that it wouldn't be in the foreseeable future. And I'm just sitting there thinking "Bad move". Because they completely ruled out the geek factor. So I'm glad AMD is there to clean up after Intel's mistakes, and offer us a 64-bit desktop solution.
  • These look very interesting.. The large address space and native bignum math are nice, but not a big deal for me.. I really like the flat address space and increased number of general purpose registers.

    This is sort of odd, since those two things are completely abstracted to me when programming in user space.

    I was educated on processor architecture and assembly language on the Motorola 68000 processor. So, I have always found the x86 kludgery distasteful. The x86-64 gets rid of two of the major p

Slashdot Top Deals

I program, therefore I am.

Close