Here is the problem I am working on
The Problem: A high speed workstation has 64 bit words and 64 bit addresses with address resolution at the byte level. How many words can in be in the address space of the workstation?
I defined the different terms in the problem
Word Size - Processor natural unit of data. The word size determines the amount of information that can be processed in one go
Byte Level Addressing - Hardware architectures that support accessing individual bytes within a word
64 Bit Addressing - You have have 64 bits to specify an address in Runtime memory that holds an instruction or data
Address Space - Running program's view of memory in the system
How would you go about using all these definitions to solve this problem?
From 64 bits, I know that technically there are 2^64 locations in memory and from 64 bit words, that a processor processes 8 bytes a time. But I don't know how to use that information to conclude how many words are in the address space of the computer.
Thanks to aruisdante's comment, I was able to figure this out.
Basically 64 bit addresses means there are 2 ^ 64 total addresses. Because byte addressable memory is used here, each address will store one byte.
This means that in total, in the address space, 2 ^ 64 bytes can be stored. The problem tells you that the machine has 64 bit words or that each word is 8 bytes long. Therefore you have 2^64/8 or 2^64/2^3 = 2^61 words in the address space.
Related
While I am trying to understand the high memory problem for 32-bit cpu and Linux, why is there no high-memory problem for 64-bit cpu?
In particular, how is the division of virtual memory into kernel space and user space changed, so that the requirement of high memory doesn't exist for 64-bit cpu?
Thanks.
A 32-bit system can only address 4GB of memory. In Linux this is divided into 3GB of user space and 1GB of kernel space. This 1GB is sometimes not enough so the kernel might need to map and unmap areas of memory which incurs a fairly significant performance penalty. The kernel space is the "high" 1GB hence the name "high memory problem".
A 64-bit system can address a huge amount of memory - 16 EB -so this issue does not occur there.
With 32-bit addresses, you can only address 2^32 bytes of memory (4GB). So if you have more that, you need to address it some special way. With 64-bit addresses, you can address 2^64 bytes of memory without special effort, and that number is way bigger than all the memory that exists on the planet.
That number of bits refers to the word size of the processor. Among other things, the word size is the size of a memory address on your machine. The size of the memory address affects how many bytes can be referenced uniquely. So doing some simple math we find that on a 32 bit system at most 2^32 = 4294967296 memory addresses exist, meaning you have a mathematical limitation to about 4GB of RAM.
However on a 64 bit system you have 2^64 = 1.8446744e+19 memory address available. This means that your computer can theoretically reference almost 20 exabytes of RAM, which is more RAM than anyone has ever needed in the history of computing.
I'm aware that 32k = 32 * 2^10 which equals **32768 memory addresses**. However it is the byte that is throwing me off here. Does that indicate the width of the addressable memory?
How does the byte come into play here? Does that indicate byte addressable? If it were word addressable does that slash the available memory locations by half? Thanks for any replies in advance
There are basically two things in the computer architecture:
1:Address bus(n-bit processor)
2:Memory,
here, address bus defines the number of addresses in your system, suppose if you have 16 bit processor, that means you may have 2^16 address space,
and if you have 32K byte RAM, then this represents the memory of your system.
Now, how these 32K memory is represented in 2^16 address space that is different and how the memory is accessed is based on the type of addressing, whether it is byte addressable or word addressable.
Until now I thought that a 32-bit processor can use 4 GiB of memory because 232 is 4 GiB, but this approach means processor have word size = 1 byte. So a process with 32-bit program counter can address 232 different memory words and hence we have 4 GiB.
But if a processor has word size larger than 1 byte, which is the case with most of processors now days I believe (My understanding is that word size is equal to the width of data bus, so a processor with 64-bit data bus must have a word size = 8 bytes).
Now same processor with 32 bit Program counter can address 2^32 different memory words, but in this case word size is 8 bytes hence it can address more memory which contradicts with 4 GiB thing, so what is wrong in my argument ?
Your premise is incorrect. 32-bit architectures can address more than 4GB of memory, just like most (if not all) 8-bit microcontrollers can use more than 256 bytes of memory. Indeed a 32-bit program counter can address 232 different memory locations, but word-addressable memory is only used in architectures for very special purposes like DSPs or antique architectures in the past. Modern architectures for general computing all use byte-addressable memory
See Why byte-addressable memory and not 4-byte-addressable memory?
Even in 32-bit byte-addressable architectures there are many ways to access more than 4GB of memory. For example 64-bit JVM can address 32GB of memory with 32-bit pointer using compressed Oops. See the Trick behind JVM's compressed Oops
32-bit x86 CPUs can also address 64GB (or more in later versions) of memory with PAE. It basically adds a another level of indirection in the TLB with a few more bits in the address. That allows the whole system to access more than 4GB of memory. However the pointers in applications are still 32-bit long so each process is still limited to 4GB at most. The analog on ARM is LPAE.
The 4GB address space of each process is often split into user and kernel space (before Meltdown), hence limited the user memory even more. There are several ways to workaround this
Spawning multiple processes, which is used in Adobe Premiere CS4
Mapping the needed part of memory into the current address space, like Address Windowing Extensions on Windows
...
CPU (at least x86 family 32-bit) must be able to access any byte/word/dword in 4GB space. So an instruction is encoded such a way that target word size and memory address (usually) belong to different bit-fields. So it doesn't matter whether CPU accesses byte or dword, but the encoded memory address must be the same.
Note that 32-bit OS and x86 CPU technically is able to acccess more than 4GB address space using PAE mode. But it is not supported by, say, the current Windows OS family (except Server editions). Some versions of WinXP, as well as Linux and other 32-bit OS can address 64GB of memory on x86 CPU.
Also, usually OS reserves some part of virtual address space (for OS kernel, Video memory etc.), so user programs may use, say, no more than 3 GB of RAM of the 4GB an OS can address within each process.
I've been flying around the internet today trying to wrap my head around this topic. So here's what I understood so far. So the bigger the register size the bigger the instructions a processor can handle?
Quote:
The size of the registers, which is sometimes called the word size, indicates the amount of data with which the computer can work at any given time.
Question 1:
How would this be explained in terms of dealing with RAM? Why would a 32-bit processor be less adept or slower at processing information in this case?
Also, the term addressing. So while a 64-bit processor can "address" 2^64 different locations in RAM, a 32-bit processor can only deal with 2^32.
Question 2:
What does addressing mean? And why would the ability to address more locations be more helpful?
Question 3:
How are these 2 points, 1)Number of addressable locations and 2)Instruction size, related?
I hope my questions aren't confusing. It would be nice if references and examples to RAM as well as comparisons between 32 and 64-bits would be given in the explanations.
As chux already stated, there can be a lot of different bus width's in a computer system. That said, I assume you're talking about usual PC architectures here. Now, to your questions:
Performance difference between 32 and 64 bit systems
The hardware usually is able to operate on bigger numbers than a 32 bit system, so it can e.g. sum two 64 bits numbers in one operation, while a 32 bit system would need at least two (plus some operations to combine the results). This means a software that does lots of operations in big numbers will probably be faster on a 64 bit system, but a software that don't need big numbers will not be faster
A 64 bit processor usually fetch bigger blocks of data from memory than a 32 bit one. If the data bus is 64 bits instead of 32, it'll fetch double the bytes than the 32 bit system
This is actually a negative point in 64 bit system: since you have more addressable memory, you also need more memory for pointers, so 64 bit applications will also use a little more memory than the same aplication compiled for a 32 bit system.
Memory addressing
The memory address is a number that uniquely identifies a position in memory, where data is stored. With a 32 bit number, you can adress 2^32 positions, which is roughly 4 GB. This is why 32 bit PC's cannot use more than 4 GB of memory (they actually can, with some restrictions. See PAE). Using 64 bit numbers means the computer can now address 2^64 positions, which means it could, in principle, use up to 16 exbibytes of memory. In practice, other limits prevent a PC from having all that memory.
Addressable locations vs Memory Size
Since lots of instructions should reference a memory position, this means that some of them will have to be bigger, so they have room for memory adresses.
Bigger instructions usually means bigger software code, but this is not a problem in most cases, because the difference isn't that big, and because most of software size usually is composed of data, rather than code.
Disclaimer: Not all I said is valid for every software/architecture. There are a lot of detais that may have more impact in performace and memory usage than the points I wrote here.
The bit width of a processor's registers, it addressing range and the processor internal/external bus width between the processor and RAM are independent.
A 32-bit processor commonly can handle 32-bit addresses, but it may only handle 24 or maybe 64. Many possibilities have occurred.
Addressing would the the maximum range from 0 to N-1 of unique addresses that could be generated. If there is truly N locations of memory is another matter.
The width of the bus between CPU and RAM dramatically affects performance. This width, independent of CPU reg size and RAM size, throttle throughput.
Addressing range and resister size tend to correlate. Units with wider registers usually have wider address range. There is no rule that forces these 2 to be the same.
Suggest reviewing CPU architectures and micro controller and the theoretical Turing Machine
What I understood in a very naive way about 32 bit vs 64 bit processors is:
On 32 bit, an 'int' is represented as 32 bits but n 64 bit processor, int is represented as 64 bit. IS it right? IS this the only difference? From this over simplification, it is not clear why 64 bit is 'better' than 32 bit.
My other question is: If I have a simple client server application(java) where client is 32 bit and server is 64 bit, will that cause a problem when data is transferred between client and server?
In virtually every case, what makes a CPU 64-bits is the number of bits in the general-purpose registers, and as a consequence, the number of bits in a memory address.
Sadly, the C "int" does not vary with CPU size, and neither does the size of any other type AFAIK.
64-bit and 32-bit (and 16-bit and 8-bit) CPUs can process 8, 16, 32 and 64 bit integers [and floating point]. What they cannot all do is address memory with 64-bit addresses [or 32-bit addresses in the case of 16-bit and 8-bit CPUs].
Therefore, it does not matter what size CPU a client or server program is running on. What CAN matter, if the author of the program is not aware of CPU architecture issues, is that without careful specification, data sent by different CPUs can send their bytes in different order (like the 8-bytes of a 64-bit integer or floating-point number) and/or assume the bytes are in a different order.
My advice is to always order data to be transmitted in "little endian" order, because there IS only one little endian order. Sadly, there are several versions of big endian order, depending on CPU register/address size and CPU conventions for data-types larger than their register sizes. But not everyone agrees with me about this point.