[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference rusure::math

Title:Mathematics at DEC
Moderator:RUSURE::EDP
Created:Mon Feb 03 1986
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2083
Total number of notes:14613

96.0. "Math Library and Microvaxen" by HARE::STAN () Wed Jul 25 1984 18:56

+---------------+
! d i g i t a l !    I n t e r o f f i c e    M e m o r a n d u m
+---------------+


To:  List                       Date:  23 July 1984

                                From:  Jeffrey C. Wiener
                                Dept:  Commercial Languages and Tools
                                Ext.:  381-2181    Loc.  ZKO2-3/K06
                                File:  HARE::[WIENER]REV2.RNO
                                TYPIST: JCW Rev.:  0

List (action): Linda Baillie, Ken Budnik, Ken Cowan, Diane Hess, Matt LaPine,
Pam Levesque, Farokh Morshed, Stan Rabinowitz, Jim Totton, Ned Anderson,
Joel Clinkenbeard, Rich Grove, Kevin Harris, Larry Kenah, Mary Payne


Subj: The impact of the microVAXen subsettings on the math component of the
VAX-11 Common Run-Time Library.





1  INTRODUCTION/HISTORY.

    The subsetting  of  the  VAX  architecture,  namely  the  microVAX
    subsets  (see  section  E.4 of the "DEC STD 032-0 VAX ARCHITECTURE
    STANDARD"), has had  an  impact  on  the  VAX-11  Common  Run-Time
    Library.   Before the introduction of the microVAX subsettings the
    math library was using the following "backup  data  type"  policy,
    which  was  based  on  D being the preferred double precision data
    type:

                    Old "Backup Data Type" Policy.
                    ------------------------------

         F floating point routines  may  only  use  D  floating  point
         instructions/routines  as  backup to gain better mathematical
         accuracy.

         G floating point routines  may  only  use  H  floating  point
         instructions/routines  as  backup to gain better mathematical
         accuracy.

    The initial microVAX subsetting was to include only the  F  and  G
    floating  point  data  types,  D  and  H were to be emulated.  The
    performance of any F data type math routine that used D as backup,
    or  any  G  data  type  math  routine  that used H as backup would
    therefore suffer from this emulation.  To avoid  this  undesirable
    performance  penalty  a  new "backup data type" policy was needed.

Math library changes.                                             Page 2
INTRODUCTION/HISTORY.


    Eight math routines were rewritten to conform to this new  "backup
    data type" policy.

                    New "Backup Data Type" Policy.
                    ------------------------------

         F floating point routines  may  only  use  G  floating  point
         instructions/routines  as  backup to gain better mathematical
         accuracy.

         D, G, and H floating point routines will not be backed up  by
         any other floating point data type.

    These new microVAXen routines are distinguished from their MTH$ or
    OTS$  counterparts by the prefix UVX$.  Now two math libraries are
    needed,  one  for  the  VAXen  and  another  for  the  microVAXen.
    Initially  the  RTL  group  thought  that  the UVX$ routines would
    replace their MTH$/OTS$ counterparts on the VAXen  when  G  became
    the   preferred   double   precision   data  type.   But  customer
    unhappiness with the use of G instead of  D  has  now  led  us  to
    believe  that  these  dual libraries may never go away.  This will
    cause some development and maintenance problems.

    Another set  of  RTL  routines  was  affected  by  the  microVAXen
    subsetting,  the  OTSCVT  routines.   Some  of  these routines use
    packed  decimal  instructions,  which  must  be  emulated  on  all
    microVAXen,  while others use both packed decimal instructions and
    D to back up F.  The former were rewritten to  remove  the  packed
    decimal  instructions;  these  new routines are being used on both
    the VAXen and the microVAXen due to  their  improved  performance.
    The  remaining OTSCVT routines were not modified; it was felt that
    the packed decimal instructions could not be easily removed, and a
    removal  of  the  D  backup  would  have  very  little performance
    enhancement relative to the time needed to do the  packed  decimal
    emulation.

    Finally,  to  accommodate  all   of   the   different   microVAXen
    subsettings  that  are  now in use, some have no floating point at
    all, some have F and G (microVAX I), some have F and  D  (microVAX
    I),  and  some  have  F,  D,  and  G  (microVAX II), the emulation
    facility routine has been rewritten to emulate all  four  floating
    point data types:  F, D, G, and H.

Math library changes.                                             Page 3
MTH$/OTS$ MATH ROUTINES.


    2  MTH$/OTS$ MATH ROUTINES.

    When the FG microVAX I was being developed the RTL group  found  8
    MTH$/OTS$ routines that used either D or H backup.  These routines
    are as follows:

             1. MTH$EXP             uses D floating backup
             2. MTH$SQRT            uses D floating backup
             3. MTH$SQRT_R2         uses D floating backup
             4. MTH$SINCOS(D)       uses D floating backup
             5. OTSPOWRR            uses D floating backup
             6. OTSPOWCJ            uses D floating backup
             7. MTH$GSINCOS(D)      uses H floating backup
             8. OTS$POWGG           uses H floating backup

    To speed up their performance on an FG microVAX I  these  routines
    were  modified  to  conform  to the "new backup data type" policy,
    that is, F routines would only use G backup and G  routines  would
    not  use  H  backup.   These  new UVX$ routines are used on the FG
    microVAX I.

             1. UVX$EXP             uses G floating backup
             2. UVX$SQRT            uses G floating backup
             3. UVX$SQRT_R2         uses G floating backup
             4. UVX$SINCOS(D)       uses G floating backup
             5. UVXPOWRR            uses G floating backup
             6. UVXPOWCJ            uses NO backup data type
             7. UVX$GSINCOS(D)      uses NO backup data type
             8. UVX$POWGG           uses NO backup data type

    Next came the announcement that there would be another microVAX I,
    this  one  an  FD machine.  The FD machine uses the VAXen routines
    rather than the new UVX$ routines.  For 5 of these 8 routines this
    makes  sense,  EXP,  SQRT,  SQRTR2, SINCOS(D), and POWRR all use D
    backup.  In the case of the G floating  routines,  GSINCOS(D)  and
    POWGG,  the  use  of  the  UVX$  routines  would  have  been  more
    appropriate, these routines do not need to emulate H instructions.
    It  is  true that if a user executes a G floating routine on an FD
    machine the user should expect that the G routine will run  slowly
    because of the need to emulate the G data type, but the user would
    not expect H floating emulation too.  Packaging considerations led
    to the use of the VAXen versions of the two G floating routines in
    question.  Finally, the UVX version of POWCJ should be used on all
    VAXen and microVAXen, the routine needs no backup data type and is
    faster than OTSPOWCJ on all machines.  It was  an  oversight  that
    this was not done.

    Which routines will be used on the microVAX II?  Why not  use  the
    UVX$  versions, these follow the "new data type" policy!  But what
    about our customers who prefer D over  G?   They  all  have  large
    databases  containing  lots  of  data  in  "D" format, and can not
    convert because they must maintain this information for concurrent

Math library changes.                                             Page 4
MTH$/OTS$ MATH ROUTINES.


    use/access  by 780s/750s/730s with only F and D hardware.  Also, I
    doubt that they would be pleased that the UVX$ and VAXen  versions
    of  a  given routine do not always return exactly the same values;
    their applications might give slightly different results on  their
    VAXen and their FG microVAX I and microVAXen II.

    As far as performance goes, except for the UVX$POWCJ routine,  the
    5  VAXen  F floating routines run faster on an FD machine than the
    corresponding UVX$ routines do on an FG machine.  The  performance
    difference  is  not  that  great  and  can be accounted for by the
    differences in converting an F floating point value to a  D  or  G
    floating point value:

             ; Let R0 contain an F floating point value.
             ; Convert R0 to a D floating number

                     CLRL   R1       ; Takes 0.60 microsec with no FPA

             ; Let R0 contain an F floating point value.
             ; Convert R0 to a G floating number

                     CVTFG  R0, R0   ; Takes 1.60 microsec with no FPA






    3  LACK OF PACKED DECIMAL INSTRUCTIONS ON MICROVAXS.

    The routines  OTSCVTRT.MAR  and  OTSCVTDT.MAR  use  the  following
    coding sequence at least once.

             CVTLP
             CVTPS
             SKPC

    This instruction sequence must  be  emulated  on  all  microVAXen,
    resulting in very poor performance.  These routines were rewritten
    to remove the above coding sequence (they now use EDIV and a table
    look-up).    Performance   tests  showed  that  the  VAX  780  was
    performing faster with the new routines too.  With  this  in  mind
    the  old  versions  of  OTSCVTRT and OTSCVTDT were replaced by the
    newer versions.

Math library changes.                                             Page 5
LACK OF PACKED DECIMAL INSTRUCTIONS ON MICROVAXS.


    3.1  OTS$CVT Routines.

    The F floating OTSCVT routines that presently use D floating point
    backup are as follows:

             1. OTSCVTFP_R9
             2. OTSCVTPF_R9
             3. OTSCVTRFP
             4. OTSCVTTF

    I was not privy  to  the  reasons  why  these  routines  were  not
    replaced  by  their  UVX$  counterparts.  The first three routines
    listed above all use packed instructions.  It might have been felt
    that  the  D dependency in these routines was only a small part of
    the emulation overhead.  The  OTSCVTTF  routine  converts  a  text
    string  containing  a  representation  of  a numeric value to an F
    floating representation of that value.  The routine supports F, E,
    D,  and G input type conversion as well as similar types for other
    languages.  I am not  sure  why  this  routine  does  not  have  a
    microVAXen  counterpart, unless it was felt that the users of this
    routine are mainly D data type users.

    A more plausible reason for the lack of  UVX$  versions  of  these
    routines is as follows:

         All the VAXen math routines, both  MTH$  and  OTS$  routines,
         reside  in  MTHRTL.   When  the  appropriate  microVAXen UVX$
         versions  were  written  a  new  UVMTHRTL  was  created;  the
         routines  in  UVMTHRTL  have  the same set of entry points as
         those in MTHRTL; The LINKer  gets  the  appropriate  library.
         Since the OTSCVT routines reside in LIBRTL instead of MTHRTL,
         creating UVX$ versions of these  routines  would  demand  the
         creation  of  a  UVLIBRTL.   Getting  the  LINKer  to get the
         appropriate library might not be feasible.  A  discussion  of
         the  two  math  libraries,  what they are and why they are as
         they are will be contained in a memo entitled "The  Math  RTL
         problem" by Matt LaPine.

    A copy of this memo will be available soon by contacting either me
    or Matt.  Matt and I hope to merge our memos in the near future.

Math library changes.                                             Page 6
OPEN QUESTIONS AND POSSIBLE SOLUTIONS.


    4  OPEN QUESTIONS AND POSSIBLE SOLUTIONS.


    1.  Will a third math library be needed to  support  microVAX  II?
        No new routines would need to be written, but a repackaging of
        the VAXen and UVX$ routines would be needed.

          o  Use the VAXen math library.  It will  satisfy  the  large
             users  who prefer D over G.  Except for the FG microVAXen
             I, all VAXen and microVAXen will  return  the  same  math
             values.   The draw back to this solution is that we would
             be  delaying  the  use  of  G  as  our  preferred  double
             precision data type.

          o  Use the UVX$ library.  Digital  would  be  following  its
             goal  of  replacing  D  by  G  as  the  preferred  double
             precision data type, and no G  routine  would  require  H
             emulation.  The FG microVAXen I and the FDG microVAXen II
             would return the same math values, but these values might
             differ  from  those  returned  on  the  VAXen  and the FD
             microVAXen.

          o  Use the VAXen library for all  F  routines  and  the  UVX
             library for all G routines.  Except for the FG microVAXen
             I, all VAXen and microVAXen will  return  the  same  math
             values  for  F  floating point routines.  For G routines,
             the FG microVAXen I  and  the  FDG  microVAXen  II  would
             return  the  same  math  values,  but  these values might
             differ from those  returned  on  the  VAXen  and  the  FD
             microVAXen.   It  is  not  at  all clear that this can be
             accomplished.   For  more  discussion   read   the   last
             paragraph  in  3.1  and  Matt LaPine's memo "The Math RTL
             Problem".


     2.  What if anything will be done about the VAXen  and  UVX$  not
         returning  exactly  the  same  mathematical  values?   If the
         results are to agree, which  routine,  VAXen  or  UVX$,  gets
         modify?   Will  the  solution  to  this  problem fit into the
         notion of upward compatibility?

          o  We will accept the fact that the VAXen and UVX$  routines
             might  not  return  exactly  the  same values.  This will
             violate the notion of upward compatibility.

          o  The  routines  should  give  the  same  results.    Which
             routine(s)  is  modified  might depend upon how much of a
             performance penalty would be felt in  modifying  a  given
             VAXen/UVX$  routine  to agree with its "clone"; we do not
             want to pay a high performance  penalty  on  any  of  the
             architectures.

Math library changes.                                             Page 7
OPEN QUESTIONS AND POSSIBLE SOLUTIONS.


          o  Do not permit any backup data type usage in any routines.
             This  would  be  a very long term effort.  not only would
             the backup data type need to be removed, but at least the
             same  degree  of  accuracy  and  about the same degree of
             performance would be necessary.


     3.  If the VAXen  and  UVX$  routines  return  exactly  the  same
         mathematical  values,  will a third math library be needed to
         support microVAX II?

          o  Alternative 2 in OPEN QUESTION 1 seems to be the  way  to
             go, that is, use the UVX$ routines.


     4.  Why isn't H used to backup the D and G  routines?   H  for  F
         too!

          o  Using H to backup F,D, and G routines would automatically
             solve  the  problem  of different architectures returning
             different math values.  However, at the present time this
             is  not  feasible;  H  is  too slow and only supported by
             emulation on many machines.


     5.  Should the four OTSCVT routines in 3.1 be modified to replace
         D backup with G backup?

          o  The answer to this question might depend  upon  who  uses
             these routines.

          o  All the VAXen math routines, both MTH$ and OTS$ routines,
             reside  in  MTHRTL.  When the appropriate microVAXen UVX$
             versions were written a new  UVMTHRTL  was  created;  the
             routines in UVMTHRTL have the same set of entry points as
             those in MTHRTL; The LINKer gets the appropriate library.
             Since  the  OTSCVT  routines  reside in LIBRTL instead of
             MTHRTL, creating UVX$ versions of  these  routines  would
             demand the creation of a UVLIBRTL.  Getting the LINKer to
             get the appropriate library might  not  be  feasible.   A
             discussion  of  the two math libraries, what they are and
             why they are as they are will  be  contained  in  a  memo
             entitled "The Math RTL problem" by Matt LaPine.


     6.  How  are  enhancements  to  existing  routines  to  be  made.
         Suppose  that  an  F floating point routine presently uses no
         backup data type.  An enhancement to this  routine  could  be
         made  by using a backup data type.  Which backup data type do
         we use?

Math library changes.                                             Page 8
OPEN QUESTIONS AND POSSIBLE SOLUTIONS.


          o  Just use G for backup, D will no longer be used.  I doubt
             that this is either practical or desirable.

          o  Just use D for backup.  Not a good choice  either;  G  is
             suppose  to  be  our  choice  for a double precision data
             type.

          o  Create two new routines.  One will use D for  backup  and
             the  other  will  use G.  This seems to be the way to go.
             Note that we will pay a price for the  extra  development
             time,  maintenance and testing that will be needed.  Also
             see items 7 and 8 below.

          o  Only make enhancements that do not require the use  of  a
             backup  data type.  It does not seem logical not to use a
             higher data type to help improve accuracy,  reduce  space
             requirements,    and    increase    performance.    Would
             development time increase too!

          o  Use H to backup F,D, and G.  At  the  present  time  this
             alternative   can  not  be  taken  due  to  the  required
             emulation of  H  on  many  architectures,  and  the  slow
             performance of H in general.


     7.  Is it better to make enhancements to math  routines  that  do
         not  require  the  use  of  a backup data type.  Consider the
         following following scenario:

             You have two possible ways to improve the accuracy of an
             F floating point routine MTH$x which presently uses no
             backup and has a least significant bit error, LSB error,
             greater than one:

                1. Create a new MTH$x with D backup AND a dual UVX$x
                   with G backup, both with an LSB error less than one.

              or

                2. Create a new MTH$x with no backup, an LSB error
                   less than one, but not as accurate as case 1.

             To avoid creating two routines option 2 seems desirable.
             When should option 2 be rejected? Option 2 will most
             likely require more memory to be expended; when is this
             not desirable. Should performance be a measurement for
             which option is chosen?

          o  Create a version using a backup data type (either D or G)
             and  a  version  with  no  backup  data  type  used.  Run
             accuracy tests and performance tests.  Use some  sort  of
             guidelines  to decide which alternative to take, that is,

Math library changes.                                             Page 9
OPEN QUESTIONS AND POSSIBLE SOLUTIONS.


             use no backup or create two  new  routines,  one  with  D
             backup  and  one  with  G  backup.   This  seems like the
             logical alternative, but what are the performance, space,
             and  accuracy  guidelines that are needed to decide which
             option to take?

          o  The use of H as  a  backup  data  type  for  F,D,  and  G
             routines  would ease our dilemma.  Now it would only be a
             case of using H backup or no backup.  As stated above, we
             are not in a position to use H as a backup data type.


     8.  Assuming that we want the VAXen and UVX$ routines  to  return
         the same mathematical values, how can we be sure that they do
         return exactly the same results?

          o  You will not be able to prove  that  they  always  return
             exactly the same values.

          o  Use one universal backup policy for both libraries.


T.RTitleUserPersonal
Name
DateLines
96.1HARE::STANTue Jul 31 1984 20:34267
+---+---+---+---+---+---+---+
| d | i | g | i | t | a | l |       I n t e r o f f i c e   M e m o r a n d u m
+---+---+---+---+---+---+---+



To:     RTL Group                               Date:   31-Jul-1984
                                                From:   Matt LaPine
cc:                                             Dept:   Languages & Tools
                                                Ext:    381-2201
                                                Mail:   ZKO2-3/K06
                                                Net:    TURTLE::LAPINE

Subj:   "The MTHRTL Problem"





    1  SOME HISTORY

         Before MicroVAX, all VAX processor implementations used  F_floating
    and D_floating as the default single and double-precision floating point
    data types.  Unless  optional  G_  and  H_floating  point  hardware  was
    purchased,  G_  and  H_  floating  instructions  would  be  emulated  in
    software.

         A  version  of  MicroVAX  I  offers  G_floating  as   the   default
    double-precision floating point data type (referred to commonly as an FG
    MicroVAX I).  This means  that  D_  and  H_  floating  instructions  are
    emulated.



    2  THE PROBLEM

         Unfortunately   the   above   situation   had   grave   performance
    implications  for  the  MTH$  facility in the Run-Time Library.  Certain
    MTH$ (and OTS$) routines must promote calculations to a higher precision
    (backup) floating point data type in order to achieve adequate accuracy.
    Usually, this would mean promoting from F_ to D_floating,  but  if  this
    was  done  on  a  MicroVAX  with  G_floating  hardware,  the  D_floating
    instructions would be emulated,  and  the  resulting  performance  level
    would be unacceptable.



    3  THE ORIGINAL SOLUTION


                                                                          Page 2


         3.1  The Accepted Solution

         It was decided that the best solution to  the  performance  problem
    was  to  have  two  seperate  MTHRTL's,  each with the same set of entry
    points, but with one, MTHRTL, using D_floating as  the  backup  floating
    point data type, and the other, UVMTHRTL, using G_floating.

         There would remain a single entry in IMAGELIB  for  MTHRTL,  but  a
    boot  time  decision  would  be  made  whether or not to redirect MTHRTL
    references to UVMTHRTL.  On a VAX family processor  with  G_floating  as
    the  default  double-precision  floating  point  data  type  instead  of
    D_floating (an FG MicroVAX I for example), a system logical  name  would
    be defined:

        MTHRTL  =  SYS$SYSROOT:[SYSLIB]UVMTHRTL.EXE

         This would instruct programs referencing MTHRTL routines to execute
    the  G_floating  versions in UVMTHRTL instead of the original D_floating
    versions in  MTHRTL,  and  thus  gain  better  performance  by  avoiding
    emulation of D_floating instuctions.



    3.2  The Rejected Solution

         An alternate suggestion was to have the affected routines perform a
    $GETSYI  service upon entry to determine the current floating point data
    types, and then to branch to the appropriate code accordingly.   A  flag
    could  be  used  to  ensure  that  this  was  only  done  once per image
    activation.  This alternative was attractive because  it  preserved  the
    idea  of  a  single  math  library  (MTHRTL)  containing a single set of
    routines.  Unfortunately, the overhead of  invoking  $GETSYI  even  once
    would  introduce  an  unacceptable level of performance into MTHRTL, and
    thus this solution was rejected.



    4  THE PROBLEM THAT THE ORIGINAL SOLUTION CAUSED

         As we know, IMAGELIB is the library of  all  the  shareable  images
    that the LINKer will search to resolve external references.  Entries for
    all of the RTL shareable images (with the exception of VMSRTL) reside in
    IMAGELIB.   Now,  each of these entries contain (among other things) the
    GSMATCH and the creation date and time (CDT) that IMAGELIB  expects  the
    image  associated  with that entry to have.  The LINKer will check to be
    sure that IMAGELIB copy and the actual image copy of GSMATCH and the CDT
    are  the  same;  if they are not, the LINKer will report an error when a
    user attempts to LINK a program.

         There is no way to make sure that the creation  date  and  time  on
    MTHRTL  and  UVMTHRTL  is  the  same;  therefore, if UVMTHRTL instead of
    MTHRTL is used via the  logical  name  mechanism  described  above,  the
    LINKer will report DATMISMATCH errors for any program linked against it.
    Clearly, reporting an error whenever a user attempts to LINK  a  program
    is unacceptable.

                                                                          Page 3


    5  THE SOLUTION TO THE DATMISMATCH PROBLEM

         5.1  Specification

         It was agreed to make a small change in the LINKer; the high bit of
    the  Major  ID  field  of GSMATCH would be used as a flag to the LINKer.
    This flag would instruct the LINKer NOT to perform the creation date and
    time check described above.  We would simply then set this bit in MTHRTL
    and UVMTHRTL via the LINKer options file and relink the images.



    5.2  Implementation

         Unfortunately, this change did not  make  it  in  for  FT2  of  VMS
    version 4; there was some misunderstanding of which bit was the high bit
    in GSMATCH.  The change had to be included for MicroVMS version 1, so it
    had  to  be  put into the FT2 Update.  Once clarification as to what bit
    was the  high  bit  in  the  Major  ID  was  obtained,  the  appropriate
    modification  in  the  LINKer  options files was made and new MTHRTL and
    UVMTHRTL images were provided for the FT2 Update.



    6  WHAT ELSE HAD TO CHANGE

         A new problem was introduced.  The Image Activator, as well as  the
    LINKer,  is  concerned  with  GSMATCHes  in shareable images.  A list of
    shareable images referenced, along  with  expected  GSMATCH  values,  is
    contained in the image header of any (normal) image.  If the Major ID of
    a MTHRTL  a  user  has  previously  LINKed  an  application  against  is
    different  from  the  Major ID of the current MTHRTL (i.e., the expected
    GSMATCH for MTHRTL in the user's image  header  is  different  from  the
    GSMATCH of the current MTHRTL), the Image Activator will detect that and
    will not run the application.  Any image that  has  a  reference  to  an
    entry  point  in MTHRTL (UVMTHRTL) is affected.  Relinking such an image
    so that the new GSMATCH value is reflected in the shareable  image  list
    in  the  image  header  will  correct  the  problem.  Alternatively, the
    expected GSMATCH value for MTHRTL in the application image header may be
    PATCHed.



    6.1  VMS Components

         It turned out that several VMS components were affected; SET, SHOW,
    ERF  and UETP just to name a few.  Instead of re-linking all of them, it
    was decided to simply PATCH the expected GSMATCH  value  for  MTHRTL  in
    their image headers.  The appropriate PATCH command files were generated
    and added to the FT2 Update kit.



    6.2  VMSRTL

         VMSRTL is a glaring example of an  image  that  references  MTHRTL.
    Programs linked in version 3 or before reference MTH$ symbols in VMSRTL;

                                                                          Page 4


    as we know, for version 4, VMSRTL is  simply  a  "stub"  that  transfers
    control to MTHRTL or any of the 6 other shareable images that VMSRTL was
    broken up into.  VMSRTL was relinked, and a new copy placed on  the  FT2
    Update  kit.  Had this step not been done, any program linked in version
    3 or before would not have run.



    6.3  User Programs Referencing MTHRTL

         Any user program that has a reference to MTHRTL would  need  to  be
    relinked.   The  only  way  that  this  could happen is if a program was
    linked since the beginning of VMS version  4  Field  Test.   Thus,  only
    Field  Test customers were affected, and they would have to relink their
    affected programs.



    6.4  Layered Products Referencing MTHRTL

         BASIC and FORTRAN were identified as the only layered products that
    ship  an image and that reference MTHRTL.  PATCH command files for their
    image headers were also generated and placed on the FT2 Update kit.



    7  WHAT DIDN'T BREAK AND WON'T BREAK

         It should be kept in mind that because we have  provided  a  VMSRTL
    that knows about the new GSMATCH in MTHRTL, version 3 and older programs
    (linked against VMSRTL) will continue to run.  This means that a typical
    customer,  upgrading  from  version  3 to version 4, will be unaffected.
    Relinking in this case will not be necessary; all programs will continue
    to activate and run correctly.



    8  FUTURE RISKS

         8.1  OTS$ Conversion Routines

         There are several OTS$ conversion routines that use D_floating as a
    backup  for  F_floating;  however,  these routines reside in LIBRTL, not
    MTHRTL.  As such, a special version of LIBRTL  (UVLIBRTL,  perhaps)  may
    have  to  be generated in the same fashion as for MTHRTL in order to get
    better performance on VAX family  processors  that  emulate  D_floating.
    There  is  a  problem  with adding a new LIBRTL, however.  It is now too
    late to change anything for VMS version  4.0;  that  means  that  if  we
    introduced  a  new UVLIBRTL at some point beyond version 4.0, there will
    already be user programs linked against LIBRTL.  Recall,  the  Major  ID
    field  of  GSMATCH  in  the  image header has to change in order to have
    interchangeable RTL images.  This means that user images would  have  to
    be  either  re-linked or patched in order to continue to be able to run.
    An alternative would be to make a change to the Image Activator  similar
    to  the  LINKer  change  already  made.   This  change  would need to be
    coordinated so as to be released concurrently with the new RTL images.

                                                                          Page 5


    8.2  Floating Point Hardware On Future VAX Processors

         Also, future VAX family  processor  implementations  may  have  any
    combination  of F_, D_, G_ and/or H_floating point hardware.  This means
    that additional MTHRTL images (and possibly LIBRTL images) tuned to  the
    particular  hardware  instructions  of  a  processor, may be required in
    order to maintain adequate performance on some of these machines.



    8.3  Maintenance Problems

         There are some maintenance headaches the RTL Group will incur as  a
    result  of making "custom" copies of RTL images (i.e., MTHRTL, UVMTHRTL,
    xyzMTHRTL).



    8.3.1  Duplicate Routines -

         Because of the duplicate code strategy,  there  are  now  duplicate
    copies  of  several  MTH$ routines.  Anytime one of them is changed, the
    duplicate must be checked to see if the change is required in  it  also.
    Otherwise,   different  behavior  could  result  depending  on  the  VAX
    processor a program is run on.



    8.3.2  Entry Masks -

         The UVX$ routines must have the same identical entry masks as their
    MTH$  counterparts.  Thus, if a change to a duplicate routine requires a
    change to the entry mask, it's counterpart must  have  it's  entry  mask
    changed also, or users will receive unpredictable results.
96.2TURTLE::GILBERTTue Jul 31 1984 23:3649
Re: "The MTHRTL Problem" (memo dated 31-Jul-1984)

Let's assume that performance considerations require different code (paths)
on the various machines.  Choosing the appropriate code path could be done
at one of the following times: installation, system startup, image link,
image activation, or routine invocation.

1.  At installation time,
	Patch the shareable image, to either adjust the transfer vector, or
	Set a flag.

2.  At system startup,
	Either define a logical name to reference the appropriate image, or
	Set a flag.

3.  At image link time,
	Either reference the appropriate image, or
	Adjust the transfer vector, or
	Set a flag.

4.  At image activation time,
	Either reference the appropriate image (via a logical name), or
	Adjust the transfer vector, or
	Set a flag.

5.  At routine invocation time,
	Check a flag.

Apparently, only choices 2 and 4 (with logical names), and 5 (with a very
expensive flag) were considered.

Choice 3 has the disadvantage that layered products that ship as images
would not use the appropriate shareable image.

Choice 4 allows the cost of a $GETSYI only once per image activation, rather
than once per routine invocation.  Note that LIB$INITIALIZE could be used.

Note that the "flag" mentioned above could be made read-only (this would allow
the code that references it to be PIC).  Or, the code could reference the flag
indirectly, so that there's just one fixup to be resolved at image activation.

Choice 2 is done, in part.  The flags that $GETSYI references to determine which
instructions are emulated are set at system startup, and could be accessed by
the math shareable image, if it's acceptable to link it against SYS.STB.

There are a wide variety of choices.  Unfortunately, only the worst two were
considered.  That is why a bad choice was made.

					- Gilbert
96.3HARE::LAPINEWed Aug 01 1984 16:4970
The memo I wrote was an attempt to document what had transpired.  All of
the choices you mentioned were indeed considered, though they may not
have been mentioned in the memo.  The choice that was made is not
necessarily a great one, but unfortunately it is the ONLY viable one.

Taking your suggestions one at a time:

1. Installation time.

	If we change the image at installation time, then the image will
	be bound to a particular system; kitbuilding will yield a system
	pack that will not perform properly on other configurations.
	This is unacceptable.

2. System Startup.

	This is essentially part of what was done.

3. Image Link time.

	This is what happens as a result of 2 (above).  The appropriate image
	is referenced by virtue of a logical name, however, it is not
	necessary, as the transfer vector for both MTHRTLs is identical.
	There is no transfer vector adjustment to perform.
	Effectively, the logical is only needed at run time, but because it
	is there, the LINKer uses it too.

	It is NOT TRUE that layered products that ship as images reference
	the wrong image.  No matter what machine you link on, you end up
	with a reference to MTHRTL if you reference MTH$ symbols.  Whether
	a reference to MTHRTL is redirected to UVMTHRTL.EXE by virtue of
	a logical is transparent to the image.

	MTHRTL is in IMAGELIB.  UVMTHRTL is not, regardless of configuration.
	It is only referenced by virtue of a logical.

4. Image Activation time.

	This is also what happens as a result of 2 (above).  Either MTHRTL.EXE
	or UVMTHRTL.EXE will be activated, depending on the setting of the
	system logical MTHRTL.  Again, the transfer vectors for the 2 images
	are identical.  There is no adjustment to perform.

	The idea of using LIB$INITIALIZE on MTHRTL is useless when you recall 
	that people can link /NOSYSSHR.  In that case, the flag will never be
	set when it should be, and either (1) improper performance/results
	will be yielded, or (2) the situation will have to be handled at
	routine invocation time (see below).

	Further, image activation time for images referencing RTL routines
	is already 2-3 times slower (on the average) in version 4 than in
	version 3; using LIB$INITIALIZE would add even more overhead into 
	the activation time.  This would introduce an unacceptable level
	of performance.

5. Routine Invocation time.

	The only viable way to make the decision as to which code path to
	take at this point is to: (1) check a flag, (2) if not set, then
	call $GETSYI, and (3) branch accordingly.  This adds too much 
	overhead and introduces an unacceptable level of performance into
	such routines as MTH$SQRT and MTH$GSINCOS, and is why it was rejected
	and outlined as such in my memo.

There were really only two choices.  One adds more maintenance load, makes
life more difficult for the LINKer, but maintains adequate performance.  The
other is clean, but introduces an unacceptable level of performance.

Performance is a major issue in VMS version 4; clearly it was the more
important factor in arriving at a decision.