readme.1st

Montavista Linux 下的多平台编译软件xdc

------------------------------------------------------------------------------
When instructed to generate a map file, the linker will now include some
new information to help you diagnose memory placement and allocation
failure problems.

Unused Memory Information
-------------------------

The linker will now include a new column in the MEMORY CONFIGURATION area 
of the generated map file that displays the amount of unused (available) 
memory left in a given memory area.
  
For example, suppose you have the following MEMORY and SECTIONS directive
fragments in your linker command file:

  MEMORY
  {
     PAGE 0:
        RAM  (RWIX) : origin = 0x000100, length = 0x007f00
        ROM  (RIX)  : origin = 0x020100, length = 0x01ff00
        VECS (RIX)  : origin = 0xffff00, length = 0x000100

     PAGE 2:
        IOPORT (RWI) : origin = 0x000000, length = 0x020000
  }

  SECTIONS
  {
     .text     > ROM    PAGE 0

     ...
  }

and you'd like to determine how much memory you have left in the XXX
memory area.  The linker generated map file will show you:

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
                        (bytes)   (bytes)    (bytes)   (bytes)
----------------------  --------  ---------  --------  --------  ---- --------
PAGE 0:
  RAM                   00000100   0001ff00  00006344  00019bbc  RWIX
  ROM                   00020100   0001ff00  00003797  0001c769  R IX
  VECS                  00ffff00   00000100  00000100  00000000  R IX

PAGE 2:
  IOPORT                00000000   00020000  00000000  00020000  RWI

In this simplistic example, the linked application only used 0x3797 bytes of
the ROM memory area, leaving 0x1c769 bytes left un-allocated.

Please note that the amount of unused (available) memory listed for a given
memory area represents the sum of the available memory blocks from that
memory area.  It does not mean "the largest contiguous available block"
of memory from that area.

Allocation Failure Information
------------------------------

The linker generated map file will now also include some helpful
information in the output section listing to help you diagnose the 
cause of a failed allocation attempt.

For example, suppose you have the following MEMORY and SECTIONS directive
fragments in your linker command file:

  MEMORY
  {
   PAGE 0:

     RAM  (RWIX) : origin = 0x000100, length = 0x01ff00
     ROM1 (RIX)  : origin = 0x020100, length = 0x000f00
     ROM2 (RIX)  : origin = 0x021100, length = 0x000f00
     ROM3 (RIX)  : origin = 0x022100, length = 0x000f00
     VECS (RIX)  : origin = 0xffff00, length = 0x000100

   PAGE 2:

     IOPORT (RWI) : origin = 0x000000, length = 0x020000
  }

  SECTIONS
  {
     .text     >> ROM1 | ROM2 | ROM3    PAGE 0

     ...
  }

and, suppose the code for your application doesn't quite fit into the
memory areas provided for the .text sections of your application.

The linker will generate an error message like this:

     error: can't allocate .text:4, size 00001006 (page 0) in ROM1 (avail:
            00000000), ROM2 (avail: 00000001), ROM3 (avail: 000005c5)

to indicate that it has failed to place the specified output section
".text:4" in any of the available memory areas (ROM1, ROM2, ROM3) that 
were specified for the placement of the .text section.

In the linker generated map file, you will also see a listing of the
contents of ".text:4" that is annotated with a "FAILED TO ALLOCATE"
message, so that you can see exactly which input sections were not
placed in memory.  The listing of the ".text:4" output section might 
look like this:

SECTION ALLOCATION MAP
(Addresses surrounded by []'s are displayed for convenience only!)

output                                                          attributes/
section   page  orgn(bytes) orgn(words) len(bytes) len(words)   input sections
--------  ----  ----------- ----------- ---------- ----------   --------------
.text:4      0     00000000  [ 00000000 ] 00001006          *   FAILED TO ALLOCATE
                   00000000  [ 00000000 ] 00001006          *   rts55.lib : _printfi.obj (.text)

which indicates that the only input section that was not successfully
allocated in this link attempt was _printfi.obj from the rts55.lib object
library.

------------------------------------------------------------------------------
1.20.  Intrinsics for C64+
------------------------------------------------------------------------------
Intrinsics that aid in the manipulation of values with the long long type:

    unsigned int _hill (long long src)
      Returns the high (odd) register of a long long register pair.

    unsigned int _loll (long long src)
      Returns the low (even) register of a long long register pair.

    long long _itoll (unsigned int src2, unsigned int src1)
      Builds a new long long register pair by reinterpreting two unsigned
      values, where src2 is the high (odd) register and src1 is the low (even) 
      register.  Does not necessarily use the DMV instruction (C6400+).

Intrinsics for new C6400+ instructions:
 
    -------------------------------------------------------------------
    intrinsic   unit     src1        src2    return type    instruction
    -------------------------------------------------------------------
    _mpy32ll    .m       int,       int,     long long      MPY32
    _mpy32us    .m       uint,      int,     long long      MPY32US
    _mpy32u     .m       uint,      uint,    long long      MPY32U
 
    _smpy32     .m       uint,      uint,    uint           SMPY32
 
    _mpy32      .m       int,       int,     int            MPY32
 
    _mpy2ir     .m       int,       int,     long long      MPY2IR
 
    _cmpy       .m       uint,      uint,    long long      CMPY
    _cmpyr      .m       uint,      uint,    uint           CMPYR
    _cmpyr1     .m       uint,      uint,    unit           CMPYR1
 
    _ddotp4     .m       uint,      uint,    long long      DDOTP4
 
    _ddotph2    .m       long long, uint,    long long      DDOTPH2
    _ddotpl2    .m       long long, uint,    long long      DDOTPL2
    _ddotph2r   .m       long long, uint,    uint           DDOTPH2R
    _ddotpl2r   .m       long long, uint,    uint           DDOTPL2R
 
    _addsub     .l       int,       int,     long long      ADDSUB
         
    _addsub2    .l       int,       int,     long long      ADDSUB2
 
    _saddsub    .l       uint,      uint,    long long      SADDSUB
 
    _saddsub2   .l       uint,      uint,    long long      SADDSUB2
 
    _ssub2      .l       uint,      uint,    uint           SSUB2
 
    _shfl3      .m       uint,      uint,    long long      SHFL3
 
    _gmpy       .m       uint,      uint,    uint           GMPY
 
    _xormpy     .m       uint,      uint,    uint           XORMPY
 
    _dpack2     .l       uint,      uint,    long long      DPACK2
 
    _dpackx2    .l       uint,      uint,    long long      DPACKX2
 
    _rpack2     .s       int,       int,     int            RPACK2
    
    _dmv        .s       int,       int,     long long      DMV
 
New long long versions of previously existing intrinsics that returned a
64-bit integer value in a double:
 
    -------------------------------------------------------------------
    intrinsic   unit     src1        src2    return type    instruction
    -------------------------------------------------------------------
    _mpyhill    .m       int,        int     long long      MPYHI
    _mpylill    .m       int,        int     long long      MPYLI
    _mpy2ll     .m       int,        int     long long      MPY2
    _smpy2ll    .m       int,        int     long long      SMPY2
    _mpysu4ll   .m       int,        uint    long long      MPYSU4
    _mpyu4ll    .m       uint,       uint    long long      MPYU4


------------------------------------------------------------------------------
1.21.  Intrinsics for C67+
------------------------------------------------------------------------------

Intrinsics for new C6700+ instructions:

    -------------------------------------------------------------------
    intrinsic   unit     src1        src2    return type    instruction
    -------------------------------------------------------------------
    _mpysp2dp   .m       float,      float,  double         MPYSP2DP
    _mpyspdp    .m       float,      double  double         MPYSPDP

------------------------------------------------------------------------------
1.22.  New options c64p_l1d_workaround={on,off}
------------------------------------------------------------------------------

There is a silicon issue with certain C64+ devices.  In some cases, the
L1D cache may not work correctly when two load instructions are scheduled 
in parallel and the two loads do not share the same predicate.  The issue
arises if the two loads target the same L1D cache line and certain other
criteria are met.  The device-specific errata sheets explain whether a
specific device is vulnerable and the exact conditions required to trigger
this issue.

Starting with the 6.0.3 patch release, when compiling for C64+ the
compiler will prevent the generation of a code sequence that may trigger the 
issue.  The assembler will emit a remark if it encounters assembly code 
that may trigger the issue.

The assembler remarks can be disabled on a case by case basis using the 
.noremark directive and re-enabled by using the .remark directive.  For 
example, the remark can be turned off if the programmer knows that the 
two load pointers will never map to the same cache line.
    .noremark 5000         ; Turn remark 5000 off
  [ A0] LDW.D1T1  *A4, A6  ; Concurrent loads not to same cache line
||[ B1] LDW.D2T2  *B4, B6  ; so disable the remark issued by assembler
    .remark                ; Turn remark 5000 on

A new option, --c64p_l1d_workaround=off will tell the compiler NOT to 
prevent the sequence of code that could trigger the issue when compiling
for C64+.  This option also tells the assembler not to issue a remark when 
finding code that could trigger the issue.

By default, the compiler does not avoid this instruction sequence when
compiling for other C6000 targets.  The option --c64p_l1d_workaround=on
enables this C64+ specific workaround for these other targets.  This is
useful for building code that is safe to run on C64+ and another C6000
target.


*******************************************************************************
2. Other information
*******************************************************************************

------------------------------------------------------------------------------
2.01. Do not Link C++ Code at address 0x00000000
------------------------------------------------------------------------------
Due to a bug with C++ constructors, do not link your code (the .text 
section by default) to address 0x00000000.

-------------------------------------------------------------------------------
2.02. Using -mi<n> Doesn't Affect RTS Functions
-------------------------------------------------------------------------------
The -mi<n> option tells the compiler it can disable interrupts for no more
than n cycles.  Also, plain -mi says the compiler can presume interrupts
never occur.  

Chapter 10 of the Optimizing C Compiler User's Guide details how the RTS 
libraries are built.  You'll note that -mi<n> is not used.  So, even when 
user code is built with -mi<n>, RTS functions are not.  This means that, in 
some cases, interrupts which occur during the execution of RTS functions 
could be delayed for much longer than n cycles.  To remedy this situation, 
re-build the library with the same -mi<n> option applied to user code.  
Simply use the appropriate command as indicated in Chapter 10 of the 
Optimizing C Compiler User's Guide and add the -mi<n> option anywhere 
between the "mk6x" and "rts.src".  For example ...

    mk6x -o -mi100 rts.src -l rts6200.lib

Note you'll have to perform this step with each update of the code generation
tools.

-------------------------------------------------------------------------------
2.02. Illegal Uses of Parallel Instructions in Hand Assembly Code
-------------------------------------------------------------------------------
Instruction mnemonics cannot be put in parallel with macro calls.  For
example, the following assembly program is illegal --

mac1    .macro
        LDW    .D1T1  *A4++,A5
        .endm

        .text
        mac1
 ||     ADD    .L1    A1, A2, A3 

Instruction mnemonics cannot be put in parallel with conditional assembler
directives.  For example, the following assembly program is illegal --

        LDW    .D1T1  *A4++,A5
        .if     <condition>
 ||     ADD    .L1    A1, A2, A3
        .else
 ||     ADD    .L1    A1, A2, A3
 ||     ADD    .L2    B1, B2, B3
        .endif

-------------------------------------------------------------------------------
2.03. Notes on using the Standalone Simulator (load6x)
-------------------------------------------------------------------------------
For Workstations running Solaris, there is a script to run the standalone 
simulator that is similar to the scripts that were invoked to run the old
Solaris simulators.  load6x points to where all the necessary DLL files and 
the load6xexe executable resides.  load6xexe is the actual standalone 
simulator, and the .dll files support it.  Edit load6x and modify the LO_PATH
environment variable to where your standalone simulator resides.
 
Ex:  If your standalone simulator resides in the following directory after