It is possible for a pointer value to have more than one object
representation. If p1 and p2 are two pointers to the same object, but with
different object representations , then p1 == p2 is required to yield 1, so
the implementation must (behave as if to) supply code to "normalise" the
pointer values used in the comparison - i.e. to convert one or the other
or both to a common form. (This was perfectly common in MS-DOS days.)
Note that the same requirement (of identifying the equality of those two
pointers) is not imposed on memcmp(&p1, &p2, sizeof p1).
--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
>
It is possible for a pointer value to have more than one object
representation. If p1 and p2 are two pointers to the same object, >but with different object representations ,
Object in C means region of data storage isn't it ?
i am not getting your point,
same object with different representations ?
It is possible for a pointer value to have more than one object
representation. If p1 and p2 are two pointers to the same object,
but with different object representations ,
>
Object in C means region of data storage isn't it ?
>
i am not getting your point,
same object with different representations ?
>>
>It is possible for a pointer value to have more than one object
>representation . If p1 and p2 are two pointers to the same object, >but
>with different object representations ,
>
Object in C means region of data storage isn't it ?
>
i am not getting your point,
same object with different representations ?
Consider MS-DOS's 20-bit pointers, where logical addresses are described by
two 16-bit values, called "segment" and "offset" respectively. To get the
physical address, we left-shift the segment value by four bits, and then
add the offset value.
Five different pointer representations , all pointing to the same physical
object. All must compare equal when compared with ==. The implementation
is responsible for making this work.
--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
In article <aY2dnetnsYENaJ jVRVnyjwA@bt.co m>,
Richard Heathfield <rjh@see.sig.in validwrote:
....
>Consider MS-DOS's 20-bit pointers, where logical addresses are described by
>two 16-bit values, called "segment" and "offset" respectively. To get the
>physical address, we left-shift the segment value by four bits, and then
>add the offset value.
A nitpick surely worthy of this group...
It's not "MS-DOS's 20-bit pointers". This is a feature of the 8086
processors (and its descendants, running in "real mode"). It is not a
function of the OS in any way.
Further note that the descendants still maintain this functionality; it
is just that it is rarely used. It is no longer necessary (at least up
to the 4G mark. I'm not sure what happens if you have a machine with
more than 4G RAM).
>>Consider MS-DOS's 20-bit pointers, where logical addresses are described by
>>two 16-bit values, called "segment" and "offset" respectively. To get the
>>physical address, we left-shift the segment value by four bits, and then
>>add the offset value.
>
>A nitpick surely worthy of this group...
And note that a *real* first-class nitpicker would point out that it's
not even *MS*-DOS, as if this functionality were someone unique to
and/or invented by Microsoft...
It is possible for a pointer value to have more than one object
representation. If p1 and p2 are two pointers to the same object,
but with different object representations ,
>
Object in C means region of data storage isn't it ?
>
i am not getting your point,
same object with different representations ?
Consider, for example, "real mode" on an x86 CPU. On that particular
platform, addresses are represented by a 16-bit segment and a 16-bit
offset. (The physical address is segment*16+offs et.) Using this
particular architecture, the following segment/offset pairs all point
to the same physical address:
1234:0000
1230:0040
1200:0340
1000:2340
and even
1111:1230
0235:FFF0
In article <aY2dnetnsYENaJ jVRVnyjwA@bt.co m>,
Richard Heathfield <rjh@see.sig.in validwrote:
...
>Consider MS-DOS's 20-bit pointers, where logical addresses are described by
>two 16-bit values, called "segment" and "offset" respectively. To get the
>physical address, we left-shift the segment value by four bits, and then
>add the offset value.
>
A nitpick surely worthy of this group...
>
It's not "MS-DOS's 20-bit pointers". This is a feature of the 8086
processors (and its descendants, running in "real mode"). It is not a
function of the OS in any way.
>
Well if we're nitpicking.. :P
He didn't claim ms-dos 'owns or invented' the concept. He just offered
it as an example. MS-DOS did in fact have 20bit pointers because it ran
on 8086.
>>Consider MS-DOS's 20-bit pointers, where logical addresses are described by
>>two 16-bit values, called "segment" and "offset" respectively. To get the
>>physical address, we left-shift the segment value by four bits, and then
>>add the offset value.
>>
>A nitpick surely worthy of this group...
>>
>It's not "MS-DOS's 20-bit pointers". This is a feature of the 8086
>processors (and its descendants, running in "real mode"). It is not a
>function of the OS in any way.
>>
>
>Well if we're nitpicking.. :P
>He didn't claim ms-dos 'owns or invented' the concept. He just offered
>it as an example. MS-DOS did in fact have 20bit pointers because it ran
>on 8086.
I doubt the MSDOS standards document uses the phrase "20 bit"...
In article <aY2dnetnsYENaJ jVRVnyjwA@bt.co m>,
Richard Heathfield <rjh@see.sig.in validwrote:
...
>>Consider MS-DOS's 20-bit pointers, where logical addresses are
>>described by two 16-bit values, called "segment" and "offset"
>>respectivel y. To get the physical address, we left-shift the segment
>>value by four bits, and then add the offset value.
>
A nitpick surely worthy of this group...
>
It's not "MS-DOS's 20-bit pointers". This is a feature of the 8086
processors (and its descendants, running in "real mode"). It is not a
function of the OS in any way.
>
Further note that the descendants still maintain this functionality;
it is just that it is rarely used. It is no longer necessary (at
least up to the 4G mark. I'm not sure what happens if you have a
machine with more than 4G RAM).
The system could employ PAE to use upto 64 Gb, though applications still
see only 4 Gb and remain flat model based.
It is possible for a pointer value to have more than one object
representation. If p1 and p2 are two pointers to the same object,
but with different object representations ,
>
Object in C means region of data storage isn't it ?
>
i am not getting your point,
same object with different representations ?
>
not possible on a sane architecture, but see the "Segmentati on"
section ofhttp://en.wikipedia.or g/wiki/Intel_8086
Many sane architectures support virtual memory, by means of which you
can create aliases of the same object at different virtual addresses.
On some architectures, certain bits in an address determine whether,
for instance, the same address range is being accessed cached or
uncached.
There are also sane forms of segmentation, not simply based on
multiplying a segment by some constant and adding the offset.
In article <64de2778-0bab-4d92-aec1-de38c1c0f594@t5 4g2000hsg.googl egroups.com>,
Kaz Kylheku <kkylheku@gmail .comwrote:
It is possible for a pointer value to have more than one object
representation. If p1 and p2 are two pointers to the same object,
but with different object representations ,
Object in C means region of data storage isn't it ?
>>
i am not getting your point,
same object with different representations ?
>not possible on a sane architecture, but see the "Segmentati on"
>section ofhttp://en.wikipedia.or g/wiki/Intel_8086
>Many sane architectures support virtual memory, by means of which you
>can create aliases of the same object at different virtual addresses.
>
>On some architectures, certain bits in an address determine whether,
>for instance, the same address range is being accessed cached or
>uncached.
This is true, but not really relevant to the question. Such different
representations will not arise as a result of standard C operations.
An implementation may well provide a way to get an uncached pointer
to an object, but it is under no obligation to make that compare
equal to the cached version.
Comment