Open System Services Porting Guide (G06.29+, H06.06+, J06.03+)

• On J-series or H-series systems, the Visual Inspect debugger can be used to debug 32-bit
programs compiled with the Guardian TNS or TNS/E native compilation components and
with the OSS TNS/E native compilation components.
• On J-series or H-series systems, the Visual Inspect debugger can be used to debug TNS/R
snapshot files that were generated on a G-series system and transferred to a J-series or H-series
system.
In addition to these debuggers, the noft utility can be used to view TNS/R native object files. The
enoft utility can be used to view TNS/E native object files. See Chapter 2 (page 31), and the
noft Manual and the enoft Manual for more information about using noft and enoft.
Memory and Data Models in TNS and Native Environments
Table 10 shows the combinations of memory models and data models available in the TNS and
native environments. Both Guardian and OSS programs can use these memory and data models
on TNS and native systems, except that the TNS/E OSS environment does not support TNS
processes.
Table 10 Memory and Data Models in TNS and Native Environments
pointer size
2
long sizeint size
Data Types
SummaryModel Directive
Data
Model
Memory
Model
1
Architecture
16 bits32 bits16 bitsIP16L32noxmemN/AsmallTNS
32 bits32 bits16 bitsI16LP32(default)nowidelargeTNS
32 bits32 bits32 bitsILP32widewidelargeTNS
32 bits32 bits32 bitsILP32(default)wideN/ATNS/R and
TNS/E
64 bits64 bits32 bits(I32)LP64lp64LP64N/A64-bit TNS/E
OSS
3
1
The TNS C compiler supports two memory models, one of which supports two data models. The net effect is three
programming models: The small model has global data, heap, and stack in one segment limited to 128 KB. The large
and wide models place the heap as well as some local and global data in a separate segment of up to 128 MB. The
TNS/R and TNS/E compilers support only 32-bit int, and they use a separate reservation for the stack and place global
data and heap at the beginning of the 32-bit address space that is allotted for flat segments. (For information about
memory segments, see the Managing Memory chapter in the Open System Services Programmer's Guide.)
2
In all three TNS models, the compiler accepts explicit pointer qualifier _near or _far to specify the width (16 or 32
bits). The TNS/R and TNS/E C/C++ compilers also accept (but disregard) those qualifiers when extensions are enabled.
The TNS/E native compiler accepts pointer qualifier _ptr32 or _ptr64.
3
Beginning with the H06.24 and J06.13 RVUs, the TNS/E C/C++ compiler optionally supports 64-bit OSS programs,
widening long and default pointer types to 64 bits and moving the default heap to a much larger area in 64-bit address
space. For information about these data types and 64-bit addressable memory, see the 64-Bit Support in OSS and
Guardian chapter in the Open System Services Programmer's Guide.
If you are porting Guardian programs that use the small-memory or large-memory model, you will
have to convert your code to use large-memory model and the 32-bit (or wide) data model. General
guidelines for doing this conversion are discussed in:
• Chapter 10 (page 170)
• TNS/R Native Application Migration Guide.
• TNS/E Native Application Conversion Guide
Header Files
A single set of C library header files supports both the Guardian and OSS environments. In the
Guardian environment, header files are in $SYSTEM.SYSTEM by default. In the OSS environment,
140 Migrating Guardian Applications to the OSS Environment