Xref: utzoo comp.unix.questions:30013 comp.unix.internals:2472 comp.unix.programmer:1482 comp.lang.c:37874 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!ucsd!ucbvax!unisoft!greywolf From: greywolf@unisoft.UUCP (The Grey Wolf) Newsgroups: comp.unix.questions,comp.unix.internals,comp.unix.programmer,comp.lang.c Subject: Re: Unix Stack Frame Questions Message-ID: <3465@unisoft.UUCP> Date: 3 Apr 91 01:23:59 GMT References: <125@epic.epic.com> Reply-To: greywolf@unisoft.UUCP (The Grey Wolf) Distribution: na Organization: Foo Bar and Grill Lines: 29 /* by goehring@gnu.ai.mit.edu * In article <125@epic.epic.com> tan@epic.epic.com (Andy Tan) writes: * * 1. Is it right to assume that the address of the last automatic * variable is the bottom of stack frame ? * * it is not right to assume that there is a stack frame, and some * compilers aren't going to put autos in the frame even if a frame * exists since they can be more cheaply handled with registers. If, of course, you have the registers (68K only have so many). If there's not a stack frame, how are parameters passed to the function...? And how would you return...? * every cpu is going to have varying stack frame format(s), assuming the * cpu enforces one at all, and OS and compiler vendors are more than happy * to create oddball parameter passing and stack frame conventions. I didn't think that a CPU ever "enforced" a stack frame; ostensibly one could ignore the references to "4(fp)" in the manual and do it their own way. But a stack frame seems to be the most efficient way of dealing with calls and returns. * -- * Help stamp out vi in our lifetime! * Scott Goehring goehring@gnu.ai.mit.edu * On exile in Indianapolis, IN