Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #13294 > unrolled thread

A portable stack in C

Back to article view | Back to comp.lang.c

Contents

  A portable stack in C "io_x" <a@b.c.invalid> - 2011-11-14 17:54 +0100
    Re: A portable stack in C Barry Schwarz <schwarzb@dqel.com> - 2011-11-14 20:55 -0800
      Re: A portable stack in C jacob navia <jacob@spamsink.net> - 2011-11-15 09:22 +0100
        Re: A portable stack in C Ike Naar <ike@iceland.freeshell.org> - 2011-11-15 09:00 +0000
          Re: A portable stack in C jacob navia <jacob@spamsink.net> - 2011-11-15 11:26 +0100
        Re: A portable stack in C "BartC" <bc@freeuk.com> - 2011-11-15 10:05 +0000
          Re: A portable stack in C jacob navia <jacob@spamsink.net> - 2011-11-15 11:25 +0100
            Re: A portable stack in C "BartC" <bc@freeuk.com> - 2011-11-15 11:08 +0000
            Re: A portable stack in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-15 11:45 +0000
              Re: A portable stack in C jacob navia <jacob@spamsink.net> - 2011-11-15 12:57 +0100
                Re: A portable stack in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-15 12:39 +0000
                  Re: A portable stack in C jacob navia <jacob@spamsink.net> - 2011-11-15 14:26 +0100
                    Re: A portable stack in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-15 15:31 +0000
                      Re: A portable stack in C Keith Thompson <kst-u@mib.org> - 2011-11-15 12:53 -0800
                        Re: A portable stack in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-15 21:15 +0000
                          Re: A portable stack in C Keith Thompson <kst-u@mib.org> - 2011-11-15 14:29 -0800
                            Re: A portable stack in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-15 22:59 +0000
                          Re: A portable stack in C James Kuyper <jameskuyper@verizon.net> - 2011-11-15 17:30 -0500
                          Re: A portable stack in C Willem <willem@toad.stack.nl> - 2011-11-15 22:33 +0000
                            Re: A portable stack in C Keith Thompson <kst-u@mib.org> - 2011-11-15 15:07 -0800
                          Re: A portable stack in C Seebs <usenet-nospam@seebs.net> - 2011-11-15 22:37 +0000
                            Re: A portable stack in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-15 23:01 +0000
                Re: A portable stack in C "BartC" <bc@freeuk.com> - 2011-11-15 18:45 +0000
              Re: A portable stack in C Keith Thompson <kst-u@mib.org> - 2011-11-15 12:41 -0800
            Re: A portable stack in C Richard Damon <news.x.richarddamon@xoxy.net> - 2011-11-15 23:07 -0500
              Re: A portable stack in C Keith Thompson <kst-u@mib.org> - 2011-11-15 20:18 -0800
              Re: A portable stack in C Robert Wessel <robertwessel2@yahoo.com> - 2011-11-15 22:53 -0600
                Re: A portable stack in C "BartC" <bc@freeuk.com> - 2011-11-16 12:00 +0000
                  Re: A portable stack in C falk@rahul.net (Edward A. Falk) - 2011-11-16 16:08 +0000
                Re: A portable stack in C David Thompson <dave.thompson2@verizon.net> - 2012-01-19 02:41 -0500
        Re: A portable stack in C Thomas David Rivers <rivers@dignus.com> - 2011-11-15 11:21 -0500
        Re: A portable stack in C Barry Schwarz <schwarzb@dqel.com> - 2011-11-15 17:53 -0800
      Re: A portable stack in C "io_x" <a@b.c.invalid> - 2011-11-15 19:21 +0100
        Re: A portable stack in C Barry Schwarz <schwarzb@dqel.com> - 2011-11-15 17:53 -0800
          Re: A portable stack in C "io_x" <a@b.c.invalid> - 2011-11-18 08:13 +0100
    Re: A portable stack in C Rui Maciel <rui.maciel@gmail.com> - 2011-11-15 10:14 +0000
      Re: A portable stack in C "io_x" <a@b.c.invalid> - 2011-11-15 19:20 +0100
    Re: A portable stack in C Acid Washed China Blue Jeans <chine.bleu@yahoo.com> - 2011-11-15 08:13 -0800
    Re: A portable stack in C Kaz Kylheku <kaz@kylheku.com> - 2011-11-15 16:27 +0000
      Re: A portable stack in C "io_x" <a@b.c.invalid> - 2011-11-15 19:21 +0100
      Re: A portable stack in C Keith Thompson <kst-u@mib.org> - 2011-11-15 13:19 -0800
    Re: A portable stack in C blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-17 15:45 +0000
      Re: A portable stack in C John Gordon <gordon@panix.com> - 2011-11-17 15:56 +0000
      Re: A portable stack in C "io_x" <a@b.c.invalid> - 2011-11-17 18:02 +0100
        Re: A portable stack in C "BartC" <bc@freeuk.com> - 2011-11-17 17:35 +0000
          Re: A portable stack in C Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-11-17 18:45 +0100
          Re: A portable stack in C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-18 00:27 -0800
            Re: A portable stack in C "io_x" <a@b.c.invalid> - 2011-11-18 10:40 +0100
              Re: A portable stack in C "io_x" <a@b.c.invalid> - 2011-11-20 07:22 +0100
              Re: A portable stack in C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-21 00:38 -0800
                Re: A portable stack in C "Jo" <none@none.none> - 2011-11-21 03:44 -0600
                  Re: A portable stack in C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-21 13:00 +0200
                    Re: A portable stack in C "Jo" <none@none.none> - 2011-11-21 06:07 -0600
                Re: A portable stack in C "Jo" <none@none.none> - 2011-11-21 03:50 -0600
                Re: A portable stack in C "Jo" <none@none.none> - 2011-11-21 07:48 -0600
                Re: A portable stack in C "io_x" <a@b.c.invalid> - 2011-11-21 20:11 +0100
            Re: A portable stack in C "BartC" <bc@freeuk.com> - 2011-11-18 12:47 +0000
            Re: A portable stack in C "Jo" <none@none.none> - 2011-11-18 23:31 -0600
        Re: A portable stack in C blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-18 14:45 +0000
          Re: A portable stack in C James Kuyper <jameskuyper@verizon.net> - 2011-11-18 10:14 -0500
          Re: A portable stack in C Keith Thompson <kst-u@mib.org> - 2011-11-18 12:20 -0800
            Re: A portable stack in C blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-19 17:23 +0000
              Re: A portable stack in C Seebs <usenet-nospam@seebs.net> - 2011-11-19 18:49 +0000
                Re: A portable stack in C "Jo" <none@none.none> - 2011-11-19 22:41 -0600
                Re: A portable stack in C "io_x" <a@b.c.invalid> - 2011-11-20 07:27 +0100
                  Re: A portable stack in C "io_x" <a@b.c.invalid> - 2011-11-21 20:12 +0100
              Re: A portable stack in C "io_x" <a@b.c.invalid> - 2011-11-20 07:50 +0100
            Re: A portable stack in C "Jo" <none@none.none> - 2011-11-21 01:24 -0600
              Re: A portable stack in C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-21 05:22 -0800
                Re: A portable stack in C "Jo" <none@none.none> - 2011-11-22 03:31 -0600
    Re: A portable stack in C 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-21 06:38 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#13294 — A portable stack in C

in the while the train go always more far from home
i think to these questions:
is it possible to build a portable stack in C using uns32_t?
is it possible to define in C a pointer of size 32 bits portable
as uns32_t? could it be "uns32_t"?
is it possible using that stack for call of function as
f(a, b)  <=> push32 b|push32 a| call32 f
i remember someone says that for calling function
it has to be a stack: i'm agree with him
thank you

[toc] | [next] | [standalone]

#13354

On Mon, 14 Nov 2011 17:54:32 +0100, "io_x" <a@b.c.invalid> wrote:

>in the while the train go always more far from home
>i think to these questions:
>is it possible to build a portable stack in C using uns32_t?

Since uns32_t is not a portable type, the answer is no.  If you could
be bothered to use uint32_t at least it would comply with n1256.  But
since the type is optional, the answer would still be at best a
limited yes.

>is it possible to define in C a pointer of size 32 bits portable
>as uns32_t? could it be "uns32_t"?

You have no control over the size of pointers.

>is it possible using that stack for call of function as
>f(a, b)  <=> push32 b|push32 a| call32 f

Not on my system which doesn't use a stack or have a push instruction.

>i remember someone says that for calling function
>it has to be a stack: i'm agree with him

You shouldn't believe everything you read on Usenet.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#13356

Le 15/11/11 05:55, Barry Schwarz a écrit :
> On Mon, 14 Nov 2011 17:54:32 +0100, "io_x"<a@b.c.invalid>  wrote:
>
>> in the while the train go always more far from home
>> i think to these questions:
>> is it possible to build a portable stack in C using uns32_t?
>
> Since uns32_t is not a portable type, the answer is no.  If you could
> be bothered to use uint32_t at least it would comply with n1256.  But
> since the type is optional, the answer would still be at best a
> limited yes.
>
>> is it possible to define in C a pointer of size 32 bits portable
>> as uns32_t? could it be "uns32_t"?
>
> You have no control over the size of pointers.
>

Of course you can. Here is an 8 bit pointer:

char table[255];
char pointerInTable;

Now, "pointerInTable" points to any position within that table. For 
instance to get the contents of position 154:

pointerInTable = 154;
val = table[pointerInTable];

Using this (in plain C) you can have pointers of any size.

Want a 10 bit pointer?

Easy.

char table[1024];
int pointerInTable; /* Values from 0 to 1023 */

>> is it possible using that stack for call of function as
>> f(a, b)<=>  push32 b|push32 a| call32 f
>
> Not on my system which doesn't use a stack or have a push instruction.
>

Ahh OK;

> You shouldn't believe everything you read on Usenet.
>

You are right. I don't believe you that there isn't (by convention)
a register pointing to the stack, and that

sub stack,8
move value,[stack]

doesn't work.

Which system are you using?

[toc] | [prev] | [next] | [standalone]

#13361

On 2011-11-15, jacob navia <jacob@spamsink.net> wrote:
> Of course you can. Here is an 8 bit pointer:
>
> char table[255];
> char pointerInTable;
>
> Now, "pointerInTable" points to any position within that table. For 
> instance to get the contents of position 154:
>
> pointerInTable = 154;
> val = table[pointerInTable];

This would not work on an implementation where
char is signed and CHAR_MAX is less than 255.

An example of such an implementation (the machine I'm currently
using) has amd64 hardware running NetBSD 5.1.0 with a GCC 4.1.3
compiler. CHAR_MIN = -128 and CHAR_MAX = 127 .

"unsigned char pointerInTable;" would probably be more portable.

[toc] | [prev] | [next] | [standalone]

#13367

Le 15/11/11 10:00, Ike Naar a écrit :
> On 2011-11-15, jacob navia<jacob@spamsink.net>  wrote:
>> Of course you can. Here is an 8 bit pointer:
>>
>> char table[255];
>> char pointerInTable;
>>
>> Now, "pointerInTable" points to any position within that table. For
>> instance to get the contents of position 154:
>>
>> pointerInTable = 154;
>> val = table[pointerInTable];
>
> This would not work on an implementation where
> char is signed and CHAR_MAX is less than 255.
>
> An example of such an implementation (the machine I'm currently
> using) has amd64 hardware running NetBSD 5.1.0 with a GCC 4.1.3
> compiler. CHAR_MIN = -128 and CHAR_MAX = 127 .
>
> "unsigned char pointerInTable;" would probably be more portable.

Sure, I apologize for that blunder. It is unsigned char of course.

[toc] | [prev] | [next] | [standalone]

#13363

"jacob navia" <jacob@spamsink.net> wrote in message 
news:j9t7gd$45e$1@speranza.aioe.org...
> Le 15/11/11 05:55, Barry Schwarz a écrit :

>> You have no control over the size of pointers.

> Of course you can. Here is an 8 bit pointer:
>
> char table[255];
> char pointerInTable;
>
> Now, "pointerInTable" points to any position within that table. For 
> instance to get the contents of position 154:
>
> pointerInTable = 154;
> val = table[pointerInTable];

That's not a pointer as understood in C. It's an array index. Try passing 
pointerInTable to a function, and see if the function can access the table!

> Using this (in plain C) you can have pointers of any size.
>
> Want a 10 bit pointer?
>
> Easy.
>
> char table[1024];
> int pointerInTable; /* Values from 0 to 1023 */

And that one's not even ten bits. It's more likely 32 bits.

>> You shouldn't believe everything you read on Usenet.
>
> You are right. I don't believe you that there isn't (by convention)
> a register pointing to the stack, and that
>
> sub stack,8
> move value,[stack]
>
> doesn't work.
>
> Which system are you using?

Clearly one without a stack, perhaps some lowly controller chip.

-- 
Bartc
 

[toc] | [prev] | [next] | [standalone]

#13366

Le 15/11/11 11:05, BartC a écrit :
> "jacob navia" <jacob@spamsink.net> wrote in message
> news:j9t7gd$45e$1@speranza.aioe.org...
>> Le 15/11/11 05:55, Barry Schwarz a écrit :
>
>>> You have no control over the size of pointers.
>
>> Of course you can. Here is an 8 bit pointer:
>>
>> char table[255];
>> char pointerInTable;
>>
>> Now, "pointerInTable" points to any position within that table. For
>> instance to get the contents of position 154:
>>
>> pointerInTable = 154;
>> val = table[pointerInTable];
>
> That's not a pointer as understood in C. It's an array index. Try
> passing pointerInTable to a function, and see if the function can access
> the table!


of course it can

typedef unsigned Pointer;

int MyFn(Pointer p)
{
	return table[p];
}

Conceptually ANY pointer is an index in a big array called "memory" (or 
RAM if you like).

This huge array of characters can be accessed in some machines as a
discontinuous array, composed of several chunks (segments).

An index into those arrays is composed of two numbers: the chunk
index and the index within that chunk (segment:offset)

>
>> Using this (in plain C) you can have pointers of any size.
>>
>> Want a 10 bit pointer?
>>
>> Easy.
>>
>> char table[1024];
>> int pointerInTable; /* Values from 0 to 1023 */
>
> And that one's not even ten bits. It's more likely 32 bits.
>

Well, all my pointers in my machine are 35 bits (I have only 12GB of
memory) but they use 64... (Ignoring Virtual Memory)



>>> You shouldn't believe everything you read on Usenet.
>>
>> You are right. I don't believe you that there isn't (by convention)
>> a register pointing to the stack, and that
>>
>> sub stack,8
>> move value,[stack]
>>
>> doesn't work.
>>
>> Which system are you using?
>
> Clearly one without a stack, perhaps some lowly controller chip.
>

Impossible. There isn't a CALL instruction then. It is impossible
to implement a CALL without a conceptual stack. Yes, you can "push"
your return address into some register but this is conceptually a stack!

[toc] | [prev] | [next] | [standalone]

#13369

"jacob navia" <jacob@spamsink.net> wrote in message
news:j9temn$o6u$1@speranza.aioe.org...
> Le 15/11/11 11:05, BartC a écrit :
>> "jacob navia" <jacob@spamsink.net> wrote in message

>>> pointerInTable = 154;
>>> val = table[pointerInTable];
>>
>> That's not a pointer as understood in C. It's an array index. Try
>> passing pointerInTable to a function, and see if the function can access
>> the table!

> of course it can
>
> typedef unsigned Pointer;
>
> int MyFn(Pointer p)
> {
> return table[p];
> }

So:

(1) 'table' has to have global scope
(2) MyFn() can only access one array

To be able to access any array, you need to pass a second parameter which
specifies (or 'points to') the array you want, plus the index. Or...

> Conceptually ANY pointer is an index in a big array called "memory" (or
> RAM if you like).

... forget about normal named arrays in C, and work with a single block of
memory. So losing all the advantages of C variables, and end up needing a
index wider than 8-bits. So 'table' is just memory[120000] to
memory[120255], and table[i] is just memory[i+120000]; so simple!

You don't really want to do this sort of stuff in a high-level language.

>>> Want a 10 bit pointer?
>>>
>>> Easy.
>>>
>>> char table[1024];
>>> int pointerInTable; /* Values from 0 to 1023 */
>>
>> And that one's not even ten bits. It's more likely 32 bits.
>>
>
> Well, all my pointers in my machine are 35 bits (I have only 12GB of
> memory) but they use 64... (Ignoring Virtual Memory)

I think BS was more concerned about choosing 32-bit pointers when the
natural size was 64-bits. The utilisation of bits was less important, except
perhaps as a way of packing pointer values.

>>> Which system are you using?
>>
>> Clearly one without a stack, perhaps some lowly controller chip.
>>
>
> Impossible. There isn't a CALL instruction then. It is impossible
> to implement a CALL without a conceptual stack. Yes, you can "push"
> your return address into some register but this is conceptually a stack!

Recursive calls are more difficult. It can be emulated in software as you
say, but on simple processors you may not need recursiveness.

And I have programmed a machine without a hardware stack: you had to store a
return address in memory somewhere where the called routine could pick it up
to do an indirect jump.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13373

jacob navia <jacob@spamsink.net> writes:
<snip>
> Conceptually ANY pointer is an index in a big array called "memory"
> (or RAM if you like).

C pointers don't fit this concept.  They have a type which contributes
to the result of operations like *p, sizeof *p and p + 1.

C's function pointers don't fit well into the "memory index" model
either because you can do any array-like operations with them.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#13377

Le 15/11/11 12:45, Ben Bacarisse a écrit :
> jacob navia<jacob@spamsink.net>  writes:
> <snip>
>> Conceptually ANY pointer is an index in a big array called "memory"
>> (or RAM if you like).
>
> C pointers don't fit this concept.  They have a type which contributes
> to the result of operations like *p, sizeof *p and p + 1.
>

The *p operation is just
1) Read the value of the pointer
2) Index the memory
3) read that position.

This is just memory[p] (assuming non segmented memory)

sizeof(*p) <==> sizeof (memory[p]) where you would have
conceptually "memory" as an aray of *p.

The "p + 1" operation is the same:
memory[p+1] where "memory" is an array of objects of type *p.


> C's function pointers don't fit well into the "memory index" model
> either because you can do any array-like operations with them.
>

Function pointers can be emulated as a conceptual table of
machine instructions where p points to the start of the
sequence of instructions of a function.

In general, what I want to emphasize is the equivalence between array
indices and pointers.

And no, pleeze, I do not want to eliminate pointers from C... :-)

[toc] | [prev] | [next] | [standalone]

#13380

jacob navia <jacob@spamsink.net> writes:

> Le 15/11/11 12:45, Ben Bacarisse a écrit :
>> jacob navia<jacob@spamsink.net>  writes:
>> <snip>
>>> Conceptually ANY pointer is an index in a big array called "memory"
>>> (or RAM if you like).
>>
>> C pointers don't fit this concept.  They have a type which contributes
>> to the result of operations like *p, sizeof *p and p + 1.
>>
>
> The *p operation is just
> 1) Read the value of the pointer
> 2) Index the memory
> 3) read that position.
>
> This is just memory[p] (assuming non segmented memory)
>
> sizeof(*p) <==> sizeof (memory[p]) where you would have
> conceptually "memory" as an aray of *p.

But you want to suggest that a pointer in an index into one big array
called memory.  What type does this one big memory array have?

I know what you mean.  The type of the big array will keep changing
depending on the context, but that just shows why you can't say that a
pointer "is an index in a big array called 'memory'" -- pointers don't
fit the concept of an index into an array, because an array has one type
for all it's elements.

> The "p + 1" operation is the same:
> memory[p+1] where "memory" is an array of objects of type *p.

This last one is wrong, even assuming a magic array whose type can be
whatever is need at the time.

>> C's function pointers don't fit well into the "memory index" model
>> either because you can do any array-like operations with them.
>
> Function pointers can be emulated as a conceptual table of
> machine instructions where p points to the start of the
> sequence of instructions of a function.

So you think it's helpful to consider a function pointer to be an index
into array, but one you can't do any array operations on?  How does that
help?  What type is this new array or is it the same as the other array?
To my mind, this is am attempted simplification that complicates matters.

> In general, what I want to emphasize is the equivalence between array
> indices and pointers.

In general, I don't want to do that.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#13384

Le 15/11/11 13:39, Ben Bacarisse a écrit :
> jacob navia<jacob@spamsink.net>  writes:
>
>> Le 15/11/11 12:45, Ben Bacarisse a écrit :
>>> jacob navia<jacob@spamsink.net>   writes:
>>> <snip>
>>>> Conceptually ANY pointer is an index in a big array called "memory"
>>>> (or RAM if you like).
>>>
>>> C pointers don't fit this concept.  They have a type which contributes
>>> to the result of operations like *p, sizeof *p and p + 1.
>>>
>>
>> The *p operation is just
>> 1) Read the value of the pointer
>> 2) Index the memory
>> 3) read that position.
>>
>> This is just memory[p] (assuming non segmented memory)
>>
>> sizeof(*p)<==>  sizeof (memory[p]) where you would have
>> conceptually "memory" as an aray of *p.
>
> But you want to suggest that a pointer in an index into one big array
> called memory.  What type does this one big memory array have?
>
> I know what you mean.  The type of the big array will keep changing
> depending on the context, but that just shows why you can't say that a
> pointer "is an index in a big array called 'memory'" -- pointers don't
> fit the concept of an index into an array, because an array has one type
> for all it's elements.
>

Yes, but you can see a long double as an array of 10 bytes, or 5 shorts,
or many other representations. That is the "pointed at" type, not
the value of the pointer itself. The value of the pointer is always the 
value of an index into a byte array starting at virtual memory address
zero and going on up to the top of the virtual memory space.

>> The "p + 1" operation is the same:
>> memory[p+1] where "memory" is an array of objects of type *p.
>
> This last one is wrong, even assuming a magic array whose type can be
> whatever is need at the time.
>

That is what I am saying. Suppose

long double *pLongDouble = &var;

If you look at the VALUE of that pointer you will read (say)
0x7DF4500

What is that number?

Is the NUMBER of memory locations starting at zero that you should
skip to arrive at that value. It is NOT the number of doubles,
or long doubles or the type of whatever that pointer is being used
for.

All pointers use the same UNIT: memory locations. Of course they
dereference different types, etc. But basically they are all the same.

They are an index into the "memory" array. (Assuming non-segmented
memory)

>>> C's function pointers don't fit well into the "memory index" model
>>> either because you can do any array-like operations with them.
>>
>> Function pointers can be emulated as a conceptual table of
>> machine instructions where p points to the start of the
>> sequence of instructions of a function.
>
> So you think it's helpful to consider a function pointer to be an index
> into array, but one you can't do any array operations on?

Look:

double fn(int a, int b)
{
	return a+b;
}

unsigned char code_for_function_fn[] = {
0x55,0x89,0xe5,0x57,0x8b,0x7d,0x08,
0x0",0x7d,0x0c,0x57,0xdb,0x04,0x24,
0x83,0xc4,0x04,0x5f,0x5d,0xc3};


Both representations of the function "fn" are identical. The
proof is that if you disassemble "fn" you will obtain:

[0000000] 55               push      %ebp
[0000001] 89e5             mov       %esp,%ebp
[0000003] 57               push      %edi
[0000004] 8b7d08           mov       0x8(%ebp),%edi
[0000007] 037d0c           add       0xc(%ebp),%edi
[0000010] 57               push      %edi
[0000011] db0424           fildl     (%esp,1)
[0000014] 83c404           add       $0x4,%esp
[0000017] 5f               pop       %edi
[0000018] 5d               pop       %ebp
[0000019] c3               ret


If you cast the function pointer of "fn" into a char pointer, you can
even do a memcmp to verify that (obviously the actual contents could
be different in a different version of lcc-win or with another compiler
but that is just trivial).

All functions are just an array of instructions (well, a special array
since instructions need not to be of the same length)

> How does that
> help?

It helps to avoid being caught by software and to realize that actually
it is the hardware that does everything.

It helps because it helps you realize how the machine actually WORKS...

What type is this new array or is it the same as the other array?

There is only ONE type for pointers: Memory locations (consecutive
in a linear architecture, segmented in a "Harvard" architecture)

> To my mind, this is am attempted simplification that complicates matters.

Sure, but this is how machines actually WORK.

>
>> In general, what I want to emphasize is the equivalence between array
>> indices and pointers.
>
> In general, I don't want to do that.
>

You will agree that *p is the same as p[0] isn't it? For ALL p?

Why is that?

Anyway, I understand why you do not want to do that in general. Because
you are concerned with software and with high level languages (that
exist only in software). And that is a very legitimate concern.

I am at the interface of software and hardware. My job is to translate
software into codes that the hardware understands, so I am more 
interested in knowing how a machine actually works beyond software
abstractions.

[toc] | [prev] | [next] | [standalone]

#13389

jacob navia <jacob@spamsink.net> writes:

> Le 15/11/11 13:39, Ben Bacarisse a écrit :
>> jacob navia<jacob@spamsink.net>  writes:
>>
>>> Le 15/11/11 12:45, Ben Bacarisse a écrit :
>>>> jacob navia<jacob@spamsink.net>   writes:
>>>> <snip>
>>>>> Conceptually ANY pointer is an index in a big array called "memory"
>>>>> (or RAM if you like).
>>>>
>>>> C pointers don't fit this concept.  They have a type which contributes
>>>> to the result of operations like *p, sizeof *p and p + 1.
>>>>
>>>
>>> The *p operation is just
>>> 1) Read the value of the pointer
>>> 2) Index the memory
>>> 3) read that position.
>>>
>>> This is just memory[p] (assuming non segmented memory)
>>>
>>> sizeof(*p)<==>  sizeof (memory[p]) where you would have
>>> conceptually "memory" as an aray of *p.
>>
>> But you want to suggest that a pointer in an index into one big array
>> called memory.  What type does this one big memory array have?
>>
>> I know what you mean.  The type of the big array will keep changing
>> depending on the context, but that just shows why you can't say that a
>> pointer "is an index in a big array called 'memory'" -- pointers don't
>> fit the concept of an index into an array, because an array has one type
>> for all it's elements.
>>
>
> Yes, but you can see a long double as an array of 10 bytes, or 5 shorts,
> or many other representations. That is the "pointed at" type, not
> the value of the pointer itself. The value of the pointer is always
> the value of an index into a byte array starting at virtual memory
> address
> zero and going on up to the top of the virtual memory space.
>
>>> The "p + 1" operation is the same:
>>> memory[p+1] where "memory" is an array of objects of type *p.
>>
>> This last one is wrong, even assuming a magic array whose type can be
>> whatever is need at the time.
>>
>
> That is what I am saying.

No, look at what you wrote.  Even in your world of indexes, p+1 is not
memory[p+1] as you wrote.  You might have meant &memory[p+1] but I don't
want to guess (and you'd have to say what & means in this big array
index world).

> Suppose
>
> long double *pLongDouble = &var;
>
> If you look at the VALUE of that pointer you will read (say)
> 0x7DF4500

Do you know that this is ambiguous?  A value (in C) is a pile of bits
/interpreted as a value of some type/.  Do you believe that the value of
that pointer is always -- on all hardware -- independent of the type
used to interpret the bits?

In a debugger, the bits are often interpreted as an unsigned int, so,
for the time being, I'll assume that this is what you mean by the value
of a pointer.

> What is that number?
>
> Is the NUMBER of memory locations starting at zero that you should
> skip to arrive at that value. It is NOT the number of doubles,
> or long doubles or the type of whatever that pointer is being used
> for.
>
> All pointers use the same UNIT: memory locations. Of course they
> dereference different types, etc. But basically they are all the same.

I don't know what this means.  What is this UNIT?  If you mean that all
machine addresses use the same measure to determine where they point,
this is not true.  It can depend on the type.  C specifically allows for
different kinds of machine address that may use different units.  If
you've even wandered why C's rules of pointer conversion are the way
they are, it is largely because of this.

Note I switched to "machine address" rather than "pointer".  You, of all
people, know that C pointers don't use the same measure, but I think you
think that once you've moved into the realm of machine addresses, it
becomes true.  It does not (though I grant you it does on all the
hardware you've probably used).

> They are an index into the "memory" array. (Assuming non-segmented
> memory)

Not all pointers.  I've used a machine where function pointers "looked
like" small numbers.  The address of your first function was 0.  The
second was 1, the third 2, and so on.  In what useful way are these
indexes into some giant array called "memory"?

>>>> C's function pointers don't fit well into the "memory index" model
>>>> either because you can do any array-like operations with them.
>>>
>>> Function pointers can be emulated as a conceptual table of
>>> machine instructions where p points to the start of the
>>> sequence of instructions of a function.
>>
>> So you think it's helpful to consider a function pointer to be an index
>> into array, but one you can't do any array operations on?
>
> Look:
>
> double fn(int a, int b)
> {
> 	return a+b;
> }
>
> unsigned char code_for_function_fn[] = {
> 0x55,0x89,0xe5,0x57,0x8b,0x7d,0x08,
> 0x0",0x7d,0x0c,0x57,0xdb,0x04,0x24,
> 0x83,0xc4,0x04,0x5f,0x5d,0xc3};
>
> Both representations of the function "fn" are identical.

I think you misunderstand the meaning of identical.  One is portable
across machines and the other is not.  One can be called without
undefined behaviour the other can not, and so on.

> The
> proof is that if you disassemble "fn" you will obtain:
>
> [0000000] 55               push      %ebp
> [0000001] 89e5             mov       %esp,%ebp
> [0000003] 57               push      %edi
> [0000004] 8b7d08           mov       0x8(%ebp),%edi
> [0000007] 037d0c           add       0xc(%ebp),%edi
> [0000010] 57               push      %edi
> [0000011] db0424           fildl     (%esp,1)
> [0000014] 83c404           add       $0x4,%esp
> [0000017] 5f               pop       %edi
> [0000018] 5d               pop       %ebp
> [0000019] c3               ret

Honestly, do you really think I don't how it's usually done?  My point
is that is that it's not /always/ done this way, and that makes the
"pointer == machine address == index into a big array" model misleading.

> If you cast the function pointer of "fn" into a char pointer,

...you get undefined behaviour.

> you can
> even do a memcmp to verify that (obviously the actual contents could
> be different in a different version of lcc-win or with another compiler
> but that is just trivial).

Not without UB.

> All functions are just an array of instructions (well, a special array
> since instructions need not to be of the same length)

but the instructions need not be readable as data, and the pointer might
not have a representation that relates in any way to a data pointer.

>> How does that
>> help?
>
> It helps to avoid being caught by software and to realize that actually
> it is the hardware that does everything.
>
> It helps because it helps you realize how the machine actually
> WORKS...

You mean how some machines work.  I think machine addressing is best
explained by describing it directly. C deliberately abstracts out all
the possible differences between (many) machines so it does not work
well as a way to explain the possibilities.

> What type is this new array or is it the same as the other array?

(this is a miss-quote: I said it, not you).

> There is only ONE type for pointers: Memory locations (consecutive
> in a linear architecture, segmented in a "Harvard" architecture)

So on the machine I described above (function pointers being 0, 1, 2
etc), what is the type of the array into which these are indexes?

>> To my mind, this is am attempted simplification that complicates matters.
>
> Sure, but this is how machines actually WORK.

It's how many machines work, but you went further.  You were using this
idea to explain C pointers, and they don't work like this.

>>> In general, what I want to emphasize is the equivalence between array
>>> indices and pointers.
>>
>> In general, I don't want to do that.
>>
>
> You will agree that *p is the same as p[0] isn't it? For ALL p?

Kinda.  It's true in the sense that you get the same result when the
result is defined, and that both are undefined if either one is
undefined.  Are two "undefined behaviours" always "the same"?  A thread
about that could run and run.

> Why is that?

Because the language defines p[0] like that (when both are defined).

> Anyway, I understand why you do not want to do that in general. Because
> you are concerned with software and with high level languages (that
> exist only in software). And that is a very legitimate concern.

No.  I used to teach machine architecture as well, and C hides far
too much of what is going on to be useful.  It's useful to explain how C
can be implemented on, say, a word addressed machine, but you can't
illustrate the various address type in C (well, not easily) because
C, rightly, hides all that.

> I am at the interface of software and hardware. My job is to translate
> software into codes that the hardware understands, so I am more
> interested in knowing how a machine actually works beyond software
> abstractions.

Sure, but that does not mean the software abstractions don't exist.  If
this had started as a post about "what the hardware does" it would
merely be a limited perspective, but you started by saying that C
pointers are array indexes, and that is sufficiently wrong as to be
confusing to people learning C.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#13420

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> jacob navia <jacob@spamsink.net> writes:
[...]
>> You will agree that *p is the same as p[0] isn't it? For ALL p?
>
> Kinda.  It's true in the sense that you get the same result when the
> result is defined, and that both are undefined if either one is
> undefined.  Are two "undefined behaviours" always "the same"?  A thread
> about that could run and run.

And it's not true of p is a function pointer.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13424

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> jacob navia <jacob@spamsink.net> writes:
> [...]
>>> You will agree that *p is the same as p[0] isn't it? For ALL p?
>>
>> Kinda.  It's true in the sense that you get the same result when the
>> result is defined, and that both are undefined if either one is
>> undefined.  Are two "undefined behaviours" always "the same"?  A thread
>> about that could run and run.
>
> And it's not true of p is a function pointer.

Surely both *p and p[0] are undefined in that case.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#13427

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> jacob navia <jacob@spamsink.net> writes:
>> [...]
>>>> You will agree that *p is the same as p[0] isn't it? For ALL p?
>>>
>>> Kinda.  It's true in the sense that you get the same result when the
>>> result is defined, and that both are undefined if either one is
>>> undefined.  Are two "undefined behaviours" always "the same"?  A thread
>>> about that could run and run.
>>
>> And it's not true of p is a function pointer.
>
> Surely both *p and p[0] are undefined in that case.

*p is simply a function designator, with the same meaning as p (C99
6.3.2.1p4).  It's sometimes used to make it clear to the reader that p
is the name of an object of pointer-to-function type, not the name of a
function.

p[0] is a constraint violation.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13438

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> jacob navia <jacob@spamsink.net> writes:
>>> [...]
>>>>> You will agree that *p is the same as p[0] isn't it? For ALL p?
>>>>
>>>> Kinda.  It's true in the sense that you get the same result when the
>>>> result is defined, and that both are undefined if either one is
>>>> undefined.  Are two "undefined behaviours" always "the same"?  A thread
>>>> about that could run and run.
>>>
>>> And it's not true of p is a function pointer.
>>
>> Surely both *p and p[0] are undefined in that case.
>
> *p is simply a function designator, with the same meaning as p (C99
> 6.3.2.1p4).  It's sometimes used to make it clear to the reader that p
> is the name of an object of pointer-to-function type, not the name of a
> function.
>
> p[0] is a constraint violation.

Ah, yes, of course.  Thanks.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#13429

On 11/15/2011 04:15 PM, Ben Bacarisse wrote:
> Keith Thompson <kst-u@mib.org> writes:
> 
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> jacob navia <jacob@spamsink.net> writes:
>> [...]
>>>> You will agree that *p is the same as p[0] isn't it? For ALL p?
>>>
>>> Kinda.  It's true in the sense that you get the same result when the
>>> result is defined, and that both are undefined if either one is
>>> undefined.  Are two "undefined behaviours" always "the same"?  A thread
>>> about that could run and run.
>>
>> And it's not true of p is a function pointer.
> 
> Surely both *p and p[0] are undefined in that case.

If p is a function pointer, 6.5.3.2p4 seem to define *p quite nicely.
6.3.2.1p4 means that in most cases, *p is exactly equivalent to p,
rendering it rather pointless, but not undefined.

[toc] | [prev] | [next] | [standalone]

#13431

Ben Bacarisse wrote:
) Keith Thompson <kst-u@mib.org> writes:
)
)> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
)>> jacob navia <jacob@spamsink.net> writes:
)> [...]
)>>> You will agree that *p is the same as p[0] isn't it? For ALL p?
)>>
)>> Kinda.  It's true in the sense that you get the same result when the
)>> result is defined, and that both are undefined if either one is
)>> undefined.  Are two "undefined behaviours" always "the same"?  A thread
)>> about that could run and run.
)>
)> And it's not true of p is a function pointer.
)
) Surely both *p and p[0] are undefined in that case.

Well, technically what you just said is meaningless, you see,
'undefined' is not a value that a variable can take in C.

Pedantically, it is 'undefined behaviour' to access both these values.
The behaviour need not be the same for those two cases.  But then again, it
need not be the same when you compare the first case with the first case.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#13442

Willem <willem@toad.stack.nl> writes:
> Ben Bacarisse wrote:
> ) Keith Thompson <kst-u@mib.org> writes:
> )
> )> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> )>> jacob navia <jacob@spamsink.net> writes:
> )> [...]
> )>>> You will agree that *p is the same as p[0] isn't it? For ALL p?
> )>>
> )>> Kinda.  It's true in the sense that you get the same result when the
> )>> result is defined, and that both are undefined if either one is
> )>> undefined.  Are two "undefined behaviours" always "the same"?  A thread
> )>> about that could run and run.
> )>
> )> And it's not true of p is a function pointer.
> )
> ) Surely both *p and p[0] are undefined in that case.
>
> Well, technically what you just said is meaningless, you see,
> 'undefined' is not a value that a variable can take in C.
>
> Pedantically, it is 'undefined behaviour' to access both these values.
> The behaviour need not be the same for those two cases.  But then again, it
> need not be the same when you compare the first case with the first case.

No, the first is well-defined and the second is a constraint violation.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web