64 bit

The word size
Everything else might also be 64 bit (or more) but afaik the processor is called 64 bit solely because the word size is 64 bits

In the upcoming 64 bit processors and the Alpha processors, the address bus is 64 bit as well. In fact, that is the main reason we are switching to 64 bit processors (to escape the 4GB per process memory limit imposed by 32 bit addresses). Its also the reason pretty much all supercomputers use 64 bit processors (because they work with alot of memory).

All current 32 bit processors also have a 32 bit address bus, the only 32 bit processor I know of that did not was the cheap 386 SX (386 "celeron"), which had a 24 bit address bus. However, the original 386 DX had a 32 bit address bus and had the capacity to address 4GB of memory.

Personally I use the n-bit definition as the size of the registers.
A 64-bit processor has 64-bit registers, a 32-bit processor has 32-bit registers (not counting floating point/SIMD). However the sizes of the instruction might be larger or perhaps even smaller than that, which is why I'd ask for the instruction sizes explicitely.

Quote:

Original post by Wytter Personally I use the n-bit definition as the size of the registers. A 64-bit processor has 64-bit registers, a 32-bit processor has 32-bit registers (not counting floating point/SIMD). However the sizes of the instruction might be larger or perhaps even smaller than that, which is why I'd ask for the instruction sizes explicitely.

You're right. Computer architects will generally agree that the "bitness" of a processor is defined by the width of its general purpose registers. So in the case of X86, that would be 32 bits (despite there being 80-bit FPU registers, 64-bit MMX registers, etc.)

At the system level, sometimes different definitions are more convenient. Video game consoles used to be classified by the width of their CPU's data bus. The Sega Genesis was labelled a 16-bit system by Sega because its 68000 CPU had a 16-bit data bus (despite having 32-bit registers.)

How does the change to 64-bit alter the machine code instructions? There are twice the number of registers that can be addressed IIRC, the registers are double the width, and explicit address pointers have to be double the size. How can 64-bit processors have all these improvements, while still being able to run 32-bit apps? Surely these additions would modify the machine code. Are they literally translating each instruction into its 64-bit equivelant before processing, and if so, how do they know if it's a 32-bit app or a 64-bit app?

Quote:

Video game consoles used to be classified by the width of their CPU's data bus. The Sega Genesis was labelled a 16-bit system by Sega because its 68000 CPU had a 16-bit data bus (despite having 32-bit registers.)

Yeah, and then by the time they got to the Dreamcast, they could call them 128-bit systems, which was a great tagline.

Quote:

Original post by Nemesis2k2 How does the change to 64-bit alter the machine code instructions? There are twice the number of registers that can be addressed IIRC, the registers are double the width, and explicit address pointers have to be double the size.

Remember that bitness is the width of the invidual registers themselves and has nothing to do with how many there are. Most RISC architectures do NOT add more registers in 64-bit mode but the existing registers become 64 bits in size. For example, on PowerPC, regardless of which mode you're in, you have 32 GPRs: R0-R31 and their size depends on the mode.

Adding registers to an architecture is a separate problem from increasing register size. How you solve it depends on how the initial architecture was designed. Some processors have reserved bits in their opcode fields that are put to use. Other processors use variable-length instructions (like X86) and may have a prefix byte or some other field set to indicate that the operands are now differently sized. It's also conceivable that some processors don't allow their registers to be directly addressed so they can simply add more as they wish. Itanium, SPARC, and other architectures use relative register addressing where you access registers within a window.

Quote:

How can 64-bit processors have all these improvements, while still being able to run 32-bit apps? Surely these additions would modify the machine code. Are they literally translating each instruction into its 64-bit equivelant before processing, and if so, how do they know if it's a 32-bit app or a 64-bit app?

They certainly can modify the machine code (as I think is the case in AMD64) but even if they don't (such as on RISC chips), a 32-bit application will make certain assumptions about its environment that aren't true in 64-bit mode and thus 32-bit code CANNOT be run unless the CPU is in 32-bit mode. That's how it works: Certain tasks will be configured to execute in 32-bit mode by the OS (and the processor switches to it appropriately) whereas others run in 64-bit mode.

The proccessor doesn't need to change any code, when a 32-bit application addresses a register (for example: eax) the proccessor just uses the lower DWORD of the register (eax being the lower DWORD of rax). Just like you can access 16-bit and 8-bit parts of a register in 32-bit mode (for example 16-bit ax and 8-bit al), you can do the same in 64-bit mode.

64 bits is equivalent to approximately 32 "shave and a haircut" sessions.

Quote:

Original post by trzy Quote: How can 64-bit processors have all these improvements, while still being able to run 32-bit apps? Surely these additions would modify the machine code. Are they literally translating each instruction into its 64-bit equivelant before processing, and if so, how do they know if it's a 32-bit app or a 64-bit app? They certainly can modify the machine code (as I think is the case in AMD64)

As far as I'm aware, the AMD64 doesn't do that (At least not for 64 bit instructions specifically. The P4 (And maybe also A64?) stores code in cache as micro-ops, a special RISC-like format. But they do that with 32 bit code for efficiency reasons. They don't translate 32 bit instructions to 64.
The processor just supports multiple modes. If it runs in 32 bit mode, then it recognizes 32bit instructions only, and only uses the 8 old 32bit registers. When it runs 64 bit mode, it accepts 64 bit instructions.

It's just up to the OS to keep track of this and switch modes appropriately. Works essentially the same as when you try to run 16-bit code on a 32-bit cpu.

To support the point that it means roundly bitness of registers:

IIRC, either AMD64 or all AMD64 mobos currently have only 48bits address bus (edit: correction, only 40 bits, so you can't plug more than 1TB ram, hehe), but i guess it could be rather easily overcomed, without any software modification necessary. Another IIRC, even Pentium1 had 64-bit data bus... and another IIRC, some cheap 386 models had 16 bit data buss (for pluggability into 286 mobos), and was 32 bit by itself.

Normally, bitness shoulda stands for width of summator and width of general purprose registers that can be used for adressing. (and, FPU probably have 64 bit summator, or at least 52.)

Also, 32bit address space is 4GB big, but because of how operating systems was developed, most can access not more than 2GB on 32-bit system...

[Edited by - Dmytry on January 19, 2005 3:20:10 PM]

Quote:

Original post by Dmytry IIRC, AMD64 have 48bits adress bus.

40-bit physical, 48-bit PAE. Just like Intel's new EMT-64 Prescotts.

Quote:

Original post by Spoonbender As far as I'm aware, the AMD64 doesn't do that (At least not for 64 bit instructions specifically.

What I meant is that the operand format may be different in 64-bit mode. I'm not sure of the details but I imagine there is some difference because there are 8 more GPRs in 64-bit mode (R8-R15.)

Quote:

When it runs 64 bit mode, it accepts 64 bit instructions

They probably decode internally into the same kind of micro-ops and in 32-bit mode, adjustments are made for computations to chop to 32-bits and set flags accordingly. I don't know the details. For simplicity's sake, I imagine that regardless of whether a 32- or 64-bit mode instruction passes through the decoder, the output will be the same kind of micro-ops.

However, the OS can have an overload when translating 32-bit pointers from 32-bit applications to 64-bit in AMD64. Performance will decrease a little when you run a 32-bit app in a 64-bit OS, than if it was in a pure 32-bit OS.

The performance difference is not that huge however. I made a comparison between 32-bit and 64-bit GNU/Linux here:

http://www.hardinfo.dk/show.asp?page=5167

Warning: It's in danish, but the graphs are fairly international ;)

The reason why the i.e. xvid encoding is a bit slower is that the encoder I was using was not very optimized - it was an initial version of the port of the x86 ASM encoder, and I am sure that with time it will become faster in 64-bit than in 32-bit :-)

Quote:

Original post by Wytter However, the OS can have an overload when translating 32-bit pointers from 32-bit applications to 64-bit in AMD64. Performance will decrease a little when you run a 32-bit app in a 64-bit OS, than if it was in a pure 32-bit OS. The performance difference is not that huge however. I made a comparison between 32-bit and 64-bit GNU/Linux here: http://www.hardinfo.dk/show.asp?page=5167 Warning: It's in danish, but the graphs are fairly international ;) The reason why the i.e. xvid encoding is a bit slower is that the encoder I was using was not very optimized - it was an initial version of the port of the x86 ASM encoder, and I am sure that with time it will become faster in 64-bit than in 32-bit :-)

Why? The proccessor can dereference 32-bit pointers all right.