f78 DEC Alpha Options Contents|Index|Previous|Next
 

DEC Alpha options  

The following ‘-m’ options are defined for the DEC Alpha implementations.
-mfp-reg
-mno-fp-regs
Generate code that uses (does not use) the floating-point register set. -mno-fp-regs implies -msoft-float. If the floating-point register set is not used, floating point operands are passed in integer registers as if they were integers and floating-point results are passed in $0 instead of $f0.
This is a non-standard calling sequence, so any function with a floating-point argument or return value called by code compiled with -mno-fp-regs must also be compiled with that option. A typical use of this option is building a kernel that does not use, and hence need not save and restore, any floating-point registers.
 
-mieee
The Alpha ffb architecture implements floating-point hardware optimized for maximum performance. It is mostly compliant with the IEEE floating point standard. However, for full compliance, software assistance is required. This option generates code fully IEEE compliant code except that the inexact flag is not maintained (contrast following description for -mieee-with-inexact). If this option is turned on, the CPP macro, _IEEE_FP, is defined during compilation.
The option is a shorthand for ‘-D_IEEE_FP -D_IEEE_FP_INEXACT’ plus ‘-mieee-conformant’, and ‘-mfp-trap-mode=sui’, and ‘-mtrap-precision=i’.
The resulting code is less efficient but is able to correctly support denormalized numbers and exceptional IEEE values such as not-a-number and plus/minus infinity.
Other Alpha compilers call this option ‘-ieee_with_no_inexact’.
-mieee-with-inexact
This is like ‘-mieee’ except the generated code also maintains the IEEE inexact flag. Turning on this option causes the generated code to implement fully-compliant IEEE math. The option is a shorthand for  ‘-D_IEEE_FP -D_IEEE_FP_INEXACT’ plus ‘-mieee-conformant’, and ‘-mfp-trap-mode=sui’, and ‘-mtrap-precision=i’. On some Alpha implementations the resulting code may execute significantly slower than the code generated by default. Since there is very little code that depends on the inexact flag, you should normally not specify this option. Other Alpha compilers call this option ‘-ieee_with_inexact’.
 
-mfp-trap-mode=trap mode
This option controls what floating-point related traps are enabled. Other Alpha compilers call this option ‘-fptm ffb ’ trap mode. The trap mode can be set to one of the following four values.
 
  • ‘n’

    • This is the default (normal) setting. The only traps that are enabled are the ones that cannot be disabled in software (such as division by zero trap).
  • ‘u’

    • In addition to the traps enabled by ‘n’, underflow traps are enabled as well.
  • ‘su’

    • Like ‘su’, but the instructions are marked to be safe for software completion (see Alpha architecture manual for details).
  • ‘sui’
    • Like ‘su’, but inexact traps are enabled as well.
 
 
-mfp-rounding-mode=rounding mode
Selects the IEEE rounding mode. Other Alpha compilers call this option ‘-fprm ’ rounding mode. The rounding mode can be one of the following four values.
 
  • ‘n’

    • Normal IEEE rounding mode. Floating point numbers are rounded towards the nearest ma-chine number or towards the even machine num-ber in case of a tie.
  • ‘m’

    • Round towards minus infinity.
  • ‘c’

    • Chopped rounding mode. Floating point numbers are rounded towards zero.
  • ‘d’
    • Dynamic rounding mode. A field in the floating point control register (fpcr, see Alpha architecture reference manual) controls the rounding mode in effect. The C library initializes this register for rounding towards plus infinity. Thus, unless your program modifies the fpcr, ‘d’ corresponds to round towards plus infinity.
 
-mtrap-precision=trap precision
In the Alpha architecture, floating point traps are imprecise. This means without software assistance it is impossible to recover from a floating trap and program execution normally needs to be terminated. GNU CC can generate code that can assist operating system trap handlers in determining the exact location that caused a floating point trap. Depending on the requirements of an application, different levels of precisions can be selected, such as the following specifications:
 
  • ‘p’

    • Program precision. This option is the default and means a trap handler can only identify which program caused a floating point exception.
  • ‘f’

    • Function precision. The trap handler can determine the function that caused a floating point exception.
  • ‘i’
    • Instruction precision. The trap handler can determine the exact instruction that caused a floating point exception. Other Alpha compilers provide the equivalent options, ‘-scope_safe’ and ‘-resumption_safe’.
 
-mieee-conformant
This option marks the generated code as IEEE conformant. You must not use this option unless you also specify ‘-mtrap-precision=i’ and either ‘-mfp-trap-mode=su’ or ‘-mfp-trap-mode=sui’. Its only effect is to emit the line ‘.eflag 48’ in the function prologue of the generated assem-bly file. Under DEC Unix, this has the effect that IEEE-conformant math library routines will be linked in.
 
-mbuild-constants
Normally GNU CC examines a 32- or 64-bit integer constant to see if it can construct it from smaller constants in two or three instructions. If it cannot, it will ffb output the constant as a literal and generate code to load it from the data segement at runtime.
Use this option to require GNU CC to construct all integer constants using code, even if it takes more instructions (the maximum is six).
You would typically use this option to build a shared library dynamic loader. Itself a shared library, it must relocate itself in memory before it can find the variables and constants in its own data segment.
 
-malpha-as
-mgas
Select whether to generate code to be assembled by the vendor-supplied assembler (using the option, -malpha-as) or by the GNU assembler, using -mgas.
 
-mbwx
-mno-bwx
-mcix
-mno-cix
-mmax
-mno-max
Indicate whether GNU CC should generate code to use the optional BWX, CIX, and MAX instruction sets. The default is to use the instruction sets supported by the CPU type specified, using the -mcpu= option or that of the CPU on which GNU CC was built if none was specified.
 
-mcpu=cpu type
Set the instruction set, register set, and instruction scheduling parameters for machine type CPU type. You can specify either the EV style name or the corresponding chip number. GNU CC supports scheduling parameters for the EV4 and EV5 family of processors and will choose the default values for the instruction set from the processor you specify. If you do not specify a processor type, GNU CC will default to the processor on which the compiler was built. Supported replacements for cpu type use the following values.
 
  • ‘ev4’
    ‘    21064’
    • Schedules as an EV4 and has no instruction set extensions.
  • ‘ev5’
    ‘    21164’

    • Schedules as an EV5 and has no instruction set extensions.
  • ‘ev56’
    ‘    21164a’

    • Schedules as an EV5 and supports the BWX extension.
  • ‘pca56’
    ‘    21164pc’
    ‘    21164PC’

    • Schedules as an EV4 and supports the BWX and MAX extensions.
  • ‘ev6’
    ‘    21264’

    • Schedules as an EV5 (until Digital releases the scheduling parameters for the EV6) and supports the BWX, CIX, and MAX extensions.
 
-mmemory-latency=time
    Sets the latency the scheduler should assume for typical memory references
    as seen by the application. This number is highly dependant on the memory
    access patterns used by the application and the size of the external cache on
    the machine.
    Valid options for time use the following values.
       
    • number 
      A decimal number representing clock cycles.
    • L1

      • L2
      L3
      main 
      The compiler contains estimates of the number of clock cycles for
      typical EV4 & EV5 hardware for the Level 1, 2 & 3 caches (also
      called Dcache, Scache, and Bcache), as well as to main memory.

      Note:
      L3 is only valid for EV5.

0