Re: working with addresses

From: Jumbo (nospam)
Date: 01/15/04


Date: Thu, 15 Jan 2004 14:54:40 -0000


"Martijn Lievaart" <m@remove.this.part.rtij.nl> wrote in message
news:pan.2004.01.15.08.38.17.358368@remove.this.part.rtij.nl...
> On Thu, 15 Jan 2004 03:36:48 +0000, Jumbo wrote:
>
> >> >> > Well give us an example of these instructions you CLAIM to be
> >> >> > available on most CPU's
> >> >> > :-)
> >> >>
> >> >> MOV ES:[EBX], EAX;
> >> >
> >> > This is DOS style segment:offset addressing. This does not change the
> >> > addressing mode of the CPU.
> >>
> >> That is the point! No mode switches are needed! And BTW, it's 32 bit
code,
> >> not 16 bit msdos code.
> >>
> > You said that a simple instruction could change the size of the CPU's
> > addressing mode.
>
> I said no such thing. I stated that there are CPUs where you can use
> different sized pointers and that there are instructions for working with
> these different sized pointers. You somehow coupled that with mode
> switching and other ways of changing pointer sizes. I never talked about
> /changing/ pointer sizes, I talked about cases where different pointers
> /are/ different sized.
>
> > This instruction does not change the size of the CPU's addressing mode
> > it simply loads a register.
> > This type of addressing was virtual-86 mode.
>
> No it isn't. Reread what I said below.
>
> >> > On the 386 this is real mode and uses something like a 20-bit address
> >> > bus. To change the addressing mode to 32-bit you need to switch to
> >> > protected mode which is somewhat more complicated than simply
> >> > executing a single instruction.
> >>
> >> This was 32 bit mode addressing, showing how to use a segment register
> >> to access another segment. It's a way to address more than 4GB on a
> >> Pentium, or to access a different mapping of memory (f.i. kernel vs
> >> user). It something one does daily. It does show that the Pentium knows
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> about 48 bit pointers, which can be used in 32 bit mode. Probably there
> >> already is a compiler out there that uses this to break the 4GB
> >> barrier, just like in the good ol days of msdos it broke the 64KB
> >> barrier.
> >
> > Assembly programmers do not use segments these days they use flat mode
> > and it doesn't quite work like that.
>
> Yes it does. But I made a horrible typo above, I ment something one does
> /not/ do daily. Sorry.
>
> > In virtual-86 mode the offset is converted to a 20-bit address then
> > tables are used to merge this with the segment address , this resolves
> > to a true 32-bit address which is put on the address bus. Thus what you
>
> A rather incomplete description of what happens on a 8086, with
> virtual 86 mode thrown in, but so far OT I'll let it rest.
>
> > have demonstrated is not true 32-bit addressing, although it uses a
> > 32-bit address bus and a 32-bit register.
>
> Of course I haven't demonstrated true 32 bit addressing. Depending how you
> look at it, I demonstrated 36 or 48 bit addressing.
>
> >> That same food ole msdos is a good example of different sizes for code
> >> and data pointers. Different memory models allowed different pointer
> >> sizes. In all fairness, and IIRC, only borland smart-huge and the
> >> memory models with 16 bit data pointers could be conceivably be called
> >> standard conforming. Working with the 32 bit data pointers (far
> >> pointers) was a huge pain in the b*tt.
> >>
> > Yes I have raised this point already about near and far pointers and I
> > was abrubtly told that C had no concept of this :-) But I agree that
>
> Bad wording on my part, sorry. I ment just to say memory models that use
> 32 bit datapointers on a 8086 (apart from Borlands smart-huge).
>
> > there will be different sized pointers this is why I raise the now
> > familiar question:
> > Is it true that sizeof(apointer) will always be the same on a given
> > system?
>
> As noted above, no. 8086 allows some 16 bit data and 32 bit code popinters
> and some other processors use 32 bit code and 64 bit data pointers.
>
> There are examples (see the FAQ) where pointers to different datatypes
> are really different. I personally never encountered them (conciously),
> although I did once use a system (now what system was that again) that
> used the lower bits as tags when the type pointed to was bigger than a
> byte (which was 8 bits on that system). Converting an unaligned pointer to
> char to some other type made for interesting results.
>
> > I think from the link you posted about 64-bit pointers that we can agree
> > that in some special exceptions it is not true. But in generall I think
> > you will find that your pointers are the same size.
>
> On most modern 32 bit OSses, yes. On modern 32/64 bit OSses, no not
> neccesarily.
>
> With the transistion to 64 bits I would not be surprised if we encounter
> the same situation as with msdos memory models, so this could very well
> not be true next year.
>
With a 64-bit cpu in the future all addresses will generally still be
64-bit. Even if we only want a pointer to 2bytes the address will still be
64-bit.
Alignment is a speed issue not a size issue . The size of a pointer to a
*real* address is ultimately defined by the size of an address bus . The
size of a segment:offset address is defined by near or far, however at
machine architechture level this must be resolved to a *real* address
eventually so the maximum addressing capabilities of the machine is still
defined by the size of the address bus.

In virtual-86 mode the cpu creates a 20-bit address from the segment:offset
then this virtual address is processed via paging tables to resolve it to a
real 32-bit address. We can only have 256 paging tables as the limit is
4.3G. This process is really somewhat more complicated than that and I don't
pretend to be an expert or try to explain it fully but it's suffice to say
that your theory of using segments :offsets to create 48-bit pointers would
fail unless the address bus was 48-bit.

On a system where the address bus is 64-bit then all pointers will be 64-bit
. So there will be no need to make any pointer anything other than 64-bit,
just as today on a modern 32-bit system there is no need for a pointer to be
anything other than 32-bit. Yes I can imagine a 64-bit system where you can
use half of the address bus to access 32-bit memory and the whole address
bus to access 64-bit memory and in this case is would be reasonable to have
differnet sized pointers, like in the intel cpu where the I/O addresses are
16-bit and the main RAM is 32-bit. Thus we could have a 16-bit address to an
add-on card whilst having a 32-bit address to Main memory. Such it is
possible to have both 32-bit memory and 64-bit memory on the same system,
but what is the point in having 32-bit memory when you can have 64-bit
memory? If the clock speed is the same then there is no speed difference and
only a tiny efficiency cost in terms of energy saving.



Relevant Pages

  • Re: Is this math test too easy?
    ... communications glitch; one of the more laughable cartoons ... (A note on "in memory", which for virtual memory machines can get ... Or one can interpret the character string as one of the values ... DOS allowed NULL pointers; the value was in fact interpreted as ...
    (sci.math)
  • [PATCH 2.6.17-rc4 2/6] Some documentation for kmemleak
    ... +Kernel Memory Leak Detector ... +with the difference that the orphan pointers are not freed but only ... +An allocated block of memory is considered orphan if a pointer to its ... The memory allocations hook stores the pointer address together ...
    (Linux-Kernel)
  • [PATCH 2.6.17-rc5 2/7] Some documentation for kmemleak
    ... +Kernel Memory Leak Detector ... +with the difference that the orphan pointers are not freed but only ... +An allocated block of memory is considered orphan if a pointer to its ... The memory allocations hook stores the pointer address together ...
    (Linux-Kernel)
  • [PATCH 2.6.17-rc5 2/8] Some documentation for kmemleak
    ... +Kernel Memory Leak Detector ... +with the difference that the orphan pointers are not freed but only ... +An allocated block of memory is considered orphan if a pointer to its ... The memory allocations hook stores the pointer address together ...
    (Linux-Kernel)
  • [PATCH 2.6.17-rc5 2/8] Some documentation for kmemleak
    ... +Kernel Memory Leak Detector ... +with the difference that the orphan pointers are not freed but only ... +An allocated block of memory is considered orphan if a pointer to its ... The memory allocations hook stores the pointer address together ...
    (Linux-Kernel)