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

V

vib.cpp

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?
 
I

Ian Collins

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.
 
R

Richard

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


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".
 
B

Ben Bacarisse

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.
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.
 
F

Flash Gordon

Malcolm said:
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.
 
F

Flash Gordon

Malcolm said:
"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

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.
 
K

Keith Thompson

Flash Gordon said:
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.
 
F

Flash Gordon

Malcolm said:
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.
 
K

Keith Thompson

Malcolm McLean said:
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.
 
K

Keith Thompson

Mark McIntyre said:
<blabla-age>

Which all just goes to show why you can't trust Wikipedia. Its
user-contributed remember. For all the "3rd age of humanity" cries
that the web is a self-healing AI, the sad reality is that ignorant
people outnumber clueful ones by several thousand to one.

The quoted material from Wikipedia seemed accurate, as far as I could
tell.

However, it described the Itanium / IA-64 architecture, which very few
"Intel PCs" actually use. (IA-64 is *not* the same thing as x86-64.)
 
D

Dik T. Winter

>
> That's correct. The C standard says a pointer value is an address value, by
> definition. Whether that address value resembles one's preconceptions
> about what an address is -- that's beside the point. ....
>
> Pointers *may* have different sizes from integers.
>
> Pointers *may* have different representations from integers.

No, in general pointers are a collection of bits, and as such they represent
an integer (in the mathematical sense), but not necessarily one of the many
"int" types of C (for one thing they can be too large to fit in any of those
types).

Moreover, address arithmetic is not necessarily the same as integer
arithmetic. I give here two possible exceptions:

(1) If you have two addresses a and b, when comparing them as integers they
may be different, while they point to the same cell in memory. This
occurs on (e.g.) segmented machines where the address contains a
segment number and the cell number within a segment and where segments
can overlap. There are other cases, for instance if the address contains
a privilege level.

(2) If you have two cells with addresses a and b, and where b is the
logical successor of cell a, it is not necessarily the case that
(in integer arithmetic) b = a + 1. I do not think such machines are
in use any more, but it did occur in program memory with some early
microprocessors (e.g. TI TMS1000) that used a shift and feedback
register for the program counter (also an address). This did also
occur on very early machines that had a magnetic drum as memory and
where logically consecutive cells where spaced apart depending on the
rotation speed of the drum.

Perhaps there are more exceptions.
 
G

Guest

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

From Wikipedia:

Intel has extensively documented the Itanium instruction set and
microarchitecture, and the technical press has provided overviews. The
architecture has been renamed several times during its history. HP
originally called it PA-WideWord. Intel later called it IA-64, then Itanium
Processor Architecture (IPA), before settling on Intel Itanium Architecture,
but it is still widely referred to as IA-64. It is a 64-bit register-rich
explicitly-parallel architecture. The base data word is 64 bits,
byte-addressable. The logical address space is 2^64 bytes.

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.

I bought an new PC last week. It doesn't have an Itanium in it.
Your definition of "normal" is bizzare
 
G

Guest

(e-mail address removed) said:
On 22 Feb, 18:49, "Malcolm McLean" <[email protected]>
wrote:
"Normally" is code for "on Intel PCs".
From Wikipedia:
Intel has extensively documented the Itanium instruction set and
microarchitecture, [...]
I bought an new PC last week. It doesn't have an Itanium in it.
Your definition of "normal" is bizzare

I'm guessing that he thinks of "normal" as "something I've used".
Something /you've/ used isn't normal, *unless* he's used it too.
The fact that it frames and colours daily programming reality for a
huge number of people is of no consequence. It's still not
"normal". Until he gets a job using that hardware, of course, at
which point it becomes normal.

There's nothing particularly bad about this. People are like that.
We extrapolate our understanding of the universe from our
experience of a subset thereof, and what else /can/ we do?

Pay attention to what's going on around us?
I've never programmed any of an Itanium, a PIC or a DSP.
I'm aware they exist though.
 
R

Richard Bos

Keith Thompson said:
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.

From this I can conclude that you've never programmed under MSDOS for
the smaller memory models. There, most pointers were smaller than the
legally allowed size of long.

Richard
 
K

Keith Thompson

From this I can conclude that you've never programmed under MSDOS for
the smaller memory models. There, most pointers were smaller than the
legally allowed size of long.

Your conclusion is correct.
 
D

Dik T. Winter

>
> Since I agree with the above in its entirety, I'm trying to find what
> part of my post prompted the "No".

You said: "pointers *may* have different representations from integers", I
said: "pointers have the *same* representation as integers". Pointers are
just a bunch of bits with value 0 or 1 (assuming a binary machine, for other
kinds the discussion is similar). That is the same as a representation of
integers. A major difference is that the arithmetic on pointers can be
different from the arithmetic on integers. And I explicitly did qualify
my meaning.
> If it was my use of "integers" as
> opposed to "int types" or "integer types", I consider that an OK thing
> to do, since one, it's clear what is meant by context, and two, even
> the Standard says "integer promotions" as opposed to "integer type
> promotions" (that's only the first example that came to mind).

But still in that case, the "representation" is the same, if the machine
does not use (for instance) ternary for pointers and binary for integers,
but although I know ternary machines did exist, they did not do that. But
it need not necessarily fit in size.

And the "representation" was what the OP asked about. In both cases the
representation is a bunch of bits and you can assign 1 to one bit, 2 to the
next, 4 to the following, and so on. The next question was whether there was
a different format involved, I tried to answer that question by showing two
cases where adding 1 to a pointer in integer arithmetic does not necessarily
give the next cell. But the question itself was indeed not clear enough.

We can ask of course whether the OP meant "value" rather than "representation".
This reminds me of a discussion I earlier had in this newsgroup on what was
meant with a pointer with value 0. On (for instance) the transputer, address
0 is a perfectly valid address, as is -1 and -2 and so on. The address
ranges from -k to +l for some suitable values of k and l. So the question
was actually was the value of that pointer something that (in C) compared
equal to 0 or was it something that held the actual value 0. But apparently
this distinction was lost.

There are lots of weird machines around. I have used a machine where the
all zero bits floating point number was the unnormalised version of 0.0.
Adding 0.5 to it would result in 0.0. If you wish I can explain.

Formerly in this newsgroup the attitude that pointers worked like integers
was "all the computers are a Vax". That made porting programs to other
machines sometimes a crime. I have been involved in porting a derivate of
the Bourne shell (the whole world is Vax) to a Cray-1. A basic assumption
in that program that int-pointers would have lower bit equal to 0 is false
on that machine. Porting that program to e.g. the Data General would have
shown similar problems (for other reasons).

Yes, I have programmed a lot of weird machines, and for that reason I strictly
follow the rules the standard gives (I hope).
 
P

Phil Carmody

Dik T. Winter said:
You said: "pointers *may* have different representations from integers", I
said: "pointers have the *same* representation as integers". Pointers are
just a bunch of bits with value 0 or 1 (assuming a binary machine, for other
kinds the discussion is similar). That is the same as a representation of
integers.

In your opinion, does a 16 bit integer have the same representation as
a 32-bit integer?

Phil
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top