|
Four major porting
challenges were encountered.
Architectural differences among OpenVMS VAX, Alpha, and I64 were the
leading cause, followed by limitations of the Bliss-32 language dialect. Mistakes were made on several occasions,
introducing both subtle and not-so-subtle bugs, not all of which were
immediately detected during regression testing.
- Differences in the calling standards were
especially problematic, and accounted for two of the four challenges; see the
first and third items below.
Using a transfer
vector and fetching data from a known stack layout for VAX had to be replaced
by using a bound procedure descriptor and specially-written Macro-64 transfer
routine for Alpha, and by using a bound function descriptor, a new
OpenVMS-provided transfer routine, and special linkage for I64.
An internal
context-switching package had to be changed out to match the one used by ACMS
on each of the architectures. On VAX and
Alpha, this package had to be implemented in low-level assembly language, using
detailed knowledge of the respective calling standards and stack layouts. On I64, the implementation was greatly
simplified by making use of the new OpenVMS-provided user-mode KPS routines.
- Differences in the object file formats accounted
for another of the four challenges; see the second item below.
The Alpha object file
format is somewhat different from, yet almost completely analogous to, the VAX
object file format. The I64 ELF object
file format is driven by a cross-platform industry standard, so it is very
different from its predecessors.
However, the addition of OpenVMS-specific extensions makes the new
format completely suitable for building ported software.
- Differences in 64-bit integer math
implementations, combined with a lack of Bliss-32 language support for these
multiply and divide operations, accounted for the last challenge; see the
fourth item below.
The solution
ultimately chosen was to provide these operations using routines written in a
language that fully supports them; in this case, HP C.
1. Context Passing: Application Function Key (AFK) Asynchronous System Traps (ASTs)
VAX TDMS implements context passing for AFK ASTs by providing
a transfer vector consisting of an entry register save mask and a jump
instruction with address fix-up at the start of each context data structure.
The AST routine then fetches the context from a known relative offset on the
stack.
Over several months in late 2001, with some guidance from
OpenVMS Engineering and the Calling Standard documentation, this context
passing mechanism was ported to Alpha TDMS. The VAX transfer vector was
replaced with an Alpha bound procedure descriptor at the start of each context
data structure. A short Macro-64 transfer routine provides the context address
(bound procedure descriptor address from R27) to the AST routine as the sixth
actual argument in R21. The argument count (low byte of AI/R25) is also filled
in with the value six. Names and attributes of code program sections are
specified so that the linker places the transfer routine code immediately
before the AST code, eliminating two instructions (load and jump). This results
in an efficient implementation of AFK ASTs that is compatible with the Alpha
calling standard. Please refer to section 2.2.2 of the release notes for
further details.
Over about ten days in early 2003, with further guidance from
OpenVMS Engineering, a similar mechanism was used for I64 TDMS, which was
actually simpler to implement. The Alpha bound procedure descriptor was
replaced by the I64 bound function descriptor. A transfer routine called
OTS$JUMP_TO_BPV is already provided by OpenVMS I64, specifically for use with
bound function descriptors. The context is passed to the AST in R9 by
specifying special linkage.
Over a few days in late 2004, regression testing uncovered a
problem with the bound function descriptor, which was corrected. Please refer
to section 2.6.3 of the release notes for further details.
2. Object File Generation: Form Development Utility (FDU) Form Editor (FED) Memory-Resident Forms
VAX TDMS implements memory-resident forms for the FDU form
editor. A utility program called FDVCDDOBJ is used to package each TDMS form
from the Common Data Dictionary (CDD) into an OpenVMS VAX object file. The
linker then arranges the forms into a linked list in the FDU program.
Over about one week in May 2001, FDVCDDOBJ was easily
converted to generate object files in the OpenVMS Alpha format. The VAX and
Alpha object formats are very similar.
Over about one month in April and May 2003, with some
guidance from OpenVMS Engineering, FDVCDDOBJ was converted to generate object
files in the OpenVMS I64 (ELF) format, which is very different, and
considerably more complex. Also, ELF initially
did not provide support for Link-Time Complex Expressions (LTCEs), and this
support was not added until after the porting work on FDVCDDOBJ was completed.
The TDMS source code now compiles correctly for any of the
three recognized target platforms: VAX, ALPHA, or IA64.
3. THD Component
VAX TDMS implements a simple form of "threading"
(actually more like context switching using co-routines) with its THD
component, which is very similar to (and very compatible with) the ACMS
product's THD component on OpenVMS VAX.
From late May through late November 2001, an attempt was made
(with reasonable success) to re-implement TDMS THD using POSIX threads, a.k.a.
pthreads, formerly DECthreads. This also required extensive changes for
thread-awareness. Not much effort was expended to investigate or test for
potential thread-safety issues.
Very early during initial field test, this implementation had
to be abandoned (or at least set aside), in order to provide interoperability
with the ACMS product on OpenVMS Alpha. Please refer to section 3.23 of the
release notes for further details.
Fortunately, ACMS Engineering kindly provided its ACMS THD
OpenVMS Alpha source code. Over about one week in November 2001, this was
incorporated into Alpha TDMS.
From mid-May through mid-November 2003, possible strategies
were discussed with the ACMS and OpenVMS Engineering groups, for porting the
THD component to OpenVMS I64. On a few occasions, attempts were made to perform
some of this porting work.
As OpenVMS Engineering had advised, ACMS Engineering ported
its ACMS THD to OpenVMS I64, using the newly-enhanced OpenVMS KPS routines, and
again kindly provided the source code for I64 TDMS THD. Very little low-level
machine language was required for this new implementation, aside from the
OpenVMS KPS routines themselves.
This improves on the VAX and Alpha THD implementations, which
require much more of their own Macro-32 and Macro-64 source code.
The I64 THD also appears to be highly portable to OpenVMS
Alpha V8.2 or higher. In the event of any compelling need, it could most likely
replace the existing Alpha THD.
Within one day in June 2004, the ACMS I64 THD was easily
"dropped" into I64 TDMS.
4. 64-Bit Integer Math
The VAX TDMS source code was written almost entirely in
Bliss-32, a language dialect that has no direct support for multiply and divide
operations on 64-bit integers. OpenVMS date conversions make use of 64-bit
integers. VAX TDMS performs divide and multiply operations on these by calling
the undocumented COB$DIVQ_R8 and COB$MULQ_R8 COBOL language support run-time
library routines with special JSB linkage.
These routines are not available for the use of native
OpenVMS Alpha applications. The initial attempt during April 2001 to replace
them with in-line Bliss-32 code did not work properly. Please refer to section
2.2.10 of the release notes for further details.
One day in January 2002, the DIVQ and MULQ replacement
routines were implemented in C for Alpha, but unfortunately with coding errors
that went undiscovered for about a year, even during intensive field testing.
One day in January 2003, in response to a problem report from
a very alert HP employee and OpenVMS Ambassador (now an alumnus) in Ireland,
these coding errors were finally corrected, along with two other software problems
that had interfered with some of the date conversions. Please see section
2.2.14 of the release notes for further details.
Porting to I64 did not require any further changes to these
routines
|
