Open System Services Porting Guide (G06.24+, H06.03+)
Table Of Contents
- What’s New in This Manual
- About This Manual
- 1 Introduction to Porting
- 2 The Development Environment
- 3 Useful Porting Tools
- 4 Interoperating Between User Environments
- Purpose of Interoperability
- The OSS User Environment
- OSS Commands for the Guardian User
- Guardian Commands for the UNIX User
- OSS Pathname and Guardian Filename Conversions
- Running the OSS Shell and Commands From TACL
- Running Guardian Commands From the OSS Shell
- Running OSS Processes With Guardian Attributes
- Using OSS Commands to Manage Guardian Objects
- 5 Interoperating Between Programming Environments
- 6 OSS Porting Considerations
- 7 Porting UNIX Applications to the OSS Environment
- 8 Migrating Guardian Applications to the OSS Environment
- General Migration Guidelines
- C Compiler Issues for Guardian Programs
- Using New and Extended Guardian Procedures
- Using OSS Functions in a Guardian Program
- Interoperating With OSS Programs
- Starting an OSS Program From the Guardian Environment
- C Compiler Considerations for OSS Programs
- Porting a Guardian Program to the OSS Environment
- How Arguments Are Passed to the C or C++ Program
- Differences in the Two Run-Time Environments
- Which Run-Time Routines Are Available
- Use of Common Run-Time Environment (CRE) Functions
- Replacing Guardian Procedure Calls With Equivalent OSS Functions
- Which IPC Mechanisms Can Be Used
- Interactions Between Guardian and OSS Functions
- 9 Porting From Specific UNIX Systems
- 10 Native Migration Overview
- 11 Porting or Migrating Sockets Applications
- 12 Porting Threaded Applications
- A Equivalent OSS and UNIX Commands for Guardian Users
- B Equivalent Guardian Commands for OSS and UNIX Users
- C Equivalent Inspect Debugging Commands for dbx Commands
- D Equivalent Native Inspect Debugging Commands for dbx Commands
- E Standard POSIX Threads Functions: Differences Between the Previous and Current Standards
- Glossary
- Index
Native Migration Overview
Open System Services Porting Guide—520573-006
10-5
User Library Migration Issues
There are significant benefits to using the native C and C++ compilers. They compile
code faster than the TNS compiler and the Accelerator or Object Code Accelerator,
and may produce faster code. The native C and C++ cross compilers run in the
Guardian and OSS environments, as well as on the HP Enterprise Toolkit—NonStop
Edition (ETK) and, for G-series systems only, on the HP Tandem Development Suite
(TDS) on a PC. For more information on using the ETK on a PC, refer to the ETK
online help. For more information on using the TDS on a PC, refer to the C/C++
Programmer’s Guide or to the TDS online help.
The native linkers, nld, ld, and eld replace the Binder in native development
environments; they link object files to produce an executable file. Native object files
can be read from an archive file produced by the ar utility as well as from files
specified on the c89 command line. Virtually identical parameters for nld, ld, and
eld are supported in the Guardian environment as in the OSS environment.
The native object file tools, noft and enoft, can be used to display all parts of native
object files, such as headers, program text and data (source and object), symbol table
and components, run-time procedure table, relocation tables, and run-time data units.
noft and enoft can be used to generate cross reference information for procedures.
Again, they support virtually identical Guardian and OSS interfaces.
TNS/R native programs can be debugged using the same PC-based Visual Inspect or
command line Inspect debuggers used to debug TNS programs. TNS/E native
programs require the use of Visual Inspect or Native Inspect; Native Inspect is entirely
different from Inspect (Inspect on TNS/E systems cannot be used for TNS/E native
debugging). You should also be aware of a few differences in moving from TNS
interpreted and TNS accelerated debugging to optimized native debugging. Unlike
accelerated code, TNS environment registers do not exist in native code. Variables
might remain in registers and never be written to memory. Native C compilers support
three levels of optimization:
•
0 for no optimization
•
1 for most optimizations, good performance
•
2 for full optimizations, about a 15-percent decrease in processor path length over
1
Optimization modes 0 and 1 support symbolic debugging.
The native C compilers can be directed to accept C source files conforming to
Kernigan and Ritchie (K&R) C or Common C in addition to ISO/ANSI C. However, HP
does not provide a complete set of header files that conform to K&R C. The user must
modify existing header files or obtain files from another source to compile K&R C
source files.
User Library Migration Issues
User libraries are supported in the native environments as well as the TNS
environment. C, C++, and pTAL programs can have a user library; that is, an object file
that the operating system links to a program file at run time.