Conference turris::decc

    You should probably take the defaults and produce portable code unless
    you've thought carefully about your distribution strategy across
    machines that have and do not have the ev56 insructions.
    
    A brief web page is located under 
    
         http://labrea.zko.dec.com/~henning/Concerns_Hints_and_Tips.html
    
    but I'm thinking of updating it with some more numbers and a pretty graph
    in the next day or two, so check back again later in the week.
    

I assume you're talking vms...
From the help info:

     TUNE=keyword      Selects processor-specific instruction tuning for
                       implementations of the Alpha architecture.
                       Regardless of the setting of the /OPTIMIZE=TUNE
                       flag, the generated code will run correctly on  <<<****
                       all implementations of the Alpha architecture.  <<<****
                       Tuning for a specific implementation can provide
                       improvements in runtime performance.  Code tuned
                       for a specific target might run slower on another
                       target.

Tune tells the compiler how to shuffle instructions around to run best on the 
platform you specify, but the code WILL RUN on every platform.

From the tuning perspective, ev56 behaves the same as ev5, so use tune=ev5 will
give the best "tuning".  However, tune ALSO accepts "ev56", so you could use
that instead :)  e.g.,
	cxxcc $ cc/opt=tune=ev56  [.c]hello.c
	cxxcc $

The help page doesn't yet tell you about the cc/arch=?? option.  /arch tells the
compiler which instructions to use.  cc/arch=ev56  permits the compiler to generate
the new load/store byte/word instructions.   

cxxcc $ cc/arch=ev56  [.c]hello.c
cxxcc $ link hello
cxxcc $ run hello
hello world!

The generated program will NOT run on ev5 or ev5 platforms, since they don't 
have these new instructions.   (However,
the OVMS V7.0 kernel has code that will emulate these instructions - so such a program
will get an illegal instruction trap, trap to the OS, the kernel will emulate the
instruction, and then continue the program.  So the program actually WILL run, but
not very fast if you've got lots of instructions that need to be emulated.)

For unix, the options look like 
	-tune ev5
	-arch ev5

Mark Davis
c/c++ team

Is it too lat to change the word?

I assume that the compiler really supports ONE architecture and only different
implementations.

Hartmut

    VMS V7.0 does NOT have the instruction emulator on by default.
    V7.1 turns it on by default.

/arch: ev56's load/store byte/word instructions are an architectural extension
of the base alpha architecture.  ev5 does not "implement" these instructions,
so it is not just a different implementation from ev56.  and pca56 has
multimedia extension instructions; and ev6 has those plus sqrt and popcount and
friends.

Of course, they're all part of the alpha "family"; and we don't want to scare our
customers that their code won't run on different platforms.

We (compiler wonks) struggled with the wordsmithing for "/tune" and "/arch"; and
if it's not the best, then what do you expect when a bunch of engineers
attack a dictionary :-?

Mark

  -arch option
      Specifies which version of the Alpha architecture to generate instruc-
      tions for.   All Alpha processors implement a core set of instructions
      and, in some cases, the following extensions: BWX (byte- and word-
      manipulation instructions) and MAX (multimedia instructions).  (The
      Alpha Architecture Reference Manual describes the extensions in
      detail.)

      The option specified by the -arch flag determines which instructions
      the compiler can generate:

      generic
          Generate instructions that are appropriate for all Alpha proces-
          sors.  This option is the default.

      host
          Generate instructions for the processor that the compiler is run-
          ning on (for example, EV56 instructions on an EV56 processor, and
          EV4 instructions on an EV4 processor).

      ev4,ev5
          Generate instructions for the EV4 processor (21064, 20164A, 21066,
          and 21068 chips) and EV5 processor (some 21164 chips).  (Note that
          the EV5 and EV56 processors both have the same chip number -
          21164.)

          Applications compiled with this option will not incur any emulation
          overhead on any Alpha processor.

      ev56
          Generate instructions for EV56 processors (some 21164 chips).

          This option permits the compiler to generate any EV4 instruction,
          plus any instructions contained in the BWX extension.

          Applications compiled with this option may incur emulation overhead
          on EV4 and EV5 processors.

       pca56
          Generate instructions for PCA56 processors (21164PC chips).

          This option permits the compiler to generate any EV4 instruction,
          plus any instructions contained in the BWX or MAX extensions.

          Applications compiled with this option may incur emulation overhead
          on EV4, EV5, and EV56 processors.

  A program compiled with any of the options will run on any Alpha processor.
  Beginning with Digital UNIX V4.0 and continuing with subsequent versions,
  the operating system kernel includes an instruction emulator. This capabil-
  ity allows any Alpha chip to execute and produce correct results from Alpha
  instructions - even if the some of the instructions are not implemented on
  the chip.  Applications using emulated instructions will run correctly, but
  may incur significant emulation overhead at run time.

      The psrinfo -v command can be used to determine which type of processor
      is installed on any given Alpha system.

    When is the /arch compile option available for OVMS?
    
    I assume DECC 5.5 on OVMS 7.0, but not sure?
    
    
    Bob Knecht
    CSC - Colorado

/arch qualifier support for ev56 was present in V5.3, but at least one
ev56-specific code generation bug that had been tripped over by early
testing efforts was fixed in V5.5.  You'd have to check with VMS about
the status of EV56 support (hardware support and/or emulation?) for
a given OVMS release.  Of course you know that if you compile with
/arch=ev56 and run the code on a pre-ev56 machine, you may pay a
substantial emulation cost.

:    I assume DECC 5.5 on OVMS 7.0, but not sure?

   Alpha systems based on the EV56 microprocessor were first supported
   under OpenVMS Alpha V6.2-1H3, and are supported under V7.1 or later.
   EV56 systems are not supported under OpenVMS Alpha V7.0...

   Warning: Both the EV5 and the EV56 are each refered to as the
   `DECchip 21164' by Digital Semiconductor, for reasons I have not
   been able to grasp.  Microprocessor differentiation in the product-
   and system-level documetnation can be correspondingly difficult.

   Presently, if it's a 21164 running at 400+ MHz, it's probably EV56. 
   If it's a 21164 running at 300 MHz or below, it's probably EV5.  In
   that 300 to 400 MHz range, you'll have to look at the system hardware
   reference documentation to see if it's running the 21164 (EV5) or the
   21164 (EV56).  These ranges ar subject to change...

   There's an update to teh STARS Operating Systems article `CPU Operating
   System Versions and Release Dates Table & Flowchart' in the works,
   which has the current breakdown of EV5 vs EV56 systems.  Also see
   NOTED::HACKERS note 1422.2 for a program that can differentiate the
   21164 (EV5) from the 21164 (EV56)...

    Thanks for the update!
    
    bob