Introduction to 64-bit Computing and x86-64 259
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."
Looking forward to it (Score:5, Interesting)
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!
Re:Looking forward to it (Score:2)
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:2)
AMD is doing it right. They will have a cheap 64-bit platform for everyone. Of course, Torvalds is paid to like Hammer because his employer licensed the technology, but why would a chip manufacturer like Transmeta license it if it weren't any good?
Re:Looking forward to it (Score:2, Interesting)
I'm really looking forward to x86-64. We'll be able to slide it in alongside our existing (growing) linux compute group, an
Re:Looking forward to it (Score:5, Interesting)
Re:Looking forward to it (Score:4, Interesting)
Re:Looking forward to it (Score:2, Funny)
Simple, AMD will counter with their upcoming Bananas core and grapefruit tech. Who makes up these stupid nicknames?
Re:Looking forward to it (Score:2)
Could you pass me some of those mushrooms you have been eating?
Re:Looking forward to it (Score:2)
What to use that for (Score:3, Funny)
I bet it rips mp3s like a motherscratcher. Oh, you said "office"...
Cost advantage? (Score:2, Flamebait)
Bull (Score:2)
Re:Cost advantage? (Score:2, Informative)
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 abo
Re:Cost advantage? (Score:3, Insightful)
While it is true that 32-bit x86 chips can address 36-bits of memory using Intel's PAE, they do so using a really ugly hack. It was a really ugly hack back in the 16-bit x86 days, and it's still an ugly hack now.
AMD's solution is the right one, a true flat 64-bit address space. 64-bit integers aren't particularly important, it's quite rare that an application needs 64-bit integers, and when th
Mix code in long mode? (Score:5, Interesting)
Re:Mix code in long mode? (Score:5, Insightful)
Re:Mix code in long mode? (Score:5, Informative)
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.
Re:Mix code in long mode? (Score:2)
Re:Mix code in long mode? (Score:2)
Using the facilities in ELF to 'group' objects per architecture is a much better. Or bundling, like NeXTSTEP and Mac OS X do, which basically means that binaries for all arches are included, but it uses some OS framework to decide which binary gets run.
I have yet to play with multiplatform ELF binari
Re:Mix code in long mode? (Score:4, Informative)
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.
Re:Mix code in long mode? (Score:2)
Re:Mix code in long mode? (Score:2)
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
Re:Mix code in long mode? (Score:3, Insightful)
Re:Mix code in long mode? (Score:2)
Re:Mix code in long mode? (Score:2)
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)
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...
Re:Coding styles (Score:2)
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
Re:Coding styles (Score:2)
Re:Coding styles (Score:2)
You should almost never need to cast to (void *) in C. For example,
will always work, no matter what type of pointer q is. If you want to assign q to a type other than void *, then you'll need to cast: C++ has different rules regarding void *.x86 hardware isn't so great (Score:2, Insightful)
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)
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)
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.
Re:Wrong about underflow (Score:2)
Not when talking about integers smarty. No one was talking about floating point.
I thought counting too LOW with a signed integer was still (according to the error trap) an "overflow error", since the system really doesn't care about positive/negative. Probably just a semantic argument at this point...nevermind...
intel hack (Score:4, Insightful)
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)
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.
Re:intel hack (Score:2)
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.
Re:intel hack (Score:2)
PAE is closer to the segment/offset scheme of the 8086..80286. It still sucks, but far far less.
Why NOT? (Score:3, Insightful)
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.
Processors like businesses (Score:2, Insightful)
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
Re:Processors like businesses (Score:3, Interesting)
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
Re:Processors like businesses (Score:2)
Clean alternatives... (Score:2)
Unfortunatlely, the majority of people who had heard of Alpha just said "Nice, but we don't need it yet". Altavista was built as a technology demonstrator for the advantage of 64-bit addressing for databases and people still said "So what". Digital never made it to the big time for c
Possible x86-64SX (Score:2, Interesting)
Re:Possible x86-64SX (Score:3, Interesting)
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.
Re:Possible x86-64SX (Score:2)
Re:Possible x86-64SX (Score:2)
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)
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.
Re:Will Microsoft survive the 64-Bit transition? (Score:2)
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)
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.
Re:Will Microsoft survive the 64-Bit transition? (Score:2)
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
Re:Will Microsoft survive the 64-Bit transition? (Score:2)
My personal guess is that when the Athlon64 CPU is finally released commercially, Windows XP and Windows 2003 Server versions that work
Re:Will Microsoft survive the 64-Bit transition? (Score:2)
Re:Will Microsoft survive the 64-Bit transition? (Score:2)
Re:Will Microsoft survive the 64-Bit transition? (Score:2)
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,
Re:Will Microsoft survive the 64-Bit transition? (Score:2)
Re:Will Microsoft survive the 64-Bit transition? (Score:2)
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.
Re:Will Microsoft survive the 64-Bit transition? (Score:2, Insightful)
Actually, if you look at the Windows source (from Windows 2000 on), you'll see that most of it is #ifdefs, not a lot of new code. There was a 64-bit transition guide available before Windows 2000 launched. In fact, according to this presentation [usenix.org], they did 56 IA-64 builds a week during the Win2000 development cycle alone. MS has had 3+ years since then to prepare for 64-bit, including Opteron. So most of your points sound a bit silly to me -- if t
64-Bit: The "Torque" of a Processor? (Score:5, Insightful)
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.
Re:64-Bit: The "Torque" of a Processor? (Score:2)
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
Re:64-Bit: The "Torque" of a Processor? (Score:2)
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)
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
Re:64-Bit: The "Torque" of a Processor? (Score:2)
Funny...I would think that the game industry would be bleeding edge in processor stuff because their work is not particularly dependent on what the PC industry does from a raw hardware standpoint--until they have to port their work. But then, consoles and PCs are losing their distinctions hardware-wise. Thanks for the clarification.
PPC (Score:5, Insightful)
"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)
Re:PPC (Score:2)
Re:PPC (Score:4, Insightful)
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
Re:PPC (Score:2)
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
Re:PPC (Score:2)
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
Re:PPC (Score:2)
Must have been pretty small projects.
DOH! (Score:2)
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.
I shouldn't reply to my own posts... (Score:2)
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)
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.
Re:I shouldn't reply to my own posts... (Score:2)
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
Re:I shouldn't reply to my own posts... (Score:2)
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
Existing x86 binaries don't mean x86-64 is good (Score:2)
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
Re:Existing x86 binaries don't mean x86-64 is good (Score:3, Insightful)
If buying a new machine means you need to replace every single piece of software you use, possibly losing access to old data in the process, most ppl are just not going to buy it.
What's the Xeon 4Gb memory hack? (Score:2)
Chris
Re:What's the Xeon 4Gb memory hack? (Score:2, Informative)
Something I need clarification on (Score:2)
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
Re:Something I need clarification on (Score:2)
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
Re:Something I need clarification on (Score:2)
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
Never mind 64 bit (Score:2)
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)
Re:What about tcpa (Score:2)
64bit performance is ... (Score:2, Interesting)
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
Re:64bit performance is ... (Score:2)
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)
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 :)
Re:Long mode and vm86 mode? (Score:2)
Long mode consists of 64-bit and compatibility modes. Legacy mode consists of protected mode, vm86 and real mode. vm86 is not generally needed anymore as there are so few real mode apps that are run within protected mode. Athlon64 is the future, without giving up the present. (my highlighting)
I don't think I'm getting confused at all -- the point I just highlighted above is my contention. I don't think vm86 mode is useless anymore, there are still plenty of good uses for it. According to the diagram, lon
Intel's absurd plan for 64-bit (Score:2, Interesting)
It just feels right... (Score:2)
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
Re:Crap article. (Score:5, Interesting)
Re:Crap article. (Score:5, Interesting)
Re:Crap article. (Score:2)
16 bit adressing was mostly done with the HL register
Yes, HL was the main address pointer in the Z80. (BC and DE being the other ones.)
IX and IY were index registers: you had special instructions to access memory at (IX + n). You couldn't use them as general purpose registers, while you could perform arithmetics on HL.
TCPA (was Re:64 bit chips R cool . . . (Score:4, Insightful)
I dunno, TCPA seems kinda cool & useful. It doesn't lock down anything, it is basically just a way to encrypt/decrypt data without having the keys on a local file system (i.e. keys are stored on a black-box hardware). Spreading popularity of TCPA might also render Palladium and other DRM methods worthless. TCPA != DRM. Some IBM articles reported on
With TCPA, *you* would hold all the keys (since you can access your own hardware, hopefully), and no centralized entity (*cough* ms *cough*) would have anything to say about it.
Re:TCPA (was Re:64 bit chips R cool . . . (Score:3)
DRM is a whole other story and is often being confused with TCPA. DRM is bad stuff and WILL let big bad corporations like MS to control what you can do on your box.
TCPA and Pd (Score:2)
Nope. Not only does it not do any kind of really meaningful hardware crypto acceleration (it only performs operations using the RSA system, and doesn't support _any_ symmetric algorithms), it also hides the keys from you. They're generated in the trusted platform module and stay there for all time. It also comes with an endorsement k
Re:TCPA (was Re:64 bit chips R cool . . . (Score:2)
Yes, if they wanted to use TCPA for this purpose. However, they don't, hence Palladium. TCPA is not a MS thing. Additionally, even if they did sign Word, you could always crack the program and run it. TCPA doesn't enforce that you can only run "authorized" programs, which is what Palladium will do. You can't lock down a system with TCPA hardware.
Re:Will x86-64 be a consumer-level 64-bit solution (Score:2)
programs have always been getting larger and larger requiring more and more memory. nothing will change that except for perhaps a complete stagnation of the hardware industry.
Re:Will x86-64 be a consumer-level 64-bit solution (Score:2)
Re:Diminishing returns (Score:2)
a) the actual cost
b) the actual benefits
c) that the preferences for all users are such that the combination of a and b are not financially feasible.
Stop and think about it. How often is 64-bit integer math needed? Sometimes it is, yes, but I think the general consensus is that it is fairly uncommon. Everything from Word to The Sims to Doom 3 is not reliant on 64-bit integers in any kind of f