Conference turris::pascal

2670.0. "Multple PSECT contributions in same module - expected layout?" by GIDDAY::GILLINGS (a crucible of informative mistakes) Fri May 02 1997 00:11

  A customer is querying a difference in behaviour between VAX and Alpha
  compilers in the placement of variables in a named PSECT when there are
  multiple variables with the same PSECT attribute. Consider the following
  program:

program test( input, output );
type
  big_record = record
    big1  : array [ 1..20000 ] of integer;
    big2  : array [ 1..5000 ] of boolean;
    end;
  sml_record = record
    sml1  : array [ 1..20 ] of integer;
    sml2  : array [ 1..5 ] of boolean;
    end;
var
  a1 : [ psect( buffer_section ), aligned(13), global ] big_record; { first add
  a2 : [ psect( buffer_section ), global ] sml_record;
  a3 : [ psect( buffer_section ), global ] integer;         { last address }
begin
writeln( 'This is the address of a1=', hex( iaddress( a1 ), 16 ) );
writeln( 'This is the address of a2=', hex( iaddress( a2 ), 16 ) );
writeln( 'This is the address of a3=', hex( iaddress( a3 ), 16 ) );
writeln( 'The size of big_record=', size( big_record ) );
writeln( 'The size of sml_record=', size( sml_record ) );
end.

  The customer is assuming that the variables a1, a2 and a3 will be allocated
  to the PSECT in that order (his intention is to map thye PSECT to a
  global section, so a3 will be used to calculate the end address of the
  section). This is how the VAX compiler behaves, regardless of optimization:

$ pas/lis/show=struc/obj=psect_vax psect ! ignore PASCAL-W-ALIGNINT message
$ link/map/full psect_vax$ run psect_vax
This is the address of a1=        00000200
This is the address of a2=        00014E08
This is the address of a3=        00014E60
The size of big_record=     85000
The size of sml_record=        85
$ pas/lis/show=struc/obj=psect_vax psect/noopt
$ link/map/full psect_vax$ run psect_vax
This is the address of a1=        00000200
This is the address of a2=        00014E08
This is the address of a3=        00014E60
The size of big_record=     85000
The size of sml_record=        85

  However, on Alpha the compiler seems to vary the order depending on
  optimization:

$ pas/lis/show=struc PSECT
$ link/map/full psect
$ run psect			=> A2,A1,A3
This is the address of a1=        00032000
This is the address of a2=        00030000
This is the address of a3=        0004C000
The size of big_record=    100000
The size of sml_record=       100
$ pas/lis/show=struc/noopt PSECT
$ link/map/full psect
$ run psect			=> A3,A1,A2
This is the address of a1=        00032000
This is the address of a2=        0004C000
This is the address of a3=        00030000
The size of big_record=    100000
The size of sml_record=       100

  Now, I can't find anything in the documentation which states how multiple
  contributions to the same PSECT can be expected to behave, so to my mind
  the compiler is free to do it however it likes. Further, since the PSECT
  attributes include CON, things will be further complicated if there are
  other modules making contributions to the same PSECT.

  I think that if the customer wants a specific layout, he should state it
  explicitly. For example:

var	a : [ psect( buffer_section ), aligned(13), global ] RECORD
  		a1 : big_record; { first address }
  		a2 : sml_record;
  		a3 : integer;         { last address }
	END {RECORD}

  Even with this scheme he can retain his existing code by enclosing the
  whole program in a "WITH a DO BEGIN END" statement.

  So, if I'm correct, this is another case of a port from VAX to Alpha
  revealing an implicit dependence on coincidental VAX compiler behaviour.
  Can anyone from Pascal engineering confirm or deny? Perhaps someone could
  explain the logic behind the allocation order on Alpha?

						John Gillings, Sydney CSC

    Your assessment is 100% correct.  There is no guarantee of the
    order of the allocation.  You're alternative of the record is the
    correct one.
    
    As for "why".  On VAX, the compiler just allocates the each static
    variable as it finds them.  On Alpha, I suspect GEM allocates them
    based as to "where" they appear in the code stream (and different
    levels of optimization may affect that) as well as some sorting
    on their size and frequency to help get the best layout of the
    pointers in the linkage section, but I'm just guessing...  If you
    are really curious, I can try to find out a real answer.  Let me
    know.
    
    				-John

The GEM back end on Alpha gives a front end a choice on how to layout
psects.  The front end can do the entire layout itself or the front
end can leave the decision up to the back end.

Languages, like BLISS, which require a particular layout must do the
psect allocation in the front end.  If a language wants to allow the
back end to attempt to optimize the layout of the psect then the
allocation can be done by the back end but an optimized layout depends
on how the data is used.  It sounds like Digital Pascal should be
using the same allocation strategy that BLISS uses rather than allowing
GEM to optimize the psect layout.

    Except for a some rare cases with the /OLD_VERSION qualifier on
    VAX (note that the /OLD_VERSION isn't on Alpha), the compiler has
    always been free to choose the order of PSECT allocation.
    
    I don't think I want to change it/document it now.
    
    				-John