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!news4.google.com!proxad.net!feeder1-2.proxad.net!news.in2p3.fr!in2p3.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Pascal Calling Convention Date: Tue, 29 Mar 2011 19:02:23 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <9b04626e-567d-408c-aab3-39b964b3ffd6@l2g2000prg.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1301443349 12190 69.95.181.76 (30 Mar 2011 00:02:29 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 30 Mar 2011 00:02:29 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Xref: g2news2.google.com comp.lang.ada:19563 Date: 2011-03-29T19:02:23-05:00 List-Id: "Robert A Duff" wrote in message news:wccy63xspih.fsf@shell01.TheWorld.com... > "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. You're thinking completely wrong. You almost never would want an address of any arbitrary memory, so the segment is almost always implicit. All of the data goes into a data segment; you never have data addresses that point somewhere else. All of the code goes into a code segment, you never have code addresses that point somewhere else. In the rare case that you need extra segments (such as implementing 'Address), yes the addresses are a bit longer. But those cases are so rare that you'll hardly ever see them in practice. (Also, there is no reason for segment numbers to be more than 16 bits, there should never be more than a handful per program.) The size of System.Address in Janus/Ada was 48-bits (16 bit segment, 32 bit offset); we finally changed that to drop the segment for the Windows version just a couple of years ago because it was (very) occassionally causing trouble. The code generator still understands the 48-bit type. And the maximum segment size should always be the same as the maximum address space (32-bits on a 32-bit machine, 64-bits on a 64-bit machine). Although I think you could make an argument for a 48-bit segment size and 16-bit segment value size on a 64-bit machine; 48-bits comes close to the maximum amount of memory that will be constructable in a digital machine. > And if you don't like buffer overruns, use any langauge that > prevents them (like Ada and many others). One use of pragma Suppress or an interface to the OS or one bug and that "protection" is gone. 99% of the time, executing data is a bug. Why allow it by default? > 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.) That's not relevant to my point, which is simply that not allowing the execution of data in the default case would prevent almost all code injection attacks (usually accomplished via buffer overflows, but there are lots of other ways). There is no protection against clobbering data, and I don't think there can be any (besides the software techniques) unless the hardware supports very fine-grained memory management -- and that is likely to be far too much of a drag on performance. ... >>... 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. I think it is also close to junk. The semantics are FIFO is fine, but anything about the underlying data structure is bogus. Unless you are equating FIFO with stack in all cases, which I don't agree with. A stack is FIFO, but I don't think that implies that all data structures that are FIFO are stacks. Anyway, this is a pointless discussion. Let's go back to discussing whether membership is a set operation. ;-) Randy.