News

The newest features are listed first. If no new features are listed then the new version cover minor improvements, new device header files and bug fixes.

The bug list is found here.

Version 1.8C released

Version 1.8B released

Warning levels

All warnings has been assigned a level. The levels are numbered 1,2,3. It is possible to decide which warning levels that are printed. This is useful to limit the number of warnings. The current active warning level is decided by option -w.

  LEVEL 1: basic
  LEVEL 2: normal
  LEVEL 3: extra

  -w3 : print warnings from level 1 to 3 (all warnings)
  -w2 : print warnings from level 1 to 2 (default)
  -w1 : print warnings at level 1 only
  -w0 : print no warnings

The default active warning level is 2 (option -w2). The compiler prints the number of warnings at each level:

      Warnings (level 1-3): 2,3,0  [-w2 active]

Warnings that need an option to be printed still needs that option.

Alternative special register bit names

It is possible to use alternative bit names for special function register names inspired by the XC8 compiler. Such names are generated by the MPLAB X Code Configurator and makes it easier to include code generated automatically by MCC.

Examples:
  Alternative name:       Existing name:
  PIE4bits.TMR1IE         TMR1IE
  TXSTA1bits.TRMT1        TRMT1
  RCSTA1bits.CREN1        CREN1
  INTCONbits.GIE          GIE
  PCON0bits.nBOR          BOR_
  CRCCON0bits.FULL        CRCCON0_FULL

The new alternative names needs no further definitions. When two names <REGISTERNAME> and <BITNAME> are defined (in the device header file) and located at the same address, then the alternative name has the format:

  REGISTERNAMEbits.BITNAME

Restrictions: The alternative name only works for REGISTERNAME starting with a capital letter. The register and bit names has to be located at a fixed address using the format found in the device header files.

Version 1.8A released

Using optimization levels

The different optimization types are assigned to different optimization levels. All existing basic optimization types (1..8,10,11) are set to level 1. New optimization types are assigned higher levels. The initial optimization level is the level set at the start of compilation.

NOTE: the default initial optimization level is 1.

Optimization level 1 means that only the basic optimization is performed. The default initial optimization level may change in future releases.

The initial optimization level can be changed by option -z<N>, for example -z2 will set optimization level 2.

NOTE: There are currently no optimization types above level 1.

The current optimization level during compilation can be changed during compilation by #pragma optimize z<N>, but it is NOT possible to increase the current optimization level above the initial optimization level.

  #pragma optimize z1    // set optimization level 1 - basic types
  #pragma optimize z0    // disable all optimization

  #pragma optimize zi    // restore to initial optimization level

Changing the optimization level makes it possible to enable and disable groups of optimization types.

All optimization types are enabled by default. The optimization level will not change the individual setting (enabled/disabled) of each optimization type. If an optimization type is disabled then the optimization level will not enable this optimization type. A specific optimization type is only performed if the optimization type is enabled individually AND enabled by the current optimization level.

New code level

The code generator is improved from time to time. The code level tells which code is generated. The code generator is different from code optimization. Different code is generated for each code level. There will be changes within each level for new versions.

Available code levels:

  code level=0 : original code generator
  code level=1 : improved code related to new enhanced core 14 instructions
  code level=2 : improved code for division and remainder/modulus

The new default is code level 2.

The code level can be changed by:

  Option -c<N> where <N> is 0..2
  #pragma codeLevel <N>   // where <N> is 0..2
  #pragma codeLevel i     // restore initial code level

Option -cl<N> defines the highest level for the entire application. This level cannot be increased by #pragma codeLevel.

Emulating the FREE edition

Option -cfr will emulate operation of the FREE compiler edition with the same limitations on optimization, variable size and code generation.

Option -cfr+ is similar but ignores the variable size restrictions.

Macro identifying the number of banks

The compiler defines a macro that represent the number of banks used for GPR and SFR registers. This macro is suitable for conditional compilation. The number of banks depends on the core configuration of the device. The macro is defined in the beginning of compilation. Example:

  #if __BANKS__ == 64
   // newer device with up to 16k space for RAM/GPR and SFR
  #else  // __BANKS__ == 16
   // legacy device with 16 banks only
  #endif

Macro identifying the chip

The compiler defines a macro starting with "PIC" that identifies the device. The macro is defined in the beginning of compilation. The macro identifier is identical to the device identifier, for example "PIC18F57Q83". The device can also be identified by the established macro "_18F57Q83". Example usage:

  #if PIC18F57Q83 == 1  // alternative _18F57Q83 == 1
   // code and definitions specific for this device
  #endif

Version 1.8 released

Generating an interrupt vector table and interrupt functions

Command line option -cgi will generate an interrupt vector table. The device has to support interrupt vector tables. The newest header files contain the required #pragma intSRC_ definitions or alternatively the SETCC utility version 2 can be used to get a device header file. The generated interrupt definitions file will have the format "<device>-int.c", for example "18f57q43-int.c". The file will only be generated if it does not exist. The file contains 3 main parts:

1. List of defines to include or exclude specific interrupts
2. Device specific interrupt vector table
3. Interrupt functions where user code can be added

The contents of this file can be copied to the proper project source file and modified.

Renewed header files

New header files are generated according to the INI and CFGDATA files found in the MPLAB X package and will now contain more bit names and alternative bit names.

Renewed utility application SETCC

SETCC version 2.0 will use INI and CFGDATA files as found in MPLAB X. The use of mpasmx INC and LKR files has been removed.

Version 1.7 released

Support for SFR registers at low addresses

Some enhanced PIC18 core devices comes with SFR at low addresses, typically from address 0 to 0x4FF, and RAM from address 0x500. This change will enable more compact code by allowing MOVFF to be used more frequently instead of the 3-word MOVFFL instruction.

CC8E version 1.7 will accept RAM start addresses that are aligned with a 256 byte boundary. The access RAM will start with the first RAM address. The access SFR will be right before the RAM start.

Setting the RAM bank origin

The RAM bank origin is the MSB address of bank 0. The default RAM bank origin is 0. However, it is possible to set the RAM bank origin to a new position for variables allocated by the compiler.

 #pragma bankOrigin <N>  // map ram banks, 0->N, 1->N+1, ..
 #pragma bankOrigin      // map ram banks to actual RAM start

Or as a command line option:

 -bo<N>                  : map ram banks, 0->N, 1->N+1, ..
 -bo                     : map ram banks to actual RAM start

Example: Bank origin 5 is equal to address 0x500 which is the RAM start of some enhanced PIC18 core devices. Using bank origin 5 (#pragma bankOrigin 5, #pragma bankOrigin, -bo5 or -bo) means that bank 0 variables will be mapped to address 0x560-0x5FF, bank 1 to address 0x600-0x6FF, etc.

The obvious usage is to enable RAM allocation as if RAM started at address 0. Another usage is for redirecting variable allocation in generic SW modules. Setting a new bank origin is possible for all devices.

The access bank is not affected by the bank origin setting. RAM allocation using absolute addresses will not be affected by the bank origin.

Version 1.6G released

Version 1.6F released

Version 1.6A released

Version 1.6 released

Support for new enhanced PIC18 core

The enhanced PIC18 core has two major improvements:

1. Support for up to 16 kB RAM
2. Interrupt vector table support allowing a dedicated interrupt function for each interrupt type including automatic context save for both high and low priority interrupts.

Compiler support includes:

• 16k byte RAM/SFR addressing (64 banks of 256 bytes)
• Interrupt vector table
• Selectable interrupt vector table or traditional high/low interrupt
• Support for extended automatic interrupt context save
• Updated address range for the LFSR instruction
• Updated format for MOVLB instruction
• New long move instruction MOFFL
• New standard instructions ADDFSR and SUBFSR

Utility application SETCC

SETCC is useful for:

1. Generating device specific header files
2. Setting config symbols for a device
3. Compiling projects

Reasons for generating header files using SETCC:

• predefined header files may not be ready yet for new devices
• the number of register symbols can be selected
• the bit name format can be selected

The device header files supplied with the compiler can still be used.

Header file Options:

1. bit name format: REGISTERNAME_BITNAME
2. bit name format: BITNAME - limited set only
3. bit name format: combined BITNAME / REGISTERNAME_BITNAME

NOTE: The SETCC utility is only available for licensed editions.

Const data stored in dedicated functions for each table

The data type DataInW allows integer data that fits within an instruction word (16 bit) to be stored in const data tables that are mapped to dedicated functions containing data elements only (no code or return). Note that it is not possible to use DataInW outside the const table.

It is possible to read and assign the address of the const table, but without any operations. All access of data within this type of tables must be done by an application access function. It is not possible to use a table index read (dataTable[i]), fixed offset (dataTable[5]) or pointers.

 const DataInW dataTable[] = {
     1234,
     3456,
     0xFFFF,
     0,
 };

 uns8 getData( uns16 ix)
 {
     TBLPTR = (uns24) dataTable;  // get the table start address
     ix *= 2;
     TBLPTR += ix;
     tableReadInc();   // read LSB and increment TBLPTR
     return TABLAT;
 }
 ..
 uns16 ix16;
 uns8 x = getData(ix16);

 tableReadInc();    // read MSB and increment TBLPTR
 uns8 y = TABLAT;

Version 1.5 released

Support for symbolic device configuration

The available symbols for a specific device are identical to the symbols generated by MPLAB X. MPLAB X can be used to generate the required config setting for the project. The settings generated by MPLAB X can be copied and pasted into the source code for compilation.

 #pragma config <id> = <state> [, <id> = <state>]

 #pragma config OSC = INTIO7 // Internal oscillator
 #pragma config FCMEN = ON
 #pragma config IESO = ON
 #pragma config PWRT = ON, BOREN = SBORDIS

Option -VG or -Vg will list the available symbolic config settings at the end of the *.var file generated for the project. This list can be copied to a project C source file and modified to desired settings.

 -VG : list default config settings and alternatives
 -Vg : list config setting alternatives

The available config symbols are defined at at the end of the device header file according to the following format:

 #pragma config /<regNr> <value> <id> = <state>

The compiler supports both direct and symbolic setting of the device configuration (see CONFIG.TXT). It is NOT allowed to combine direct and symbolic config settings.

Starting assembler when using an ASM file as input

The compiler will start an assembler when using an ASM file instead of a C file as input. The assembler has to be defined using the -x and -X options.

Version 1.4F released

Version 1.4E released

Warning and error messages for certain pointer operations

Certain pointer operation will generate warnings. The warnings can be removed by adding a proper type cast. The first warning can be disabled by command line option -wx. The other two warnings be disabled by command line option -wz.

 // Suspicious pointer conversion   - different sign used
 // Incompatible pointer conversion - different size/type
 // Nonportable pointer conversion  - not a pointer/address

An error is generated when using a pointer as a table index.

Optimisation for overlapping bit parameters

Parameter transfer can be omitted for functions sharing overlapping bit parameters.

 bit sharedBitPar;
 bit func2( bit par @ sharedBitPar )
 { /*..*/ return Carry; }
 bit func1( bit par @ sharedBitPar )
 { /*..*/ return func2( par ); }

Optimisation of certain expressions

 uns8 a8, b8;
 uns16 u16;
 a8 = (a8 & 0xF) + 1;
 a8 = (b8 & 0x40) == 0;
 a8 = u16 / 16;
 a8 = !b8.3;
 W = u16 / 4;  // 8,16,32,64,128
 u8 = u16 / 8;  // 16,32,64

Generating a HEX file with data only (no code)

It is possible to successfully compile a source file that contains data only. Typically the source code will contain #pragma cdata statements with FLASH or EEPROM data.

Syntax enhancements

 char *pi;
 struct stxx *pxx;
 pxx = (struct stxx *) pi;  // struct/union type cast     

UTF byte order mark in the start of a source file

The UTF-8 representation of the Byte Order Mark is the byte sequence 0xEF,0xBB,0xBF. This sequence is allowed in the start of a source file.

Version 1.4D released

COFF debugging file

Command line option -CF will generate a COFF file (*.cof) for debugging in the MPLAB X environment.

Version 1.4C released

Version 1.4B released

Version 1.4A released

Version 1.4 released

Version 1.3F released

Version 1.3E released

Version 1.3D released

Version 1.3C released

Automatic search in installed directory for include files

The compiler will automatically search in the installed directory for include files. This means that option -I"C:Program Files\bknd\CC8E" or similar is not required to include device header and math header files. The search in the installed directory is done after other directories specified using option -I have been searched.

Version 1.3B released

PIC18LF and PIC18F devices use same header file

The compiler will include the header file for the corresponding F device when working with a LF device. These header files are normally identical except for the device name. An option will disable this merging and allow a separate header file for the LF device:

  -csh : include separate chip header file for 'LF' devices

Warning for read-modify-write sequences on the same PORT

The compiler will check read-modify-write instruction sequences on the same PORT, and generate a warning if a failure may occur. Such sequences consist of a read-modify-write (or write) instruction immediate followed by a read-modify-write instruction on the same PORT. This may result in wrong output state on some PORT pins depending on CPU speed and capasitive load on the PORT pins. The problem (and warning) can be avoided by doing the last read-modify-write operation on the LATCH register instead of the PORT register. The warning can be removed by the following option:

  -wf : no warning for read-modify-write sequences on the same PORT

Version 1.3 released

The STANDARD edition now supports 32 bit integers

Improved code generator

The code generator has been improved for for signed right shifts and some other special cases.

Applications requiring compatibility with old compiler versions can use the following:

  -cl0 : option to use old code generator for whole application

 #pragma codeLevel 0
 // use old code generator in this region
 ..
 #pragma codeLevel 1

NOTE: A full update agreement valid on the version 1.3 release date is required to get an update that will use the improved code generator.

New internal function offsetof( struct_type, struct_member)

Function offsetof() returns the offset to a structure member. The first argument must be a struct type, and the second a structure member. The function can also be used in a preprocessor expression.

 typedef struct sStx {
     char a;
     uns16 b;
 } Stx;

 x = offsetof( Stx, b);
 x = offsetof( struct sStx, a);
 x = offsetof( struct_x, member_n.sub2.q[3]);

List file with no page formatting

Option -Ln will produce a list file with no page formatting.

Version 1.2B released

Support of the standard __LINE__ and __FILE__ macros

Simplified state definition for multitasking

Task states normally have to be enumerated from 1..N with no missing numbers in between. It is now possible to use an undefined symbol to represent the state without any state numbering conflicts. The compiler defines any unknown symbols and missing state numbers to the lowest unused state numbers. Defined state number can be mixed with unknown state numbers.

 enum { SA = 1, X_STATE = 3 };
 ..
 waitState(SA);        // defined state number (1)
 ..
 waitState(X_STATE);   // defined state number (3)
 ..
 waitState(ST_Z); // state defined by compiler (2)
 ..
 waitState();     // state defined by compiler (4)
 ..
 changeState(ST_Z);    // return to state ST_Z

Alternative assignment of command line symbols

Symbols defined on the command line normally use '=' to separate the symbol and the symbol contents. It is now possible to use most ASCII token different from letters, numbers and '_' to mark the end of the symbol. This makes it easier to avoid command line interpretation conflicts. Examble:

 -DMY_SYMBOL:100
   is equivalent to:
 #define   MY_SYMBOL   100

Version 1.2A released

Automatic updating of ADSHR

Some devices use double SFR registers on the same address, using the ADSHR register bit to separate them. The ADSHR register will be updated automatically by the compiler (similar to the bank register). Manual updating of ADSHR will be removed. The setup is found in the header file.

 char OSCCON @ 0xFD3; //selected when ADSHR is 0
 char REFOCON @ 0xFD3; //selected when ADSHR is 1

The automatic updating of ADSHR can be switched off by the option -ban.

Standard MPASM EQU symbols can define config settings

Complete example setup is found in file CONFIG.TXT.

 #pragma config[_CONFIG2L] = _PWRT_ON_2L & \
                             _BOREN_OFF_2L

Multiple include paths can be separated by semicolons

A single -I option may contain multiple include paths separated by semicolons (instead of using separate -I options).

 -Ic:\path\to\inc1;c:\path\to\inc2;\inc3;inc4

Extended search for include files

The compiler can search more directories for include files when using option -cif. Step 3) and 4) are the default search for include files that are performed without this option.

1. in the directory that contains the file being compiled
2. if the file being compiled was included from another file, then the directory containing this file is searched. This is repeated until the directory of the initial (root) file has been searched.
3. in current directory (where the compiler was started). This step is NOT performed when using #include <file> or option -cxc.
4. in include directories defined by the -I option

Multiline comment allowed in #define

A comment after #define may end at a following line:

 #define M1  1  /* This comment
                   is legal */

Version 1.2 released

Stack allocation alternatives

The stack for local variables, parameters and temporary variables is normally allocated separately in each bank and the access bank. The bank is normally defined the same way as global variables through #pragma rambank or bank type modifiers. This makes it possible to split the stack into several independent stacks. Using a single stack is normally recommended, but sometimes this is not possible when the stack size is too large.

It is possible to use a single main stack for all local variables. The main stack is not an additional stack, but tells the compiler where the main stack is located (which bank). The main stack can be larger than a single bank, and is defined by the following pragma statement:

 #pragma mainStack 3 @ 0x110

Using this pragma means that local variables, parameters and temporary variables of size 3 bytes and larger (including tables and structures) will be stored in a single stack allocated no lower than address 0x110. Smaller variables and variables with a bank modifier will be stored according to the default/other rules. Using size 0 means all variables including bit variables.

Note that #pragma rambank is ignored for variables stored in the main stack. Address ranging from 0x100 to 0x1FF are equivalent to the bank1 type modifier, although the actual bank will be different after stack allocation for some variables if the main stack cross a bank boundary.

In some cases it will be efficient to use the access bank or a specific bank for local variables up to a certain size. This is possible by using the following pragma:

 #pragma minorStack 2 @ 0x10

In this case, local variables, parameters and temporary variables up to 2 bytes will be put in the access bank from address 0x10 and upward. Larger variables and variables with a bank modifier will be stored according to the default/other rules. Using size 0 means bit variables only. This pragma can be used in combination with the main stack. The variable size defined by the minor stack have priority over the main stack.

The most efficient RAM usage is to use a single stack. Separation into different stacks increase total RAM usage, and should be avoided if possible.

Strongly improved SQRT rutine

The new square root routine developed by Jim van Zee, Seattle, executes fast (1/3 of the time) and is small (save more than 50 % code). An additional benefit is improved accuracy. The routine is available for 24 and 32 bit floating point. The new routine is automatically used when including "math24lb.h" or "math32lb.h".

Option for chip redefinition

MPLAB supplies the option -p<chip> automatically. Sometimes this is not desirable. The new option -p- will clear any preceding -p<chip> to allow chip redefinition, either by a new -p<chip> or a #pragma chip statement.

Version 1.1F released

Macros can be used in #include files

The following examples show the possibilities. Note that this is not standard C.

 #include "file1" ".h" 
 #define MAC1 "c:\project\"
 #include MAC1 "file2.h"
 #define MAC2 MAC1 ".h"
 #include MAC2
 #define MAC3 <file3.h>
 #include MAC3

RULES:

1. Strings using "" can be splitted, but not strings using <>
2. Only the first partial string can be a macro
3. Nested macros is possible
4. Only one macro at each level is possible

Improved debugging support

The COD file now supports data above address 0xFFFF. This allow larger programs, config and ID locations to be defined in the COD file.

Support of CCINC and CCHOME

Environment variables can be used to define include folders and primary folder.

Variable CCINC is an alternative to the -I<path> option. The compiler will only read this variable (or specified variable) when using the following command line option:

 -li  : read default environment variable CCINC
 -li<ENVI> : read specific environment variable

Variable CCHOME can be used to define the primary folder during compilation. The compiler will only read this variable (or specified variable) when using the following command line option:

 -lh  : read default environment variable CCHOME
 -lh<ENVP> : read specific environment variable

Version 1.1E released

Version 1.1D released

New type modifier 'shadowDef'

The 'shadowDef' type modifier allow local and global variables and function parameters to be assigned to specific addresses without affecting normal variable allocation. The compiler will ignore the presence of these variables when allocating global and local variable space.

 shadowDef char gx70 @ 0x70;  // global or local

The above definition allow location 0x70 to be inspected and modified through variable 'gx70'.

Assigning function parameters to specific locations

Function parameters can be assigned to addresses. No other variables will be assigned by the compiler to these locations. Such manual allocation can be useful when reusing RAM locations manually.

 void write(char addr @ 0x70, char value @ 0x71)
 { .. }

This syntax is also possible on function prototypes.

Support for mapped CONFIG data on PIC18FxxJ1x

The compiler and header files for these devices has been updated to allow the config data to be stored at the end of the FLASH program data. The config data should be specified as normal (see CONFIG.TXT):

 #pragma config[0] = 0b.1.000.0101 

Version 1.1C released

Support for __config and __idlocs

The compiler will use __config and __idlocs in the generated assembly file when #pragma config is used in the C source. The old assembly format is still available by using the command line option -cfc.

Macros __DATE__ and __TIME__

Macros for date and time are defined when compilation starts.

 Macro      Format          Example
 __TIME__   HOUR:MIN:SEC    "23:59:59"
 __DATE__   MONTH DAY YEAR  "Jan 1 2005"
 __DATE2__  DAY MONTH YEAR  " 1 Jan 2005"

Version 1.1B released

Custom warnings and simple messages

A custom warning or a simple message can be printed in the compiler output and to the .occ file. Option -S will suppress this. "warning" and "message" are not reserved keywords. Note that these directives are not standard C.

 #message This is message 1
 #message This is message 2
 #warning This is a warning

The following output is produced:

 Message: This is message 1
 Message: This is message 2
 Warning test.c 7: This is a warning

Version 1.1A released

Functions shared between independent call trees

An error message is normally printed when the compiler detects functions that are called both from main() and during interrupt processing if this function contains local variables or parameters. This also applies to math library calls and const access functions. The reason for the error is that local variables are allocated statically and may be overwritten if the routine is interrupted and then called during interrupt processing.

The error message can be changed to a warning by the following pragma statement. Note that this means that local variable and parameter overwriting must be avoided by careful code writing.

 #pragma sharedAllocation

16 bit computed goto

The skip inline function can use a 16 bit argument. This requires normally 11 instructions (14 instructions when a 64k byte boundary is crossed). When using relocatable assembly 14 instructions are used on devices with more than 64k byte memory.

 uns16 s16;
 ..
 skip(s16);
 // skip to any instruction in a 65536 word table
 // offset 0 is the first instruction in the table
 // offset 1 is the next word in the table

 /* skipM(s16) must be used when the table contains
    double word instructions. The second word of a
    double word instruction executes a NOP if
    jumped to. */

 /* The following pragma is recommended if the
    function does not end immediate */
 #pragma computedGoto 0
 /* Optional C statements after the table */
 } /* end of function */

Improved inline assembly

The following address operations is possible when the variable/struct/array set to a fixed address.

 char tab[5] @ 0x110;
 struct { char x; char y; } stx @ 0x120;
 #asm
 MOVLW tab
 MOVLW &tab[1]
 MOVLW LOW &tab[2]
 MOVLW HIGH &tab[2]
 MOVLW UPPER &tab[2]
 MOVLW HIGH (&tab[2] + 2)
 MOVLW HIGH (&stx.y)
 MOVLW &stx.y
 MOVLW &STATUS
 #endasm

Output from preprocessor

The compiler will write the output from the preprocessor to a file (.CPR) when using the -B command line option. Preprocessor directives are either removed or simplified. Macro identifiers are replaced by the macro contents.

 -B[pims] : write preprocessor output to <src>.cpr
    p : partial preprocessing
    i : .., do not include files
    m : .., modify symbols
    s : .., modify strings

When using the alternative preprocessing formats (-Bpims), compilation will stop after preprocessing.

Version 1.1 released

Direct coded instructions

The file "hexcodes.h" contains C macros that allow direct coding of instructions.

Note that direct coded instructions are different from inline assembly seen from the compiler. The compiler will view the instruction codes as values only and not as instructions. All high level properties are lost. The compiler will reset optimization, bank updating, etc. after a DW statement.

 Example usage:
 #include "hexcodes.h"
 ..
 // 1. In DW statements:
 #asm
 DW __DECF(__FSR0L,__F,0) // Decrement FSR0L
 DW __CLRF(0xFF,1,1) // Clear ram (banked access)
 DW __BCF(__STATUS,__Carry,0) // Clear Carry bit
 DW __GOTO(0) // Goto address 0
 #endasm
 ..
 // 2. In cdata statements:
 #pragma cdata[1] = __GOTO(0x3FF)

RAM bank update settings

#pragma updateBank can be used to instruct the bank update algorithm to do certain selections. These statements can only be used inside the functions:

 #pragma updateBank entry = 0
 /* The 'entry' bank force the bank bits to be set
 to a certain value when calling this function */

 #pragma updateBank exit = 1
 /* The 'exit' bank force the bank bits to be set 
 to a certain value at return from this function */

 #pragma updateBank default = 0
 /* The 'default' bank is used by the compiler at
 loops and labels when the algorithm give up
 finding the optimal choice */

Origin alignment

It is possible to use #pragma origin to ensure that a computed goto inside a function does not cross a 256 byte address boundary. However, this may require many changes during program development. An alternative is to use #pragma alignLsbOrigin to automatically align the least significant byte of the origin address. Note that this alignment is not possible when using relocatable assembly. Relocatable assembly requires another approach to fix the address. This is found in Section Using code sections on page 74 in Chapter 6.8 Linker Support.

Example: A function contain a computed goto. After inspecting the generated list file, there are 15 instructions words between the function start and the address latch update instruction (MOVF PCL, W,0 updates PCLATH and PCLATU). The last computed goto destination address (offset 10) resides further 2 + 10 instructions words below the address latch update instruction. A fast a compact computed goto requires that these addresses resides on the same "byte page" (i.e. (address & 0xFFFF00) are identical for the two addresses). This is achieved with the statement:

#pragma alignLsbOrigin -(15+1)*2 to 254 - (2+10)*2 - (15+1)*2

The alignment pragma statement is not critical. The compiler will generate an error (option -GS) or a warning (-GW) if the computed goto cross a boundary because of a wrong alignment. An easier approach is to align the LSB to a certain value (as long as program size is not critical).

 #pragma alignLsbOrigin 0 // align on LSB = 0
 #pragma alignLsbOrigin 0 to 190 // [-254 .. 254]
 #pragma alignLsbOrigin -100 to 10

Improved const data initialization

Floating point constant expressions.

Complex address calculations.

Enum-symbols allowed.

Version 1.0I released

Improved integer math

New math library functions for 16*16 and 32*16 bit multiplication, signed and unsigned.

Inline multiplication will now optimize for speed instead of size for signed integer multiplication. Optimization for size on inline multiplication (signed and unsigned) can be forced by command line option -zZ.

Version 1.0H released

Switch statements of 16, 24 and 32 bit

The switch statement now supports variables up to 32 bit. The generated code is more compact and executes faster than the equivalent 'if - else if' chain.

Version 1.0G released

Macro stringification and concatenation

The concatenation operator ## allows tokens to be merged while expanding macros. The stringification operator # allows a macro argument to be converted into a string constant.

Version 1.0F released

Syntax improvements

Multiple assignment:

 a = b = c;

Allowing the increment operator on the left side of a statement:

 ++i;
 --x;

Improved "increment" part of the 'for' statement :

 for (i=0; i<5; a.b[x]+=2) ..

Better paranthesis support :

 *(p)
 (p)[0]
 &(l.a)

Better 'enum' support :

 typedef enum ..
 enum con { Read_A, .. };
 enum con mm;
 mm = Read_A;

Placing the interrupt routine anywhere

The interrupt routine normally have to reside on address 8 and 0x18. The following pragma statement will allow the interrupt routine to be placed anywhere. Note that the compiler will NOT generate the link from address 8/0x18 to the interrupt routine automatically.

 #pragma unlockISR

Placing 'const' data anywhere

The compiler will normally insert 'const' data at the end of the user code (high address). The following pragma statement will allow the 'const' data to be inserted between two user functions, or at a specific address (if using #pragma origin first):

 #pragma insertConst

Printing key info in the assembly file

The compiler will print info at the end of the assembly file. Total code size, maximum call level, RAM usage. In addition, the size of each function is printed. Command line option -Au removes this information.

Version 1.0E released

Creating and updating linker scripts automatically

The compiler can create and update linker scripts automatically when using the -rsc[=<file.lkr>] command line option. More details are found in LINKER.TXT.

Version 1.0D released

Version 1.0C released

Version 1.0B released

Version 1.0A released

Detailed multiline macro expansion in assembly file

Single lines from multiline macros are printed in the generated assembly file when using command line option -AR. This is sometimes useful to improve readability when expanding very long macros.

Recursive printing of errors in macros

If there is a syntax error in a defined macro, then it may be difficult to decide what the problem actually is. This is improved by printing extra error messages which points to the macro definition, and doing this recursively when expanding nested macros.

Automatic incrementing version number on file

CC8E is able to automatically increment one or more version numbers for each compilation. Syntax supported:

1. Option : -ver#verfile.c

 #include "verfile.c" // or <verfile.c>

2. Option : -ver

 #pragma versionFile // next include is version file
 #include "verfile.c" // or <verfile.c>

3. Option : -ver

 #pragma versionFile "verfile.c" // or <verfile.c>

Note that the command line option is required to make this increment happen. It is the decimal number found at end of the included file that is incremented. The updated file is written back before the file is compiled. No special syntax is assumed in the version file. Suggestions:

 #define MY_VERSION 20
 #define VER_STRING "1.02.0005"
 /* VERSION : 01110 */

If the decimal number is 99, then the new number will be 100 and the file length increase by 1. If the number is 099, then the file length remains the same. A version file should not be too large (up to 20k), otherwise an error is printed.

Formats 2 and 3 above allows more than one version file. It is recommended to use conditional compilation to manage several editions of the same program.