Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Parameters and the Stack

Reply
Thread Tools

Parameters and the Stack

 
 
Mike Wahler
Guest
Posts: n/a
 
      09-29-2003

"R.Wieser" <(E-Mail Removed)> wrote in message
news:3f789adc$0$31496$(E-Mail Removed)4al l.nl...
> CBFalconer <(E-Mail Removed)> schreef in berichtnieuws
> http://www.velocityreviews.com/forums/(E-Mail Removed)...
>
> Hello CB,
>
> > This is still OT for c.l.c. In addition, as others have
> > pointed out, there need not be any stack, or stack
> > use, whatsoever.

>
> 1) if this is OT, than your own "in addition" is certainly too ... Tsk,

tsk.
> :-\


I don't think so. I think he explained *why* OP's
query is OT.

>
> 2) If parameters are transferred by pushing them on a stack (as the OP
> describes), that stack should bloody well be there


But 'stack' is not part of the language. OP was observing
and asking about behavior of a given *implementation*, not
the language itself. Particular implementations are not
topical here, only the language.

>
> > Even if a stack and method 2 is used there is no
> > need to clean up immediately.

>
> Ofcourse. But would your "explanation" add something to the comprehension
> of the matter with the novice the answer was aimed at ? Or are you out

to
> complicate matters ? Maybe even initiate a (pardon my language)
> ****ing-contest ?
>
> > Some code generators postpone stack cleanup to a
> > convenient point. No C system is required to have a RETF or an
> > "ADD SP,(value)" instruction. My Microdata 810 certainly doesn't.

>
> Jup, it's a ****ing-contest allready ((


I don't think so. I think he's trying to clarify things
for OP.

>
> Man, get a *life* for gods sake !


A very common utterance by those who don't understand,
or simple refuse to accept reality.

>Having problems with what others do,


When folks post off topic in a topical forum, it is
indeed a problem. This is why we point it out when
something is OT, so that the OP and anyone else
reading becomes informed.

> but
> nevertheless adding to them yourself.


I don't see any additional problems, only an attempt
to correct one, and hopefully prevent future ones.

>Bad show I would say.


Good show I say. Chuck informed OP about OT-nes,
and gave a simple example to illustrate why.


>
> And please learn to read a message (the OP's) before you answer it ...


Chuck's reply indicates to me that he *did* read the message.
I find his words quite appropriate to the situation.

>It
> should save you some embarrassment.


Go look in a mirror.

-Mike


 
Reply With Quote
 
 
 
 
Charles A. Crayne
Guest
Posts: n/a
 
      09-29-2003
On Mon, 29 Sep 2003 22:42:29 +0200
"R.Wieser" <(E-Mail Removed)> wrote:

:Jup, it's a ****ing-contest allready ((

And therefore, it has been placed on the Robomoderator's "suspicious
subjects" list. So play nice.

-- The Moderator


 
Reply With Quote
 
 
 
 
Robert Redelmeier
Guest
Posts: n/a
 
      09-30-2003
In comp.lang.asm.x86 CBFalconer <(E-Mail Removed)> wrote:
> "R.Wieser" wrote:
>> There are two way's to handle the arguments that where pushed
>> onto the stack before a routine is called :
>> 1) The routine itself removes them off the stack.
>> 2) the program that calls the routine removes them off the
>> stack.


> This is still OT for c.l.c. In addition, as others have pointed
> out, there need not be any stack, or stack use, whatsoever. Even


Perhaps I can bring it a bit closer to c.l.c and clax86:

`c` permits variable numbers of perameters in a fn call.
`printf` is an excellent example.

If there is a hardware stack as on x86, it is more robust
the caller adjust it (2 above via add esp,NPARMS) than the
callee adjust it (1 above via ret NPARMS). The caller is
more likely to get it right and is less bug-sensitive:

printf ("%d one bug %d", i);

will likely crash the caller when it tried to return if
`printf` has done stack adjustment. If the caller does
adjustment, the printf will just print i & it's return addr.

-- Robert

 
Reply With Quote
 
Glen Herrmannsfeldt
Guest
Posts: n/a
 
      09-30-2003

"Bertrand Mollinier Toublet"
<(E-Mail Removed)> wrote in message
news:bl80ln$95nll$(E-Mail Removed)-berlin.de...
> (E-Mail Removed) wrote:


> > I am confused about the methods by which C passes things to other
> > routines. If I have a routine,
> >

> The "method by which C passes things to other routines" is not
> specified. Every implementor is free, from the C standard's point of
> view, to implement it as they please.


Well, not completely free. C's use of functions with a variable number of
arguments limits it somewhat.

For example, a convention where the called routine pops the arguments off
the stack, while assuming that the number of arguments agrees with the
number in the function definition would not work. The called routine must
be able to get to earlier arguments to determine the number of arguments,
which is one reason for the right to left push of the arguments on the
stack.

(I believe it is legal to use a different calling convention for varargs
functions and normal functions, but it is more convenient not to do that.)

Note that the IBM S/370 doesn't have a stack, and the normal calling
convention doesn't require one.

Whether or not a particular calling convention was compatible with the
requirements of C should be on topic. The advantages or disadvantages might
also be. The ability to call subprograms in other languages, or to call C
functions from other languages might be.

-- glen


 
Reply With Quote
 
IMSHURKKPWII@spammotel.com
Guest
Posts: n/a
 
      09-30-2003
Thanks everyone! That was very helpful. Adding to SP to remove
arguments turned out to be the method employed.

-HG.

 
Reply With Quote
 
Mark Gordon
Guest
Posts: n/a
 
      09-30-2003
On Tue, 30 Sep 2003 02:26:53 GMT
"Glen Herrmannsfeldt" <(E-Mail Removed)> wrote:

> "Bertrand Mollinier Toublet"
> <(E-Mail Removed)> wrote in message
> news:bl80ln$95nll$(E-Mail Removed)-berlin.de...
> > (E-Mail Removed) wrote:

>
> > > I am confused about the methods by which C passes things to other
> > > routines. If I have a routine,
> > >

> > The "method by which C passes things to other routines" is not
> > specified. Every implementor is free, from the C standard's point of
> > view, to implement it as they please.

>
> Well, not completely free. C's use of functions with a variable
> number of arguments limits it somewhat.
>
> For example, a convention where the called routine pops the arguments
> off the stack, while assuming that the number of arguments agrees with
> the number in the function definition would not work. The called
> routine must be able to get to earlier arguments to determine the
> number of arguments, which is one reason for the right to left push of
> the arguments on the stack.


The called routine does not need to be able to determine the number of
arguments, only where to find them. One option if using a stack and
pushing the left most argument first is to leave a register pointing to
the first argument. Another is to leave a register pointing to the last
argument before the varargs.

> (I believe it is legal to use a different calling convention for
> varargs functions and normal functions, but it is more convenient not
> to do that.)


It is legal to use different calling conventions for every individual
function as long as the compiler/linker make it all tie up at the end of
the day.

> Note that the IBM S/370 doesn't have a stack, and the normal calling
> convention doesn't require one.
>
> Whether or not a particular calling convention was compatible with the
> requirements of C should be on topic. The advantages or disadvantages
> might also be. The ability to call subprograms in other languages, or
> to call C functions from other languages might be.


Calling conventions are completely OT for this group because they are
entirely implementation dependant. If you want to discuss the merits of
different calling conventions you either want a group dealing with
writing compilers or a group for a specific processor (since the "best"
convention will depend on the details of the processor).
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.

 
Reply With Quote
 
Charles A. Crayne
Guest
Posts: n/a
 
      09-30-2003
On Tue, 30 Sep 2003 10:30:45 +0100
Mark Gordon <(E-Mail Removed)> wrote:

:Calling conventions are completely OT for this group because they are
:entirely implementation dependant.

Please note that the phrase "for this group" is a meaningless referent,
because there is no way for a reader to determine which newsgroup you are
posting from.

-- clax86 moderator

 
Reply With Quote
 
Mark Gordon
Guest
Posts: n/a
 
      10-01-2003
On Tue, 30 Sep 2003 11:30:07 -0700
"Charles A. Crayne" <(E-Mail Removed)> wrote:

> On Tue, 30 Sep 2003 10:30:45 +0100
> Mark Gordon <(E-Mail Removed)> wrote:
>
> :Calling conventions are completely OT for this group because they are
> :entirely implementation dependant.
>
> Please note that the phrase "for this group" is a meaningless
> referent, because there is no way for a reader to determine which
> newsgroup you are posting from.


Sorry, I missed the cross-post. Calling conventions are OT in
comp.lang.c, over in comp.lang.asm.x86 I can see that they could be on
topic.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.

 
Reply With Quote
 
R.Wieser
Guest
Posts: n/a
 
      10-01-2003
<(E-Mail Removed)> schreef in berichtnieuws
(E-Mail Removed)...

Hello HG,

> Thanks everyone! That was very helpful. Adding to SP to remove
> arguments turned out to be the method employed.


I'm glad our answers helped. Thanks for telling us

Regards,
Rudy Wieser




 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Why does std::stack::pop() not throw an exception if the stack is empty? Debajit Adhikary C++ 36 02-10-2011 08:54 PM
C/C++ compilers have one stack for local variables and return addresses and then another stack for array allocations on the stack. Casey Hawthorne C Programming 3 11-01-2009 08:23 PM
stack frame size on linux/solaris of a running application stack Surinder Singh C Programming 1 12-20-2007 01:16 PM
Why stack overflow with such a small stack? Kenneth McDonald Ruby 7 09-01-2007 04:21 AM
"stack level too deep"... because Threads keep their "starting" stack Sam Roberts Ruby 1 02-11-2005 04:25 AM



Advertisments