Re: put of access type

[Adam Beneschan <adam@irvine.com>]

On Aug 19, 12:00 pm, Rob Solomon <use...@drrob1-noreply.com> wrote:

> I am trying to understand this.  
>
> 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.  They  differ 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.  But I don't
> understand how.  ie, 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