------------------------------------------------------------------------------When instructed to generate a map file, the linker will now include somenew information to help you diagnose memory placement and allocationfailure 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 directivefragments 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 XXXmemory 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 IXPAGE 2:  IOPORT                00000000   00020000  00000000  00020000  RWIIn this simplistic example, the linked application only used 0x3797 bytes ofthe ROM memory area, leaving 0x1c769 bytes left un-allocated.Please note that the amount of unused (available) memory listed for a givenmemory area represents the sum of the available memory blocks from thatmemory 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 helpfulinformation 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 directivefragments 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 thememory 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 thecontents of ".text:4" that is annotated with a "FAILED TO ALLOCATE"message, so that you can see exactly which input sections were notplaced 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 successfullyallocated in this link attempt was _printfi.obj from the rts55.lib objectlibrary.------------------------------------------------------------------------------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 a64-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, theL1D cache may not work correctly when two load instructions are scheduled in parallel and the two loads do not share the same predicate.  The issuearises if the two loads target the same L1D cache line and certain othercriteria are met.  The device-specific errata sheets explain whether aspecific device is vulnerable and the exact conditions required to triggerthis issue.Starting with the 6.0.3 patch release, when compiling for C64+ thecompiler 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 onA new option, --c64p_l1d_workaround=off will tell the compiler NOT to prevent the sequence of code that could trigger the issue when compilingfor 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 whencompiling for other C6000 targets.  The option --c64p_l1d_workaround=onenables this C64+ specific workaround for these other targets.  This isuseful for building code that is safe to run on C64+ and another C6000target.*******************************************************************************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 morethan n cycles.  Also, plain -mi says the compiler can presume interruptsnever 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.libNote you'll have to perform this step with each update of the code generationtools.-------------------------------------------------------------------------------2.02. Illegal Uses of Parallel Instructions in Hand Assembly Code-------------------------------------------------------------------------------Instruction mnemonics cannot be put in parallel with macro calls.  Forexample, 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 assemblerdirectives.  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 oldSolaris 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_PATHenvironment variable to where your standalone simulator resides. Ex:  If your standalone simulator resides in the following directory after