On Tue, 16 Dec 2003 10:10:16 -0800, Richard Maine <[log in to unmask]>
wrote:

>Jim Riley wrote:
> > Would set X(51) to 123., but its effect on I(51) would be undefined.
>
>and Bill Long replied:
> > Actually, the *effect* on I(51) is well defined by the standard. I(51)
> > becomes undefined.
>
>Of course, to fully appreciate Bill's (accurate) comment, you need
>to understand how the standard defines "undefined". I'm tempted
>to add a smiley...except that the question is real and nontrivial.

If an undefined variable is used where a defined variable is required,
isn't the program non-conforming? And if a program is non-conforming does
the standard define what will happen?

What I was really saying that setting the value of a datum of one type,
would have no defined (by the standard) effect on a datum of another type
that it shares a numeric storage unit with. That is, if an Integer I and
Real X were equivalenced, then setting the value X would leave no bit
residue for I.

Couldn't I realize my Fortran storage as text representing Fortran
constants (the syntax of constants denotes their type). So in the
following code:

    REAL X
    INTEGER I
    EQUIVALENCE (X,I)

Would initially set the value of I and X to ' ' (i.e. undefined).

    I = 2

This would set the value of I and X to '2' (which is not a valid value for
X).

    X = I + 2

This would set the value of I and X to '4.0E0' which is not a valid value
for I. If the code then had a:

    WRITE (UNIT=*, FMT=*, IOSTAT=ISTAT) I

My processor could set ISTAT to a positive non-zero value.

A program could not rely on this behavior, but it would be a reasonable way
for that processor to handle that non-conforming program.


Alternatively, I could realize a numeric storage unit as a sequence of bit
fields:

   1-1: Logical
   2-33: Integer
   34-65: Real
   66-145: Double Precision

Double Precision values would be stored in the 80 bits of a storage unit,
and 0 bits of the next storage unit. A storage sequence could hold both an
odd and even array of Double Precision values.

So if I had:

    REAL X
    INTEGER I
    EQUIVALENCE (X,I)

    I = 2

This would set the integer field of the storage unit to 2 .

    X = I + 2

This would set the real field of the storage unit to 4.0E0 .

    WRITE (UNIT=*, FMT=*, IOSTAT=ISTAT) I

This particular processor might print

    2

Even though I is undefined at that point in the program.


The next step would be to convert a storage sequence from a sequence of
4-field elements to 5 sequences of single-field elements of different
lengths (there would be two sequences of double precision values of 1/2 the
length). I could eliminate the parts of the sequences that aren't declared
in the program (IIUC, the only way to have mixed type storage sequences is
through Common association and Equivalence association which are all
resolvable when the program is compiled).

    REAL X(3)
    INTEGER I(5)
    EQUIVALENCE (X,I)

Would create a storage sequence of 5 145-bit storage units, which would be
converted to a 5 element 1-bit Logical array, a 5-element 32-bit Integer
array, a 5-element 32-bit Real Array, a 2-element 80-bit Double Precision
array (corressponding to I(1:2) and I(3:4)), and a 2-element 80-bit Double
Precision array (corresponding to I(2:3) and I(4:5)). I could discard the
Double Precision and Logical arrays, and the last 2 elements of the Real
array.

The tricky part would be if I had something like:

    INTEGER I(3)
    REAL X,Y
    EQUIVALENCE (I(1), X)
    EQUIVALENCE (I(3), Y)

If these were local declarations, I could separate the storage of X and Y
only storing 2 reals, rather than 3 reals. But if there was also a common
declaration:

    COMMON /COM/ I

I would have to worry about something like this in another program unit.

    INTEGER I(3)
    REAL Z(3)
    EQUIVALENCE (I, Z)
    COMMON /COM/ I

>To other matters..note that the cases mentioned are very simple ones
>because of their homogeneity. You don't have to get very complicated
>at all before valid implementation strategies get severely
>constrained. The non-obvious ones start needing to get very messy.
>Consider (assume implicit typing)
>
> subroutine sub1
> common /com/ x(3),i,y,j
> save /com/
> y = 123.4
> j = 567
> ...
> end
>
> subroutine sub2
> common /com/ i(3),x,y,j
> save /com/
> ...
> end
>
>The assignments to y and j in sub1 will cause y and j in
>sub2 to be defined (and being defined is a much less tricky
>concept in the standard than being undefined is).

The linker could generate code that could get the actual address of the
variables. Even in a conventional implementation, it would have
to get the base address of the common for use with fixed offsets generated
by the compiler. A whole set of addresses for each variable used in
program unit shouldn't be that much more difficult.

>It is certainly posible in theory for a compiler to implement this
>with separate storage areas for reals and integers. Whether it is
>practical is a different matter - I'd guess not.

The toughest practical aspect might be handling the expectations of
programmers that non-conforming use of equivalence and commons would work
in a certain way (e.g to reduce the use of memory, to implement structures,
to map to certain external data layouts, to allow precice definition of
floating point values).

--
Jim Riley