SAS/C Cross-Platform Changes for Release 7.50

Release 7.50 Enhancements to the SAS/C Cross-Platform Compiler

New Options Summary

Compiler Options summarizes all the new cross-platform compiler options. This table is an extension of the table labeled, "Compiler Options" in Chapter 3, "Compiling C and C++ Programs."

The option specifications are listed in the first column of the table. The second column indicates whether the option can be negated. An exclamation point (!) means that the option can be negated. A plus sign (+) means that the option cannot be negated.

Compiler Options
Option Negation Default Description

-Karchlevel=let
!
-Knoarchlevel Specifies 390 architecture.

-Kasynsig
!
-Kasynsig Specifies the detection of asynchronous signals when exiting from a function.

-Kbfp
!
-Knobfp Specifies IEEE floating point format.

-Kcoverage
!
-Knocoverage Activates the COVERAGE feature of the compiler.

-Kc99subset
!
-Knoc99subset See description.

-Khugeptrs
!
-Knohugeptrs Specifies 64-bit addressing.

-Khxref
!
-Knohxref Prints references in standard header files in the cross-reference listing.

-Kiccp
!

Call the CICS traslator before compiling.

-Kixref
!
-Knoixref Prints references in user header files in the cross-reference listing.

-Kmpsafe
!
-Knompsafe Specifies safe asynchronous signals for nonMP configurations.

-Knofriendinject
!
-Kfriendinject
For C++ compilations: Disable the creation of visible names for friend class and function declarations.

-Koptions
!
-Koptions Specifies options listing.

-Koldforscope
!
-Knooldforscope
For C++ compilations: Use the old scoping rules for variables declared in the initialization clause of a for statement.

-Kstkbelow
!
-Knostkbelow Allocates stack below the 16M line.

-Kstmap
!

Requests a map of structure elements.

-Kwarn
!
-Knowarn Causes the compiler warning messages to be printed.

***Compiler Options***
Option	Negation	Default	Description
`-Karchlevel=let`	`!`	-Knoarchlevel	Specifies 390 architecture.
`-Kasynsig`	`!`	-Kasynsig	Specifies the detection of asynchronous signals when exiting from a function.
`-Kbfp`	`!`	-Knobfp	Specifies IEEE floating point format.
`-Kcoverage`	`!`	-Knocoverage	Activates the COVERAGE feature of the compiler.
`-Kc99subset`	`!`	-Knoc99subset	See description.
`-Khugeptrs`	`!`	-Knohugeptrs	Specifies 64-bit addressing.
`-Khxref`	`!`	-Knohxref	Prints references in standard header files in the cross-reference listing.
`-Kiccp`	`!`		Call the CICS traslator before compiling.
`-Kixref`	`!`	-Knoixref	Prints references in user header files in the cross-reference listing.
`-Kmpsafe`	`!`	-Knompsafe	Specifies safe asynchronous signals for nonMP configurations.
`-Knofriendinject`	`!`	`-Kfriendinject`	For C++ compilations: Disable the creation of visible names for friend class and function declarations.
`-Koptions`	`!`	-Koptions	Specifies options listing.
`-Koldforscope`	`!`	`-Knooldforscope`	For C++ compilations: Use the old scoping rules for variables declared in the initialization clause of a `for` statement.
`-Kstkbelow`	`!`	-Knostkbelow	Allocates stack below the 16M line.
`-Kstmap`	`!`		Requests a map of structure elements.
`-Kwarn`	`!`	-Knowarn	Causes the compiler warning messages to be printed.

New Options

-Karchlevel

allows you to request code generation for a specific level of the 390 architecture. By specifying this option, you can exploit newer features of recent processors, but you should be aware that the generated code will fail if you run it on a processor that does not have the indicated feature.

The archlevel option specifies an architectural level by a single-letter code. Four codes are supported currently, with the following meanings.

a The processor supports the logical string assist facility. This facility allows the compiler to generate better code for string.h built-in functions such as strlen, strcpy, and strcmp.

b The processor supports the immediate and relative instruction set, as well as the compare and move extended facility. This allows the compiler to generate improved code in many areas.

c The processor supports the floating-point extensions feature. This feature allows the compiler to generate improved code for floating-point computations, and is required to use IEEE floating-point. Note that use of archlevel(c) is advantageous for programs which use the traditional 390 hex format for floating-point as well as for IEEE applications.

d The processor supports the z/Architecture. This feature allows the compiler to exploit 64-bit registers for programs which use the long long data type, and is a prerequisite for 64-bit addressing support.

Note: The codes are cumulative so that, for instance, specifying an architecture level of c indicates presence of all features defined for levels a and b,as well as c. [cautionend]

If no architecture level is specified, the compiler assumes that none of the above architectural features can be used. However, if the bfp option is specified, an archlevel of c is assumed by default, and if the hugeptrs option is specified, the archlevel is assumed to be d.

-Kasynsig

specifies that extra code should be generated when necessary to detect asynchronous signals on exit from a function. If the program does not use any asynchronous signals (such as SIGINT, SIGALRM, or any POSIX signal), you can improve performance slightly by specfying noasynsig.

If noasynsig is specified but the program responds to asynchronous signals, detection of these signals by the program may be delayed, causing the handler to be called later than would otherwise be expected.

-Kbfp

specifies that the default floating point format is binary (IEEE). Note that the BFP option implies the ARCHLEVEL(C) option.

-Kcoverage

activates the COVERAGE feature of the compiler, which provides information on which lines of code written in C were executed during a compilation. This adds additional code and a data element for tracking execution to the object. The information about which lines of code were executed are made available at runtime by the _ _cvgtrm routine, which the user can provide.

-Kc99subset

-Kc99subset enables the following new features of the ISO C99 standard:

Variable declarations may occur anywhere within a compound block and in the first clause of a for statement.
The treatment of large unsuffixed decimal constants is C99 compliant in the determination of type, for example, 4000000000 is a 64 bit signed integer instead of a 32 bit unsigned integer.
The predefined identifier _ _func_ _ is made available for each function. Whenever referenced _ _func_ _ is treated as if it were declared at the beginning of the function as follows:
```
static const char _ _func_ _[] = function-name;
```
If the identifier is not used, the declaration will be deleted and no space will be wasted.

Preprocessor macros may have a variable number of arguments, for example,

#define LOGIT(...) fprintf(logfile, _ _VA_ARGS_ _)
LOGIT("x was %d, but y was %d", x, y);

inline is a keyword. This is equivalent to the SAS/C _ _inline keyword except that
- Only one definition may occur in a compilation unit.
- An actual external definition will be created if the function is declared with external linkage.
restrict is a keyword. The optimizer does not use the information provided by the use of this qualifier; consequently, its use will not result in better code genration. The keyword is enabled as a convenience for porting code written for C99 to SAS/C.
Note: -Kc99subset is ignored for C++ compilations.

-Khugeptrs

specifies that the object code is intended to execute in 64-bit addressing mode. When hugeptrs is specified, the default pointer type is _ _huge, and the size of signed and unsigned long data is 8 bytes. Note that the hugeptrs option implies the ARCHLEVEL(D) option.

Though the hugeptrs option is valid under CMS, the object code generated with this option cannot be executed under CMS because of operating system limitations.

-Khxref

prints references in standard header files in the cross-reference listing. See hlist for a description of header files.

-Kiccp

calls the CICS translator before compiling. When -Kiccp is specified, the CICS translator is called regardless of the file extension.

Prior to the implementation of the -Kiccp option, it was necessary to use a .ccp extension to indicate that the CICS translator should be called. Now that the -Kiccp is available, you can use one of the following commands to call the CICS translator:

sascc370 -Kiccp test.cxx
sascc370 -Kiccp test.c

where:

The .cxx extension causes the C++ translator to be called after the CICS translator.
The .c extension causes the C compiler to be called after the CICS translator.

The old behavior is still functional, and you can use the .ccp extension to indicate that the CICS translator should be called.

-Kixref

lists references in user #include files.

-Kmpsafe

specifies that extra code should be generated to assure correct behavior when a SAS/C asynchronous signal is detected on a different processor in an MP configuration than the one executing the SAS/C program. An example would be a user-added asynchronous signal which is generated by a subtask of the SAS/C program. mpsafe causes a slight performance penalty in the function epilog, so it should be used only when the object code may be used in the presence of such asynchronous signals.

If nompsafe is specified or defaulted, an asynchronous signal generated on another processor may be ignored or may cause an ABEND if it occurs while the function is returning.

-Knofriendinject

specifies that the translator should make the names of of friend class and function names visible in the enclosing non-class scope of the class containing the declaration. This is called friend name injection. The C++ standard requires that friend names not be injected. However older code may require name injection. The -Kfriendinject option is the default for compatability with older code. However this default may change in a future release.

The -Knofriendinject option is equivalent to the SAS/C C++ Development System's nofriendinject option.

-Koldforscope

specifies that the scope of a variable defined in the initialization clause of a for statement will follow the old C++ rules concerning scoping. The new scoping rules in the C++ standard specify that the scope of a variable defined in the for loop initialization clause only includes the for statement and its associated loop body.

The -Koldforscope option is equivalent to the SAS/C C++ Development System's oldforscope option.

-Koptions

generates an options listing. The options listing contains all options in effect for the compilation.

-Kstkbelow

causes the stack frame for functions in this compilation to be allocated below the 16M line. If the _stkabv external variable has been set to indicate the the program wants to have the stack above the line, but certain functions cannot tolerate this (for example, stack variables will be passed to system services that run only AMODE=24), then stkbelow can be specified to force the auto variables of such functions to be allocated below the line. For assembler routines, the STKBELOW=YES option of the CENTRY macro will accomplish the same result. For best results, compile only those functions that require a stack below the line with stkbelow.

-Kstmap

requests that a map of structure elements and their offsets be generated in the cross-reference for each structure tag enclosed. Specifying the -Kstmap option implies the -Kxref option.

-Kwarn

causes compilation warning messages to be printed. nowarn suppresses warning messages.

New cool Options

cool Options Summary

cool Options lists the new cool options. This table is an extension of the table labeled, "cool Options," in Chapter 6, "Prelinking C and C++ Programs."

cool Options
sascc370 Option Negation Default coolOption Description

-Aenexitdata=dll
+

-xtdll
Under Windows, specifies the name of a DLL that generates external symbols that are used by COOL for extended processing.

-Asevere
!
-Anosevere
-we
Causes COOL to assign the same level of importance to warnings as it does to errors.

***cool Options***
sascc370 Option	Negation	Default	coolOption	Description
`-Aenexitdata=`dll	`+`		`-xt`dll	Under Windows, specifies the name of a DLL that generates external symbols that are used by COOL for extended processing.
`-Asevere`	`!`	`-Anosevere`	`-we`	Causes COOL to assign the same level of importance to warnings as it does to errors.

cool Options Description

-Aenexitdata=dll: Under Windows, specifies the name of a Dynamic-Link Library that generates external names that are used by COOL to resolve extended names. See "COOL Extended Names Processing" in Appendix 7, "Extended Names" of the SAS/C Compiler and Library User's Guide.
severe (-Asevere under USS): causes COOL to assign the same level of importance to warnings as it does to errors. If COOL returns a warning, the COOL return code is the same as if COOL had returned an error; however, the message the user receives for a warning remains the same as before. It indicates only that COOL has returned a warning, not an error.

New Alternative Code Page Feature

In Chapter 3, "Compiling C and C++ Programs," following the section titled, "External Compiler Variables," add a new heading of the same level with the title, "Alternative Code Page Feature," that contains the following text.

With release 7.50, the SAS/C and C++ cross-platform compiler allows you to specify alternative codepages for the translation of characters used in your source code. Two codepage tables are required: one giving the ASCII to EBCDIC translation and a second giving the EBCDIC to ASCII translation. The codepage tables must be placed in files named atoe.codepage and etoa.codepage. The location of the directory containing these files is specified with the _SASC_CODEPAGE_PATH environment variable.

The alternative codepages enable you to control the way the ASCII characters in your source code are translated into EBCDIC by the compiler. For example, you can use them to control the way the ASCII `$' is translated in the following example:

#include <stdio.h>
void main(void)
{
	int ascii_char = '$';
	
	printf("ebcdic_char = %c\n", ascii_char);
	printf("ebcdic_char = %d\n", ascii_char);
}

If you compile this on the cross-platform compiler, the ASCII `$' 0x24 will be translated into the EBCDIC `$' 0x5B. By default the `$' will be displayed at run-time on your EBCDIC mainframe even though you compiled it on an ASCII machine.

This default behavior is what you usually require; however, there are situations in which you want to control the ASCII to EBCDIC translation performed by the compiler. You do this by supplying alternative codepages.

The following figures, atoe.codepage and etoa.codepage, provide examples of alternative codepages. Note that the codepage tables consist of a 16X16 array of hexadecimal digits where position determines the replacement value and comments are delineated by semicolons.


atoe.codepage


  00 01 02 03 37 2D 2E 2F 16 05 15 0B 0C 0D 0E 0F     ; 00 ;
  10 11 12 13 3C 3D 32 26 18 19 3F 27 1C 1D 1E 1F     ; 10 ;
  40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61     ; 20 ;
  F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F     ; 30 ;
  7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6     ; 40 ;
  D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D     ; 50 ;
  79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96     ; 60 ;
  97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07     ; 70 ;
  20 21 22 23 24 25 06 17 28 29 2A 2B 2C 09 0A 1B     ; 80 ;
  30 31 1A 33 34 35 36 08 38 39 3A 3B 04 14 3E FF     ; 90 ;
  41 AA 4A B1 9F B2 6A B5 BB B4 9A 8A B0 CA AF BC     ; A0 ;
  90 8F EA FA BE A0 B6 B3 9D DA 9B 8B B7 B8 B9 AB     ; B0 ;
  64 65 62 66 63 67 9E 68 74 71 72 73 78 75 76 77     ; C0 ;
  AC 69 ED EE EB EF EC BF 80 FD FE FB FC BA AE 59     ; D0 ;
  44 45 42 46 43 47 9C 48 54 51 52 53 58 55 56 57     ; E0 ;
  8C 49 CD CE CB CF CC E1 70 DD DE DB DC 8D 8E DF     ; F0 ;


etoa.codepage


  00 01 02 03 9C 09 86 7F 97 8D 8E 0B 0C 0D 0E 0F     ; 00 ;
  10 11 12 13 9D 0A 08 87 18 19 92 8F 1C 1D 1E 1F     ; 10 ;
  80 81 82 83 84 85 17 1B 88 89 8A 8B 8C 05 06 07     ; 20 ;
  90 91 16 93 94 95 96 04 98 99 9A 9B 14 15 9E 1A     ; 30 ;
  20 A0 E2 E4 E0 E1 E3 E5 E7 F1 A2 2E 3C 28 2B 7C     ; 40 ;
  26 E9 EA EB E8 ED EE EF EC DF 21 24 2A 29 3B 5E     ; 50 ;
  2D 2F C2 C4 C0 C1 C3 C5 C7 D1 A6 2C 25 5F 3E 3F     ; 60 ;
  F8 C9 CA CB C8 CD CE CF CC 60 3A 23 40 27 3D 22     ; 70 ;
  D8 61 62 63 64 65 66 67 68 69 AB BB F0 FD FE B1     ; 80 ;
  B0 6A 6B 6C 6D 6E 6F 70 71 72 AA BA E6 B8 C6 A4     ; 90 ;
  B5 7E 73 74 75 76 77 78 79 7A A1 BF D0 5B DE AE     ; A0 ;
  AC A3 A5 B7 A9 A7 B6 BC BD BE DD A8 AF 5D B4 D7     ; B0 ;
  7B 41 42 43 44 45 46 47 48 49 AD F4 F6 F2 F3 F5     ; C0 ;
  7D 4A 4B 4C 4D 4E 4F 50 51 52 B9 FB FC F9 FA FF     ; D0 ;
  5C F7 53 54 55 56 57 58 59 5A B2 D4 D6 D2 D3 D5     ; E0 ;
  30 31 32 33 34 35 36 37 38 39 B3 DB DC D9 DA 9F     ; F0 ;

These sample codepages use the same default translations that are used by the SAS/C library. Note that the library's translation is not affected by the alternative codepage feature described here. The library's translation is controlled by the tables found in prefix.SOURCE(L$USKCS) . The alternative codepages will affect only the compiler's translation of ASCII to EBCDIC characters.

The set command can be used to set the value of the _SASC_CODEPAGE_PATH environment variable. For example, the following command can be used to specify the fully qualified path to the directory containing the alternative codepages under Windows:

set _SASC_CODEPAGE_PATH=C:\codepages

This command will set the _SASC_CODEPAGE_PATH environment variable to the \codepages directory on your C drive.

Note: Under UNIX, you have to export the _SASC_CODEPAGE_PATH as well as set it. [cautionend]

If the alternative codepages are properly formatted and found in the location specified by the _SASC_CODEPAGE_PATH environment variable, the following notes will be displayed when you compile:

NOTE: Environment variable "_SASC_CODEPAGE_PATH" found.
NOTE: Alternative codepages will be loaded from the "C:\codepages" directory

If errors are detected while processing the codepages, cautions will be displayed.

Chapter Contents
Previous
Next
Top of Page

`a`	The processor supports the `logical string assist` facility. This facility allows the compiler to generate better code for `string.h` built-in functions such as `strlen`, `strcpy`, and `strcmp`.
`b`	The processor supports the immediate and relative instruction set, as well as the compare and move extended facility. This allows the compiler to generate improved code in many areas.
`c`	The processor supports the floating-point extensions feature. This feature allows the compiler to generate improved code for floating-point computations, and is required to use IEEE floating-point. Note that use of `archlevel(c)` is advantageous for programs which use the traditional 390 hex format for floating-point as well as for IEEE applications.
`d`	The processor supports the z/Architecture. This feature allows the compiler to exploit 64-bit registers for programs which use the long long data type, and is a prerequisite for 64-bit addressing support.