Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Re: A portable stack in C (http://www.velocityreviews.com/forums/t805931-re-a-portable-stack-in-c.html)

Barry Schwarz 11-15-2011 04:55 AM

Re: A portable stack in C
 
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

jacob navia 11-15-2011 08:22 AM

Re: A portable stack in C
 
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?

Ike Naar 11-15-2011 09:00 AM

Re: A portable stack in C
 
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.

BartC 11-15-2011 10:05 AM

Re: A portable stack in C
 
"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



jacob navia 11-15-2011 10:25 AM

Re: A portable stack in C
 
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!



jacob navia 11-15-2011 10:26 AM

Re: A portable stack in C
 
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.


BartC 11-15-2011 11:08 AM

Re: A portable stack in C
 
"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


Ben Bacarisse 11-15-2011 11:45 AM

Re: A portable stack in C
 
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.

jacob navia 11-15-2011 11:57 AM

Re: A portable stack in C
 
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... :-)





Ben Bacarisse 11-15-2011 12:39 PM

Re: A portable stack in C
 
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.


All times are GMT. The time now is 05:45 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.