If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
size of physical memory is given by size of address registers in CPU or size of address bus??
i have read when we move from 32bit machine to 64bit, the size of
physical memory increases from 4GB(2pow32) to 16exabytes(2pow64). So it means that size of physical memory is limited by size of address registers in the CPU. Now as per 8086 architectute, registers are 16 bit but address bus is 20bit. So it says that we can address 2power20 memory locations using register values+offset. Here size of physical memory is working according to address bus(20 bits) and not registers(16 bit). So my query is whether it is size of address registers that determine the size of physical mem locations we can address or it is the address bus that governs this factor??? Plz put forward your points as i need them urgently for an ongoing project. |
#2
|
|||
|
|||
size of physical memory is given by size of address registers in CPU or size of address bus??
Arunaabh wrote:
i have read when we move from 32bit machine to 64bit, the size of physical memory increases from 4GB(2pow32) to 16exabytes(2pow64). So it means that size of physical memory is limited by size of address registers in the CPU. Now as per 8086 architectute, registers are 16 bit but address bus is 20bit. So it says that we can address 2power20 memory locations using register values+offset. Here size of physical memory is working according to address bus(20 bits) and not registers(16 bit). So my query is whether it is size of address registers that determine the size of physical mem locations we can address or it is the address bus that governs this factor??? The correct answer is "it depends." On most systems, the size of the address bus determines the maximum possible size of physical memory (although in practice, most inexpensive machines will have a limit much lower because of memory controller limits - we've been able to buy 32-bit desktop machines since the late 1980s and having a desktop machine where you could practically plug in 4gb of memory only goes back 3-4 years outside of the very high end world.) On most systems, the size of the address registers determines the maximum size of (linear) virtual memory. On some machines/processor architectures, those are exactly the same - this is true for most pure 32-bit CPUS from the mid-1980s to mid-late 1990s. For example, the 80386 through Pentium classic, the 68020 and Sparc v7/v8) On many older 32-bit processors (68000/68010 and IIRC the first generation Vaxen, 80386SZ also) and most current 64-bit ones (AMD64, certainly), the physical address lines are often smaller than the address register size. This can allow for future extension of the architecture. On most 8-bit architectures, and on many 16-bit architectures, the physical address bus was larger than the address register size either through segmentation 8086, 80286 and PDP-11 for example) or paired registers (8080/Z80, 6502, pretty much all 8-bit systems.) This is also true for some 32-bit systems (through PAE on P6-generation Intel processors, for example). -- Nate Edel http://www.cubiclehermit.com/ "What's the use of yearning for Elysian Fields when you know you can't get 'em, and would only let 'em out on building leases if you had 'em?" (WSG) |
#3
|
|||
|
|||
size of physical memory is given by size of address registersin CPU or size of address bus??
Arunaabh wrote:
i have read when we move from 32bit machine to 64bit, the size of physical memory increases from 4GB(2pow32) to 16exabytes(2pow64). So it means that size of physical memory is limited by size of address registers in the CPU. Now as per 8086 architectute, registers are 16 bit but address bus is 20bit. So it says that we can address 2power20 memory locations using register values+offset. Here size of physical memory is working according to address bus(20 bits) and not registers(16 bit). Don't confuse yourself with the old 16-bit x86 architecture. For all intents and purposes, it is mostly irrelevant in the 32-bit era, and it is completely irrelevant in the 64-bit era. Just for historical curiosity. The old 16-bit architecture obtained 20-bit addresses by combining two 16-bit registers together in a wierd overlapping tandem method known as the "segment" and the "offset". The upper part of the 20-bit address was represented by the 16-bit segment register, while the lower part was represented by the 16-bit offset register. Basically that meant that there were 12-bits in the middle of the address that could either be represented by incrementing a segment register or by incrementing an offset register, thus many different combinations of segment or offset could result in the exact same absolute address. All of that nonsense went away with the 32-bit architecture. Because the registers became a full 32-bit, thus a single register could represent the whole address space. Now, in 32-bit modes, you still had the option of continuing to use the old segment registers, and using that you could theoretically obtain a 48-bit address (16-bit segment, plus a 32-bit offset register); but nobody ever used the architecture like that, they only used the 32-bit offset register for everything ignoring the segment registers completely. In the 64-bit architecture, most vestiges of the old segment registers are gone now, you only use the 64-bit registers for all addresses now. So those segments are even more irrelevant in the 64-bit era. So my query is whether it is size of address registers that determine the size of physical mem locations we can address or it is the address bus that governs this factor??? It's the address bus that determines the size of the memory you can put on it. For example even though 64-bit architecture would make you think that this processor should be able to address upto 2^64 bytes of memory, most of the 64-bit architectures don't implement the full 64-bits for addressing yet. Thus if your processor architecture supported only upto 40-bits of the 64-bit address space, then 40-bits is your limit, that's all. Yousuf Khan -- There is no failure, only delayed success |
#4
|
|||
|
|||
size of physical memory is given by size of address registersin CPU or size of address bus??
Yousuf Khan wrote:
Arunaabh wrote: i have read when we move from 32bit machine to 64bit, the size of physical memory increases from 4GB(2pow32) to 16exabytes(2pow64). So it means that size of physical memory is limited by size of address registers in the CPU. Now as per 8086 architectute, registers are 16 bit but address bus is 20bit. So it says that we can address 2power20 memory locations using register values+offset. Here size of physical memory is working according to address bus(20 bits) and not registers(16 bit). Don't confuse yourself with the old 16-bit x86 architecture. For all intents and purposes, it is mostly irrelevant in the 32-bit era, and it is completely irrelevant in the 64-bit era. Just for historical curiosity. The old 16-bit architecture obtained 20-bit addresses by combining two 16-bit registers together in a wierd overlapping tandem method known as the "segment" and the "offset". The upper part of the 20-bit address was represented by the 16-bit segment register, while the lower part was represented by the 16-bit offset register. Basically that meant that there were 12-bits in the middle of the address that could either be represented by incrementing a segment register or by incrementing an offset register, thus many different combinations of segment or offset could result in the exact same absolute address. All of that nonsense went away with the 32-bit architecture. Because the registers became a full 32-bit, thus a single register could represent the whole address space. Now, in 32-bit modes, you still had the option of continuing to use the old segment registers, and using that you could theoretically obtain a 48-bit address (16-bit segment, plus a 32-bit offset register); but nobody ever used the architecture like that, they only used the 32-bit offset register for everything ignoring the segment registers completely. For values of "they" which equal Microsoft... The common 16 bit model (not "only") was 64k code and 64k data, with the data and stack segment in the same place. That eliminated the need to use segment prefix for accessing both program data and stack resident data. The NS-C and some of the UNIX compiler split the data and stack. In the 64-bit architecture, most vestiges of the old segment registers are gone now, you only use the 64-bit registers for all addresses now. So those segments are even more irrelevant in the 64-bit era. However, it would seem that the recent addition of an execute prevent bit to deter self-modifying code addresses some of the same issues that having a non-writable code segment and non-executable data and/or stack were used to prevent. If you look at the way modern x86 systems work, the things which were done in segments are now done in pages. Same idea of control, smaller and more numerous pieces. I still think the MULTICS hardware probably did it best (I know, not Intel related). -- bill davidsen SBC/Prodigy Yorktown Heights NY data center http://newsgroups.news.prodigy.com |
#5
|
|||
|
|||
size of physical memory is given by size of address registersinCPU or size of address bus??
Bill Davidsen wrote:
All of that nonsense went away with the 32-bit architecture. Because the registers became a full 32-bit, thus a single register could represent the whole address space. Now, in 32-bit modes, you still had the option of continuing to use the old segment registers, and using that you could theoretically obtain a 48-bit address (16-bit segment, plus a 32-bit offset register); but nobody ever used the architecture like that, they only used the 32-bit offset register for everything ignoring the segment registers completely. For values of "they" which equal Microsoft... The common 16 bit model (not "only") was 64k code and 64k data, with the data and stack segment in the same place. That eliminated the need to use segment prefix for accessing both program data and stack resident data. The NS-C and some of the UNIX compiler split the data and stack. And there were plenty of 3rd party libraries around that allowed you to use more than one 64K segments for each type of segment too. In the 64-bit architecture, most vestiges of the old segment registers are gone now, you only use the 64-bit registers for all addresses now. So those segments are even more irrelevant in the 64-bit era. However, it would seem that the recent addition of an execute prevent bit to deter self-modifying code addresses some of the same issues that having a non-writable code segment and non-executable data and/or stack were used to prevent. If you look at the way modern x86 systems work, the things which were done in segments are now done in pages. Same idea of control, smaller and more numerous pieces. Yeah, but what can you do? People have stopped using segments, so they had to bring all of those useful features into pages instead. It's probably the best of both worlds now: segements offered greater security features, while pages offered greater memory management granularity, put all of the security features of segments into pages and you get the best of both worlds. Yousuf Khan Yousuf Khan |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
A7V880 - 4x1GB DDR400 Unbuffered Modules...Is it possible? | News su Libero | Asus Motherboards | 2 | April 11th 05 09:40 AM |
On the brink of madness... | I.C. Koets | General | 18 | January 31st 05 10:49 PM |
64 bit processors | [email protected] | General | 34 | December 31st 04 04:44 PM |
Tualatin in a GA-6WMMC7 | ~misfit~ | Overclocking | 33 | April 23rd 04 06:30 AM |
FIC or HIS for a 9600Pro? | Phrederick | General | 8 | December 16th 03 12:17 PM |