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: a07f3367d7,9506bdc34331969a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!i18g2000pro.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: put of access type Date: Wed, 19 Aug 2009 14:01:28 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <8sho8596j3qnja38id9ipejk0opkcn5b5m@4ax.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 1250715689 781 127.0.0.1 (19 Aug 2009 21:01:29 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 19 Aug 2009 21:01:29 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i18g2000pro.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),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:7882 Date: 2009-08-19T14:01:28-07:00 List-Id: On Aug 19, 12:00=A0pm, Rob Solomon wrote: > I am trying to understand this. =A0 > > Back when I learned Modula-2, I learned that pointer types are > assignment compatible with System.Address and I understand them as > being the same thing. =A0They =A0differ in context, not value. > > I see that access types are being used the same as pointer types, but > if I understand correctly, are actually quite different. =A0But I don't > understand how. =A0ie, how are access types and pointers different? Access types can potentially carry more information than just an "address" of something. Simon mentioned one; if a type is "access String;", then a value that designates a string has to carry not just the address of the sequence of characters, it also has to carry the lower and upper bounds of the string, somehow (either the access value is a pointer to a structure that contains the bounds somewhere, or the bounds could be part of the access value). Besides that, there are other cases where access objects need additional information. In some cases, like access parameters, an access object may carry both an "address" and some information about the accessibility level, in order to prevent these access objects from being stored in a way that produce pointers to objects that no longer exist (on the stack). For access-to-subprogram objects, the access object may need to carry information about the stack frame, so that when a subprogram is called indirectly, it will refer to the right local variables. Here, it's possible to implement access-to- subprogram objects without that extra information. But since Ada refuses to equate an "access" with an "address", it allows implementors the freedom to implement access types as something more than mere addresses. Also, there's no rule saying that an access value has to be an address at all. It's certainly conceivable that an access value may be implemented as a reference to some storage pool and an offset into that pool, allowing for the possibility that the memory management system may just decide to pick up the whole pool and move it to some other address, without making any of the access values invalid. I don't know of any implementation that actually does this, but since Ada doesn't equate accesses with addresses, it certainly makes something like that possible if it's needed. Also, I can envision that an access-to-task might, in some cases, not be an address at all, but rather a thread ID or some other sort of ID known to the operating system. Others have argued with me on whether this is feasible; but since Ada doesn't equate accesses with addresses, it's at least conceivable, and might be a fine idea in some implementations, perhaps in limited cases. > What is the difference between integer_address and address? Please keep in mind that although most people are familiar with architectures where all of memory is considered to be one big block and addresses are just offsets into that block (a "linear address space"), it isn't always the case. One processor I work with heavily allows objects to be created outside that linear address space. A System.Address in that case cannot be a mere integer; for that processor, a System.Address is two words, where one is a descriptor that identifies an "object" (essentially an index into the processor's object table), and the other word is an offset into that object. Also, I think there are some processors in which code and data are in two separate address spaces, so that the same integer may refer to one chunk of memory if used in a "data" context, but a different chunk if used in a "code" context. In such a case, an implementor may not want System.Address to be a simple integer. Also, on systems such as these, there is no requirement that To_Integer to convert a System.Address to an Integer_Address will always succeed (it could raise an exception), and conversely there is no requirement that To_Address to convert an Integer_Address to a System.Address be capable of producing every possible address that an object could occupy. -- Adam