Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Today was day 2 of my hardware class. We went over chapter 3 of our book, which is processors, and we talked about all that good stuff.
I already knew that 32-bit/64-bit referred to the address bus. However, my instructor informed us that 64-bit processors do not actually have a 64-bit address bus, but instead a 36-bit address bus. Is this true, and if so, why do they call it a 64-bit CPU instead of 36-bit?
I already knew that 32-bit/64-bit referred to the address bus.
I don’t think this is true. For example, the i686 (i.e., Pentium Pro) has a 64-bit data bus but is most surely 32-bit. I think the 32 or 64 generally refers to the size of the virtual address space (i.e., how big a general-purpose integer register should be so that it can hold an arbitrary memory address).
Distribution: Distribution: RHEL 5 with Pieces of this and that.
Kernel 2.6.23.1, KDE 3.5.8 and KDE 4.0 beta, Plu
Posts: 5,700
Rep:
Man that is one confusing question let alone the answer. I google for the following
' 64 bit processor 36 bit address ' and found one mess of answers. It does not make since to me yet.
The bit size of a modern CPU is almost an arbitrary number decided upon by the marketers of the design. So many different aspects use so many different sizes that no size is really representative.
But for x86, the 32 bit CPUs (or mode of a 64 bit CPU) do internally use 32 bit addresses and the 64 bit CPUs (when running 64 bit mode) do use 64 bit addresses.
Those sizes refer to the actual programming language objects (such as pointers in C or registers used for addressing in asm) used to address memory.
In 32 bit x86, 32 bits is also the number of bits in the size of the virtual address space.
In 64 bit x86, there are 48 bits in the size of the virtual address space. However, that restriction is only represented in a few CPU features that are touched only by kernel code. If someone invented a compatible next generation of x86_64 CPUs supporting more than 48 bit virtual addressing, only OS kernels would need to change to support those. Ordinary programs could be binary compatible.
Most CPUs don't have anything you would reasonably call a "physical address bus" (physical addresses are multiplexed in fairly complex ways). But each CPU model does have some limit on physical addressing. Various x86_64 CPUs have various limits and some of those are 36 bits. The x86_64 architecture itself also has a limit on physical addressing (I forget what it is). But like the 48 bit limit on virtual addressing, an architecture change to increase that limit would affect only kernel code. Within that architecture physical limit (that I've forgotten) differences in CPU addressing limits (36 bit physical vs. 40 bit physical, etc.) don't even affect kernel code. Until you actually connect ram or mapped IO to a CPU to need more than 36 bit physical, even the kernel doesn't care where exactly that limit lies.
Quote:
Originally Posted by LinuxCrayon
I already knew that 32-bit/64-bit referred to the address bus.
"address" yes.
"bus" no.
32-bit/64-bit refers to the size of an address as used by all native software.
A "bus" has to be a physical address (but a physical address doesn't need to be a "bus"). The physical address for any one model of 32 bit x86 chip may be larger or smaller than 32 bits. The physical address for any existing model of 64 bit x86 is much smaller than 64 bits.
To add to what Johnsfine said: On intel cpu motherboards the memory controller is on the motherboard (as opposed to AMD's being on the cpu) and some motherboard chipsets are only 32bit(intel 945?). On these motherboards(with 64bit cpu) you have all the same memory limitations as a 32bit cpu.
According to my textbook, Managing and Troubleshooting PCs, Second Edition, by Mike Meyers, on pg. 96:
Quote:
With the 32-bit address bus of the Pentium and later CPUs, the maximum amount of memory the CPU can address is 2**32, or 4,294,967,296 bytes . With a 64-bit address bus, CPUs can address 2**64 bytes of memory, or more precisely, 18,446,744,073,709,551,616 bytes of memory...
And later on the same page:
Quote:
No 64-bit CPU uses an actual 64-bit address bus. Right now, the most RAM anybody uses is 4 GB, so there's no much motivation for creating a CPU or a motherboard that can handle and hold 16 EB. Every 64-bit processor gets its address bus "clipped" down to something reasonable. The Intel Itanium, for example, only has a 44-bit address bus for a mazimum address space of 2**44...
The emphasis on bus is mine because you said know to the bus portion of address bus. By saying no to bus, I'm assuming you're referring to address registers?
If they are 64-bit, shouldn't that mean they're capable of being 64-bit? If so, why "clip" them down? And if you clip them down, shouldn't you then refer to it by its new name? Couldn't that technically be misadvertisement?
Also, another CPU question. My instructor said that the fastest multiplier speed he's seen recently is 8x. I'm assuming he's either wrong or hasn't worked with recent hardware in ages. I was under the impression that multiplier speeds were significantly higher than that, say in the 12-20 range.
It's a little confusing. I'm sorry. I'd ask my professor, but as I stated earlier I really just don't like him. He's a little...rude.
According to my textbook, Managing and Troubleshooting PCs, Second Edition, by Mike Meyers, on pg. 96:
There is some room for interpretation and for saying it is a semantic question rather than a factual question. But in my opinion, by using the word "bus", he has established the meaning of that sentence in a way that makes it flat out wrong.
Quote:
If they are 64-bit, shouldn't that mean they're capable of being 64-bit? If so, why "clip" them down?
All modern general purpose CPU designs use "virtual memory". That means there must be mapping hardware in the CPU that translates every address from a virtual address to a physical address.
A translation from a 64-bit virtual address to a 64-bit physical address would be wastefully expensive. So the AMD64 architecture has programs use 64 bit addresses, but it only translates from a 48-bit virtual address to a 52-bit physical address.
A 64-bit address can access 16,777,216 Terabytes. The AMD64 design will translate addresses that are in the bottom 128 Terabytes and addresses that are in the top 128 Terabytes. But any address in the middle 16,776,960 Terabytes will be rejected by the translation system.
Signals going out of the physical CPU package are much more expensive in both the fabrication cost and power use of a CPU than internal signals. So at the point of translation from 48 bit virtual to 52 bit physical, the CPU thows away the top bits, so it only uses 36 or 40 (in models I know about) bits of physical address.
Quote:
And if you clip them down, shouldn't you then refer to it by its new name? Couldn't that technically be misadvertisement?
The important point is that it is all invisible to the application program.
An application program can be written and compiled now with the AMD64 architecture, that thinks it has full 64-bit addressing. If we assume that program solves varying size problems (as most useful programs do), it would request from the OS enough virtual memory to solve the current problem, and the user would hope there is enough physical memory backing that virtual memory to allow the problem to be solved in a reasonable amount of time.
If you run that program today, the OS will probably limit that program to using no more than 16 Terabytes of virtual memory. No computer has enough physical memory that even allowing for massive address sparcity and swapping more than 16 Terabytes makes sense.
Someday ram will be cheaper and OS writers may support the full 128 Terabytes that AMD64 has designed for application programs (or maybe some OS's already do). If ram gets even cheaper, CPU makers might redesign the translation unit to translate more than 48 bits and OS writers would change that small part of the kernel, and then that same program without even recompiling could use more than 128 terabytes of virtual memory.
The true part of the advertising is that a program can be compiled and run now to use full 64-bit addressing, subject to only using addresses the kernel tels it are valid. That same program may some day run on a newer CPU and kernel and really get some benefit from having more than 48 bits in each virtual address.
Quote:
Also, another CPU question. My instructor said that the fastest multiplier speed he's seen recently is 8x. I'm assuming he's either wrong or hasn't worked with recent hardware in ages. I was under the impression that multiplier speeds were significantly higher than that, say in the 12-20 range.
So far as I understand, that multiplier on my computer is the ratio between the 200Mhz standard clock of the AM2 socket and the 3.2 Ghz clock of my CPU, so it is 16 for my system.
Maybe your instructor hasn't seen a variety of modern CPUs.
johnsfine, thank you! You've put it into clearer perspective than my instructor ever could have...and I'm going to have to take him for the MCSE classes, too!
Oh, and don't worry--I'm also taking the Linux classes and Cisco classes...I just believe in being well-rounded.
I see the last reply to this thread is 6 months old, so by now you may already have learned this:
The '64' part of 'x64' for a 64-bit processor has absolutely nothing to due with the address bus. It means that the general purpose registers (among others) in the processor is 64 bits, which also means the data bus is 64 bits.
In the 1980s the IBM XT (8088 microprocessor) was 16 bits internally but 8 bits externally and thus had an 8 bit data bus, as did the 6800 series Motorola microprocessor chips. Later, Motorola came out with the 68000 series, and IBM came out with the AT computers (Intel 80286), which were 16-bit internally and externally and had a 16-bit data bus. Later, Intel came out with 80386, 80486, and 80586 (pentium), which were all 32-bit internally and they all had a 32-bit data bus (externally), except the less expensive 80386SX, which was 32-bit internally, but had a 16-bit data bus externally.
For today's processors the x86 represents a 32-bit architecture that is backwards compatible to the 086, 286, 486, 586, and 686 architecture which is a 32-bit architecture sharing the same base instruction set as the 80086, with some extras added on for each step of the 286, 386, 486, 586, and 686 respectively. The x64 refers to the 64-bit architecture, with 64-bit registers and data bus, but also backwards compatible to the 32-bit x86 architecture. Thus, the x86 represents 32-bit architecture that also has other aspects of the 80x86 microprocessor architecture, while 'x64' refers to the 64-bit architecture that has backwards compatibility to the x86. But remember, it's the data bus thats 32 bit (x86) and 64-bit (x64) not the address bus.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.