Originally posted by: Calin
You can think somewhat at the 64-bit instructions as just another kind of instruction set extension like the SSE. If your program doesn't know SSE, it won't use it.
- OMG, NO! 64-bit is not at all like an instruction extension like MMX or SSE.
No offense, but there are lots of myths about various CPU-thingies circulatating. Let's not add to them, even if you're tempted to 'simplify' things for the sake of the OP.
64-bit is really about moving to a completely new CPU. The "X86" has gone through that metamorphosis twice before, '286 and '386. 64-bit is an "extension" in the meaning that the CPU retains backwards compatibility through two different 32-bit 'personalities'.
It is absolutely not an extension in the sense of simply adding instructions.
One of these 32-bit 'personalities' is
'legacy mode' in which the CPU works in a manner
identical to previous 32-bit CPUs, '386 through to Pentium4 and AthlonXP. Including these CPUs' backwards 16-bit compatibility with '286 and 8086, - and also their inability to run any 64-bit code. This is how most A64s and 600-P4 operates today, under a 32-bit OS.
The CPU can of course NOT execute 64-bit code from legacy mode.
The other 32-bit personality is the ability to execute 16-bit-pm and 32-bit-pm instructions from its 64-bit
'long mode' through an emulation layer ('compatibility submode') in memory management.
However in this 'long mode' the CPU is
NOT operating like previous 32-bit CPUs and is
not compatible at lower & higher levels, like adress translation, interrupts, exceptions, or with non protected mode instructions!
A 64-bit OS, of course, runs the CPU in 'long mode'.
(it is much more complex than that, however it is simpler than the move from 16-bit processors to 32-bit processors).
Sorry, I beg to differ again. But it is much, much easier to
port software from 32-bit to 64-bit, since both Win32 and Win64 program models use a flat virtual space. I assume you were thinking of that aspect alone?
In other ways, the move to 64-bit from 32-bit is certainly not simpler than 16-bit to 32-bit.
I never knew 64-bit operating systems won't run old 16-bit applications.
I assume this is a decision by Microsoft.
Since the AMD86-64 CPU is not compatible with 8086, '286 real mode, '386 virtual real mode or any 16-bit hardware access, in 'long mode', I can only assume that MS decided to get rid of a lot of luggage and save themselves trouble by dropping 16-bit support completely from Windows64. Theorethically, it seems to me it should be possible to build an OS that runs some very well written and well behaved Windows16 programs, on a 64-bit CPU in 'long mode'.
...But, like, why bother?
Why slower? Some other things even in 32-bit processors use only 16 or 8 bits. Also, 64-bit has bigger instructions/adresses, so they use more cache, so your cache miss might go up (a bit, some or a lot)
Possible performance penalty from 64-bit is not significant enough to be ever worthy of mentioning. It would only be visable in software were there is a direct instruction to instruction correspondance between 32-bit and 64-bit version. That's only how people like SiSoft build their "benchmarks" - until Intel is ready :disgust: - .
A mature 64-bit compiler will put out 64-bit code that is different from 32-bit code and makes use of the new additional true GP registers, and other additional registers for a performance improvement.
It is true that software that makes use of integers longer than 32-bit will achieve a dramatic performance increase from porting to 64-bit (100%-500%). This is not the usual case however, but 64-bit software will still feature a performance increase, maybe 20%-40% compared to most 32-bit software due to other reasons.
(edited for clarity)