Does object renaming allow the view to be a copy?

Does object renaming allow the view to be a copy?

[G.B.]

A SO answer (41746244) has given rise to the question of whether
or not a compiler implementer may make a renamed object a copy
of the original. (Layman's assumptions from LRM 3.1(7), 8.5.1),

So, is the following program, modifying compoments of and array,
ever allowed to raise Renaming_Is_Copying?

with System;
procedure Renaming is

     Renaming_Is_Copying : exception;

     type R is record
         A, B : Integer;
     end record;

     type List is array (Natural range <>) of R;
     Stuff : List := (10 .. 20 => R'(A => 2, B => 3));
begin
     for K in Stuff'Range loop
         declare
             --
             --  Does Ada allow a compiler to make X be a copy?
             --
             X : R renames Stuff (K);
             use type System.Address;
         begin
             if X'Address = Stuff (K)'Address then
                 X.A := X.B;
             else
                 raise Renaming_Is_Copying;
             end if;
         end;
     end loop;
end Renaming;

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: Does object renaming allow the view to be a copy?

[Simon Wright]

"G.B." <bauhaus@notmyhomepage.invalid> writes:

> So, is the following program, modifying compoments of and array,
> ever allowed to raise Renaming_Is_Copying?

>     Renaming_Is_Copying : exception;
>
>     type R is record
>         A, B : Integer;
>     end record;
>
>     type List is array (Natural range <>) of R;

and would it make a difference if an R was small enough to fit into a
register?

Re: Does object renaming allow the view to be a copy?

[AdaMagica]

Am Sonntag, 22. Januar 2017 09:27:47 UTC+1 schrieb G.B.:
> A SO answer (41746244) has given rise to the question of whether
> or not a compiler implementer may make a renamed object a copy
> of the original. (Layman's assumptions from LRM 3.1(7), 8.5.1),

3.1(7) ...a renaming_declaration is an example of a declaration that does not define a new entity, but instead defines a view of an existing entity (see 8.5)...

So how can you think a compiler may create a copy?

8.5(3) The elaboration of a renaming_declaration evaluates the name that follows the reserved word renames and thereby determines the view and entity denoted by this name (the renamed view and renamed entity).
[A name that denotes the renaming_declaration denotes (a new view of) the renamed entity.]

Same here. You get a new view of the entity.

BTW: A renaming is not a macro. Thus the following fragment does not change X:

X: T renames Y (I);

I := I + 1;

Re: Does object renaming allow the view to be a copy?

[Simon Wright]

AdaMagica <christ-usch.grein@t-online.de> writes:

> Am Sonntag, 22. Januar 2017 09:27:47 UTC+1 schrieb G.B.:
>> A SO answer (41746244) has given rise to the question of whether
>> or not a compiler implementer may make a renamed object a copy
>> of the original. (Layman's assumptions from LRM 3.1(7), 8.5.1),

I did suggest that it would have to be a crazy implementer who did this.

> 3.1(7) ...a renaming_declaration is an example of a declaration that
> does not define a new entity, but instead defines a view of an
> existing entity (see 8.5)...
>
> So how can you think a compiler may create a copy?

I think that if the object isn't limited and the operations done on it
don't alter its contents you'd be hard put to it to tell the difference,
that's all.

But like I said, crazy. Under the hood, any sensible person would have a
reference to the original object.

Re: Does object renaming allow the view to be a copy?

[Dmitry A. Kazakov]

On 2017-01-22 18:37, Simon Wright wrote:
> AdaMagica <christ-usch.grein@t-online.de> writes:
>
>> Am Sonntag, 22. Januar 2017 09:27:47 UTC+1 schrieb G.B.:
>>> A SO answer (41746244) has given rise to the question of whether
>>> or not a compiler implementer may make a renamed object a copy
>>> of the original. (Layman's assumptions from LRM 3.1(7), 8.5.1),
>
> I did suggest that it would have to be a crazy implementer who did this.
>
>> 3.1(7) ...a renaming_declaration is an example of a declaration that
>> does not define a new entity, but instead defines a view of an
>> existing entity (see 8.5)...
>>
>> So how can you think a compiler may create a copy?
>
> I think that if the object isn't limited and the operations done on it
> don't alter its contents you'd be hard put to it to tell the difference,
> that's all.
>
> But like I said, crazy. Under the hood, any sensible person would have a
> reference to the original object.

Some packed Boolean, not at the storage element margin?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Does object renaming allow the view to be a copy?

[AdaMagica]

Am Sonntag, 22. Januar 2017 21:24:12 UTC+1 schrieb Dmitry A. Kazakov:
> On 2017-01-22 18:37, Simon Wright wrote:
...
> > But like I said, crazy. Under the hood, any sensible person would have a
> > reference to the original object.
> 
> Some packed Boolean, not at the storage element margin?

Of course not in cases like that:

type Set is array (Index) of Boolean with Packed;
My_Set: Set;

My_Element_Presence: Boolean renames My_Set (I);

My_Set (I) := not My_Set (I);
My_Element_Presence := not My_Element_Presence;

Under the hood, the same packing and unpacking has to be performed. A simple reference is impossible in this case.

Re: Does object renaming allow the view to be a copy?

[Dmitry A. Kazakov]

On 23/01/2017 11:49, AdaMagica wrote:
> Am Sonntag, 22. Januar 2017 21:24:12 UTC+1 schrieb Dmitry A. Kazakov:
>> On 2017-01-22 18:37, Simon Wright wrote:
> ...
>>> But like I said, crazy. Under the hood, any sensible person would have a
>>> reference to the original object.
>>
>> Some packed Boolean, not at the storage element margin?
>
> Of course not in cases like that:
>
> type Set is array (Index) of Boolean with Packed;
> My_Set: Set;
>
> My_Element_Presence: Boolean renames My_Set (I);
>
> My_Set (I) := not My_Set (I);
> My_Element_Presence := not My_Element_Presence;
>
> Under the hood, the same packing and unpacking has to be performed. A
> simple reference is impossible in this case.

Yes, renaming/viewing is richer than mere referencing. It is similar to 
parameter passing when the compiler is free to use any method.

(IMO being conceptually same as parameter passing, renaming must support 
array index sliding and other translations of the constraints as 
requested by the declared view).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Does object renaming allow the view to be a copy?

[Randy Brukardt]

"G.B." <bauhaus@notmyhomepage.invalid> wrote in message 
news:o61qau$ock$1@dont-email.me...
>A SO answer (41746244) has given rise to the question of whether
> or not a compiler implementer may make a renamed object a copy
> of the original. (Layman's assumptions from LRM 3.1(7), 8.5.1),

Logically, the item is not a copy. How the compiler implements that, 
however, is its business.

> So, is the following program, modifying compoments of and array,
> ever allowed to raise Renaming_Is_Copying?

Of course. The program has nothing to do with copying that I can see.

...
>         begin
>             if X'Address = Stuff (K)'Address then

The meaning of X'Address is implementation-defined (as someone said, 
consider what happens if X is allocated in a register). It's best if its use 
is limited to the sort of low-level purposes for which it was defined (that 
is, handling memory-mapped hardware). Note in particular 13.3(16): if the 
objects in question aren't "aliased", the result of 'Address may not be 
"useful".

If the objects are aliased, then you don't need to use 'Address to get the 
answer to your question:

             if X'Access = Stuff (K)'Access then

would answer your question (but you might need to declare an appropriate 
access type somewhere). Note that the compiler would strip off any funny 
business for this latter case.

IMHO, 'Address should only appear in a program that is interfacing to some 
memory-mapped entity; else use some form of 'Access (or 'Unchecked_Access).

                                     Randy.

Re: Does object renaming allow the view to be a copy?

[Robert Eachus]

On Monday, January 23, 2017 at 3:40:10 PM UTC-5, Randy Brukardt wrote:
 
> IMHO, 'Address should only appear in a program that is interfacing to some 
> memory-mapped entity; else use some form of 'Access (or 'Unchecked_Access).

Hmm.  My code has cases of:
      for X'Address use at mod 4;

I've also broken abstractions by using 'Address to obtain access to the details
of an otherwise private type--those are old, and can be updated to use child packages.

I also seem to recall that a lot of the NUMWG work uses address clauses when pulling floating point numbers apart--and putting them back together.

and I also have some mixed Fortran and Ada that uses at Foo'Address + 24 or the like to deal with Fortran common blocks that are really overlays. (For example, one declaration has the common block as an array, another converts it to a vector.)

Are all of these deprecated now?

 

Re: Does object renaming allow the view to be a copy?

[Randy Brukardt]

"Robert Eachus" <rieachus@comcast.net> wrote in message 
news:1554966b-2882-4f1f-8cc8-be5a03e44ad0@googlegroups.com...
> On Monday, January 23, 2017 at 3:40:10 PM UTC-5, Randy Brukardt wrote:
>
>> IMHO, 'Address should only appear in a program that is interfacing to 
>> some
>> memory-mapped entity; else use some form of 'Access (or 
>> 'Unchecked_Access).
>
> Hmm.  My code has cases of:
>      for X'Address use at mod 4;

Looks like you are trying to set Alignment which Ada 83 didn't have. Set 
alignment directly, so your reader knows what you're doing.

> I've also broken abstractions by using 'Address to obtain access to the 
> details
> of an otherwise private type--those are old, and can be updated to use 
> child packages.

Correct.

> I also seem to recall that a lot of the NUMWG work uses address clauses 
> when pulling
> floating point numbers apart--and putting them back together.

Ada 95 says that Unchecked_Conversion can be by-reference, so the 
performance reason for not using UC in this case doesn't exist (assuming a 
friendly implementer). UC also doesn't force a compiler to abandon many 
useful optimizations (or do horrible analysis before allowing it).

> and I also have some mixed Fortran and Ada that uses at Foo'Address + 24 
> or the like to deal with
> Fortran common blocks that are really overlays. (For example, one 
> declaration has the common block
>                     as an array, another converts it to a vector.)

This falls under "interfacing to some memory-mapped entity"; I purposely 
didn't say "hardware" because sometimes software needs it too.

> Are all of these deprecated now?

All but the last can be done better with other constructs, IMHO. For the 
last, it's case-by-case what the best approach would be: you might need 
'Address.

                       Randy.