Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Do address have some special format to separate with common integers?

Reply
Thread Tools

Do address have some special format to separate with common integers?

 
 
vib.cpp@gmail.com
Guest
Posts: n/a
 
      02-22-2009
A pointer cannot hold a non_address value, but what is the difference
of the representation of address with an ordinary integer? do address
have some special format to separate with common integers?
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      02-22-2009
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> A pointer cannot hold a non_address value,


That depends on the architecture, on many common systems a pointer can
hold ant numerical value that fits within its width.

> but what is the difference
> of the representation of address with an ordinary integer? do address
> have some special format to separate with common integers?


Again, the answer is architecture dependant. Systems with segmented
address spaces have special pointer formats, those with flat address
spaces need not.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Richard
Guest
Posts: n/a
 
      02-22-2009
Ian Collins <(E-Mail Removed)> writes:

> (E-Mail Removed) wrote:
>> A pointer cannot hold a non_address value,

>
> That depends on the architecture, on many common systems a pointer can
> hold ant numerical value that fits within its width.
>
>> but what is the difference
>> of the representation of address with an ordinary integer? do address
>> have some special format to separate with common integers?

>
> Again, the answer is architecture dependant. Systems with segmented
> address spaces have special pointer formats, those with flat address
> spaces need not.


Those "special pointers" are still the "address".

 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-22-2009
Richard <(E-Mail Removed)> writes:

> Ian Collins <(E-Mail Removed)> writes:
>
>> (E-Mail Removed) wrote:
>>> A pointer cannot hold a non_address value,


That is not a well-defined term. Pointers can hold values that you
can't use to access an object. For example,: int i; int *ip = &i + 1;
is OK but you can't access *ip. That might be what you mean by a
non-address value though I would call it, informally, an invalid
pointer.

>> That depends on the architecture, on many common systems a pointer can
>> hold ant numerical value that fits within its width.
>>
>>> but what is the difference
>>> of the representation of address with an ordinary integer? do address
>>> have some special format to separate with common integers?

>>
>> Again, the answer is architecture dependant. Systems with segmented
>> address spaces have special pointer formats, those with flat address
>> spaces need not.

>
> Those "special pointers" are still the "address".


Yes, Ian Collins said so in the message you seem to be replying to. I
don't think anyone (serious) disputes the fact that valid object
pointers store addresses.

The OP raised two issues: "non-address values" and the degree to which
addresses are similar in representation to integers. Both of these
points have been answered at least to some extent, though I thought it
worth adding a bit more.

--
Ben.
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      02-22-2009
Malcolm McLean wrote:
>
> <(E-Mail Removed)> wrote in message news:
>> A pointer cannot hold a non_address value, but what is the difference
>> of the representation of address with an ordinary integer? do address
>> have some special format to separate with common integers?
>>

> Normally no, pointers are the same width as the natural integer type for
> the machine, and are just integers internally.


Malcolm, you KNOW that this is wrong. At least, you should do by now.

> However this doesn't always hold true. The most familiar exception is
> the old x86 series of chips found in early PCs. Addresses were segment +
> offset.


Although pointers were not always segment+offset. When they are (I know
there is still 8086 code out there) the pointer is larger than the
natural integer type.

Not all processors have only one natural integer type (registers one
size, data bus another size). I've used one where the address registers
and data bus were 16 bits but the accumulator was 32 bits. I've also
read specs for even more surprising combinations in the past.

It is now common once more for pointers to by larger than the int type,
for very good reasons.
--
Flash Gordon
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      02-22-2009
Richard wrote:
> Ian Collins <(E-Mail Removed)> writes:
>
>> (E-Mail Removed) wrote:
>>> A pointer cannot hold a non_address value,


>> That depends on the architecture, on many common systems a pointer can
>> hold ant numerical value that fits within its width.
>>
>>> but what is the difference
>>> of the representation of address with an ordinary integer? do address
>>> have some special format to separate with common integers?


>> Again, the answer is architecture dependant. Systems with segmented
>> address spaces have special pointer formats, those with flat address
>> spaces need not.

>
> Those "special pointers" are still the "address".
>

Did I say otherwise?

--
Ian Collins
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      02-22-2009
Malcolm McLean wrote:
>
> "Flash Gordon" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)-gordon.me.uk...
>> Malcolm McLean wrote:
>>>
>>> <(E-Mail Removed)> wrote in message news:
>>>> A pointer cannot hold a non_address value, but what is the difference
>>>> of the representation of address with an ordinary integer? do address
>>>> have some special format to separate with common integers?
>>>>
>>> Normally no, pointers are the same width as the natural integer type
>>> for the machine, and are just integers internally.

>>
>> Malcolm, you KNOW that this is wrong. At least, you should do by now.
>>

> "Normally" is code for "on Intel PCs".


Ah, so by "Normally" you mean the minority of cases. Every PC I've ever
come across has had more processors not based on the X86 architecture
(or its successors) than it has processors based on the x86
architecture. Then there are all the things which are not PCs.

> From Wikipedia:
>
> Intel has extensively documented the Itanium instruction set and


<snip>

> Sounds like the natural integer size is 64 bits. As is the natural
> integer size. If your C compiler doesn't provide 64-bit ints, complain
> and join my campaign to pressurise them to do so.


Intel recommend using a 32 bit int on the IA64. Therefore Intel consider
32 bits to be a natural size of the architecture. What makes you think
you know Intel architectures better than Intel do.
--
Flash Gordon
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-22-2009
Flash Gordon <(E-Mail Removed)> writes:
[...]
> Not all processors have only one natural integer type (registers one
> size, data bus another size). I've used one where the address
> registers and data bus were 16 bits but the accumulator was 32
> bits. I've also read specs for even more surprising combinations in
> the past.
>
> It is now common once more for pointers to by larger than the int
> type, for very good reasons.


A perhaps interesting data point: On all the C implementations I've
used (on which I've checked this), all pointer types are the same size
as long int. In some cases, this is the same size as int; in others,
long int is twice the size of int.

I do not suggest that this is "normal", just that it seems to be
common. I'm well aware that there are a lot of systems I haven't used
where this doesn't apply.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      02-22-2009
Malcolm McLean wrote:
>
> "Flash Gordon" <(E-Mail Removed)> wrote in message
>> Malcolm McLean wrote:
>>>

>> Intel recommend using a 32 bit int on the IA64. Therefore Intel
>> consider 32 bits to be a natural size of the architecture. What makes
>> you think you know Intel architectures better than Intel do.
>>

> All you need to know is that the architecture can address 64 bits of
> address space, and can load 64 bit data elements with reasonable
> efficiency. That's not a deep understanding of the architecture.


No, you also need to know what is efficient.

> What Intel lack is a deep understanding of programming issues.


I suspect they have a lot more knowledge about it than your or I. After
all, they also do compilers!

> The
> result of their policy will be that size_t becomes the default integer
> type.


Nope. For many reasons. Starting with all the code that is using int's
for monetary values. Then there is all the SW using int's for
coordinates. Not to forget all the other uses of int.

> Obviously, if everyone provided 64 bit ints, there would no need for a
> campaign for them.


There is no need for a campaign for them.
--
Flash Gordon
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-22-2009
"Malcolm McLean" <(E-Mail Removed)> writes:
> "Flash Gordon" <(E-Mail Removed)> wrote in message
>> Malcolm McLean wrote:
>>>

>> Intel recommend using a 32 bit int on the IA64. Therefore Intel
>> consider 32 bits to be a natural size of the architecture. What
>> makes you think you know Intel architectures better than Intel do.
>>

> All you need to know is that the architecture can address 64 bits of
> address space, and can load 64 bit data elements with reasonable
> efficiency. That's not a deep understanding of the architecture.
>
> What Intel lack is a deep understanding of programming issues. The
> result of their policy will be that size_t becomes the default integer
> type.


Why should there even be a "default" integer type, especially with the
removal of the implicit int rule in C99? Use whatever type is
appropriate for a given context. If you need a 64-bit signed integer,
you can use long long, int_least64_t, int_fast64_t, or int64_t,
depending on your specific needs.

> Obviously, if everyone provided 64 bit ints, there would no need for a
> campaign for them.


If there were a need for such a campaign, there would probably be more
than one person participating in it.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
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
Separate Tabs, Separate Sessions BigAndy Firefox 0 05-09-2007 09:27 AM
Separate Tabs, Separate Sessions BigAndy Firefox 0 05-09-2007 09:26 AM
Using separate classpaths for separate classes? Frank Fredstone Java 1 06-27-2006 06:46 AM
separate require files for common routines, our, and use strict question Bill Perl Misc 4 01-19-2004 01:39 PM
How to use several separate classes (separate files) to be executed in one class (another file) EvgueniB Java 1 12-15-2003 01:18 AM



Advertisments