[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| 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 15: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.R | Title | User | Personal
Name | Date | Lines |
|---|
| 96.1 | | HARE::STAN | | Tue Jul 31 1984 17:34 | 267 |
| +---+---+---+---+---+---+---+
| 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.2 | | TURTLE::GILBERT | | Tue Jul 31 1984 20:36 | 49 |
| 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.3 | | HARE::LAPINE | | Wed Aug 01 1984 13:49 | 70 |
| 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.
|