Re: 991108.11 Fortran 90 arrays - a couple of questions

[Michael Eager <eager at eagercon dot com>]

First, it's a bit problematic to use the text of a proposal as if it
were the specification.  This can lead to misinterpretations.  The text in 
the specification, once it has been reviewed and edited, should be more
precise and unambiguous.  Implementation based on a proposal can be very
useful in that it may reveal problems or inconsistencies in the proposal.
But you are out on a limb and you take your chances.

I believe that the value of DW_AT_stride is the number of bytes between
array elements.  

The object referred to by the DW_OP_push_object_address is the address of
the object described by the current DIE.  I don't believe that it has the
interpretation you suggest, that it dereferences the top of the evaluation
stack in some fashion.  Perhaps Ron can explain the parenthetical comment
in the description.

"Knott, Martin" wrote:
> 
> Furthermore, I have a question concerning the use of DW_AT_stride. The
> proposal states that this attribute "specifies the number of bytes of memory
> between successive elements of the given dimension". However, our dope
> vector information contains a 'multiplier' field where the stride field is
> in the example, and we have an additional 'scale_factor' field:
> 
> struct desc {
>     void *base;
>     :
>     int scale_factor;
>     int flags;
>     struct dims_str {
>        long low_bound;
>        long upper_bound;
>        long multiplier;  // 'stride' field in proposal
>     } dims[7];
> }
> 
> This multiplier field is the number of elements between successive values.
> For example, if we have an array
> 
> integer A(low_1:upp_1,low_2:upp_2,low_3:upp_3)
> 
> then to calculate the address of A(i,j,k) we have
> 
> address of A(i,j,k) = base + [multiplier_1*(i-low_1) +
>                               multiplier_2*(i-low_2) +
>                               multiplier_3*(i-low_3)]*scale_factor
> 
> >From what I understand from the proposal:
> 
> address of A(i,j,k) = base + stride_1*(i-low_1) +
>                              stride_2*(i-low_2) +
>                              stride_3*(i-low_3)
> 
> Thus stride_1 = multiplier_1*scale_factor.
> 
> I would be grateful if you could clarify that this is the intended
> interpretation of the DW_AT_stride attribute.
> 
> If this is the case, I will have to use a Dwarf expression to multiply the
> multiplier or the scale_factor values together to obtain the required stride
> value since, in general, neither the multipliers or the scale_factor will be
> known at compile time.
> 
> One solution in the Dwarf would be compute the DW_AT_Stride value from the
> following Dwarf expression:
> 
> DW_AT_stride = DW_OP_push_object_address      # (1) Address of dope vector
>                DW_OP_plus_uconst 32           # (2) Locate value of
>                DW_OP_deref                    # (3) required multiplier.
>                DW_OP_push_object_address      # (4) Repeat to place the
>                DW_OP_lit12                    # (5) scale factor
>                DW_OP_plus                     # (6) on the stack,
>                DW_OP_deref                    # (7)
>                DW_OP_mul                      # (8) and multiply to get
> stride.
> 
> However, My problem is in understanding the definition of
> DW_OP_push_object_address in the proposal.
> 
> The proposal states that the object "may correspond to an independent
> variable or be a component of an array or record/struct/class [whose address
> is known only to the debugger as a result of earlier expression evaluation
> steps]".
> 
> Applied to the above Dwarf expression, does the phrase "earlier expression
> evaluation steps" imply that, at step (4), the effect of the
> DW_OP_push_object_address is to push the address of the result of step (3)
> on the stack? Or, would it have the effect of pushing the address of the
> original object (the dope vector) on the stack? The latter option would
> certainly be more beneficial to myself. Again I would appreciate some
> clarification of the proposal in this regard.
> 
> It must be noted that the scale factor is not always the same value as the
> size of the element type. For example,
> 
> program main
> 
>    type t_1
>      integer a
>      real b
>    end type
> 
>    type(t_1) s_1
>    integer, pointer, dimension(:) :: x
> 
>    x => s_1%a         ! (1)
> 
> end program main
> 
> The size of the element type for the pointer x will be 4 (as it will be an
> integer base type), whereas the scale factor will be 8 once the assignment
> (1) has been executed.
> 
> Thank you for your assistance.
> 
> Regards
> 
> Martin Knott
> 
> Edinburgh Portable Compilers Ltd
> 17 Alva Street
> Edinburgh
> Scotland


-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077