Re: question about functions

Re: question about functions

[David Starner]

On Thu, 20 Jan 2000 17:44:52 +0100, Pascal LEJEUNE <pascal.lejeune@matra-transport.fr> wrote:
>Hello,
>
>I would like to know if there is a "clean" (i.e. not compiler dependant)
>solution to this problem :

No. There's not even a decent compiler dependent version. This is not an
acceptable way to do whatever you were trying to do. What were you trying
to do?

>I explain :
>if C := f(A, B);
>
>how can i know, in f, C's addres ?
No. 

>function f(A, B : in T) return T is
>   ...
>begin
>   ...
>   address of the result of f ?
>   ...
>end f;

The result is usually copied to a return value before being
copied back. Probably by unchecked conversions between integers
and pointers and the right knowledge of the stack, you could
find the value. (This would be highly system and compiler
specific, and is not recommended.)

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

question about functions

[Pascal LEJEUNE]

Hello,

I would like to know if there is a "clean" (i.e. not compiler dependant)
solution to this problem :


- i have a function, for example : f(A, B : in T) return T
- how can i find the return address in f ?


I explain :
if C := f(A, B);

how can i know, in f, C's addres ?
function f(A, B : in T) return T is
   ...
begin
   ...
   address of the result of f ?
   ...
end f;


Thank you for your help



        Pascal LEJEUNE

Re: question about functions

[Stephen Leake]

"Pascal LEJEUNE" <pascal.lejeune@matra-transport.fr> writes:

> I explain :
> if C := f(A, B);
> 
> how can i know, in f, C's addres ?
> function f(A, B : in T) return T is
>    ...
> begin
>    ...
>    address of the result of f ?
>    ...
> end f;

You can't find the address of C from within f, in Ada, C, or any other
moderatly high level language. Only assembler lets you do that, as far
as I know.

If you could, what would you do with it? Maybe there is another way to
get the same effect.

One alternate approach that is possible in Ada is to pass the result
as an 'out' parameter :

procedure f (A, B : in T; C : out T);

now you can do C'Address.

I'd still like to know what you are going to do with it.

-- Stephe

Re: question about functions

[Tucker Taft]

Pascal LEJEUNE wrote:
> 
> Hello,
> 
> I would like to know if there is a "clean" (i.e. not compiler dependant)
> solution to this problem :
> 
> - i have a function, for example : f(A, B : in T) return T
> - how can i find the return address in f ?
> 
> I explain :
> if C := f(A, B);
> 
> how can i know, in f, C's addres ?
> function f(A, B : in T) return T is
>    ...
> begin
>    ...
>    address of the result of f ?
>    ...
> end f;
> 
> Thank you for your help

There is no way to know the address of the object being assigned the
result of the function call.  I don't know of any language that would 
provide this. Note that the function result might not be stored into a 
variable at all.

You need to change your function into a procedure with an OUT parameter,
then use 'Address on the OUT parameter, if knowing the address is
essential.

>         Pascal LEJEUNE

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: question about functions

[Hyman Rosen]

"Pascal LEJEUNE" <pascal.lejeune@matra-transport.fr> writes:
> I explain :
> if C := f(A, B);
> how can i know, in f, C's addres ?
> function f(A, B : in T) return T is
> begin
>    address of the result of f ?
> end f;

How bizarre! There is no way to do this, of course.

Re: question about functions

[tmoran]

function ADD (A, B : in T) return T is
   tmp : T;
begin
   -- call a procedure which use directly the hardware :
   proc (a'address, b'address, tmp'address);
   return tmp;
end ADD;

Re: question about functions

[Samuel T. Harris]

tmoran@bix.com wrote:
> 
> function ADD (A, B : in T) return T is
>    tmp : T;
> begin
>    -- call a procedure which use directly the hardware :
>    proc (a'address, b'address, tmp'address);
>    return tmp;
> end ADD;

The compiler may pass A and B in registers instead of
on the stack. In this case a'address and b'address
will cause runtime errors. VADS on SGI IRIX causes
a either a bus error or segmentation fault (I can't
remember now) for a similar subprogram we needed.

To get around this, you need temps for A and B, ala ...

function ADD (A, B : in T) return T is
  temp_a : t := a;
  temp_b : t := b;
  result : t;
begin
  proc (temp_a'address, temp_b'address, result'address);
  return result;
end;

In our case VADS was not smart enough to recognize that
the usage of the parameters includes a 'address attribution
which should preclude passing A and B in registers. Given
the other complex data flow analysis employed by the
compiler for other optimizations, this seems a reasonable
check.

Of course VADS is Ada 83. Perhaps the language laywers
in the news group can expound on any new Ada 95 rules
which eliminates this situation?

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

question about functions

[Pascal LEJEUNE]

Hello everybody,

Thank you for your replies !!!!
What I want to do, is to give my user the possibility of operators
to a type (for example C := A + B, C := A - B, C := A < B ...). This
type is not very complex (a record of 4 bytes).
Then, my operator is a rename of a function, for example :
function "+" (A, B : in T) return T renames ADD;

Finaly, my function ADD use a hardware component which do
the operation with the addresses (it's an asic which needs
to know on which variable the operation is done) :

function ADD (A, B : in T) return T is
   tmp : system.address;
begin
   << find the address of the result (that's my problem !!) >> and
   put it in a local variable (tmp)

   call a procedure which use directly the hardware :
   proc (a'address, b'address, tmp);
end ADD;

So, the problem is quite simple : the type T is a "numerical" type
on which it is normal to have operators ... but the hardware need
to have the address of the arguments and the address of the result !!!

I hope i'll find a "nice" solution (ie in Ada or C), but if it is
impossible,
i'll use ASM !


Thank you !!!


 Pascal LEJEUNE

Re: question about functions

[Stephen Leake]

"Samuel T. Harris" <samuel_t_harris@Raytheon.com> writes:

> tmoran@bix.com wrote:
> <snip> 
> The compiler may pass A and B in registers instead of
> on the stack. In this case a'address and b'address
> will cause runtime errors. VADS on SGI IRIX causes
> a either a bus error or segmentation fault (I can't
> remember now) for a similar subprogram we needed.
> 
> To get around this, you need temps for A and B, ala ...
> 
> function ADD (A, B : in T) return T is
>   temp_a : t := a;
>   temp_b : t := b;
>   result : t;
> begin
>   proc (temp_a'address, temp_b'address, result'address);
>   return result;
> end;
> 
> In our case VADS was not smart enough to recognize that
> the usage of the parameters includes a 'address attribution
> which should preclude passing A and B in registers. Given
> the other complex data flow analysis employed by the
> compiler for other optimizations, this seems a reasonable
> check.
> 
> Of course VADS is Ada 83. Perhaps the language laywers
> in the news group can expound on any new Ada 95 rules
> which eliminates this situation?

At a guess, adding 'aliased' should help. Or pragma Volatile.

-- Stephe

Re: question about functions

[Matthew Heaney]

In article <un1q01s1n.fsf@gsfc.nasa.gov> , Stephen Leake 
<Stephen.Leake@gsfc.nasa.gov>  wrote:

> One alternate approach that is possible in Ada is to pass the result
> as an 'out' parameter :
>
> procedure f (A, B : in T; C : out T);
>
> now you can do C'Address.

C'Address is only defined if T is a by-reference type.

See RM95 13.3 (16).


--
Science is, foremost, a method of interrogating reality: proposing
hypotheses that seem true and then testing them -- trying, almost
perversely, to negate them, elevating only the handful that survive to
the status of a theory. Creationism is a doctrine, whose adherents are
interested only in seeking out data that support it.

George Johnson, NY Times, 15 Aug 1999

Re: question about functions

[Matthew Heaney]

In article <3889A56C.61C4@nospam.com.tj> , Andy <andy@nospam.com.tj>  
wrote:

>> One alternate approach that is possible in Ada is to pass the result
>> as an 'out' parameter :
>>
>> procedure f (A, B : in T; C : out T);
>>
>> now you can do C'Address.
>>
> But this would give the address of the formal parameter which
> may not be the address of the actual parameter. Unless T is a
> tagged type, isn't the compiler free pass parameters by
> reference or value?

Certain types are guaranteed to be passed by reference.  By-reference
types include tagged types and limited types.  (Note that a limited type
doesn't have to be tagged to be passed by reference.)

Scalar types must be passed by value.

The language doesn't specify whether composite types (nonlimited records
arrays) are passed by reference or by value.

If you want to take the address (here, C'Address) of a subprogram
parameter, the parameter must be a by-reference type: either tagged or
limited.

See RM95 13.3 (16).

--
Philosophy may be ignored but not escaped; and those who most ignore
least escape.

David Hawkins

Re: question about functions

[Andy]

Stephen Leake wrote:
> 
> "Pascal LEJEUNE" <pascal.lejeune@matra-transport.fr> writes:
> 
[snipped]
> One alternate approach that is possible in Ada is to pass the result
> as an 'out' parameter :
> 
> procedure f (A, B : in T; C : out T);
> 
> now you can do C'Address.
> 
But this would give the address of the formal parameter which
may not be the address of the actual parameter. Unless T is a
tagged type, isn't the compiler free pass parameters by 
reference or value?
 
Andy

Re: question about functions

[Mats Weber]

Matthew Heaney wrote:

> > procedure f (A, B : in T; C : out T);
> >
> > now you can do C'Address.
> 
> C'Address is only defined if T is a by-reference type.
> 
> See RM95 13.3 (16).

Not true. I think you are misinterpreting that paragraph. C'Address will
return the address of the actual parameter if T is by reference, and the
address of the formal if T is by copy.

Re: question about functions

[Stephen Leake]

Andy <andy@nospam.com.tj> writes:

> Stephen Leake wrote:
> > 
> > "Pascal LEJEUNE" <pascal.lejeune@matra-transport.fr> writes:
> > 
> [snipped]
> > One alternate approach that is possible in Ada is to pass the result
> > as an 'out' parameter :
> > 
> > procedure f (A, B : in T; C : out T);
> > 
> > now you can do C'Address.
> > 
> But this would give the address of the formal parameter which
> may not be the address of the actual parameter. Unless T is a
> tagged type, isn't the compiler free pass parameters by 
> reference or value?

It depends on why you are taking the address. In another post, you
said you wanted to call a function implemented in assembly/hardware:

    Fast_Thing (A'address, B'address, C'address);

If C is passed by copy, any changes 'Fast_Thing' makes to C will be
copied back out to the "real" C when procedure 'f' returns. If C is
passed by reference, 'Fast_Thing' operates directly on the "real" C.
Either way, everyone is happy. The point is the compiler knows better
than you whether copy or reference is better, and you don't have to
care.

On the other hand, if Fast_Thing needs to keep a copy of C'address for
later use, then you have a problem. In that case, you should pass the
address to 'f', not the object:

procedure f (A, B : in T; C : access T);

Use System.Address_To_Access_Conversions to reliably convert C to
System.Address, independent of which compiler you are using.

-- Stephe

Re: question about functions

[Stephen Leake]

"Matthew Heaney" <matthew_heaney@acm.org> writes:

> In article <un1q01s1n.fsf@gsfc.nasa.gov> , Stephen Leake 
> <Stephen.Leake@gsfc.nasa.gov>  wrote:
> 
> > One alternate approach that is possible in Ada is to pass the result
> > as an 'out' parameter :
> >
> > procedure f (A, B : in T; C : out T);
> >
> > now you can do C'Address.
> 
> C'Address is only defined if T is a by-reference type.
> 
> See RM95 13.3 (16).

13.3 (16) is implementation advice; it suggests that X'Address be
   useful in certain situations, including by-reference types.

X'Address is _defined_ in 13.3 (11), which says nothing about where it
may be useful. Hmm, I'm not clear if a subprogram parameter is an
"object" here, but I believe it is.

In any case, I have often successfully used 'Address on subprogram
parameters that are not of a by-reference type, with both ObjectAda
and GNAT, so at least some compilers go beyond the implementation advice.

-- Stephe

Re: question about functions

[Matthew Heaney]

In article <uwvozl2hp.fsf@gsfc.nasa.gov> , Stephen Leake 
<Stephen.Leake@gsfc.nasa.gov>  wrote:

> In any case, I have often successfully used 'Address on subprogram
> parameters that are not of a by-reference type, with both ObjectAda
> and GNAT, so at least some compilers go beyond the implementation advice.

Of course it *may* work, but you are depending on an implementation
specific feature, namely the parameter passing mechanism used for
composite types.

Even within one compiler, an array may be passed by value if it's
"small" enough.

Re: question about functions

[Stephen Leake]

"Matthew Heaney" <matthew_heaney@acm.org> writes:

> In article <uwvozl2hp.fsf@gsfc.nasa.gov> , Stephen Leake 
> <Stephen.Leake@gsfc.nasa.gov>  wrote:
> 
> > In any case, I have often successfully used 'Address on subprogram
> > parameters that are not of a by-reference type, with both ObjectAda
> > and GNAT, so at least some compilers go beyond the implementation advice.
> 
> Of course it *may* work, but you are depending on an implementation
> specific feature, namely the parameter passing mechanism used for
> composite types.
> 
> Even within one compiler, an array may be passed by value if it's
> "small" enough.

This is getting confusing, but I think it's important, so let me try
to be clear. Suppose I have a procedure that does matrix multiply,
written in assembly. It takes the address of the operands and result
as parameters:

procedure Assem_Mat_Mul (A, B, C : in System.Address);
-- C = A x B, all 3 x 3 matrices

Now I want to wrap that in a properly typed Ada procedure:

type Matrix is array (1 .. 3, 1 .. 3) of Float;

procedure Ada_Mat_Mul (A, B : in Matrix; C : out Matrix)
is begin
  Assem_Mat_Mul (A'Address, B'Address, C'Address);
end Ada_Mat_Mul;

I claim Ada_Mat_Mul is independent of the parameter passing mechanism
used for C. 

If C is passed by copy, 'Address will give the address of the copy,
Assem_Mat_Mul will write the result there, and the result will be
copied out when Ada_Mat_Mul returns.

If C is passed by reference, 'Address will give the address of the
actual parameter, Assem_Mat_Mul will write the result there.

On the other hand, if the compiler vendor chooses to _only_ provide the
support for 'Address required by 13.3 (16), then C'Address is invalid,
whether C is passed by copy or reference. This is because C is neither
aliased nor of a by-reference type.

So you can say Ada_Mat_Mul is not "very" portable, because it relies
on vendors going beyond the implementation advice in 13.3 (16). But it
does _not_ depend on the parameter passing mechanism.

-- Stephe