Re: working with addresses
From: Jumbo (nospam)
Date: Thu, 15 Jan 2004 14:54:40 -0000
"Martijn Lievaart" <firstname.lastname@example.org> wrote in message
> 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
> >> 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
> 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
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.