Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Sizes of pointers

 
 
Tim Rentsch
Guest
Posts: n/a
 
      08-19-2013
glen herrmannsfeldt <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> wrote:
>> Keith Thompson <(E-Mail Removed)> writes:

>
> (snip)
>>> The point is that sign-extension is a simple way to describe the
>>> replication of the high order bit. I don't think anyone is
>>> arguing that pointers on such a system *must* be described as (or
>>> as behaving like) signed integers, merely that they can reasonably
>>> be described that way.

>>
>> I'm happy to agree that it's reasonable to describe how x86-64
>> pointers work using sign extension, etc, if others are willing to
>> agree that it's equally reasonable to describe how those pointers
>> work without using sign extension, etc. In short, I think what
>> you're saying is pretty much the same as what I'm saying... but
>> I'm not sure that other people in the discussion agree on that.

>
> I might even say more reasonable, but less convenient.
>
> Reminds me of the ways PL/I and (newer) Fortran pass arrays.
> (being an addressing question, it might be applicable).
>
> Both languages allow one to declare arrays giving lower and
> upper bounds for dimensions. For PL/I, when passed to a called
> procedure, the bounds information is also passed, both lower and
> upper bound.
>
> With Fortran assumed shape, where dimension information is
> passed to a called routine, only the extent is passed. (As seen
> in the called routine, the origin is 1, by default, or can be
> specified other than 1.)
>
> The former seems more natural, but the latter is sometimes more
> convenient, especially when rewriting old routines.
>
> They are both reasonably, but I don't know that you can say
> equally reasonable. (As with addressing, it is difficult to
> measure reasonableness.)


The two situations have nothing to do with each other. In the
first case the scheme being described is fixed but different
descriptions are offered. In the second case two different
schemes are considered (compared, contrasted, etc). Trying
to draw parallels between them is nonsensical.
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      08-21-2013
Stephen Sprunk <(E-Mail Removed)> writes:

> On 08-Aug-13 19:09, Tim Rentsch wrote:
>> Keith Thompson <(E-Mail Removed)> writes:
>>> Tim Rentsch <(E-Mail Removed)> writes:
>>>> This is all just circular reasoning - it's a sign bit
>>>> because what's being done is sign extension, and it's
>>>> sign extension because what's being "extended" is a
>>>> sign bit. It's just as consistent to say the smaller
>>>> address space is mapped to the larger address space
>>>> by replicating the high order bit. The addresses
>>>> themselves have no intrinsic signedness - only which
>>>> point of view one takes might ascribe one.
>>>
>>> The point is that sign-extension is a simple way to describe the
>>> replication of the high order bit. I don't think anyone is
>>> arguing that pointers on such a system *must* be described as (or
>>> as behaving like) signed integers, merely that they can reasonably
>>> be described that way.

>>
>> I'm happy to agree that it's reasonable to describe how x86-64
>> pointers work using sign extension, etc, if others are willing to
>> agree that it's equally reasonable to describe how those pointers
>> work without using sign extension, etc. In short, I think what
>> you're saying is pretty much the same as what I'm saying... but
>> I'm not sure that other people in the discussion agree on that.

>
> I deny that it's "equally reasonable" to describe something
> universally known as "sign extension" with an invented term that
> serves only to remove the term "sign" from an explanation of
> pointers, especially when the same documents call that same
> something "sign extension" when applied to any other type of
> value.


Obviously how pointers work on x86-64 is not universally known
as sign extension, as there are numerous examples of documents
that describe it using different terms.

More importantly, the point of my comment was not about the
term "sign extension" but the concept of sign extension. By
analogy, inverting all the bits of a computer word can be seen
either as logical complementation or as negation under a ones
complement representation. Whatever name the operation code
happens to have, we conceptualize the operation in different
ways, depending how we view the spaces of values represented.
Similarly, just because how pointer expansion works happens to
match a mechanism named "sign extension", that doesn't mean we
must necessarily impute the concepts of signed values to the
bits being operated on, and different conceptualizations will
naturally lead to different descriptions.

> Yes, it can be done, but that doesn't make it "equally
> reasonable".


I don't see any support for this position other than your
repeated assertion that it must be so.
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      08-21-2013
Philip Lantz <(E-Mail Removed)> writes:

> Tim Rentsch wrote:
>> glen herrmannsfeldt writes:
>> > Tim Rentsch wrote:
>> >> IMO it is more natural to think of kernel memory and user memory
>> >> as occupying separate address spaces rather than being part of
>> >> one combined positive/negative blob;
>> >
>> > I agree, but ... being able to store a pointer in 32 bits
>> > when you don't need to address more is reasonable. Having parts
>> > of the OS addressable, for example shared libraries usable by all,
>> > is also convenient.

>>
>> That has no bearing on my comment. Having separate address
>> spaces doesn't preclude any variety of representations that
>> might address memory in either address space.
>>
>> > Sign extending a 32 bit integer allows it to specify the lower 2GB
>> > and top 2GB of a 64 bit address space.

>>
>> Yes, _if_ you think of the two address spaces as a combined
>> positive/negative blob. I prefer to think of those address
>> spaces as separate.
>>
>> > That makes more sense than saying that it is a 32 bit number,
>> > except the high bit has an unusual positive place value.

>>
>> There's nothing wrong with having that opinion, as long
>> as you understand that it is nothing more than opinion.

>
> In the following example, assume that the array 'arr' is at
> address 0xffffffff80001000, in what I would call the negative
> part of the address space, which you say is a matter of opinion.


If you read the previous posting again, I believe you will see
that my comment is about which view makes more sense, not about
whether believing addresses are signed is an opinion. I don't
think there is any debate about whether addresses are "truly
signed", only about whether it's more convenient to think of them
that way.

> extern char arr[];
>
> void f(char *p)
> {
> p[-200] = 0; // movb -200[rdi], 0 c6 87 38 ff ff ff 00
> }
>
> void g(size_t i)
> {
> a[i] = 0; // movb a[rdi], 0 c6 87 00 10 00 80 00
> }
>
> [.. code and text paragraph swapped to help reading flow ..]
>
> Note that the exact same instruction and encoding are used for
> the two examples. In both cases, the 32-bit constant part of the
> address is sign-extended as part of address calculation. Is it
> your contention that calling -200 negative is also a matter of
> opinion?


The abstract value -200 is certainly negative; that is true by
definition.

The operand part of the instruction (ie, the bits corresponding
to the '38 ff ff ff' byte values) is certainly not negative.
Neither is it positive. Only numbers are positive or negative;
the operand portion of the instruction is just a collection of
bits, not a number.

The question then becomes what do we consider those bits as
representing? We might consider them as representing a signed
value (ie, -200); or, we might consider them as representing a
large unsigned value, which has the same effect under the rules
of unsigned arithmetic as subtracting 200. The second view is
like what happens in C when we add a negative signed value to an
unsigned value, eg

unsigned u = 1000;
u = -200 + u;

After the assignment u will have the value 800. However, what is
being added to u is not (under the semantic rules of the C
abstract machine) a negative value, but rather a large unsigned
value.

Moreover, note that the instructions and formats being used here
are regular x86 instructions (ie, not specific to x86-64).
Before the x86-64, addresses in x86 were not thought of as
being signed. So there is some precedent for the idea that
what is being represented in the operand field is a large
unsigned value rather than a signed value.

> (I did the instruction selection and encoding by hand; I hope I
> didn't make an error. But even if I did, the point remains
> valid.)


Everyone agrees that the mechanism of address expansion in x86-64
is isomorphic to the mechanism of sign extension. Does this mean
these addresses _must_ be seen as being signed? Of course it
doesn't. Lots of people prefer that view, but certainly there
are equally consistent views that do not treat addresses as being
signed. Which view is more convenient? Obviously different
people have different opinions on that question. All I'm saying
is the last question has no absolute answer.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      08-22-2013
Stephen Sprunk <(E-Mail Removed)> writes:

> On 08-Aug-13 18:55, Tim Rentsch wrote:
>> Stephen Sprunk <(E-Mail Removed)> writes:
>>> On 08-Aug-13 06:13, Tim Rentsch wrote:

> [snip]
>
>>>> Sounds to me like you're the one being dogmatic.
>>>
>>> I acknowledged that there are two views. That one of them is
>>> simpler, more elegant and more self-consistent is objectively
>>> true.

>>
>> Is that so? Just what physical equipment do you have in mind to
>> measure the simplicity, elegance, and self-consistency of a point of
>> view, to back up your claim?

>
> Compare these two explanations:
>
> 1. Pointers are signed.
>
> 2. Pointers are unsigned, but when copying them to a larger register you
> use sign extension, though it's not called sign extension, rather than
> zero extension, which is used for unsigned values of other types.
>
> I dare you to come up with _any_ measure of simplicity, elegance or
> self-consistency that does not favor the first option.


In the first place, it was you who made the claim, not me. If
there a burden to be borne here, such as coming up with a
measure, it is you who bear it -- if you can't support your own
claim, it is simply an unsupported claim, and no disproof
required. I have made no claims about which view is simpler,
etc, either objectively or otherwise.

In the second place, it is trivial to come up with a measure that
favors the second option over the first, eg, "longer explanations
are more elegant than shorter explanations".

In the third place, what you apparently fail to understand is
that the issue here is not to define a _measure_, but to describe
a means to perform an objective _measurement_, where the result
of the measurement mechanism is both objective and corresponds
to what most people would agree is simple, elegant, and
self-consistent. The claim about which view is simpler, etc,
has meaning only if those words have a previously agreed upon
meaning -- if someone is going to define their meaning after
the fact, any claim about which view is simpler, etc, is a
completely empty statement.
 
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