Slashdot Mirror
Introduction to 64-bit Computing and x86-64
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."
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.
Reliable, Great Value Hosting: $7.95/mo 2.4G/120G
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.
From the elf(3) manual page:
[snip]
ELF provides a framework in which to define a family of object files, supporting multiple processors and architectures. An important distinction among object files is the class, or capacity, of the file. The 32-bit class supports architectures in which a 32-bit object can represent addresses, file sizes, etc., as in the following.
[snip]
So, basically it's possible with ELF. I don't know about PE. Otherwise, bundling is possible. Just look at Mac OS X/NeXTSTEP, which used fat bins with Bundles.
Well, any one who assumes pointers are ints deserves a slap.
And accessing memory above 4GB is very slow on the Xeons.
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 of how to do it on Linux:
For Windows, it's called Address Windowing Extensions (AWE).
I think MySQL supports these tricks too
Alan.
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.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
You're 1/2 correct. While current 32-bit x86s can access an address space larger than 32 bits (36 bits currently, although I believe you can extend further to about 39 bits), you cannot address that additional space linearly. You end up with separate 4GB segments that you have to manage directly. Pointers start to get weird again if you try to address more than 4GB with a single process.
We've had large flat address spaces for so long, and they offer so many conveniences, that nobody's too excited about introducing "near" vs. "far" pointers and segments back into the programmer's model. Those aren't new -- 16-bit x86 code used these heavily -- but nobody was sad to see them go. Right now, those issues are hidden in kernel space, and tasks only see a nice, flat 4GB window on the world. RAM beyond 4GB is used across multiple tasks, for disk cache, and so on. A single task can access more than 4GB through creative mmap()'s and crap. Eew.
Thus, tasks that want many GBs of data in RAM really need to go to 64-bit pointers (or, at least, more than 32-bit pointers) for true efficiency. That essentially means transitioning to a 64-bit architecture.
--JoeProgram Intellivision!
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 to fall into the group of applications that slow down quite a bit under stress.