From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,2cb1f0b6d642e1dc X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!z27g2000prz.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Pascal Calling Convention Date: Mon, 28 Mar 2011 08:41:21 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <9b04626e-567d-408c-aab3-39b964b3ffd6@l2g2000prg.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1301326882 19761 127.0.0.1 (28 Mar 2011 15:41:22 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 28 Mar 2011 15:41:22 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: z27g2000prz.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:18545 Date: 2011-03-28T08:41:21-07:00 List-Id: On Mar 26, 7:24=A0pm, "Randy Brukardt" wrote: > "Robert A Duff" wrote in messagenews:wccbp= 0xy5hu.fsf@shell01.TheWorld.com... > ... > > > Thanks for the clarification. =A0I agree with the above, and of course = I > > agree that the stack doesn't have to be a contiguous block of memory. > > But why do you call that "contiguous stack" thing a "hardware stack"? > > I mean, on most architectures, push/pop are implemented by subtract/add > > instructions on the stack pointer register. =A0That's not a whole lot o= f > > "hardware support for stacks". =A0The hardware has instructions that > > support implementing arrays, and linked lists, too, but we don't call t= hem > > "hardware arrays" or "hardware linked lists". > > > OK, on x86, there are push/pop instructions. =A0But most stack > > manipulation is still just subtract/add. =A0Call pushes a return addres= s. > > Enter/leave instructions are stack-oriented, but nobody uses those, > > because they're slow. =A0Maybe "the stack" on x86 could be called a > > "hardware stack", but it's pretty marginal in practice. > > I can't speak for Keith, but most of the hardware architectures that I've > worked on have had at least some architectual support for a "hardware" > stack. Not only the Push/Pop instructions of the X86 for instance, but al= so > the special SS stack segment register. The 68K also had a dedicated stack > register and some special instructions for call/ret. Even the Unisys U220= 0 > mainframe had a stack segment and special instructions for call/ret and > stack frames. I've worked with several RISC machines that don't have this kind of support, though. There are, of course, calling conventions for those machines that programmers follow (if they want their programs to cooperate in any way with other software), and conventionally one particular register is designated the stack register. But from a hardware standpoint, there's nothing special about the register, in the sense that there are no instructions that operate on that register that aren't available on all general registers, and nothing else special about how the register is implemented in hardware (such as being one of a few designated registers that are saved when an interrupt occurs). I don't know what the definition of "hardware- supported stack" is, but it seems like having a special stack register would be one necessary characteristic. -- Adam