DDC-I now offers TADS hosted on PC Windows (NT 4.0 or higher, including 2000 Professional and XP Professional). Many of our existing TADS customers are now migrating to a windows hosted environment – a move that also involves a product version upgrade (v6.x). This article describes the following issues that may be encountered in such a migration:
Differences in code generation (object files)
Differences in tool usage (command line syntax)
Changes in the Run-Time System (RTS)
Reuse of an existing RTS customized under v4.x or v5.x
Reuse of existing Universe, Project, and Library database files
Migration from VAX/VMS to PC/Windows
Migration from Sun/Solaris to PC/Windows
Migration from v4.x to v6.x
Migration from v5.x to v6.x
Target-specific issues
Migration to the Windows host platform can offer significant benefits in ease of use and maintainability. DDC-I actively supports the TADS product for the 1750a, 68xxx and i960 targets, and periodically releases updated versions containing improvements and “bug” fixes.
How similar are the object files?
TADS Windows v6.x was derived from the Solaris hosted TADS v5.2.3 toolset, with only host related changes being made. This implies that compiler and linker generated files should be identical. This is in fact the case...almost. The only noted difference is in the compiler generated labels, which should pose little concern. Customers coming from an earlier version (e.g. v5.1) should expect almost identical generated object files taking into account any differing code generation resulting from “bug” fixes in intermediate versions. For a more detailed description of the fixed problems, please refer to chapter four of the appropriate “Getting Started” manual. The most apparent difference in the generated object files is the byte ordering. All .tof and .xtof files are host-dependent with regards to byte ordering. VAX and Intel platforms are “little-endian”, while Sun platforms are “big-endian”. For example, comparison of a TADS Windows v6.x generated object file with a TADS Solaris v5.x generated object file would require the latter object file be reordered via the TADS reorder utility. The reorder utility simply reorders the host-dependent bytes in the specified object file. See further below for information regarding TADS v4.x object files.
How different is the tool usage and how will it impact current build scripts?
TADS Windows v6.x supports command-line options from both the VAX/VMS and Solaris tools. This dual support of command-line option syntax simplifies the porting of existing build scripts to Windows batch files. One difference is with the invocation of the tools. Since TADS Windows v6.x was derived from TADS Solaris v5.2.3, the Solaris naming conventions were reused. The following example shows what a complete sample build script from VAX/VMS would look like on Windows:
------------------------------------------------------------------------------
$! This is an example script using TADS VAX/VMS 1750a v5.x
$ set noon
$ al17 create project hanoi_prj [.prj_dir]
$ al17 create library hanoi_prj:hanoi_lib [.lib_dir]
$ tada/1750a /debug/suppress=all/library=hanoi_prj:hanoi_lib hanoi.ada
$ al17 link /library=hanoi_prj:hanoi_lib hanoi
$ exit
------------------------------------------------------------------------------
@echo off
rem This is an example script using TADS PC/Windows 1750a v6.x
adalib1750a create project hanoi_prj prj_dir
adalib1750a create library hanoi_prj:hanoi_lib lib_dir
tada1750a /debug/suppress=all/library=hanoi_prj:hanoi_lib hanoi.ada
adalib1750a link /library=hanoi_prj:hanoi_lib hanoi
------------------------------------------------------------------------------
Regardless of legacy host, minor adjustments to build scripts may be needed to accommodate host-specific issues, such as directory paths and filenames.
Are there differences with the librarian sub-commands?
The TADS Windows v6.x librarian also has dual support to accept either the Solaris or VAX/VMS sub-command or option syntax via the command-line or interactively.. The following example illustrates an invocation of the TADS librarian:
A new GUI was introduced in TADS Sun/Solaris v5.2.3, bringing the functionality of AdaScope to a user-friendly environment. This newly introduced interface is provided in TADS PC/Windows v6.x. If AdaScope is executed in line mode, then it will behave as did the TADS v5.x AdaScope. The AdaScope sub-commands have not been modified, providing the user a familiar debug environment. Command scripts can be reused, but they need to be modified to compensate for any host related issues (e.g. serial ports).
Can initialization files be reused?
Both the TADS librarian and TADS debugger use optional initialization files. These can be reused, with minor modifications. Reuse of TADS v5.x initialization files simply require any host related data to be modified (e.g. directory paths). Reuse of TADS VAX/VMS v5.x initialization files require an additional step of renaming the initialization files, because the TADS Solaris naming conventions were followed. The librarian initialization file from VMS, adalib.ini, should be copied to .adalibrc and the debugger initialization file from VMS, adascope_init, should be copied to .adascoperc.
Have there been any changes to the runtime system or debug directives?
No, there have been no changes to the runtime system (RTS) or debug directives from v5.x to v6.x. Existing VAX/VMS object files, generated with TADS v5.x tools, can be reused with TADS v6.x. Note that reuse of object files generated with TADS Solaris v5.x tools, requires the object files to be reordered. See further below for information regarding RTS changes since TADS v4.x .
Can a customized runtime be reused?
A v5.x customized runtime can certainly be reused. If the customized runtime to be reused was created with TADS VAX/VMS v5.x, then it can be reused as is. If the customized runtime to be reused was created with TADS Solaris v5.x, then the objects files will have to be extracted, with your existing TADS v5.x object file librarian. The object files will then need to be reordered using the TADS v6.x reorder utility. Finally the runtime library will have to be reassembled using the TADS v6.x object file librarian. See further below for information on reusing a TADS v4.x customized runtime.
Can the Project and Librarian database files be reused?
No. These database files are host specific and must be recreated on the new host.
Can a TADS v4.x project be migrated to v6.x?
Almost everything stated above holds true for customers wishing to migrate a TADS v4.x project to v6.x, except the answers pertaining to reuse of existing object files and customized runtimes. There were major modifications to the debug directives and runtime system with TADS v5.1. The new format of the debug directives provides better debugging of optimized code. All of the runtime modifications were to allow for the new debug directive formats and Ada95 support. The runtime supported Ada95 features include priority queuing and protected objects. If the runtime has been heavily configured or customized under TADS v4.x, then it can be reused as long as no debugging is required and no usage of TADS supported Ada95 features are introduced. In general, object files compiled under TADS v4.x should be recompiled under v6.x to assure compatibility.
Are there any target-related issues, which arise when migrating from TADS v4.x to v6.x?
The only other target related improvement made, other than ones the previously mentioned, was to the 1750a Expanded Memory product (Static and Full), in regards to long calls or cross-segment calls support. The TADS v4.x 1750a product had a deficiency in this area, which was corrected in TADS v5.1. For the i960, both Small Virtual Mode and Physical Mode are fully supported. Full Virtual Mode for i960, available in v4.x, is no longer offered. All 68xxx runtimes are fully supported.
Is migrating to TADS Windows v6.x worth the effort?
This is a very important question. DDC-I has strived to minimize any differences in the systems, therefore migrating to TADS v6.x will require a small amount of effort. Scripts must be edited, sources must be recompiled, executables must be relinked and tested. Through every step of this transition, DDC-I will be there to provide support. When questions arise, DDC-I will respond promptly and effectively. If problems are encountered, DDC-I will address them in future upgrade releases. Work-arounds or patches may be provided for critical problems. In conclusion, not only does TADS v6x. provide a bridge to a newer, less expensive platform, but it is backed up by DDC-I’s uncompromising support.
Customer Quote:
"You have talented and dedicated people working for you. They are superlative. DRS appreciates their efforts and I personally am most grateful to be working with such an excellent group."
