Re: What does '64 bit' mean? Lame question, but hear me out :)

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Yousuf Khan (bbbl67_at_ezrs.com)
Date: 01/22/05 

Date: Fri, 21 Jan 2005 19:58:57 -0500

Christoph Nahr wrote:
> "64 bit" is not a clearly defined label. It means that *something*
> inside the CPU is 64 bit wide but it doesn't say what!
>
> Generally, though, a 64-bit CPU can be expected to have a "word size"
> of 64 bit. A "word" is the unit of data that the CPU can transport
> and process without having to slice it up into smaller pieces.

Actually, I think the word size is always the same size, 16-bit. 32-bit
is called double word (dword), and 64-bit is called quadword (qword).

I think what you're really trying talk about is called the "register size".

> And then there's the problem with wasted space. Lots of data actually
> fits in 32 bits just fine, which is one reason why we're so slow to
> move to 64-bit systems. Now when you have a 64-bit CPU but you
> actually just need 32-bit numbers you have two choices: pack two
> 32-bit numbers each into a 64-bit word and waste time with packing &
> unpacking; or only put one 32-bit number in a 64-bit word and waste
> half the memory space, in main memory and in the CPU cache!

There's not necessarily any wasted space, it depends on the 64-bit model
that Microsoft adopted for Windows. If you look at this link, it
discusses the various variations of the 64-bit model, such as LP64,
ILP64, & LLP64. I believe that Microsoft has chosen the LP64 model,
which means longs and pointers are 64-bit, but integers remain 32-bit.

64-BIT PROGRAMMING MODELS
http://www.opengroup.org/public/tech/aspen/lp64_wp.htm

LP64 recognizes the fact that perhaps most calculations won't require
using 64-bit integers (if you /really/ do need the 64-bit integer use
long), but their memory addressing modes certainly will.

> So whether a 64-bit CPU will actually speed up your application is
> rather doubtful. You can only expect a significant gain if you're
> already processing 64-bit integers. Likewise, the increased memory
> range will only benefit you directly if you're rummaging through huge
> databases; however, since operating systems and applications tend to
> get bigger and bigger anyway, this should still benefit the user who
> runs multiple programs at once.

The 64-bit CPU will speed up your applications but not because of the
64-bit upgrade. Some CPU manufacturers have taken the opportunity to add
a lot of other features at the same time as they upgraded the registers.
For example, they took the opportunity to add faster memory interfaces
into the processor. They also doubled the number of registers in the
processor from 8 to 16 of them. So even if you never need to use the
full 64-bits, you still have access to twice as many 32-bit registers. Etc.

> The whole situation is quite a bit different from the 16-to-32 bit
> swtich, from a perspective of expected gains. Back then everyone was
> constantly bumping against the 16-bit range which simply isn't enough
> to do much useful work, either in terms of value ranges or in terms of
> memory space. We're slowly exhausting the 2 GB RAM Windows leaves for
> apps but it's not critical yet, and 32 bits as a computational range
> have proved sufficient for nearly anything...

Actually it only seemed that way because the Intel 16-bit x86
instruction set was really a 20-bit memory addressing model. In other
words, the Intel 16-bit was an extended version of 16-bit. If Intel had
used a pure 16-bit memory model, then the maximum limit of memory
would've been really 64KB, and we would've been ready to switch to a
pure 32-bit instruction set probably by 1982. I don't know if you
remember computers like the Commodore 64 or the Apple II, which were
pure 16-bit addressing models. Intel extended the life of 16-bit by
almost a decade because of this one kludge. But it was a kludge, and
eventually all kludges come to a screeching halt and everybody clamours
to get away from them.

        Yousuf Khan

Relevant Pages

  • Re: kernel problem
    ... Scanning 0 areas for low memory corruption ... CPU: L2 Cache: 512K ... Performance Events: AMD PMU driver. ... generic registers: 4 ...
    (Linux-Kernel)
  • Re: pcib allocation failure
    ... pcib1: attempting to grow prefetch window for ... attempting to grow memory window for ... cpu0: on acpi0 ... <ACPI PCI bus> on pcib0 ...
    (freebsd-current)
  • Re: OT: IA-128 ???
    ... Would creating 128but floating point registers provide ... engine to store more of s database in memory to increase performance. ... Intel always pre-announces new technologies at IDF ... I'm sure everyone here already knew that some SSE2 instructions ...
    (comp.os.vms)
  • Next July 27: boot failure(hang) on x86_64 box.
    ... Freeing unused kernel memory: 1360k freed ... ACPI: PM-Timer IO Port: 0x488 ... CPU: L2 Cache: 1024K ... # AX.25 network device drivers ...
    (Linux-Kernel)
  • Re: The variable bit cpu
    ... what changes to the instruction set would you make to address data ... Possibly little changes since the cpu can detect the size of each variable ... Assuming the CPU and the main memory are seperated the communication between ... The CPU could act upon "virtual registers". ...
    (sci.electronics.design)