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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#13433

On 2011-11-15, Ben Bacarisse <ben.usenet@bsb.me.uk> 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.

So far as I can tell, p[0] is undefined because it's *(p+0) and I don't
think arithmetic operators are defined on function pointers, even when
they should be identities, but *p is perfectly well defined.  It turns
out to be the same as p, though.

Basically, the very old idiom
	(*fp)();
is preserved by stating that you can dereference a function pointer but
the function decays back into its address immediately.

If memory serves, this means that, given a function pointer fp, you can
do stuff like
	fp();
	(*fp)();
	(*************fp)();
and get the same results in all cases.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#13439

Seebs <usenet-nospam@seebs.net> writes:

> On 2011-11-15, Ben Bacarisse <ben.usenet@bsb.me.uk> 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.
>
> So far as I can tell, p[0] is undefined because it's *(p+0) and I don't
> think arithmetic operators are defined on function pointers, even when
> they should be identities, but *p is perfectly well defined.  It turns
> out to be the same as p, though.
>
> Basically, the very old idiom
> 	(*fp)();
> is preserved by stating that you can dereference a function pointer but
> the function decays back into its address immediately.
>
> If memory serves, this means that, given a function pointer fp, you can
> do stuff like
> 	fp();
> 	(*fp)();
> 	(*************fp)();
> and get the same results in all cases.

Yes, I'd forgotten the old idiomatic (and the still perfectly valid) *p
despite using old versions of C where it was required.  How quickly
people forget!

-- 
Ben.

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

#13403

"jacob navia" <jacob@spamsink.net> wrote in message
news:j9tk3s$7bl$1@speranza.aioe.org...
> 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)


Yes, you can throw away everything in C, and just have a gigantic static
array of bytes 'memory'.

But superimposing ordinary variables, arrays, and structs on top of that is
fiddly.

However, even supposing that was done, that's not sufficient, because each
function invocation will have it's own local byte-array for local variables. 
Now, this array can presumably also be located a space somewhere in the 
global array, but then, so what?

I'm not sure where you're going with this. You know have control over the
size and range of pointers, by using indexes (although if memory[] is the
same size as the machine's memory, the width of your index will be the same
as the width of your pointers), but you've thrown away half of C too, and
programming becomes next to impossible.

Maybe this is how it's all done at a low-level, but I don't think it's what
that poster had in mind.

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

Array accesses usually involve two elements: the array, and the index. And
the array itself will be a pointer (that is, if you forget the nonsense
about a giant byte-array).

While pointer accesses usually involve one element, the pointer value, with
an optional offset.

And if you have this:

 int A;

and want to pass a pointer to A to some function, how exactly would you turn
that into an index, without rewriting your entire application in a
stripped-down, low-level version of C?

-- 
Bartc 

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

#13417

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 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>

And the C memory model does *not* treat all of memory as a single array.

-- 
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]

#13458

On 11/15/11 5:25 AM, jacob navia wrote:

>> 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!
> 
> 

I have used several machines with the equivalent of a CALL instruction
and no built in stack.

On one, the call instruction deposited the return address into the
location pointed to by the call instruction, and began execution at the
next word of memory. (This machine of course did not have the concept of
"Rom", all memory was Read/Write, (actually Core)).  Typically the
subroutine would be written with the Word before the entry point
containing a "Jump Far" instruction, which took 2 words, the second
being the address to jump to.

A second machine a CALL instruction was described as a Branch & Link
instruction, where prior to jumping to the specified address, the return
address was moved into a "link" register. (Interrupts needed their own
version of this register). If a subroutine needed to call another
subroutine, it needed to save this register before making the call.

Compilers for these machines would use an extension to the language to
mark functions that might be recursive, and those would use a special
software based stack to save any needed data, like the return address.
No recursive functions would use static addresses for this. Of course to
be able to claim to be ISO Standard C, they would need to assume that
all functions were recursive, but then I was using these machines before
C90 was a standard.

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

#13460

Richard Damon <news.x.richarddamon@xoxy.net> writes:
> On 11/15/11 5:25 AM, jacob navia wrote:
>>> 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!
>
> I have used several machines with the equivalent of a CALL instruction
> and no built in stack.

I think (I *hope*) that the two of you are using the word "stack"
in two different ways.

There has to be a conceptual stack of some sort (a last-in first-out
data structure) to support recursion.  (The same mechanism is
commonly used to support non-recursive function calls as well.)
The implementation of that stack may or may not be a contiguous
linearly growing region of memory of the kind that exists on many
common C implementations.

[...]

-- 
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]

#13461

On Tue, 15 Nov 2011 23:07:10 -0500, Richard Damon
<news.x.richarddamon@xoxy.net> wrote:
>
>I have used several machines with the equivalent of a CALL instruction
>and no built in stack.
>
>On one, the call instruction deposited the return address into the
>location pointed to by the call instruction, and began execution at the
>next word of memory. (This machine of course did not have the concept of
>"Rom", all memory was Read/Write, (actually Core)).  Typically the
>subroutine would be written with the Word before the entry point
>containing a "Jump Far" instruction, which took 2 words, the second
>being the address to jump to.



This machine didn't happen to have 12 bit words, did it?  (Although
the PDP-8 was not the only machine that used that scheme.)

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

#13470

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message 
news:p9g6c7dr6co1bh8vb3827mlsp6qehnc90c@4ax.com...
> On Tue, 15 Nov 2011 23:07:10 -0500, Richard Damon
> <news.x.richarddamon@xoxy.net> wrote:
>>
>>I have used several machines with the equivalent of a CALL instruction
>>and no built in stack.
>>
>>On one, the call instruction deposited the return address into the
>>location pointed to by the call instruction, and began execution at the
>>next word of memory. (This machine of course did not have the concept of
>>"Rom", all memory was Read/Write, (actually Core)).  Typically the
>>subroutine would be written with the Word before the entry point
>>containing a "Jump Far" instruction, which took 2 words, the second
>>being the address to jump to.
>
>
>
> This machine didn't happen to have 12 bit words, did it?  (Although
> the PDP-8 was not the only machine that used that scheme.)

The Digico Micro 16V used the same scheme. I believe that used 16 bits 
(instructions had 4-bit opcodes, and 12-bit address fields).

-- 
Bartc  

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

#13483

In article <ja08m1$s1v$1@dont-email.me>, BartC <bc@freeuk.com> wrote:
>
>>
>> This machine didn't happen to have 12 bit words, did it?  (Although
>> the PDP-8 was not the only machine that used that scheme.)
>
>The Digico Micro 16V used the same scheme. I believe that used 16 bits 
>(instructions had 4-bit opcodes, and 12-bit address fields).

PDP-10 (and I assume PDP-6) also had that scheme, but I doubt it was used
very much.

The second scheme (link registers) included, of course, the IBM 360/370 series.

-- 
	-Ed Falk, falk@despams.r.us.com
	http://thespamdiaries.blogspot.com/

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

#15939

On Tue, 15 Nov 2011 22:53:57 -0600, Robert Wessel
<robertwessel2@yahoo.com> wrote:

> On Tue, 15 Nov 2011 23:07:10 -0500, Richard Damon
> <news.x.richarddamon@xoxy.net> wrote:
> >
> >I have used several machines with the equivalent of a CALL instruction
> >and no built in stack.
> >
> >On one, the call instruction deposited the return address into the
> >location pointed to by the call instruction, and began execution at the
> >next word of memory. (This machine of course did not have the concept of
> >"Rom", all memory was Read/Write, (actually Core)).  Typically the
> >subroutine would be written with the Word before the entry point
> >containing a "Jump Far" instruction, which took 2 words, the second
> >being the address to jump to.
> 
> 
> 
> This machine didn't happen to have 12 bit words, did it?  (Although
> the PDP-8 was not the only machine that used that scheme.)

PDP-8 doesn't do exactly that. It does store the return address in the
first word of the subroutine, but you return with a 'jump indirect'
from anywhere in the same page; there is no 'jump far' as such,
although it might be convenient sometimes to put your 'jump indirect'
in the word before the return-address word.

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

#13393

jacob navia wrote:

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


I  believe ( if I have my Barry's right) that Barry may be working on an IBM
mainframe.

We happen to make C/C++ compilers for the mainframe...

There is no hardware stack (well - technically there is, but it's not very
convenient and isn't used much.... it's a "newer" addition to the hardware
and is a little cumbersome to use and pretty much only stacks the 
registers.)

On the IBM mainframe, programs typically do reserve a register to
be the "stack pointer" - they call it the "dynamic save area" (DSA).
Most of the time, this is R13, but that is only by convention.. and many
programmers choose alternatives.

There is no "call" instruction - there is a BALR (Branch and Link Register).
BALR names two registers - the first one receives the address of the
instruction following the BALR, the 2nd one has the branch target.

Thus - to effect a "call", you use BALR to jump to the routine.   The 
routine
is then obliged to allocate some space and point R13 to it.  It can then
save the remaining registers along with the return address (loaded into R14
by the BALR instruction.)  You also want to save the previous R13 before
pointing at the new space.

(There is a newer variant of the BALR, named BASR - to handle some
addressing mode situations... newer being, only 20-30 yrs old...  BALR
was part of the original specification.)

The "allocation of space" can be as simple as pointing R13 at some static
space in the program; or as complicated as invoking operating system
services to dynamically allocate space, or having the runtime system
manage this space by allocating blocks and giving up chunks of the blocks
as needed.

Then, on return, you load R13 from the saved location (to restore its 
previous
value) as well as the other registers... which includes the initial 
value of R14.
And, you branch back to the location specified in R14.   (You may also have
to de-allocate the space allocated at the start.)

The act of
    1) Save R13
    2) Point R13 at some new space
        ...
    n) Restore R13 to old value

clearly is a "stack" in the C sense.   But, it is interesting to note that
this stack is not contiguous.  One stack location doesn't necessarily
have any bearing on another, etc...

This is by convention only - and many mainframe programming
environments decide to abandon that convention... making it rather
frustrating to mix-and-match language implementations or runtime
environments.

So - you are partially right - there is by convention a "stack pointer",
but you can't just subtract a value from it any expect it to work
in any meaningful fashion.

There are aveats here - the newer, post 1990 hardware implemented guard
pages and copy-on-write in the virtual memory addressing system,
so there are new linkage conventions - called XPLINK, that get
close to the subtrace-a-value-from-the-stack-pointer paradigm.  But, if the
value you want to subtract is larger than the hardware page size,
then you still have to "punt out" to an out-of-line routine to allocate
stack space and move the guard page...

Also - this all pertains to MVS and z/OS.  The z/Linux linkage conventions
follow the z/Linux ELF ABI, where R15 is the stack pointer... and where
things work as you might expect.


   - Dave Rivers -

-- 
rivers@dignus.com                        Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

#13452

On Tue, 15 Nov 2011 09:22:39 +0100, jacob navia <jacob@spamsink.net>
wrote:

>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:

You and io_x deserve each other.

-- 
Remove del for email

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

#13402

"Barry Schwarz" <schwarzb@dqel.com> ha scritto nel messaggio
news:j3r3c7tl1v45qjvee173t8759n1074h4ll@4ax.com...
> 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.

yes i have if the size of executable + data reachable is short
for 32 bits
e.g. executable + data are in the address 0..12345
so uns16_t can be ok as a pointer

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

your system can not work to the right way, has to be slow,
because variables memory for functions has to be in a stack
way for to be fast

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

i believe only in what i see: and i see stack is a very good thing;
all informatic without stacks for me is not good.

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

#13453

On Tue, 15 Nov 2011 19:21:12 +0100, "io_x" <a@b.c.invalid> wrote:

>
>"Barry Schwarz" <schwarzb@dqel.com> ha scritto nel messaggio
>news:j3r3c7tl1v45qjvee173t8759n1074h4ll@4ax.com...
>> 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.
>
>yes i have if the size of executable + data reachable is short
>for 32 bits
>e.g. executable + data are in the address 0..12345
>so uns16_t can be ok as a pointer

If you already knew how to do what you wanted, why did you bother
asking?

>
>>>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.
>
>your system can not work to the right way, has to be slow,
>because variables memory for functions has to be in a stack
>way for to be fast

I'll be sure to tell IBM that their mainframes are slow (in spite of
all the business processing currently being done on them) and cannot
have a C compiler (in spite of the three that I'm aware of, including
the ubiquitous gcc).

>
>>>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.
>
>i believe only in what i see: and i see stack is a very good thing;
>all informatic without stacks for me is not good.

Fortunately, myopia is not very contagious.

-- 
Remove del for email

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

#13581

"Barry Schwarz" <schwarzb@dqel.com> ha scritto nel messaggio
news:hn26c7lev40tsaniu3rjua2525pidldjjb@4ax.com...
> On Tue, 15 Nov 2011 19:21:12 +0100, "io_x" <a@b.c.invalid> wrote:
>>>>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.
>>
>>yes i have if the size of executable + data reachable is short
>>for 32 bits
>>e.g. executable + data are in the address 0..12345
>>so uns16_t can be ok as a pointer
>
> If you already knew how to do what you wanted, why did you bother
> asking?

The questions here are:

FOR CODE
Is the address 0..0FFFFFFFFh enought for contain in the txt region
one program [in cpu instructions]?

That range address can contain one OS, and all *usefull*
program one can imagine?

for me the answer is yes.

FOR DATA
Is the address 0..0FFFFFFFFh enought for contain in the data region
all possible data useful for one program?

for data it is not true so i think i need a range address of 64 bits
so some register of 64 bit or a coulple of 2 32 bit registers
and some special instruction for see the data...

possibly i don't know what i say, and i'm just a troll
and what i say has no meaning...
excuse for the time all you lost for that
Have good days

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

#13365

io_x wrote:z

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

Portable in what sense?  In the sense that, if you compile it specifically 
for a target platform then your code would run without any change?  Or in 
the sense that one could copy a binary to a different platform and it would 
successfully execute just as it is?


> 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

Yes, it's possible to call functions like that.  In fact, it's how the so 
called C calling convention (CDECL) and standard calling convention 
(STDCALL) handle function parameters.

Regarding the stack bit, a stack isn't necessarily required to call 
functions.  Other calling conventions, such as the FASTCALL calling 
convention, passes the first parameters through registers.


Rui Maciel

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

#13400

"Rui Maciel" <rui.maciel@gmail.com> ha scritto nel messaggio
news:j9te1m$m98$1@speranza.aioe.org...
> io_x wrote:z
>
>> 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"?
>
> Portable in what sense?  In the sense that, if you compile it specifically
> for a target platform then your code would run without any change?

yes, without undefinited behaviour we have the portable assembly, we have
the cpu the language define
type of fixed size, operation without UB on these types, a stack
and a stack pointer for define push32, pop32 etc and
a portable way of calling32

> Or in
> the sense that one could copy a binary to a different platform and it would
> successfully execute just as it is?

not the binary, but the result of the compilation

>> 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
>
> Yes, it's possible to call functions like that.  In fact, it's how the so
> called C calling convention (CDECL) and standard calling convention
> (STDCALL) handle function parameters.

good both, stdcall i remember i like more

> Regarding the stack bit, a stack isn't necessarily required to call
> functions.  Other calling conventions, such as the FASTCALL calling
> convention, passes the first parameters through registers.

i don't like that

> Rui Maciel

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

#13392

In article <4ec14700$0$1387$4fafbaef@reader2.news.tin.it>,
 "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?
> is it possible to define in C a pointer of size 32 bits portable
> as uns32_t? could it be "uns32_t"?

If your implementation defines intptr_t, that is an integer the implementations 
gurarantees is large enough to hold a pointer.


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

You would have to intermingle such a stack with function calls, popping the 
stack as you return from calls. If you don't want to tie the stack to the calls, 
you would have to implement the stack separately. There are many such 
implementations.

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

An implementation is allowed to handle calls in a manner that correctly executes 
the program. For example if the compiler/linker determines there is no 
recursion, it can statically allocate all locals, argument lists, and return 
address holders.

-- 
White folks think they're at the top,  |   Faded, patched, secret so tight...
ask any proud white male.              |       I'm whoever you want me to be.
A million years of evolution,          |  Annoying Usenet one post at a time.
and we get Danny Quayle.               |    At least I can stay in character.

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

#13394

On 2011-11-14, 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?
> is it possible to define in C a pointer of size 32 bits portable
> as uns32_t? could it be "uns32_t"?

Maybe you are thinking about

  typedef uint32_t *p_uint32_t;


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

In general, no.

It is possible to develop a portable library for constructing C function calls
at run time. (Just not portable in the sense that it easily compiles for
new machines, but portable in the sense that someone who knows what he or she
is doing can put in some work to get it going in a given environment.)

Look for Bruno Haible's "ffcall" collection of libraries:

http://www.haible.de/bruno/packages-ffcall-README.html

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

I do not. On many architectures, arguments are passed in registers.  If there
are many arguments, then some combination of stack and registers is used.
In general, preparing the machine for a call to a routine requires assembly
language programming.

The above "ffcall" libraries include assembly language code for various target
machines.

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

#13401

"Kaz Kylheku" <kaz@kylheku.com> ha scritto nel messaggio
news:20111115081750.842@kylheku.com...
> On 2011-11-14, 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?
>> is it possible to define in C a pointer of size 32 bits portable
>> as uns32_t? could it be "uns32_t"?
>
> Maybe you are thinking about
>
>  typedef uint32_t *p_uint32_t;

no i think uint32_t as a pointer; in x86 for 32 bit is possible,
in x86 for 64 bit it is possible if the code+data can have
rapresentation in 0..UNS32_MAX [all seen as one array of 4GB]

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

so without define the stack: how are possible recursive functions?
how one can say no to the varibles local to function in memory;
as the memory representation of variables in a stack way?

> It is possible to develop a portable library for constructing C function calls
> at run time. (Just not portable in the sense that it easily compiles for
> new machines, but portable in the sense that someone who knows what he or she
> is doing can put in some work to get it going in a given environment.)
>
> Look for Bruno Haible's "ffcall" collection of libraries:
>
> http://www.haible.de/bruno/packages-ffcall-README.html

>> i remember someone says that for calling function
>> it has to be a stack: i'm agree with him
>
> I do not. On many architectures, arguments are passed in registers.

wrong wrong

> If there
> are many arguments, then some combination of stack and registers is used.

wrong wrong

> In general, preparing the machine for a call to a routine requires assembly
> language programming.
>
> The above "ffcall" libraries include assembly language code for various target
> machines.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web