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-7-bit Path: g2news2.google.com!news1.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting.com!newshosting.com!news-out.readnews.com!transit3.readnews.com!newspump.sol.net!news.mv.net!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Pascal Calling Convention Date: Tue, 29 Mar 2011 15:19:50 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <9b04626e-567d-408c-aab3-39b964b3ffd6@l2g2000prg.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1301426390 16722 192.74.137.71 (29 Mar 2011 19:19:50 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 29 Mar 2011 19:19:50 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:T7kRZMNpU1n3/1WjgJ42nSXQTiA= Xref: g2news2.google.com comp.lang.ada:19554 Date: 2011-03-29T15:19:50-04:00 List-Id: "Randy Brukardt" writes: >...The problem with segments > is segments that are too small, not the basic idea. One problem with segments is that you need twice as many address bits to address the same amount of memory. If you give me a 64-bit address that has a 32-bit segment number and a 32-bit offset, they're too small, and not enough of them (for some purposes). I'd rather have a 64-bit flat address space. So maybe you give me a 128-bit address. Now there are plenty of segments and they're plenty big, but you've hugely increased the size of all my pointer-heavy data structures, causing all my programs to run slower. In that case, I still want a 64-bit flat address space. And if you don't like buffer overruns, use any langauge that prevents them (like Ada and many others). Note that x86 segmentation won't do array-bounds checking correctly, so the compiler has to implement it in software anyway. (Think about a packed array of Boolean.) >> Keith is trying to clarify, by calling that contiguous thing >> a "hardware stack", but I'm saying the word "hardware" doesn't >> capture the intended meaning. > > It does on most architectures. I don't believe I've ever seen a modern > architecture without some sort of Call/Return instructions. Most RISC machines I've seen have call/ret, but they are not stack instructions. Call saves the return address in a register. Ret jumps based on the content of a register. It's up to software to push/pop return addresses on a stack. I'll grant you that the term "hardware stack" might make sense in the x86 context, and some others. >... Some of them > allow use of any register, so there isn't a dedicated stack register. > > In any case, I read your reply as saying that it didn't make sense to ever > refer to a "hardware stack", which makes no sense to me. It's not what I meant. >... As soon as you are > talking about hardware or implementations, you are talking in a > target-specific way, ... Not at all. The statement "All Ada implementations must use a stack to implement procedure calls, because the semantics are FIFO." is talking about implementations, but it's not target-specific. Keith was just trying to clarify that that statement doesn't imply anything about the way the stack is implemented. He is, of course, right. He's also right that it needs clarification, because some people think call/return stacks must be contiguous chunks of memory. Or they think they always are contiguous, and there are no machines (or languages!) where it makes sense to do otherwise. >...so it doesn't make much sense to make any > generalizations. And it's a generalization, and it makes sense, and it's even true (that "All Ada ... stack ..."). >...It makes perfect sense to talk about a hardware stack on an > X86; if you are talking about some other target, maybe not. - Bob