pointer normalization

[Charlton Wilbur]

Re: pointer normalization

>>>>"MD" == Morris Dovey <mrdovey@iedu.c omwrites:

(quoting someone else, which attribution I have lost)

>If the top 4 bits are taken outside, they should be decoded
>(eg. zeros). Otherwise extending the memory beyond 4K words
>becomes difficult. And problems on those top 4 address lines
>might be missed.

MDI'm almost embarassed to point out how easily any such
MDproblems are avoided. All that decoding unused address lines
MDgets is increased product cost. We already have enough
MDbloatware without building it into circuits, too.

>If not then the uP should insist those 4 bits were zero or
>whatever. Then the same software can run on a version with more
>address lines.

MDNah - it's a non-issue, and only worth mentioning as an
MDexample of multiple addresses pointing to the same memory
MDlocation.

Ask the people of Mac SE/30s who had to struggle with "32-bit clean"
software issues, particularly from Microsoft, if it's a "non-issue."

You see, in the early days of the Macintosh computer line, around the
time that the Macintosh II came out, it was obvious to anyone that
only 24 bits of memory addressing would ever be necessary.
Microsoft's products, most notably Word, used the upper 8 bits of the
32-bit pointer to hold information about the pointer.

Of course, like the famous 640K prediction, this one was also false,
and when Macs came out that actually had enough memory, virtual and
otherwise, so that full 32-bit addressing was useful, people had to
cope with the backwards Microsoft decision, and the resulting random
crashes of Word, destroying hours' worth of work, for several years
while it all got straightened out.

So yeah, if you are *sure* that you'll never need the full range of
pointers, don't bother with any sort of normalization. Just use
Microsoft as an object lesson.

Charlton


--
Charlton Wilbur
cwilbur@chromat ico.net

[Erik Trulsson]

Re: pointer normalization

Charlton Wilbur <cwilbur@chroma tico.netwrote:

>>>>>"MD" == Morris Dovey <mrdovey@iedu.c omwrites:

>
(quoting someone else, which attribution I have lost)
>

>If the top 4 bits are taken outside, they should be decoded
>(eg. zeros). Otherwise extending the memory beyond 4K words
>becomes difficult. And problems on those top 4 address lines
>might be missed.

>
MDI'm almost embarassed to point out how easily any such
MDproblems are avoided. All that decoding unused address lines
MDgets is increased product cost. We already have enough
MDbloatware without building it into circuits, too.
>

>If not then the uP should insist those 4 bits were zero or
>whatever. Then the same software can run on a version with more
>address lines.

>
MDNah - it's a non-issue, and only worth mentioning as an
MDexample of multiple addresses pointing to the same memory
MDlocation.
>
Ask the people of Mac SE/30s who had to struggle with "32-bit clean"
software issues, particularly from Microsoft, if it's a "non-issue."

For a general purpose-computer with lots of third-party software it can
indeed be a problem.

For an embedded device (CPUs with only 4K words are not used in anything
except embedded devices nowadays) it is not a problem.
Here people can switch to a completely different CPU architecture (with
all the porting this entails) if they can save 50 cents per unit.

For embedded devices one usually does not need to care about binary
compatibility (or even source code compatibility) with previous or
future generations of the product.

>
You see, in the early days of the Macintosh computer line, around the
time that the Macintosh II came out, it was obvious to anyone that
only 24 bits of memory addressing would ever be necessary.
Microsoft's products, most notably Word, used the upper 8 bits of the
32-bit pointer to hold information about the pointer.
>
Of course, like the famous 640K prediction, this one was also false,
and when Macs came out that actually had enough memory, virtual and
otherwise, so that full 32-bit addressing was useful, people had to
cope with the backwards Microsoft decision, and the resulting random
crashes of Word, destroying hours' worth of work, for several years
while it all got straightened out.
>
So yeah, if you are *sure* that you'll never need the full range of
pointers, don't bother with any sort of normalization. Just use
Microsoft as an object lesson.
>
Charlton
>
>

--
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@studen t.uu.se

[Morris Dovey]

Re: pointer normalization

Charlton Wilbur wrote:

So yeah, if you are *sure* that you'll never need the full range of
pointers, don't bother with any sort of normalization. Just use
Microsoft as an object lesson.

Hmm. My choice would be to _not_ use M$ in /any/ context.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA

http://www.iedu.com/DeSoto/

[Charlton Wilbur]

Re: pointer normalization

>>>>"MD" == Morris Dovey <mrdovey@iedu.c omwrites:

MDCharlton Wilbur wrote:

>So yeah, if you are *sure* that you'll never need the full
>range of pointers, don't bother with any sort of normalization.
>Just use Microsoft as an object lesson.

MDHmm. My choice would be to _not_ use M$ in /any/ context.

Even as an example of what not to do?

Charlton


--
Charlton Wilbur
cwilbur@chromat ico.net

[Morris Dovey]

Re: pointer normalization

Charlton Wilbur wrote:

>

>>>"MD" == Morris Dovey <mrdovey@iedu.c omwrites:

>
MDCharlton Wilbur wrote:
>

>So yeah, if you are *sure* that you'll never need the full
>range of pointers, don't bother with any sort of normalization.
>Just use Microsoft as an object lesson.

>
MDHmm. My choice would be to _not_ use M$ in /any/ context.
>
Even as an example of what not to do?

There're enough examples without their contributions.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA

http://www.iedu.com/DeSoto/

[sophia]

Re: pointer normalization

On Apr 16, 5:52 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:

sophia said:
>
>
>
>
>

On Apr 16, 7:59 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

sophia said:

>

Dear all,

>

 can any one explain what is meant by pointer normalization
given here:-

>

http://c-faq.com/ansi/norml.html

>

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.
>
Logical    Logical    Physical
segment    offset     address
address    address
  0001       1030     01040
  0002       1020     01040
  0003       1010     01040
  0004       1000     01040
  0005       00F0     01040
>
etc.
>
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.

Peter van der linden in his book says that

An address on the intel 8086 is formed by combining a 16- bit segment
with a 16 bit offset......... ............... ..
............... ............... ............... ........
............... ............... ..............

In general , there will be 4096 different segment/offset combinations
that point to the same address.

A C - compiler writer needs to make sure that pointers are compared in
canonical form on a P.C , otherwise two pointers that have different
bit patterns but designate the same address may wrongly compare un
equal. this will be done for you if you use the "huge" keyword, but
does not occur for the large model.

now question is

In present day 32 bit C compilers how this pointer normalization
done ?

[Bartc]

Re: pointer normalization

sophia wrote:

Peter van der linden in his book says that
>
An address on the intel 8086 is formed by combining a 16- bit segment
with a 16 bit offset......... ............... ..
............... ............... ............... ........
............... ............... ..............
>
In general , there will be 4096 different segment/offset combinations
that point to the same address.

....

In present day 32 bit C compilers how this pointer normalization
done ?

If you're talking about common desktop PCs, there usually isn't any
normalisation needed, each pointer is a linear 32-bit value.

But there will always be a few odd machines with strange ways of addressing
memory. And with 64-bit machines, if 32-bit and 64-bit pointers are ever
mixed in the same application, some normalising is needed there (but the
situation is a little different: a short pointer with a long one).

That's the compiler's headache however not yours.

Are you researching an article or something?

--
Bart

[Gordon Burditt]

Re: pointer normalization

>Peter van der linden in his book says that

>
>An address on the intel 8086 is formed by combining a 16- bit segment
>with a 16 bit offset......... ............... ..

>In general , there will be 4096 different segment/offset combinations
>that point to the same address.
>
>A C - compiler writer needs to make sure that pointers are compared in
>canonical form on a P.C , otherwise two pointers that have different
>bit patterns but designate the same address may wrongly compare un
>equal. this will be done for you if you use the "huge" keyword, but
>does not occur for the large model.

A compiler writer only needs to worry about normalizing pointers
if non-normalized pointers can occur by normal operation of C. For
example, in large model, pointer addition affects only the offset
and you can't have an object larger than 64k, so pointer arithmetic
won't generate un-normalized pointers, so a straight 32-bit comparison
can be used to compare pointers (assuming you've covered all the other
ways of generating un-normalized pointers). However, in huge model,
objects can be larger than 64k, and pointer arithmetic may alter
the segment, so you have a choice of pointer arithmetic always doing
normalizing, or comparing pointers doing normalizing.

>In present day 32 bit C compilers how this pointer normalization
>done ?

Present day desktops use linear addresses (unless you're talking
about Pentium 48-bit pointers and a larger than 4GB address space
for an individual process). You can't have an un-normalized pointer,
so it's a non-issue.