Silverfrost Forums

Welcome to our forums

Equivalence statement

12 Aug 2011 5:02 (Edited: 18 Aug 2011 9:56) #8797

Hi,

I have been debugging someone else's code and have the following question regarding the EQUIVALENCE statement used there;

Can someone please explain what it is supposed to mean? The equivalence statement here?

12 Aug 2011 7:20 #8798

What it means in EQUIVALENCEing control and kontrol is that they share the same physical addresses in the computer RAM – i.e. they start at the same address. As each is 8 bytes long, and there are 512 of them, it marks out a block of storage that is 4k bytes long. Sometimes this 4k will hold REAL8 values, and sometimes, INTEGER8 values. This sort of thing was done in the past. Nowadays, you could ALLOCATE 4k, use it to hold REAL8 values, then DEALLOCATE it, ALLOCATE 4k again to store INTEGER8 values and so on. You would take pot luck as to whether you got the same physical memory, but it would work all the same.

My guess is that it is used to store REAL8 values at a different time to when it stores INTEGER8 values, as you can’t store in one way and read back in the other.

The other EQUIVALENCE uses the first 80 bytes to store characters – again, the same memory block is being used, but almost certainly not at the same time. As you have so much memory these days, you could simply comment-out the EQUIVALENCE statements and it would probably work OK. (Sometimes you can’t).

This is a trick to cope with being short of RAM – a real problem in the distant past.

There are other uses for EQUIVALENCE. Hopefully you won't encounter them ...

Eddie

15 Aug 2011 4:32 (Edited: 18 Aug 2011 9:56) #8799

But, i get junk values for realarray(3) and realarray(4) inspite of the equivalence. Why is it so?

15 Aug 2011 5:08 #8800

Try this:

      program CheckEquivalence           

      integer*8 intarray(4) 
      real*8 realarray(4) 
      
      equivalence(realarray,intarray) 
      
      realarray(3)=3 
      intarray(4)=4 
      
      realarray(1)=1.0 
      realarray(2)=2.0 
      
      do i=1,4     
      write(*,*)'All real  ',realarray(i)       
      enddo 

      do i=1,4       
      write(*,*)'All int   ',intarray(i)       
      enddo      

      do i=1,3       
      write(*,*)'Some real ',realarray(i)       
      enddo
      write(*,*)'Last int  ',intarray(4) 
      
      end

In your Fortran, you assigned 3 to realarray(3). The compiler makes that into 3.0D0, and the program wrote the byte pattern for that into bytes 17-24. You set the first two realarray values to REAL constants, and the compiler again, correctly, made the program store these as 1.0D0 and 2.0D0 respectively. However, you assigned 4 to intarray(4). That's fine as it goes. However, the byte pattern for '4' as an INTEGER is likely to be something like:

0000000 00000000 00000000 00000100

which interpreted as a REAL*8 is 0.0D0 (well perhaps 0.0 x 2^4, which comes to the same thing).

If you interpret the byte patterns as INTEGER*8, the 4th set of bytes (25 to 32) is correct, and the first 3 sets are nonsense. The WRITE statement takes the set of bytes and interprets them as the correct type for the variable.

You clearly don't understand the huge difference between the way INTEGER and REAL are stored, and if you want to mix them up like you have done, then you do it at your own peril. Even in the depths of the past when people did regularly EQUIVALENCE arrays of different type, it was a way of using the space effectively. Only the addresses are EQUIVALENT, not the contents!

Regards

Eddie

15 Aug 2011 5:18 (Edited: 18 Aug 2011 9:57) #8801

Last int 4

Please login to reply.