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.

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)

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

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

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