PE> zatest.obj(ZATEST.C) :  warning L4008: aliased fix-up to non-alias 
 PE>                                    object near 22 in object CODE32


 Area Os2prog, Msg#1973, Oct-01-93 20:23:20
    From: Keith Medcalf
      To: Peter Fitzsimmons
 Subject: strstr Limits?

 On Sep 30 15:14, Peter Fitzsimmons of 1:250/292 wrote:

  KM>> Keith Medcalf
  KM>> Toronto Labs CSet++ Support

  PF> Now for a question:  Can you verify for me that linker warning L4008 can
  PF> be ignored?  Someone at the IBM tech interchange said so,  I am just
  PF>
  PF> double checking.

  PF> As in:

  PF> loadsql.obj(loadsql.c) :  warning L4008: aliased fix-up to non-alias
  PF>    object near B in object SEG16T__err_handler

 Yes.  I checked this one myself because all _Far16 declared functions
 generate it so I asked the back-end team to tell me why.  Apparently, early
 versions of CSet++ created an ALIAS for 16:16 entry points where the actual
 function code and entry point were declared in a CODE16 segment.  This CODE16
 segment was an ALIAS for a range in a code32 segment, and the linker did
 fixups between the aliased code and the non-aliased code.

 Somewhere along the beta's this design changed in the compiler, and CSet now
 generates a standard prologue and epilogue around the function in the CODE32
 segment, and provides a 16:16 'stub' which points does a far16 call into the
 16 bit segment.  This improved performance and kept all the code running in
 CODE32 rather than in CODE16.  In fact, when you declare an _Far16 function,
 you are just telling the compiler to create some extra code in 16:16 address
 space that can 'transport' the call to the 32-bit segment.  There is no
 longer any aliasing of segments.

 Since the actual external symbol refers to the 16:16 entry point, and other
 modules refer to this symbol, the linker is expecting to be able to generate
 a fixup to the CODE32 alias rather than jumping into 16:16 code.  Since there
 is no alias, it emits the warning; however, the code still works as expected
 because the linker does a correct fix up anyway.

 As an aside, the code path to call a 16:16 function from 0:32 code is four to
 fifteen times longer than the equivalent near call between 0:32 functions.
 This just covers the prologue thunking.  If pointers must be thunked and
 checked, it will get longer.  We actually had a caller who had benchmarked
 the differences between various calls between the various code segment types.
  On average a 0:32 call to a 16:16 function took 4 times longer than a call
 to a 0:32 function (from 0:32 code), and a call from 0:32 code to a 0:32
 function was just over twice the speed of a call from 16:16 code into 16:16
 code.  We verified these figures.

 Does this mean OS/2 could run twice as fast or more if the 16:16 code were
 removed?  Now I have actually seen solid benchmarks that show that mixed
 16/32 code runs several times slower than either pure segmented or pure flat
 code.

 Keith

--- Maximus/2 2.01