Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Sizes of pointers

Reply
Thread Tools

Sizes of pointers

 
 
James Kuyper
Guest
Posts: n/a
 
      08-01-2013
On 08/01/2013 01:29 PM, Robert Wessel wrote:
> On Wed, 31 Jul 2013 19:30:50 +0200, Rosario1903
> <(E-Mail Removed)> wrote:

....
>> i not see the reasons for distinguish pointers from unsigned
>> [and all the concern they generate in portability of C programs]
>> in not consider the pointer just as one fixed size unsigned
>> for example something as:
>> p32u32 *p;
>>
>> p is a pointer that can contain one 32 bit address [unsigned]
>> that point to one array of 32 bits unsigned
>>
>> would resolve all problems i see of undefinitions
>> and portability of programs for pointer "point of view"
>>
>> if people has need of 64 bit pointers to u32
>> somehting
>> p64u32 *p;

>
>
> Simply because there are machines and implementations where pointers
> are *not* simple integers.


That doesn't quite answer the question. Why are such machines designed
that way? I know that they do exist, and write my programs accordingly,
but I don't know enough about hardware design to answer that question. I
know that some systems support the illusion of a simple linear address
space, even when the underlying reality is far more complicated. I don't
know what the issues are that prevent other systems from doing the same
- do you?

 
Reply With Quote
 
 
 
 
Rosario1903
Guest
Posts: n/a
 
      08-01-2013
On Thu, 01 Aug 2013 12:29:05 -0500, Robert Wessel wrote:

>On Wed, 31 Jul 2013 19:30:50 +0200, Rosario1903
><(E-Mail Removed)> wrote:
>
>>On Tue, 30 Jul 2013 11:02:45 +0100, "James Harris \(es\)" wrote:
>>>
>>>James

>>
>>i not see the reasons for distinguish pointers from unsigned
>>[and all the concern they generate in portability of C programs]
>>in not consider the pointer just as one fixed size unsigned
>>for example something as:
>>p32u32 *p;
>>
>>p is a pointer that can contain one 32 bit address [unsigned]
>>that point to one array of 32 bits unsigned
>>
>>would resolve all problems i see of undefinitions
>>and portability of programs for pointer "point of view"
>>
>>if people has need of 64 bit pointers to u32
>>somehting
>>p64u32 *p;

>
>
>Simply because there are machines and implementations where pointers
>are *not* simple integers.


how they disign machines not easy, and that not use math in general in
particular
unsigned integer math?

 
Reply With Quote
 
 
 
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      08-01-2013
James Kuyper <(E-Mail Removed)> wrote:
> On 08/01/2013 11:45 AM, Bart van Ingen Schenau wrote:


(snip)
>> Can you give an example how the DS9000 could make a conversion between
>> pointers to structs fail, given that the pointers involved are required
>> to have the same representation and alignment (and that the intent of
>> that requirement is to allow for interchangeability)?


> Well, the designers of the DS9000 are notorious for ignoring the intent
> of the standard; some have even claimed that they go out of their way to
> violate the intent.


Some years ago I was wondering about the possibility of generating
JVM code as output of a C compiler. Seems to me that it has pretty
many of the same problems as the DS9000, at least with the assumption
that you want to to run reasonably fast. (You could, of course,
write an 8086 emulator in Java and run 8086 code, but I don't
count that.)

Pointers to structs are one of the complications. Consider a
struct as an object of the appropriate class. You can pass around
references to the object, extract and modify fields in the object,
but you can't do some other things that C expects. If you cast
the pointer to (unsigned char*) then the compiler has to figure
out how to allow you to do many of those things.

-- glen
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      08-01-2013
James Kuyper <(E-Mail Removed)> wrote:
> On 08/01/2013 01:29 PM, Robert Wessel wrote:
>> On Wed, 31 Jul 2013 19:30:50 +0200, Rosario1903


(snip)
>> Simply because there are machines and implementations where
>> pointers are *not* simple integers.


> That doesn't quite answer the question. Why are such machines designed
> that way? I know that they do exist, and write my programs accordingly,
> but I don't know enough about hardware design to answer that question.


Well, consider protected mode on the 80286. (I believe still supported
by all later x86 processors.) You have a segment selector (16 bits)
and offset into the segment (16 bits).

Real (8086) mode you could think of as a funny way to address 1MB,
but protected mode allows for much bigger virtual addressing without
so much extra hardware. A segment selector selects a (64 bit)
segment descriptor (hidden from you by the OS). The descriptor
holds a segment origin and segment length (from 1 to 64K bytes).
You can do virtual memory swapping whole segments to/from disk.
The processor never has to consider instructions crossing page
boundaries, and the complications that causes. If a segment selector
can be loaded into a segment register, the segment is addressable.
If you subtract ring bits and global/local bit, that allowed for
a 29 bit virtual address space when most computers has 640K or RAM.

> I know that some systems support the illusion of a simple linear
> address space, even when the underlying reality is far more
> complicated. I don't know what the issues are that prevent other
> systems from doing the same
> - do you?


There were (maybe still in museums) machines with tagged memory.
Each memory word had bits to indicate the type of data stored
in it.

I believe there have also been machines where memory protection
depended on the compiler not generating code that could access
where it shouldn't, and users could only run the output of such
compilers. Whether or not addressing is linear, there is no way
to address something other than the way supplied by the system.
(I am not sure about C pointers on such processors.)

The main reasons are to make processors easier to build, and to
make more efficient use of the available bits.

-- glen
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      08-01-2013
On 31-Jul-13 12:30, Rosario1903 wrote:
> i not see the reasons for distinguish pointers from unsigned


What about systems with signed pointers, such as x86-64?

> [and all the concern they generate in portability of C programs]
> in not consider the pointer just as one fixed size unsigned for
> example something as:
> p32u32 *p;
>
> p is a pointer that can contain one 32 bit address [unsigned] that
> point to one array of 32 bits unsigned
>
> would resolve all problems i see of undefinitions and portability of
> programs for pointer "point of view"
>
> if people has need of 64 bit pointers to u32 somehting
> p64u32 *p;


So, you're proposing hard-coding the size of various types, which means
the code would gratuitously break when ported to a system that doesn't
have pointers and/or integers of exactly the specified size? How does
that improve portability in any meaningful way? It seems to me that
would make portability problems worse, not better.

The vast majority of code has no need to know exactly how wide pointers
are or, provided it meets the range requirements, exactly how wide an
integer type is. C's imprecise type system allows code to be _more_
portable than systems that are excessively precise, which is a big part
of C's enduring success.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      08-01-2013
On 08/01/2013 06:43 PM, Stephen Sprunk wrote:
> On 31-Jul-13 12:30, Rosario1903 wrote:
>> i not see the reasons for distinguish pointers from unsigned

>
> What about systems with signed pointers, such as x86-64?


A question came up awhile ago about whether pointers could be
meaningfully related to signed integers. I don't write the kind of code
where it makes any difference, so I didn't know whether there were any
such implementations, much less one as widely used as that one. I wish
someone had mentioned that during that discussion.

>> [and all the concern they generate in portability of C programs]
>> in not consider the pointer just as one fixed size unsigned for
>> example something as:
>> p32u32 *p;
>>
>> p is a pointer that can contain one 32 bit address [unsigned] that
>> point to one array of 32 bits unsigned
>>
>> would resolve all problems i see of undefinitions and portability of
>> programs for pointer "point of view"
>>
>> if people has need of 64 bit pointers to u32 somehting
>> p64u32 *p;

>
> So, you're proposing hard-coding the size of various types, which means
> the code would gratuitously break when ported to a system that doesn't
> have pointers and/or integers of exactly the specified size? How does
> that improve portability in any meaningful way? It seems to me that
> would make portability problems worse, not better.


Possibly he's implying that pointers must be stored in exactly 32 or 64
bits, regardless of the size of hardware addresses, with the C
implementation being responsible for trimming or padding the pointers as
needed to make that work. p32u32 would give access to no more that 4GB
of different memory locations, even on systems which have Etabtyes of
memory installed. On systems which have only 64KB of memory installed,
only the 16 low-order bits of each pointer would be meaningful, the rest
would be wasted. It would need to be specified which pointer type the
unary & operator returns, or perhaps two different operators would be
needed, one for each pointer type?
It would be possible to mandate this; I don't see any advantages,
though, and I expect that adding such a mandate to the standard would be
a good way to kill that version of C, permanently.

 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      08-02-2013
On 01-Aug-13 12:54, James Kuyper wrote:
> On 08/01/2013 01:29 PM, Robert Wessel wrote:
>> Simply because there are machines and implementations where
>> pointers are *not* simple integers.

>
> That doesn't quite answer the question. Why are such machines
> designed that way? I know that they do exist, and write my programs
> accordingly, but I don't know enough about hardware design to answer
> that question. I know that some systems support the illusion of a
> simple linear address space, even when the underlying reality is far
> more complicated. I don't know what the issues are that prevent other
> systems from doing the same - do you?


You seem to be under the impression that a flat linear address space per
process is always the best answer. That may not be true.

The usual counter-example is the AS/400, which puts every object into a
different segment. That enables strict bounds-checking, and it also
plays into the OS security scheme; processes share a single address
space, but you don't want one process/user to modify data belonging to
another process/user willy-nilly.

x86's 16-bit protected mode was sort of like that under early version of
Windows, but it didn't work very well because there were only a few
thousand segments available. Once the i386 introduced 32-bit offsets
and paging, segments became a vestigial CPU feature.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      08-02-2013
Stephen Sprunk <(E-Mail Removed)> wrote:

(snip on the properties of C pointers and addressing hardware)

> You seem to be under the impression that a flat linear address space per
> process is always the best answer. That may not be true.


> The usual counter-example is the AS/400, which puts every object into a
> different segment. That enables strict bounds-checking, and it also
> plays into the OS security scheme; processes share a single address
> space, but you don't want one process/user to modify data belonging to
> another process/user willy-nilly.


> x86's 16-bit protected mode was sort of like that under early version of
> Windows, but it didn't work very well because there were only a few
> thousand segments available. Once the i386 introduced 32-bit offsets
> and paging, segments became a vestigial CPU feature.


Well, there was one other problem and that is that they never
implemented a segment descriptor cache. Every segment selector
load requires loading a 64 bit descriptor. A cache would have sped
up processing in many cases.

With a good descriptor cache, 80386 protected mode, with 4GB segments,
might have delayed the need for 64 bit addressing. (That, and some
way around the 32 bit MMU.)

-- glen
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      08-02-2013
On 08/01/2013 10:50 PM, Stephen Sprunk wrote:
> On 01-Aug-13 12:54, James Kuyper wrote:
>> On 08/01/2013 01:29 PM, Robert Wessel wrote:
>>> Simply because there are machines and implementations where
>>> pointers are *not* simple integers.

>>
>> That doesn't quite answer the question. Why are such machines
>> designed that way? I know that they do exist, and write my programs
>> accordingly, but I don't know enough about hardware design to answer
>> that question. I know that some systems support the illusion of a
>> simple linear address space, even when the underlying reality is far
>> more complicated. I don't know what the issues are that prevent other
>> systems from doing the same - do you?

>
> You seem to be under the impression that a flat linear address space per
> process is always the best answer. That may not be true.


No, I'm saying that to address the issue raised by Rosario1903 requires
explaining why a flat linear address space per process is NOT the best
answer. I'm sure there's good reasons, and I have some idea what they
might be, but I'm not a hardware-oriented person, and am therefore not
the best person to explain those reasons.

I can, as a software-oriented person, say that a simple linear address
space per process simplifies the programming, so there had better be a
good reason for any platform that doesn't provide one.
--
James Kuyper
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      08-02-2013
On 01-Aug-13 18:10, James Kuyper wrote:
> On 08/01/2013 06:43 PM, Stephen Sprunk wrote:
>> On 31-Jul-13 12:30, Rosario1903 wrote:
>>> i not see the reasons for distinguish pointers from unsigned

>>
>> What about systems with signed pointers, such as x86-64?

>
> A question came up awhile ago about whether pointers could be
> meaningfully related to signed integers. I don't write the kind of
> code where it makes any difference, so I didn't know whether there
> were any such implementations, much less one as widely used as that
> one. I wish someone had mentioned that during that discussion.


Sorry, I must have missed that discussion. It's my favorite x86-64
quirk, so I rarely pass on an opportunity to mention it.

One _can_ describe x86-64 pointers in unsigned terms, and some sources
go to great lengths to do so; it's just that an explanation of certain
kernel details is both shorter and easier to understand when presented
in signed terms.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Different sizes of data and function pointers on a machine -- void*return type of malloc, calloc, and realloc Myth__Buster C Programming 23 06-26-2012 08:29 PM
pointers, pointers, pointers... cerr C Programming 12 04-07-2011 11:17 PM
Re: Win 7 changing font sizes without icon sizes? why? Computer Support 0 03-21-2010 11:32 AM
Re: Win 7 changing font sizes without icon sizes? why? Computer Support 0 03-21-2010 11:31 AM
The File Sizes of Pictures on my CDs Increased to Unreadable Sizes Marful Computer Support 11 03-08-2006 07:13 PM



Advertisments