1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

size of physical memory is given by size of address registers in CPU or size of address bus??

Discussion in 'Intel' started by Arunaabh, Apr 8, 2006.

  1. Arunaabh

    Arunaabh Guest

    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
    Arunaabh, Apr 8, 2006
    1. Advertisements

  2. Arunaabh

    Nate Edel Guest

    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, Apr 10, 2006
    1. Advertisements

  3. Arunaabh

    Yousuf Khan Guest

    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.
    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
    Yousuf Khan, Apr 13, 2006
  4. 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.
    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, Apr 17, 2006
  5. Arunaabh

    Yousuf Khan Guest

    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.
    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
    Yousuf Khan, May 6, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.