CC8E C Compiler

CC8E
PRICES
BUY NOW
DOWNLOAD

Introduction
Features

- supported chips

News red_ball.gif (129 bytes)
Examples
FAQ
Feedback
Support
Distributors

CC5X
Leanslice
HOME

NEWS

The newest features are listed first.

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.

End line