Home > Archive > Fortran > November 2004 > equivalence with dummy arguments
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
equivalence with dummy arguments
|
|
| Ryo Furue 2004-11-13, 9:18 am |
| Hello all,
Equivalence with dummy arguments is illegal. But what were plausible
reasons for making it illegal in Fortran 77? This is just historical
curiosity.
I can think of an argument against equivalence with dummies in
Fortran 90:
module mod !! Assume kind values represent sizes in byte.
contains
subroutine sub(a)
real(8) :: a(:) !-- If a's memory isn't contiguous...
integer(4):: b(2*size(a))
equivalence (a,b) !-- then b's memory will be non-uniform.
!! a(1), <garbage>, a(2), ...
!! b(1),b(2), <gargage>, b(3),b(4), ...
......
program main
use mod
real(8):: a(100,200)
call sub(a(30,:)) !-- non-contiguous array
! (Assume no copy is made.)
I could imagine that if this equivalence is allowed, it would be
messy to implement. But, I can't think of any such example
in Fortran 77.
Regards,
Ryo
| |
| Ken Plotkin 2004-11-13, 3:58 pm |
| On 13 Nov 2004 02:16:01 -0800, furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue)
wrote:
>Equivalence with dummy arguments is illegal. But what were plausible
>reasons for making it illegal in Fortran 77? This is just historical
>curiosity.
Equivalence specifies the storage order/overlap of specific variables.
You don't get to personally pick out the physical memory location, but
once the compiler picks a spot for one of the variables, the other is
assigned its position at (or relative to) that. I cannot think of any
possible way for that to be meaningful with dummy arguments:
equivalence is a deterministic command among specific variables.
>I can think of an argument against equivalence with dummies in
>Fortran 90:
[snip]
The same argument applies in F77. You would be specifying that two
unspecified entities occupy the same physical memory.
Ken Plotkin
| |
| Ryo Furue 2004-11-14, 3:55 am |
| Hi,
Thanks for the response. I read your answer serveral
times, but I'm afraid I don't understand. I feel dumb.
I think I'm missing something. Could you give me an example
of what could be wrong with equivalence with dummies?
Or, for example, could you explain what possiblly goes
wrong in the following?
! code (1)
subroutine sub(a)
real*8 a
integer*4 b(2)
equivalence (a,b)
a = 3.14d0 !-> Compiler emits code to store the
! 8-byte value 3.14d0 to the location
! named a.
b(1) = 123 !-> Compiler emits code to store the
! 4-byte value 123 to the first half
! of the same location as a.
end
The compiler can emit machine code to store the value
3.14d0 to the location named a. Why cannot the compiler
emit the code to store the value 123 into the same location?
As you say, the location itself is determined at runtime.
But I don't see how that prevents using the same location
with different names (sometimes "a" and sometimes b(1)).
My example in the previous post shows a case where you can
use the same location with different names but that would
require siginficant extra efforts on the compiler's part.
On the other hand, I don't think code (1) requires any extra
efforts, because the compiler already has to allow the
following:
! code (2)
program main
real*8 a
integer*4 b(2)
equivalence (a,b)
a = 3.14d0
b(1) = 123
end
Ken Plotkin <kplotkin@nospam-cox.net> wrote in message news:<m5ccp0lf56g4lre91mf3f4a71v2g7f6fpc@4ax.com>...
[...]
> [snip]
>
> The same argument applies in F77. [...]
I don't think the "same" argument applies to F77. At least *my*
argument against equivalence with F90 is different from yours,
which I don't understand.
> You would be specifying that two
> unspecified entities occupy the same physical memory.
Why is that difficult?
Regards,
Ryo
| |
| Jim Giles 2004-11-14, 3:56 pm |
| furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue) wrote in message news:<e10cccdf.0411130216.6e708ddf@posting.google.com>...
> Hello all,
>
> Equivalence with dummy arguments is illegal. But what were plausible
> reasons for making it illegal in Fortran 77? This is just historical
> curiosity.
Consider:
subroutine xyz(p,q)
real p(*), q(*), temp(6)
equivalence (p(1),temp(1)), (q(1),temp(3))
...
This claims that P and Q are stored two storage units
apart. How can the compiler guarantee this (unless it
mandates copy-in/copy-out as the parameter passing
mechanism)?
Now consider:
program main
real t(5)
...
call xyz(t(3), t(1))
Now, the TEMP variable in XYZ is associated with array T
in some skew order? That is, TEMP(1) and TEMP(2) are
associated with T(3) and T(4)? While TEMP(4) and TEMP(5)
are associated with T(2) and T(3)? And TEMP(3) is either
associated with T(5) or T(1), but which? Or, what meaning
do you assume?
No doubt you could restrict the use of EQUIVALENCE to
avoid problems of this sort and still allow it to be
used with dummy arguments, but why? I can't think of
a legal purpose. Type cheating through EQUIVALENCE
is non-standard and reshaping an array argument can
already be done through sequence association.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Ken Plotkin 2004-11-14, 3:56 pm |
| On 13 Nov 2004 22:51:05 -0800, furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue)
wrote:
[snip]
> subroutine sub(a)
> real*8 a
> integer*4 b(2)
> equivalence (a,b)
[snip]
>The compiler can emit machine code to store the value
>3.14d0 to the location named a. Why cannot the compiler
>emit the code to store the value 123 into the same location?
[snip]
It can't. a does not exist in the subroutine, so the routine cannot
equivalence anything to it - the subroutine wouldn't have a clue as to
where to find it.
At run time, a is supplied to the subroutine by the calling program.
It exists in the calling program. b only exists in the subroutine, so
it cannot be equivalenced to something outside of the subroutine's
turf.
You should look up how variables are passed to subroutines,
particularly when (as in most cases) they're passed by reference.
Are you trying to do something specific, or are you just poking around
the edges? If it's just poking around the edges, this isn't a good
edge to poke around. Equivalence is generally denigrated these days.
Most (maybe even all) of the reasons for its existence are obsolete.
If you're trying to figure out somehting you need to do, describe it
and someone here should be able to point you in the right direction.
Ken Plotkin
| |
|
| Ken Plotkin wrote:
>
> edge to poke around. Equivalence is generally denigrated these days.
> Most (maybe even all) of the reasons for its existence are obsolete.
I suspect Neanderthals wouldn't know what to do with a wheel either -
likewise for the bozos who never saw equivalence. The *ugliness* of the
equivalence less world,
drag = .5*cd*s*rho(x(2))*x(4)**2
drag = .5*cd*s*rho(h)*v**2
is there for denigrators to enjoy, but they should quit advocating their
myopic views on the rest of the world.
| |
| Ryo Furue 2004-11-15, 3:57 am |
| Ken Plotkin <kplotkin@nospam-cox.net> wrote in message news:<o98fp0hkufp9u5ugoqq0l3vpg2ep03mhsa@4ax.com>...
> On 13 Nov 2004 22:51:05 -0800, furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue)
> wrote:
>
> [snip]
> [snip]
> [snip]
>
> It can't. a does not exist in the subroutine, so the routine cannot
> equivalence anything to it - the subroutine wouldn't have a clue as to
> where to find it.
>
> At run time, a is supplied to the subroutine by the calling program.
> It exists in the calling program. b only exists in the subroutine, so
> it cannot be equivalenced to something outside of the subroutine's
> turf.
I now see what you mean! Thanks for the explanation. But in the examble
above, why does b need to exist in the subroutine? The whole memory range
of b could coinside with that of a and reside outside the subroutine.
That is, the above program could be internally implemented as
!! Pseudo-code (Not Fortran 77. Nor Fortran 90).
subroutine sub(a)
real*8, target :: a
integer*4, pointer:: b(2)
b => a
a = 3.14d0 !! stores the value into the memory of a.
b(1) = 123 !! stores the value into the same memory.
The memory of a resides outside the subroutine. We merely
introduce another name, b, for the same memory location.
But, the example James Giles gives is convincing.
This is mainly a historical curiosity, as I said at the
top of my original posting. I was curious as to why equivalence
with dummies wasn't allowed. There are instances that such a
feature can be convenient, though.
Regards,
Ryo
| |
| Ken Plotkin 2004-11-15, 3:57 am |
| On Mon, 15 Nov 2004 00:05:52 GMT, kia <kia@sparrow.com> wrote:
>I suspect Neanderthals wouldn't know what to do with a wheel either -
>likewise for the bozos who never saw equivalence. The *ugliness* of the
>equivalence less world,
That would depend on the particular neanderthal. But I'm not sure
what any of us today would do with a stone axe - or the knowledge of
how to make one.
> drag = .5*cd*s*rho(x(2))*x(4)**2
> drag = .5*cd*s*rho(h)*v**2
Cute. I think I may have done something like that once or twice, but
tended to lose track when the same entity had two different names.
I've used equivalence mostly for two things: to overlay different data
types for bit twiddling, and to allow array indices to begin at less
than 1 back in the days when they began only at 1.
>is there for denigrators to enjoy, but they should quit advocating their
>myopic views on the rest of the world.
You mean you're not going to embrace the F subset and use only the new
sanctioned features? :-)
Ken Plotkin
| |
| Ken Plotkin 2004-11-15, 3:57 am |
| On 14 Nov 2004 18:10:08 -0800, furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue)
wrote:
[snip]
> integer*4, pointer:: b(2)
[snip]
IMHO, pointers are a dangerous thing to have in Fortran. They're OK
for real programmers, but not for the scientists and engineers (like
me) who use Fortran so they don't have to learn how to program.
>The memory of a resides outside the subroutine. We merely
>introduce another name, b, for the same memory location.
[snip]
But you're spoiling the benefit of having a subroutine: giving a local
variable scope outside of where it needs to be, losing the information
hiding, etc.
Ken Plotkin
| |
| Ryo Furue 2004-11-15, 3:57 am |
| jamesgiles@att.net (Jim Giles) wrote in message news:<a4cd1bc4.0411140712.38845e8@posting.google.com>...
> furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue) wrote in message news:<e10cccdf.0411130216.6e708ddf@posting.google.com>...
[...]
>
> Consider:
>
> subroutine xyz(p,q)
> real p(*), q(*), temp(6)
> equivalence (p(1),temp(1)), (q(1),temp(3))
> ...
[...]
Thank you for the clear example! That's convincing.
> No doubt you could restrict the use of EQUIVALENCE to
> avoid problems of this sort and still allow it to be
> used with dummy arguments, but why? I can't think of
> a legal purpose. Type cheating through EQUIVALENCE
> is non-standard and reshaping an array argument can
> already be done through sequence association.
Yes, I was thinking of more restricted use of equivalence.
You *could* restrict equivalence so that the "aliases"
won't place restrictions on the memory layout of the
actual arguments.
Once I wanted this feature in this kind of situation:
!!-- Crude pseudo-code. Not Fortran.
!!
subroutine sub(a)
real(8), target :: a(:)
complex(16), pointer :: c(size(a)/2) !! a's Fourier coefficients
c => a !! c is an alias for a.
!== We're in the physical space ==
!... Use a ...
!== Complex Fourier transform: Result is stored in a. ==
call fourier_trans(a)
!== Now, we're in the Fourier space ==
!... Use c ...
!== Let's go back to the physical space ==
call inverse_fourier_trans(a)
!== We're back in the physical space ==
!... Use a ...
end subroutine sub
I needed to treat the same array sometimes as a 2N-elemment
real array and sometimes as an N-element complex array.
The natural logic of the proram required that the caller of
sub not need to know the existence of Fourier transforms in it.
Also, the FFT routines I used stored the result of transform
into the same input array.
I thought the strategy shown above in the form of pseudo-code
was most natural. But, of course, since this wasn't (and isn't)
allowed in Fortran, and since memory wan't tight for my application,
I ended up in writing wrappers for the FFT routines, something along
the lines of
subroutine my_ft(c,a)
complex(16), :: c(:) !! size N
real(8), :: a(:)
call fourier_trans(a)
do i = 1, N
c(i) = dcmplx(a(i*2-1), a(i*2))
end do
end subroutine my_ft
and used it like this
subroutine sub(a)
real(8) :: a(:)
complex(16):: c(size(a)/2)
!== We're in the physical space ==
!... Use a ...
!== Complex Fourier transform.
call my_ft(c,a)
!== Now, we're in the Fourier space ==
!... Use c ...
etc.
This solution is in fact cleaner. But it uses more memory
and it requires extra copying. So, if memory had been tight
or if I had wanted to avoid copying, I would have had to create
extra subroutines to cheat on types on the boundaries of calling
subroutine sub(a)
real(8) a(:)
...use a...
call fourier_trans(a)
call use_c(a) !!<- cheating on type
call inverse_fourier_trans(a)
...use a...
end
subroutine use_c(c)
complex(16) c(*)
...use c...
end
I'd rather have the cheating more visible (equivalence is a more
visible form of cheating in this case).
Anyway, once again, this question is mainly from curiosity
about history. I'm not saying that equivalence with dummies
should be allowed.
Thanks again,
Ryo
| |
| glen herrmannsfeldt 2004-11-15, 8:56 am |
| Ryo Furue wrote:
> jamesgiles@att.net (Jim Giles) wrote in message news:<a4cd1bc4.0411140712.38845e8@posting.google.com>...
[color=darkred]
The uses would be much more restricted, and most can be done
with a workaround.
[color=darkred]
[color=darkred]
> Thank you for the clear example! That's convincing.
A fine example, but consider that the restrictions on
the use of COMMON and EQUIVALENCE aren't much different
from such a restriction. You can't, for example,
EQUIVALENCE two variables in two different COMMON blocks
for pretty much the same reason. Yet equivalencing
to variables in COMMON is legal and many legal ones
can be confusing. EQUIVALENCE between an array and
a variable or array in COMMON can easily also EQUIVALENCE
to other variables in the same COMMON, even if it was
not intended.
I would have to check, but I believe that type cheating
between REAL and COMPLEX is legal and well defined.
That also could be useful when applied to dummy arguments.
[color=darkred]
> Yes, I was thinking of more restricted use of equivalence.
> You *could* restrict equivalence so that the "aliases"
> won't place restrictions on the memory layout of the
> actual arguments.
Do remember that this restriction came when machines with
32K memory were common, and squeezing a Fortran compiler
into such memory wasn't easy.
> Once I wanted this feature in this kind of situation:
(snip)
> I needed to treat the same array sometimes as a 2N-elemment
> real array and sometimes as an N-element complex array.
> The natural logic of the proram required that the caller of
> sub not need to know the existence of Fourier transforms in it.
> Also, the FFT routines I used stored the result of transform
> into the same input array.
> I thought the strategy shown above in the form of pseudo-code
> was most natural. But, of course, since this wasn't (and isn't)
> allowed in Fortran, and since memory wan't tight for my application,
> I ended up in writing wrappers for the FFT routines, something along
> the lines of
The REAL and IMAG functions for extracting the parts of a
COMPLEX variable are hopefully expanded inline and optimized
to an access of the appropriate part. Fortran, though, doesn't
have the PL/I pseudo-variable to assign into part of a complex
variable. That is one case I can see where there would be a
significant advantage to such equivalence.
(Note: for comparison purposes only.)
In PL/I one can work with part of a complex number, such as:
REAL(C(I))=2*REAL(C(I))+3;
which should compile directly to modifying the real part of
the complex number. In Fortran, one might try:
C(I)=CMPLX(2*REAL(C(I))+3,IMAG(C(I))
where one might expect the compiled code to load and store the
imaginary part, and it is, to me, less readable. Then PL/I also
lets to do something like:
DO IMAG(C(I))=1 TO 100;
using the imaginary part of a complex variable as a DO variable.
(Note that PL/I does allow integer complex variables, but
DO loops on floating point variables are allowed.)
It would seem that there are some uses of EQUIVALENCE that could
be done on dummy variables, but they are disallowed anyway.
I believe it is a reasonable restriction for the time.
-- glen
| |
| Joost VandeVondele 2004-11-15, 8:56 am |
| > No doubt you could restrict the use of EQUIVALENCE to
> avoid problems of this sort and still allow it to be
> used with dummy arguments, but why? I can't think of
> a legal purpose. Type cheating through EQUIVALENCE
> is non-standard and reshaping an array argument can
> already be done through sequence association.
I've also once tried to equivalence a dummy argument, and I still have
no nice solution for what I want to do, so I would be happy to hear
suggestions.
The issue is an interface to some legacy code (f77), that is
performance critical, and where memory is an issue. We would like to
wrap it in a module. The point is that in the calling routine 'data'
is a complex array, whereas in the subroutine it is a real array (both
too hard-wired to change). Schematically it looks like:
program main
integer, parameter :: sp=KIND(0.0)
TYPE datatype
complex(kind=sp), DIMENSION(:), POINTER :: cc
! would like allocatable, but we require plain f95
END TYPE
integer, parameter :: N=90000000
TYPE(datatype) :: data
ALLOCATE(data%cc(N))
![...]
CALL dosomething(data%cc,N)
end program
SUBROUTINE dosomething(r,N)
REAL :: r(2,N)
![...]
END SUBROUTINE
I know that's illegal in f77 as well, but in practice it is giving
excellent performance on many different architectures/compilers (we
use compiler flags like -mismatch_all as required). It would be nice
to get the code standard conforming without performance impact, and
something like
SUBROUTINE dosomething_new(c,N)
COMPLEX :: c(N)
REAL :: r(2,N)
EQUIVALENCE(c(1),r(1,1))
! [...]
END SUBROUTINE
would certainly be 'intuitive'. Any alternatives welcome ...
TIA,
Joost
| |
| Richard E Maine 2004-11-15, 3:59 pm |
| furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue) writes:
> Equivalence with dummy arguments is illegal. But what were plausible
> reasons for making it illegal in Fortran 77? This is just historical
> curiosity.
It is sometimes hard enough to say what the reasons were for a
decision made when I was in the room. Heck, it is sometimes hard
for me to remember what my own reasons were for some particular
vote. :-( You are asking for reasons for decisions made over
4 decades ago, perhaps as much as 5. After all, odds are that
f77 did it that way because f66 had, which in turn... I haven't
bothered to trace back all the way, but it probably goes a bit.
So keep in mind that this is *PURE* speculation (which probably
implies something about side effects, but I'm not sure what. :-))
You aren't going to find anyone around here who actually knows.
Note that *ALL* valid forms of equivalence are completely static
and relate to do with compile-time layout of memory. I'm not
saying that this is the only way that equivalence could be done.
Nor am I arguing that other things wouldn't have been useful.
I am just asking you to consider that this is the way that
equivalence was done. Think about that in the context of the time.
What do you think that the main purpose of equivalence was?
From what I see, which is consistent with 3rd and 4th hand tales,
equivalence was mostly to save memory by using the same memory for
different variables where practical. If you didn't program in those
days, you probably have a hard time envisioning how important memory
use was. Equivalence of dummy arguments wouldn't have much to do
with compile-time memory layout to save memory.
Note that equivalence for type-cheating has never been standard
(ok, real/complex is a special case, which I'd have to look up to
be absolutely sure of in detail). Thus it seems unlikely that it
was a major motivator. Note again that I'm saying absolutely nothing
about whether it should have been done or might have been useful.
I am trying to deduce what the motivations might have been, not
debate anything about what should have been done.
I make no claim about what the reasons were, but I think that the above
might offer some insight into a plausible relevant mindset.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Michael Metcalf 2004-11-15, 3:59 pm |
|
> From what I see, which is consistent with 3rd and 4th hand tales,
> equivalence was mostly to save memory by using the same memory for
> different variables where practical. If you didn't program in those
> days, you probably have a hard time envisioning how important memory
> use was.
Richard, to get this first hand, it is sufficient to read Jean Sammet's book
(1968?), where EQUIVALENCE is noted as a major advantage of the (then)
Fortran language, just for this reason.
Regards,
Mike
| |
| Jim Giles 2004-11-15, 3:59 pm |
| I wrote:
glen herrmannsfeldt answered:
[color=darkred]
> I would have to check, but I believe that type cheating
> between REAL and COMPLEX is legal and well defined.
> That also could be useful when applied to dummy arguments.
I believe that sequence association can also do this though.
As can explicit use of TRANSFER these days.
Ryo Furue wrote:
glen herrmannsfeldt answered:
[color=darkred]
> The REAL and IMAG functions for extracting the parts of a
> COMPLEX variable are hopefully expanded inline and optimized
> to an access of the appropriate part. Fortran, though, doesn't
> have the PL/I pseudo-variable to assign into part of a complex
> variable. That is one case I can see where there would be a
> significant advantage to such equivalence.
That's why I proposed a set of extensions to the COMPLEX
data type for the next (F200x?, F201x?) standard. These
were to rationalize the treatement of COMPLEX and make it
more consistent with derived types.
> In PL/I one can work with part of a complex number, such as:
>
> REAL(C(I))=2*REAL(C(I))+3;
And, under my proposed extensions:
C(I)%R = 2* C(I)%R + 3
I find this last more legible. And, it doesn't add yet
another concept (pseudo-variables) to complicate the
language. It makes full use of the understanding users
already have of existing features of the language.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Jim Giles 2004-11-15, 3:59 pm |
| jv244@cam.ac.uk (Joost VandeVondele) wrote in message news:<54661aa9.0411150213.4f4e6f5@posting.google.com>...
> complex(kind=sp), DIMENSION(:), POINTER :: cc
>
> ALLOCATE(cc(N)) ! [... My change (giles) ...]
> ![...]
> CALL dosomething(data%cc,N)
....
> SUBROUTINE dosomething(r,N)
> REAL :: r(2,N)
> ![...]
> END SUBROUTINE
>
> I know that's illegal in f77 as well, but in practice it is giving
> excellent performance on many different architectures/compilers (we
> use compiler flags like -mismatch_all as required). [...]
You are probably right about that being illegal. I'm away from
home and can't check the standard document(s) easily. I *thougt*
it might be permitted under sequence association.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| glen herrmannsfeldt 2004-11-15, 3:59 pm |
|
Joost VandeVondele wrote:
(snip about EQUIVALENCE on dummy arguments)
> I've also once tried to equivalence a dummy argument, and I still have
> no nice solution for what I want to do, so I would be happy to hear
> suggestions.
> The issue is an interface to some legacy code (f77), that is
> performance critical, and where memory is an issue. We would like to
> wrap it in a module. The point is that in the calling routine 'data'
> is a complex array, whereas in the subroutine it is a real array (both
> too hard-wired to change). Schematically it looks like:
(snip)
> TYPE datatype
> complex(kind=sp), DIMENSION(:), POINTER :: cc
> END TYPE
> integer, parameter :: N=90000000
> TYPE(datatype) :: data
> ALLOCATE(data%cc(N))
> CALL dosomething(data%cc,N)
> end program
> SUBROUTINE dosomething(r,N)
> REAL :: r(2,N)
> I know that's illegal in f77 as well, but in practice it is giving
> excellent performance on many different architectures/compilers (we
> use compiler flags like -mismatch_all as required). It would be nice
> to get the code standard conforming without performance impact, and
> something like
I believe, but haven't actually looked it up, that passing COMPLEX to
a dummy array is legal Fortran 77. The above uses many non-F77
features, so obviously is not standard Fortan 77.
Someone else will have to say that this is legal on later standards.
-- glen
| |
|
| Joost VandeVondele wrote:
>
> use compiler flags like -mismatch_all as required). It would be nice
> to get the code standard conforming without performance impact, and
> something like
>
> SUBROUTINE dosomething_new(c,N)
> COMPLEX :: c(N)
> REAL :: r(2,N)
> EQUIVALENCE(c(1),r(1,1))
> ! [...]
> END SUBROUTINE
>
> would certainly be 'intuitive'. Any alternatives welcome ...
Here's something that'll make you legit - straight out of McCracken pg.
21.5 - have fun.
program ancient
parameter (n = 10)
complex c(n)
common /magic/ c
data c/10*(1,-1)/
call dosomething_old
end
subroutine dosomething_old
parameter (n = 10)
complex c(n)
common /magic/ c
real r(2,n)
equivalence (c, r)
print*, r(2,4)
end
| |
| Ryo Furue 2004-11-18, 3:56 am |
| Richard E Maine <nospam@see.signature> wrote in message news:<m1fz3b129m.fsf@MLMCE0000L22801.local>...
> furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue) writes:
>
[...][color=darkred]
> So keep in mind that this is *PURE* speculation (which probably
> implies something about side effects, but I'm not sure what. :-))
:) Thanks for your speculation. I understand your point. I'm not
asking for what were the *real* reasons. I'm asking for ..., yes,
speculations.
[...]
> Note that *ALL* valid forms of equivalence are completely static
> and relate to do with compile-time layout of memory.
OK.
> [...] Think about that in the context of the time.
> What do you think that the main purpose of equivalence was?
>
> From what I see, which is consistent with 3rd and 4th hand tales,
> equivalence was mostly to save memory by using the same memory for
> different variables where practical. If you didn't program in those
> days, you probably have a hard time envisioning how important memory
> use was.
OK. Although I didn't program in those days (I was perhaps born,
though), I can assume that there was such a situation.
> Equivalence of dummy arguments wouldn't have much to do
> with compile-time memory layout to save memory.
I'm wondering if you could elaborate on this part. I mean,
there is the staticness of the memory layout on one hand,
and there is the need for saving memory on the other. How
were these two things related? in your speculation, of course.
It seems to me that if you want to save memory, you could do so
also by equivalencing dummies ... I may be missing something....
I'm not demanding that the decision should have been logical,
and I understand you try to portray the "mindset" of the day.
I'm just saying that the mindset isn't still very clear to me.
On the other hand, perhaps, problems that would have arised
if equivalence with dummies had been allowed (such as James
Giles's example) were thought not worth solving?
Cheers,
Ryo
| |
| Richard Maine 2004-11-18, 3:56 am |
| furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue) writes:
> It seems to me that if you want to save memory, you could do so
> also by equivalencing dummies ... I may be missing something....
In most implementations, dummy arguments don't use any memory.
They are effectively just pointers to the actual arguments.
I am oversimplifying and also using terminology sloppily, but
I think it expresses the general point reasonably.
--
Richard Maine
email: my last name at domain
domain: summertriangle dot net
| |
| glen herrmannsfeldt 2004-11-18, 3:56 am |
| Richard Maine wrote:
> furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue) writes:
[color=darkred]
> In most implementations, dummy arguments don't use any memory.
> They are effectively just pointers to the actual arguments.
> I am oversimplifying and also using terminology sloppily, but
> I think it expresses the general point reasonably.
The F66 implementations that I know of that use copy in/copy out
for scalar arguments don't for arrays. But all that is usually
needed is the offset from the origin of the array, and it would
still be possible to do that with EQUIVALENCE on dummy arrays.
It wouldn't directly save memory, but it might save having to
copy an array.
As far as EQUIVALENCE history, it seems to exist in the 704
Fortran compiler from 1956. From the manual for that system:
"The EQUIVALENCE statement enables the programmer, if he wishes,
to control the allocation of data storage in the object program.
I particular, it permits him to economise (sic) on data storage
requirements by causing storage locations to be shared by two
or more quantities, when the logic of his program permits.
It also permits him, if he wishes, to call the same quantity
by several different names, and then ensure that those names
are treated as equivalent."
COMMON didn't exist yet, so the interaction between COMMON
and EQUIVALENCE wasn't an issue.
Next after EQUIVALENCE the FREQUENCY statement is described...
"The FREQUENCY statement permits the programmer to give his
estimate, for each branch-point of control, of the frequencies
with which the several branches will actually be executed in
the object program. This information is used to optimize
the use if index registers in the object program."
The ratio of probabilities for each branch of an arithmetic
IF statement (the only kind if IF) and computed GOTO could
be given, and also the expected number of trips through
a DO loop when one of the DO parameters is a variable.
It seems, though, that FREQUENCY didn't make it into
the standard.
Also, note that programmers were expected to be male.
-- glen
| |
| Joost VandeVondele 2004-11-18, 8:58 am |
| bv <bvoh@Xsdynamix.com> wrote in message
> Here's something that'll make you legit - straight out of McCracken pg.
> 21.5 - have fun.
>
Unhappily, this nice trick is not possible with dynamically allocated
arrays, or where the dosomething is called with arrays that are not
the same (location/size) at every call.
Thanks,
Joost
| |
| Richard Edgar 2004-11-18, 8:58 am |
| glen herrmannsfeldt wrote:
> Next after EQUIVALENCE the FREQUENCY statement is described...
>
> "The FREQUENCY statement permits the programmer to give his
> estimate, for each branch-point of control, of the frequencies
> with which the several branches will actually be executed in
> the object program. This information is used to optimize
> the use if index registers in the object program."
I wonder if something like this would be useful, with today's highly
pipelined processors which _really_ don't like branches. But do it with
comments, like OpenMP. e.g.
IF( ..... ) THEN
!$EXPECTED
...
ELSE
...
END IF
which would tell the compiler to expect the IF statement to be true most
of the time. You could also include it in CASE statements. Since it's a
comment, it wouldn't affect compilers that didn't know about it.
Richard
| |
| Gordon Sande 2004-11-18, 3:59 pm |
|
Richard Maine wrote:
> furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue) writes:
>
>
>
>
> In most implementations, dummy arguments don't use any memory.
> They are effectively just pointers to the actual arguments.
> I am oversimplifying and also using terminology sloppily, but
> I think it expresses the general point reasonably.
>
A common feature of many early machines was the ability to use
indirect addresses. Any similarity between a C pointer and an
indirect address is purely due to habits of the time. Machines
with indirect addressing require some scheme to prevent pointer
cycles. So one might have only one level, a maximum of 256 levels
or timeouts. Same for the "execute" instruction. More elaborate
instruction sets could add indexing along the indirection chain.
Page faulting while indirect referencing makes life interesting
at the level of fault handlers.
Fortran and such instruction sets were well matched. Even the
notorious "one trip" DO loop of pre F77 Fortrans matched the
index register instructions. Complex instruction sets fell out
of fashion as the balances between between hardware and software
or memory and processor changed.
| |
| Gordon Sande 2004-11-18, 3:59 pm |
|
glen herrmannsfeldt wrote:
> Richard Maine wrote:
>
>
>
>
>
>
>
> The F66 implementations that I know of that use copy in/copy out
> for scalar arguments don't for arrays. But all that is usually
> needed is the offset from the origin of the array, and it would
> still be possible to do that with EQUIVALENCE on dummy arrays.
> It wouldn't directly save memory, but it might save having to
> copy an array.
>
> As far as EQUIVALENCE history, it seems to exist in the 704
> Fortran compiler from 1956. From the manual for that system:
>
> "The EQUIVALENCE statement enables the programmer, if he wishes,
> to control the allocation of data storage in the object program.
> I particular, it permits him to economise (sic) on data storage
> requirements by causing storage locations to be shared by two
> or more quantities, when the logic of his program permits.
> It also permits him, if he wishes, to call the same quantity
> by several different names, and then ensure that those names
> are treated as equivalent."
>
> COMMON didn't exist yet, so the interaction between COMMON
> and EQUIVALENCE wasn't an issue.
>
> Next after EQUIVALENCE the FREQUENCY statement is described...
>
> "The FREQUENCY statement permits the programmer to give his
> estimate, for each branch-point of control, of the frequencies
> with which the several branches will actually be executed in
> the object program. This information is used to optimize
> the use if index registers in the object program."
>
> The ratio of probabilities for each branch of an arithmetic
> IF statement (the only kind if IF) and computed GOTO could
> be given, and also the expected number of trips through
> a DO loop when one of the DO parameters is a variable.
Some descriptions of the mind set of the time indicate that
the major issue surrounding the use of compilers was that
they would not allow the programs to be as efficient as
the assembly language programs. There were two responses
to this. In one the compiler would produce assembly code and
a programmer would do a final optimization clean up or it.
In the other, used in the IBM FORTRAN II, the compiler would
do elaborate optimization, including a Monte Carlo of program
paths, using either inferred information or the explicit values
from the FREQUENCY statements. It was not long until the
literature was concerned with the software crisis, software
engineering became a respectable topic and some even went
to the extreme of suggesting that the software would become
more expensive than the hardware it ran on.
Now the video buffer on a desktop may have as much storage
as the shared disk on the mainframe of a major university.
(And micros hard disk would probably store the contents of the
full tape library!) And more processor is used to scale and
shade the fonts than that old mainframe had for computing.
> It seems, though, that FREQUENCY didn't make it into
> the standard.
Or SENSE LIGHT, or many specializations of IF, or ...
> Also, note that programmers were expected to be male.
>
> -- glen
>
| |
| Michael Metcalf 2004-11-18, 3:59 pm |
|
>
>
> Or SENSE LIGHT, or many specializations of IF, or ...
>
I'm sure I once read that FREQUENCY fell into disrepute because it had been
implemented in the wrong sense!
Of course, SENSE LIGHT didn't make sense any longer on machines with no
lights. There was, however, for some time the ability to set and sense
virtual lights.
Regards,
Mike Metcalf
| |
| Ryo Furue 2004-11-18, 8:58 pm |
| Richard Maine <nospam@see.signature> wrote in message news:<87brdvoog2.fsf@vega.site>...
> furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue) writes:
>
>
> In most implementations, dummy arguments don't use any memory.
> They are effectively just pointers to the actual arguments.
Well, I know that. Perhaps I didn't present well what I have in mind.
What I was thinking of is this
subroutine sub(aa)
real aa(*)
integer nn(100)
equivalence (aa,nn) !! nn "points" to the same memory as aa.
... use aa ...
... aa is finished ...
... Now aa's memory contents can be destroyed ...
... Now use nn. We save memory! ...
I mean, by using the actual argument through the dummy (pointer)
and through the equivalence, we save memory! nn doesn't need
its own memory.... This kind of thinking.
So, my question still stands, I think. Or I may be still
missing something....
Ryo
| |
| Richard E Maine 2004-11-18, 8:58 pm |
| furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue) writes:
> Richard Maine <nospam@see.signature> wrote in message news:<87brdvoog2.fsf@vega.site>...
>
> Well, I know that. Perhaps I didn't present well what I have in mind.
> What I was thinking of is this...
I think I've said all that I can usefully do so on this. I've attempted
to present my speculation about possible reasons. I'm already out on
a limb. I simply have no basis at all to argue about whether there are
other ways to also look at things. Of course, there are other ways;
I would not dream of implying otherwise.
I have presented all the data I have. I realize it isn't much, but
that's all there is, at least from me. If it isn't adequate, then I
don't have an answer for you. Speculation about how other viewpoints,
or even variants of the same theme, might have come to different
conclusions is at least speculation**2; I have nothing to say about it.
I think you are looking for more certainty about reasons than is
possible. Anyway, I don't have it.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| glen herrmannsfeldt 2004-11-18, 8:58 pm |
|
Ryo Furue wrote:
(snip)
> Well, I know that. Perhaps I didn't present well what I
> have in mind. What I was thinking of is this
> subroutine sub(aa)
> real aa(*)
> integer nn(100)
> equivalence (aa,nn) !! nn "points" to the same memory as aa.
> ... use aa ...
> ... aa is finished ...
> ... Now aa's memory contents can be destroyed ...
> ... Now use nn. We save memory! ...
> I mean, by using the actual argument through the dummy (pointer)
> and through the equivalence, we save memory! nn doesn't need
> its own memory.... This kind of thinking.
As I said previously, EQUIVALENCE came in 1956. It is still
possible to do what you ask, only indirectly. Now, why it was
never added later, is a different question. As machines got bigger
and compilers logic got more complicated it could have been.
But as it was always possible to do indirectly...
subroutine sub(aa)
real aa(1)
C (are we still talking about 1956?)
equivalence (a,n)
....
n=int(some expression)
aa(i)=a
It requires one extra line to do the conversion separately from
the expression.
-- glen
| |
|
| Joost VandeVondele wrote:
>
> Unhappily, this nice trick is not possible with dynamically allocated
> arrays, or where the dosomething is called with arrays that are not
> the same (location/size) at every call.
The latter can be remedied, on the former you'll get a substantial
performance hit - still interested? Here's a second pass,
program take_II
parameter (n = 10)
complex c(n)
real r(2,n)
equivalence (c, r)
data c/10*(1,-1)/
call dosomething(r,n)
end
subroutine dosomething(r,n)
real r(2,n)
print*, r(2,4)
end
| |
| Walter Spector 2004-11-19, 3:58 pm |
| Ryo Furue wrote:
> ....
> What I was thinking of is this
>
> subroutine sub(aa)
> real aa(*)
> integer nn(100)
> equivalence (aa,nn) !! nn "points" to the same memory as aa.
> ... use aa ...
> ... aa is finished ...
> ... Now aa's memory contents can be destroyed ...
> ... Now use nn. We save memory! ...
While I've wanted to do this sort of thing years ago, it really makes
little sense in F90/F95 and on modern hardware. Nowadays, depending on
what needs to be done, one can use:
1.) Allocatable (or automatic) arrays in SUB for scratch space. It is
silly to pass it through the arg list - unless, maybe, maybe, the routine
is called billions of times. (And even then, sometimes it is preferable to
use a SAVEd allocatable array in SUB.)
2.) Derived type passed in/out via the arg list.
Walt
-...-
Walt Spector
(w6ws at earthlink dot net)
| |
| glen herrmannsfeldt 2004-11-19, 3:58 pm |
|
Walter Spector wrote:
(snip on EQUIVALENCE of dummy arguments)
> While I've wanted to do this sort of thing years ago, it really makes
> little sense in F90/F95 and on modern hardware. Nowadays, depending on
> what needs to be done, one can use:
> 1.) Allocatable (or automatic) arrays in SUB for scratch space. It is
> silly to pass it through the arg list - unless, maybe, maybe, the routine
> is called billions of times. (And even then, sometimes it is preferable to
> use a SAVEd allocatable array in SUB.)
The time savings from allocation probably come at somewhat less than
billions of times, but yes, in most cases allocating in the subroutine
is fine. Millions might be enough to make it worthwhile in time.
-- glen
| |
| Ryo Furue 2004-11-19, 8:57 pm |
| Richard E Maine <nospam@see.signature> wrote in message news:<m1wtwi4zi9.fsf@MLMCE0000L22801.local>...
> furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue) writes:
>
[color=darkred]
> I think I've said all that I can usefully do so on this. I've attempted
> to present my speculation about possible reasons. I'm already out on
> a limb. I simply have no basis at all to argue about whether there are
> other ways to also look at things. Of course, there are other ways;
> I would not dream of implying otherwise.
First of all, I have no intention whatsoever to argue against
what you are saying. You offered your speculation. There's
no point in arguing against it because other views are of
course posssible. (If you find my language impolite or harsh,
considered it as due to the fact that I'm not a native speaker
of English. I'm trying to be not agressive but clear.)
Rather, there is one point which is not clear to me in what
you are saying. I repeat I'm not arguing against your view,
or I'm not try to present a different one, but I'm trying
to understand yours.
In your first response, you said
> Note that *ALL* valid forms of equivalence are completely static
> and relate to do with compile-time layout of memory. [...]
> [...]
> What do you think that the main purpose of equivalence was?
>
> From what I see, [...] equivalence was mostly to save memory by
> using the same memory for different variables where practical.
> [...]
> Equivalence of dummy arguments wouldn't have much to do
> with compile-time memory layout to save memory.
What I'm trying to understand is this last sentence.
What does the saving of memory have to do with *compile-time*
memory layout? What's the logic?
I do understand that the saving of memory has to do with
memory layout. But why compile-time? I can't follow this
jump (which it seems to me to be) in logic.
In other words, there are two things: (1) All legal forms of
equivalence concern only about *compile-time* memory layout;
(2) Primary purpose of equivalence was to save memory.
I fail to see a logical connection between these two.
In short, what I do understand are:
(1') Equivalence concerns about memory layout;
(2) Primary purpose of equivalence was to save memory.
And what I don't understand is: How does the notion of
"compile-time" come into play in this picture?
Sorry for this repetitive presentation of my question.
I've cast it in different forms so that the chance of
its getting across will be higher (I hope). If this fails,
I'll give it up.
Regards,
Ryo
| |
| Gordon Sande 2004-11-19, 8:57 pm |
|
Ryo Furue wrote:
> Richard E Maine <nospam@see.signature> wrote in message news:<m1wtwi4zi9.fsf@MLMCE0000L22801.local>...
>
>
>
>
>
> First of all, I have no intention whatsoever to argue against
> what you are saying. You offered your speculation. There's
> no point in arguing against it because other views are of
> course posssible. (If you find my language impolite or harsh,
> considered it as due to the fact that I'm not a native speaker
> of English. I'm trying to be not agressive but clear.)
>
> Rather, there is one point which is not clear to me in what
> you are saying. I repeat I'm not arguing against your view,
> or I'm not try to present a different one, but I'm trying
> to understand yours.
>
> In your first response, you said
>
>
>
>
> What I'm trying to understand is this last sentence.
> What does the saving of memory have to do with *compile-time*
> memory layout? What's the logic?
>
> I do understand that the saving of memory has to do with
> memory layout. But why compile-time? I can't follow this
> jump (which it seems to me to be) in logic.
>
> In other words, there are two things: (1) All legal forms of
> equivalence concern only about *compile-time* memory layout;
> (2) Primary purpose of equivalence was to save memory.
> I fail to see a logical connection between these two.
Rather than *compile time* perhaps *completely specified at
compile time* might make sense. equivalence was designed
when all storage was static so the variables had known
memory locations (up to relocation by the loader) with
the exception of dummy arguments which were associated
with variable with known memory locations.
At that time memory was so tight that that the loader was
in the memory locations which would shortly (at end of loading
and start of execution) be blank common. In the very beginning
there was only blank common.
> In short, what I do understand are:
> (1') Equivalence concerns about memory layout;
> (2) Primary purpose of equivalence was to save memory.
> And what I don't understand is: How does the notion of
> "compile-time" come into play in this picture?
>
> Sorry for this repetitive presentation of my question.
> I've cast it in different forms so that the chance of
> its getting across will be higher (I hope). If this fails,
> I'll give it up.
>
> Regards,
> Ryo
| |
| glen herrmannsfeldt 2004-11-19, 8:57 pm |
|
Ryo Furue wrote:
(big snip of discussion of EQUIVALENCE and dummy variables)
> Rather, there is one point which is not clear to me in what
> you are saying. I repeat I'm not arguing against your view,
> or I'm not try to present a different one, but I'm trying
> to understand yours.
> In your first response, you said
Note that Fortran traditionally allowed, though the standard didn't
require, completely static allocation. The memory layout was completely
defined at compile time. (The EQUIVALENCE quote in a previous post
was from 1956.)
[color=darkred]
From the quote, yes, it seems to be memory savings.
[color=darkred]
[color=darkred]
[color=darkred]
> What I'm trying to understand is this last sentence.
> What does the saving of memory have to do with *compile-time*
> memory layout? What's the logic?
Dummy arguments don't compile time memory allocated to them.
Over the years, Fortran has pretty much required that a dummy
array reference the memory in the calling program. So the subroutine
can't reduce the usage of its own memory through the use of dummy
variables, because they are not part of its own memory. (If Fortran
66 allowed copy in/copy out for arrays, that would seem incompatible
with the popular dimension (1) system. I will assume, then, that
it isn't used in older Fortran code.)
> I do understand that the saving of memory has to do with
> memory layout. But why compile-time? I can't follow this
> jump (which it seems to me to be) in logic.
> In other words, there are two things: (1) All legal forms of
> equivalence concern only about *compile-time* memory layout;
> (2) Primary purpose of equivalence was to save memory.
> I fail to see a logical connection between these two.
> In short, what I do understand are:
> (1') Equivalence concerns about memory layout;
> (2) Primary purpose of equivalence was to save memory.
> And what I don't understand is: How does the notion of
> "compile-time" come into play in this picture?
When you write programs in any language do you consider how
much memory they are using, when that memory is being used and
when it is just sitting around doing nothing, and otherwise try
to minimize usage of memory? With the size of most computers
today many people don't try very hard to do that. Consider that
many programs read in some data, process it, and write out results
based on that data. In many cases it is possible to read in
and process the data one line at a time, yet it is not uncommon
to see programs that will try to read it all at once. While this
often works, it arbitrarily limits the usefulness of programs where
often that limit isn't needed.
If you don't apply any consideration, any cost, to the memory use
of your programs then there is no way to explain the desire to
reduce that usage. Consider that many numerical algorithms operate
on data in place, with matrix inversion and Fourier transform as two
examples. It turns out not to be hard to do in those cases, yet it
is easier to describe the algorithms using separate arrays.
In both cases the same dummy array is reused, yet with little possible
advantage with EQUIVALENCE.
-- glen
| |
| Ryo Furue 2004-11-20, 3:57 am |
| glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote in message news:<cnja96$q2f$1@gnus01.u.washington.edu>...
> Ryo Furue wrote:
[...]
>
[...][color=darkred]
> As I said previously, EQUIVALENCE came in 1956. It is still
> possible to do what you ask, only indirectly.
[...]
> subroutine sub(aa)
> real aa(1)
> C (are we still talking about 1956?)
> equivalence (a,n)
> ...
> n=int(some expression)
> aa(i)=a
Hi, Glen. I wasn't "ask"ing that! I'm afraid to say that you cited my
example out of the context. I was (or we were) talking about the
saving of memory space by equivalence. Your example shows how to cheat
on types, which is a present-day common use of equivalence. But, my
example shows that you *could* save memory by equivalencing dummies
if it were allowed. (Note that in your example, we still need memory
for the variable "a" or "n"; in contrast, that in my example, the variable
nn doesn't consume memory at all.)
In addition, I'm not asking for the feature, anyway. I just want to
understand why equivalencing dummies was made illegal in F77.
Regards,
Ryo
| |
| Rich Townsend 2004-11-20, 3:57 am |
| Ryo Furue wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote in message news:<cnja96$q2f$1@gnus01.u.washington.edu>...
>
>
> [...]
>
>
> [...]
>
>
> [...]
>
>
>
> Hi, Glen. I wasn't "ask"ing that! I'm afraid to say that you cited my
> example out of the context. I was (or we were) talking about the
> saving of memory space by equivalence. Your example shows how to cheat
> on types, which is a present-day common use of equivalence. But, my
> example shows that you *could* save memory by equivalencing dummies
> if it were allowed. (Note that in your example, we still need memory
> for the variable "a" or "n"; in contrast, that in my example, the variable
> nn doesn't consume memory at all.)
>
> In addition, I'm not asking for the feature, anyway. I just want to
> understand why equivalencing dummies was made illegal in F77.
Your example at the top shows a fundamental misconception about dummy
arguments in Fortran. Unlike C, dummy arguments in Fortran are passed by
reference, not by value (or rather, the language behaves as if they
were). Therefore, aa and nn in your example don't get allocated memory
upon subroutine entry; instead, they are just used as aliases for the
true arguments that the subroutine is called with.
Since these true arguments already have storage space allocated in the
calling routine, it is meaningless to talk about equivalencing them.
Equivalence only makes sense when new memory is being allocated, by
saying "hey, lets make these two variable names refer to the same piece
of memory that we just created". But in the case of dummy arguments, no
new memory is being allocated; instead, already-existing memory is being
referenced by new variable names for the duraration of the subroutine.
I hope this clears up why equivalencing of dummy arguments isn't really
meaningful.
cheers,
Rich
PS This explaination is not standard conforming. The cogniscenti in
c.l.f could no doubt drive holes through it, but hopefully it is not too
far from the truth to be useful to you...
--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware
[ Delete VOID for valid email address ]
| |
| Rich Townsend 2004-11-20, 3:57 am |
| Rich Townsend wrote:
> Ryo Furue wrote:
>
>
>
> Your example at the top shows a fundamental misconception about dummy
> arguments in Fortran. Unlike C, dummy arguments in Fortran are passed by
> reference, not by value (or rather, the language behaves as if they
> were). Therefore, aa and nn in your example don't get allocated memory
> upon subroutine entry; instead, they are just used as aliases for the
> true arguments that the subroutine is called with.
>
> Since these true arguments already have storage space allocated in the
> calling routine, it is meaningless to talk about equivalencing them.
> Equivalence only makes sense when new memory is being allocated, by
> saying "hey, lets make these two variable names refer to the same piece
> of memory that we just created". But in the case of dummy arguments, no
> new memory is being allocated; instead, already-existing memory is being
> referenced by new variable names for the duraration of the subroutine.
>
> I hope this clears up why equivalencing of dummy arguments isn't really
> meaningful.
>
> cheers,
>
> Rich
>
> PS This explaination is not standard conforming. The cogniscenti in
> c.l.f could no doubt drive holes through it, but hopefully it is not too
> far from the truth to be useful to you...
>
Damn, I hadn't read your message through properly -- I see you weren't
talking about equivalencing two dummy arguments, but instead a dummy
argument and a local variable. Which makes a lot more sense.
Why this was forbidden, I'm not sure; but it may have something to do
with the fact that although Fortran routines use *semantic* call by
reference, the actual implementation is allowed to be done in just about
any way -- including copy-in/copy-out. In fact, there are certain
situations in Fortran 90/95 where such a copy-in/copy-out is strongly
hinted at by the standard, I believe.
With this in mind, can you imagine what a mess equivalence would be with
a non-transparent call-by-reference implementation, such as
copy-in/copy-out? Is the equivalence to the copy variable? Or to the
original? Hell, just thinking about it, I already feel C/C++ angst
rising in me -- who is the real Slim Shady, and who is just a pointer?
cheers,
Rich
--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware
[ Delete VOID for valid email address ]
| |
| Ken Plotkin 2004-11-20, 3:57 am |
| On 19 Nov 2004 16:56:41 -0800, furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue)
wrote:
[snip]
>In addition, I'm not asking for the feature, anyway. I just want to
>understand why equivalencing dummies was made illegal in F77.
Do you have a particular problem in mind where you think you need to
do this? Or are you just getting your jollies by pursuing this
question?
Ken Plotkin
| |
| glen herrmannsfeldt 2004-11-20, 8:56 am |
| Ryo Furue wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote in message news:<cnja96$q2f$1@gnus01.u.washington.edu>...
(snip)
[color=darkred]
> Hi, Glen. I wasn't "ask"ing that! I'm afraid to say that you cited my
> example out of the context. I was (or we were) talking about the
> saving of memory space by equivalence. Your example shows how to cheat
> on types, which is a present-day common use of equivalence. But, my
> example shows that you *could* save memory by equivalencing dummies
> if it were allowed. (Note that in your example, we still need memory
> for the variable "a" or "n"; in contrast, that in my example, the variable
> nn doesn't consume memory at all.)
> In addition, I'm not asking for the feature, anyway. I just want to
> understand why equivalencing dummies was made illegal in F77.
It has been illegal since 1956. They just continued its
being illegal in 1977.
The hard case is the case where the types are different, so
I answered that. If they are not different just assign to
the array you have.
I believe you are allowed to declare a one dimensional
array as a dummy argument, even when it is called with more
than one dimension. You may then compute the appropriate
position in the array using any method you like. This will
allow you to do any memory saving, except for the case where
the variables have different type.
This was very popular in the early days, through Fortran 66.
Many Fortran 66 programs lasted through the Fortran 77 years.
-- glen
| |
| Jim Giles 2004-11-20, 3:56 pm |
| Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote in message news:<cnmdcf$ier$1@scrotar.nss.udel.edu>...
....
> Why this was forbidden, I'm not sure; but it may have something to do
> with the fact that although Fortran routines use *semantic* call by
> reference, the actual implementation is allowed to be done in just about
> any way -- including copy-in/copy-out. In fact, there are certain
> situations in Fortran 90/95 where such a copy-in/copy-out is strongly
> hinted at by the standard, I believe.
Fortran's semantics does not correspond to call by reference
or to copy-in/copy-out. This is deliberate since both, or some
combination, are allowed.
In some environments, copy-in/copy-out is more efficient. In
distributed-parallel, for example, where call by reference would
involve a network communication for each operation on each argument,
it's more efficient to just copy the data once into the processor
that runs the procedure and copy the data back to the processor
in which the caller resides at the end.
In quite a few implementations that *appear* to be call by reference
(they pass addresses), their semantics is consistent with copy-in/
copy-out: they make local copies within the procedure, either because
the code works better if you guarantee the data is consecutive, or
because the platform has a large register pool and can keep the data
there. And, some arguments (or parts of some arguments) may be
copied this way while others are not.
In any case, the fact remains that Fortran is not in any official
or practical sense to be described as semantically a call by reference
language. It is misleading to users (and implementors) to try to
use that terminology in describing argument association in Fortran.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Rich Townsend 2004-11-20, 8:56 pm |
| Jim Giles wrote:
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote in message news:<cnmdcf$ier$1@scrotar.nss.udel.edu>...
> ...
>
>
>
> Fortran's semantics does not correspond to call by reference
> or to copy-in/copy-out. This is deliberate since both, or some
> combination, are allowed.
>
> In some environments, copy-in/copy-out is more efficient. In
> distributed-parallel, for example, where call by reference would
> involve a network communication for each operation on each argument,
> it's more efficient to just copy the data once into the processor
> that runs the procedure and copy the data back to the processor
> in which the caller resides at the end.
>
> In quite a few implementations that *appear* to be call by reference
> (they pass addresses), their semantics is consistent with copy-in/
> copy-out: they make local copies within the procedure, either because
> the code works better if you guarantee the data is consecutive, or
> because the platform has a large register pool and can keep the data
> there. And, some arguments (or parts of some arguments) may be
> copied this way while others are not.
>
> In any case, the fact remains that Fortran is not in any official
> or practical sense to be described as semantically a call by reference
> language. It is misleading to users (and implementors) to try to
> use that terminology in describing argument association in Fortran.
>
You appear to confuse semantics with implementation. If something
*appears* to be call-by-reference, then it has call-by-reference
semantics -- irrespective of whether it is actually implemented as
call-by-reference, or by copy-in/copy-out, or by a relay team of
Mongolian yak herders. By 'call-by-reference semantics', I was simply
referring to the fact that modifying a Fortran dummy leads to
corresponding modifications in the true argument. Such behaviour could
equally be described as 'copy-in/copy-out semantics', since the end
result is the same.
cheers,
Rich
--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware
[ Delete VOID for valid email address ]
| |
| Ryo Furue 2004-11-20, 8:56 pm |
| Thank you very much, Rich, for writing clearly. I really appreciate it.
Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote in message news:
[...]
[...][color=darkred]
> Your example at the top shows a fundamental misconception about dummy
> arguments in Fortran. Unlike C, dummy arguments in Fortran are passed by
> reference, not by value (or rather, the language behaves as if they
> were). Therefore, aa and nn in your example don't get allocated memory
> upon subroutine entry; instead, they are just used as aliases for the
> true arguments that the subroutine is called with.
In fact, honestly, sincerely, I know every single point you make here,
except for the "misconception" bit. Please believe me. And now, I'd like
to ask you to bear with me a little bit more. It seems to me that what
I mean is not somehow understood. You seem to think I think equivalencing
dummies is meaningfull because I don't understand how dummies work internally.
Not so. Also, I don't have the slightest intention to attack you.
I just want to make me understood correctly.
> Since these true arguments already have storage space allocated in the
> calling routine, it is meaningless to talk about equivalencing them.
> Equivalence only makes sense when new memory is being allocated, by
> saying "hey, lets make these two variable names refer to the same piece
> of memory that we just created".
Yes, this is exactly what I'd like to question about. Why is the giving
of a new name meaningful only when new memory is being allocated?
The following is a bit longish explanation of my point. It would be a bit
longish because I'd like to be very careful to make myself clear.
(1) program main
real aa(100)
integer nn(100)
... use aa ...
... use nn ...
Suppose you realize that you don't use aa and nn at the same time.
Then you realize you economize on memory by modifying the above code
to
(2) program main
real aa(100)
integer nn(100)
equivalenc(aa, nn) !! aa and nn share the same memory.
... use aa ...
... use nn ...
In (1), you use extra memory for nn, but not in (2). So you
saved memory. Do you agree that this is one of the meaningful
uses of equivalence? If so, let me proceed.
(3) subroutine sub(aa)
real aa(100) !! dummy
integer nn(100) !! local array; allocates memory.
... use aa ...
... use nn ...
program main
real a(100)
call sub(a)
......
What is the total memory use (for arrays) of this program?
100 x 4 x 2 = 800 bytes (assuming that reals and integers are
4-byte objects. Sizes can be otherwise.)
Suppose you realize you don't use aa and nn at the same time.
Then you could economize memory by modifying the above into
(4) subroutine sub(aa)
real aa(100) !! dummy
integer nn(100) !! will "point to" the dummy.
equivalence(aa, nn) !! aa and nn share the same memory.
!! This equivalence is internally similar to
!! integer, pointer:: nn(100)
!! nn => aa !! not allowed in Fortran, either.
... use aa ...
... use nn ...
program main
real a(100)
call sub(a)
...
What is the memory use? 100 x 4 = 400.
In (3), you use extra memory for nn, but not in (4).
So you saved memory.
What I don't understand is: while (2) is a meaningful use of
equivalence, why isn't (4) so? To me, the pair (3) and (4) is
completely parallel to (1) and (2). If I parody on your words,
"hey, let's make nn refer to the same piece of memory as aa
somebody created for us. Otherwise we'd waste memory!" :-)
If you think (3) is a contrived example, what about a more realistic
one like the following?
Let's say we create a subroutine "sub" which is meant to be part of
a library. Suppose "sub" operates on a given array and return its results
in the same array. Also suppose we need work areas in "sub".
A first bad design is
(5) subroutine sub(arr, N)
real arr(N) !! input and output
real rwork(10000) !! let's hope it's large enough
integer iwork(10000) !! ditto
do i = 1, N
... use arr(i) and rwork(i) ...
end do
do i = 1, N
... use arr(i) and iwork(i) ...
end do
A library subroutine shouldn't (a) waste memory or (b) impose arbitrary
limits on the input size.
So a better design would be
(6) subroutine sub(arr, rwork, iwork, N)
!!... ask the user to supply work areas....
real arr(N), rwork(N)
integer iwork(N)
... same ...
Not bad. But, we realize that we don't use rwork and iwork at the
same time. So, we could save memory by modifying (6) into
(7) subroutine sub(arr, rwork, N)
real arr(N), rwork(N)
integer iwork(N)
equivalence (rwork, iwork) !! iwork "points to" rwork
... same ...
Yes, (6) is more portable than (7) but on the other hand (6) saves
memory. Which is better depends on the use of this library.
Sorry for the long-windedness. To summarise, my question is:
What's so different between (2) and (4)?
Finally, It's possible that *I* misunderstand what you are saying.
If so, please point out my miconception.
Thank you again for your reply. I appreciate it.
Ryo
| |
| Gordon Sande 2004-11-20, 8:56 pm |
|
Rich Townsend wrote:
> Jim Giles wrote:
>
>
> You appear to confuse semantics with implementation. If something
> *appears* to be call-by-reference, then it has call-by-reference
> semantics -- irrespective of whether it is actually implemented as
> call-by-reference, or by copy-in/copy-out, or by a relay team of
> Mongolian yak herders. By 'call-by-reference semantics', I was simply
> referring to the fact that modifying a Fortran dummy leads to
> corresponding modifications in the true argument. Such behaviour could
> equally be described as 'copy-in/copy-out semantics', since the end
> result is the same.
Call-by-reference connotes a particular set of semantics relating to
aliasing as does copy-in/copy-out. The point is that both of the
connoted semantics are other than those of Fortran, or otherwise
stated they are wrong when used to describe Fortran. If someone
takes the common definition of these and thinks Fortran uses the
method then they are prone to get a nasty surprise.
Surprises come when you use "extensions" silently and think you
have a standard conforming program.
> cheers,
>
> Rich
>
| |
| glen herrmannsfeldt 2004-11-21, 3:58 am |
| Gordon Sande wrote:
(snip)
> Call-by-reference connotes a particular set of semantics relating to
> aliasing as does copy-in/copy-out. The point is that both of the
> connoted semantics are other than those of Fortran, or otherwise
> stated they are wrong when used to describe Fortran. If someone
> takes the common definition of these and thinks Fortran uses the
> method then they are prone to get a nasty surprise.
I believe that call by value return is the usual name for
copy in/copy out. The OS/360 compilers do it for scalar
variables, but not arrays. I don't know any that do it
for arrays, but as far as I know it is legal there, too.
> Surprises come when you use "extensions" silently and think you
> have a standard conforming program.
Well, there is the common extension (in F66 days) of dimensioning
arrays (1) in a subroutine, and trusting in the addressing
system to find all the elements. Presumably that wouldn't
work for copy in if it used that dimension for the amount
to copy. It was common enough that I am sure there would
have been complaints if it didn't work. Presumably any
bounds checking would also be done with that number, and
would fail, independent of calling convention.
-- glen
| |
| glen herrmannsfeldt 2004-11-21, 3:58 am |
| Ryo Furue wrote:
(snip)
> Yes, this is exactly what I'd like to question about. Why is the giving
> of a new name meaningful only when new memory is being allocated?
> The following is a bit longish explanation of my point. It would be a bit
> longish because I'd like to be very careful to make myself clear.
> (1) program main
> real aa(100)
> integer nn(100)
> ... use aa ...
> ... use nn ...
> Suppose you realize that you don't use aa and nn at the same time.
> Then you realize you economize on memory by modifying the above code
> to
Well, I already demonstrated how this could be done, slightly
indirectly but it can be done.
There are many things that Fortran could do, things that
other languages allow, but that it doesn't do. If it did
them, then it wouldn't be Fortran. I asked before about
conversion of subroutine arguments to the declared type,
which Fortran doesn't do.
It is not that it is impossible, or useless to allow
equivalence to dummy arguments, but just that Fortran
doesn't allow it. The rule is almost 50 years old.
There is less reason for the memory saving uses for
EQUIVALENCE every year, yet it is still allowed.
(snip)
> In (1), you use extra memory for nn, but not in (2). So you
> saved memory. Do you agree that this is one of the meaningful
> uses of equivalence? If so, let me proceed.
>
> (3) subroutine sub(aa)
> real aa(100) !! dummy
> integer nn(100) !! local array; allocates memory.
> ... use aa ...
> ... use nn ...
(snip)
Certainly this could work and could save memory. It is
not so likely to be used in a real program. I would only
expect it in cases where real values were later written
back to the array.
-- glen
| |
| Jim Giles 2004-11-21, 3:58 am |
| Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote in message news:<cno9ot$5vs$1@scrotar.nss.udel.edu>...
> Jim Giles wrote:
....
>
> You appear to confuse semantics with implementation. If something
> *appears* to be call-by-reference, then it has call-by-reference
> semantics -- irrespective of whether it is actually implemented as
> call-by-reference, or by copy-in/copy-out, or by a relay team of
> Mongolian yak herders. By 'call-by-reference semantics', I was simply
> referring to the fact that modifying a Fortran dummy leads to
> corresponding modifications in the true argument. Such behaviour could
> equally be described as 'copy-in/copy-out semantics', since the end
> result is the same.
I do not have any such confusion. I can write a formal semantic
description of Fortran's parameter passing (with a little brush-up
on the terminology). I could write formal descriptions of call
by reference and of copy-in/copy-out. They would be three different
descriptions. The fact that a change to the dummy argument leads
to a change to the corresponding actual argument is a property
of many parameter passing protocols, including call by name,
call by reference, and call by value/result. That doesn't make
them semantically the same - they just share one common property.
I know quite well the difference between semantics (the meaning
of a program language feature) and pragmatics (the implementation
of a programming language feature). You appear to have a very
loose idea of semantics. Call by reference and copy-in/copy-out
have the same end result in Fortran (but not usually in any other
language) not because they are semantically identical but because
Fortran has very careful rules disallowing programs that rely
on the differences between those two semantics. Too many people,
after hearing that "Fortran uses call by reference semantics",
assume that the semantic properties of that parameter passing
protocol may *all* be relied upon. It is misleading to users
and implementors) to try to use that terminology in describing
argument association in Fortran. The Fortran standard doesn't
directly mention either parameter passing protocol.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Ryo Furue 2004-11-21, 8:56 am |
| Ken Plotkin <kplotkin@nospam-cox.net> wrote in message news:
[...]
>
> Do you have a particular problem in mind where you think you need to
> do this? Or are you just getting your jollies by pursuing this
> question?
Thank you for your interest! The answers to your questions are:
I *had* a particular problem in mind when I *wanted* to equivalence
dummies. That was several years ago. I'm not using the code
any more. Right now, I'm just pursuing my curiosity.
In fact, earlier in this thread, I explained in what particular
situation I wanted to equivalence dummies and how I solved it
without equivalence with dummies:
http://groups.google.com/groups?dq=...-8%26oe%3Dutf-8
Since the posting I cite above is rather long-winded, here I post
a short example illustrating my problem at the time:
subroutine sub(aa) !! Say, N is a parameter constant, whose
real aa(2*N) !! defintion is elided for brevity.
complex cc(N)
equivalence (aa,cc) !! illegal.
... use aa ...
call complex_fourier_trans(aa) !! transform aa -> cc
... use cc's, which are aa's Fourier coefficients ...
call inverse_fourier_trans(cc) !! transform cc -> aa
... use aa ...
Since this was illegal, I had to use extra memory for the Fourier
coefficients. For example,
subroutine sub1(aa)
real aa(2*N)
complex cc(N) !! local array. Waste of memory.
... use aa ...
call complex_fourier_trans(aa) !! transform aa -> cc
forall(i=1:N) cc(i) = cmplx(aa(2*i-1),aa(2*i))
... use cc ...
call inverse_fourier_trans(cc) !! transform cc -> aa
forall(i=1:N) {aa(2*i-1) = real(cc(i)); aa(2*i) = imag(cc(i))}
... use aa ...
(Sorry, I used pseudo-Fortran to save space.) Since aa and cc were
never used at the same time, you *could* have economized on memory
if equivalencing dummies had been allowed as in the first illegal
Fortran code.
Fortunately, memory wasn't tight for the program I was writing,
I chose to waste memory.
I'm not saying equivalencing dummies was the only possibility to
save memory. But, I don't think legal alternatives are as clean as
the illegal solution I showed. (Could you come up with one, just
fun? :-)
Regards,
Ryo
| |
| glen herrmannsfeldt 2004-11-21, 8:56 am |
| Ryo Furue wrote:
(snip)
> http://groups.google.com/groups?dq=...-8%26oe%3Dutf-8
> Since the posting I cite above is rather long-winded, here I post
> a short example illustrating my problem at the time:
> subroutine sub(aa) !! Say, N is a parameter constant, whose
> real aa(2*N) !! defintion is elided for brevity.
> complex cc(N)
> equivalence (aa,cc) !! illegal.
> ... use aa ...
> call complex_fourier_trans(aa) !! transform aa -> cc
> ... use cc's, which are aa's Fourier coefficients ...
> call inverse_fourier_trans(cc) !! transform cc -> aa
> ... use aa ...
In recent years modular programming is becoming more
popular. If you could write the part between the two
FFTs in a separate subroutine, then you could pass
the real array to a subroutine and use a complex dummy.
(I believe that is legal, but it will take a while to
find it in the standard.)
Yes, there is the difficulty of assigning to part of a
complex variable.
-- glen
| |
| Ryo Furue 2004-11-21, 8:56 am |
| Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote in message news:
[...]
> Damn, I hadn't read your message through properly -- I see you weren't
> talking about equivalencing two dummy arguments, but instead a dummy
> argument and a local variable. Which makes a lot more sense.
Sorry I posted a reply to your previous message before reading this one.
Thanks for the followup! Now that we understand each other....
> Why this was forbidden, I'm not sure; but it may have something to do
> with the fact that although Fortran routines use *semantic* call by
> reference, the actual implementation is allowed to be done in just about
> any way -- including copy-in/copy-out. In fact, there are certain
> situations in Fortran 90/95 where such a copy-in/copy-out is strongly
> hinted at by the standard, I believe.
>
> With this in mind, can you imagine what a mess equivalence would be with
> a non-transparent call-by-reference implementation, such as
> copy-in/copy-out? Is the equivalence to the copy variable? Or to the
> original?
Yes, that's a very interesting point. I considered (a little bit about)
it before my original post which started this thread, but didn't find
what's difficult on the compiler's part. I thought that equivalencing
a dummy *could* be implemented as pointing exactly the same memory
as the dummy.
subroutine sub(aa, N)
real aa(N)
integer nn(N)
equivalence (aa,nn) !! illegal
aa(1) = 3.14 !! The value is assigned to *some* memory area.
nn(1) = 123 !! The value would be assigned to the *same* memory area.
If the argument is passed by copy-in, aa "uses" or "refers to" that copy.
Then nn would use the same memory as aa.
In short, if we decide that the local alias (nn in the above) would
always "use" the same memory as the dummy "uses", then we could implement
the equivalence without any difficulty. The actual argument can
be passed by a pointer, by copy-in, or even in a register. Doesn't matter.
If we always require that nn use the same memory as aa, the compiler can
easily do that. So I thought. What do you think?
Best regards,
Ryo
| |
| Rich Townsend 2004-11-21, 3:58 pm |
| Jim Giles wrote:
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote in message news:<cno9ot$5vs$1@scrotar.nss.udel.edu>...
>
>
> ...
>
>
>
> I do not have any such confusion. I can write a formal semantic
> description of Fortran's parameter passing (with a little brush-up
> on the terminology). I could write formal descriptions of call
> by reference and of copy-in/copy-out. They would be three different
> descriptions. The fact that a change to the dummy argument leads
> to a change to the corresponding actual argument is a property
> of many parameter passing protocols, including call by name,
> call by reference, and call by value/result. That doesn't make
> them semantically the same - they just share one common property.
>
> I know quite well the difference between semantics (the meaning
> of a program language feature) and pragmatics (the implementation
> of a programming language feature). You appear to have a very
> loose idea of semantics. Call by reference and copy-in/copy-out
> have the same end result in Fortran (but not usually in any other
> language) not because they are semantically identical but because
> Fortran has very careful rules disallowing programs that rely
> on the differences between those two semantics. Too many people,
> after hearing that "Fortran uses call by reference semantics",
> assume that the semantic properties of that parameter passing
> protocol may *all* be relied upon. It is misleading to users
> and implementors) to try to use that terminology in describing
> argument association in Fortran. The Fortran standard doesn't
> directly mention either parameter passing protocol.
>
Yep, you're right. I was referring to semantics at the very loosest
level; in fact, I meant nothing more than the common property that you
mention above. However, in a vain attempt to reclaim a shred of dignity,
can I pedantically point out that the (2003) standard *does* directly
mention copy-in/copy-out, in note 12.26.
cheers,
Rich
--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware
[ Delete VOID for valid email address ]
| |
| Jim Giles 2004-11-21, 8:57 pm |
| Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote in message news:<cnq5gf$mdc$1@scrotar.nss.udel.edu>...
....
> Yep, you're right. I was referring to semantics at the very loosest
> level; in fact, I meant nothing more than the common property that you
> mention above. However, in a vain attempt to reclaim a shred of dignity,
> can I pedantically point out that the (2003) standard *does* directly
> mention copy-in/copy-out, in note 12.26.
Note that notes are not normative. And in any case, the note
refers to the fact that the standard doesn't wish to force one
implementation strategy over another.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Rich Townsend 2004-11-21, 8:57 pm |
| Jim Giles wrote:
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote in message news:<cnq5gf$mdc$1@scrotar.nss.udel.edu>...
> ...
>
>
>
>
> Note that notes are not normative. And in any case, the note
> refers to the fact that the standard doesn't wish to force one
> implementation strategy over another.
>
And note the word "vain" in my remark above.
--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware
[ Delete VOID for valid email address ]
| |
| glen herrmannsfeldt 2004-11-22, 9:02 am |
| Ryo Furue wrote:
(snip)
> Sorry I posted a reply to your previous message before reading this one.
> Thanks for the followup! Now that we understand each other....
(snip)
> Yes, that's a very interesting point. I considered (a little bit about)
> it before my original post which started this thread, but didn't find
> what's difficult on the compiler's part. I thought that equivalencing
> a dummy *could* be implemented as pointing exactly the same memory
> as the dummy.
It could be, but that is not what was done in 1956, and it was
not changed since. (Is anyone working on a 50th birthday
party?)
For comparison, the C preprocessor can be used to rename
variable, and play other tricks with them. Though one
loses the C array syntax if applied to arrays. If one
wants the subscripts in the opposite order,
#define A(x,y) B[y][x]
can be used. Array offsets could be done, also.
The C union allows some of what EQUIVALENCE does, in allowing
two different variables to use the same storage, but it is
a little different in what is allowed.
PL/I has the DEFINED attribute, which can be used to
index arrays in different ways, but the variables are expected
to have the same type. I don't believe it can be used
between REAL and COMPLEX variables, though I am not sure
about that.
Note that EQUIVALENCE is symmetric. The two variables are
really equivalent. It is a little less obvious that can be
true when one is a dummy.
PL/I's DEFINED variables are not equivalent to the original,
among other things they can't be DEFINED again.
-- glen
| |
| Richard E Maine 2004-11-22, 3:58 pm |
| furufuru@ccsr.u-tokyo.ac.jp (Ryo Furue) writes:
> Yes, this is exactly what I'd like to question about. Why is the giving
> of a new name meaningful only when new memory is being allocated?
I don't believe that anyone has claimed that it wasn't meaningful.
If they did, then I missed that point in my admittedly quick skim
of the posts in this thread.
I thought you were trying to understand the original reasons (which as
many have said, long predate f77). If that is indeed your goal, then
you won't get there with the style of question you are asking. In asking
whether some *OTHER* possibility could have been meangful and useful,
I seriously doubt that you will make any progress at all towards
understanding the original reasons. All here are (I think) in agreement
that other posssibilities are meaningful... but that just isn't a
useful line to pursue for your stated goals.
If you really want much hope of understanding, I think you'll need a
little more thorough background than the isolated snippets you'll get
from this thread. Until you have a better feeeling for the general
language "culture" (as I might call it) of the time, there isn't much
hope of real understanding.
For example, consider a much simpler question. *MUCH* simpler. One
I bet you aren't even aware of; most Fortran programmers today aren't
because they have gotten used to at least f77. Recall again that the
basic equivalence rules mostly predate f77, so you have to understand
them in context of the pre-f77 "culture". Yes, it makes a difference.
You are asking whether some other possibilities might also be
meaningful. Then let's ask whether it might be meaningful to reference
an array element with something like, for one example, x(2+i). Bet
you didn't know that you can't do that (we are immersing ourselves in
a pre-f77 world, so f77 and later stuff doesn't count.) Nope. The
only forms allowed for array indices are forms like
2
i
i+2
i-2
3*i
3*i+2
3*i-2
where the 2 and 3 can be any (unsigned) integer literal, and the i can be
any integer variable. The above list of forms is very limitted, and is
very literal. No, it doesn't allow "equivalent" forms. In particular,
while i+2 is ok, 2+i is not. And the one that I recall running into
is that i+j is not ok. To do i+j, you need to make a separate temporary
variable for the index; lots of temporary variables in my f66 code to
work around things like this (and the even more strict limits on DO
loop index "expressions").
I think you need to get in a mindset to understand why the f66 standard
didn't allow 2+i or i+j here before you can address the far more
complicated question of why it doesn't allow equivalence of dummy args.
Reading the f66 standard would probably be instructive. Not just the
snippets that people cite here, but the whole standard. Snippets
don't immerse you in the mindset. The thing is only 24 pages long
(of actual text, excluding things like the foreward, contents, and
appendices), and it isn't particularly small print. Maybe that
siz enumber alone might help.
I'll repeat the 2 observations that I initially made. You appear to
have focussed on only one of them.
1. Equivalence appears to have been largely aimed at saving memory.
2. All equivalences were about static memory allocation.
You seem to have gotten point 1, and are asking about why it couldn't
apply elsewhere; of course, it could. But you seem to have missed
point 2 - or anyway, you haven't let the concept sink in. All the
equivalence rules are about static allocation. If you start asking why
they have to be, then you haven't "got" it yet - wrong question. They
don't have to be, but they are. Dummy arguments do not generally
involve static memory allocation. Therefore, they don't "fit" in the
mindset that equivalence is about static memory allocation.
I often regret even attempting to answer questions about why some
things were done. This thread illustrates my reluctance. The threads
so often turn into "well why wasn't it done some other way instead?"
That is *NOT* the same question (and is a much harder one to answer).
But that's what almost all of this thread seems to be about. Even most
of the attempts at "explanation" are going into what complications they
might imagine withh these other ways... Maybe I'm wrong, but I doubt
that such matters were even discussed, because I doubt that the question
was ever asked. If you start with the 2 observations I listed above,
then you won't ever get into asking questions about dummy arguments;
if you do get into it, then I think you missed the mindset because
you must have been trying to think about generalizing and abstracting
the ideas beyond the world of static allocation.
Now I'm all for generalizing and abstracting ideas. Some of the
application work I'm most proud of has involved abstracting things so
that they could then be applied to different problem domains than h | | |