TASKING VX-toolset for C166 v2.2r2
RELEASE NOTE

When using the product without a valid license, the tools will run in trial mode. This means you can use the toolset 15 days with full functionality. When running in trial mode, each tool will report the number of days left. When using a license that does not cover the full toolset, the tools that are not covered by the license will run in trial mode.

When after installing the license file the tools that are covered by the license still report that they are running in trial mode, this means that there is a license error. If you want to force the termination of the trial mode to get the FLEXlm error message you can set the environment variable FORCE_NO_TRIAL to "yes".

STLPort IO-stream Libraries

The STLPort io-stream libraries are included for all data models. When you want to use the io-stream libraries and you are using single precision float (-F option) or the user-stack model (--user-stack option) you will have to build these libraries from the sources. See the User Guide Chapter 11 for more information on building these libraries.

Application Wide Compilation: MIL Linking

MIL Linking

The C compiler frontend always produces an intermediate representation of the translated C file(s). This intermediate code, called MIL (Medium level Intermediate Language), is normally stored in memory and from there directly processed by the backend. With the compiler options --mil and --mil-split, the MIL code is written into a file. When this file is fed again to the compiler, only the backend will be executed to produce assembly code. When passing all MIL files of your application at once to the compiler it will link these files and produce a single assembly source file. This process is called MIL Linking.

The advantage of MIL linking is that the compiler has an application wide scope and can perform application wide checks and optimizations, such as inlining and code compaction. Because the backend now always compiles the whole application at once, the compilation process will take more time if only few modules are changed. To reduce this disadvantage to a minimum, the compiler supports the --mil-split option. When supplying this option the compiler will perform MIL linking of all input files, and then splits the linked MIL code into multiple intermediate files, one per input file. If an existing MIL file exists, the compiler will only overwrite it if the result would be different. This effectively allows a builder tool, such as make, to run the backend only on MIL files that have actually changed.

Because the linked MIL stream of the whole application is split into modules after MIL linking, it is possible that a modification in one module requires multiple MIL files to be updated. A simple example is a function that inlined by the compiler in multiple locations spread over multiple files. When modifying this function all files where it is inlined must be build again.

MIL Archives

The compiler can link libraries of MIL files, called MIL archives. The filename suffix of MIL archives is .ma. The C libraries are included as MIL archives in the same variants as the object library versions. MIL archives can be created with the archiver, ar166, included in the product.

Eclipse

In Eclipse you can enable MIL linking as follows:

1. Open the Project -> Properties dialog.
2. Select Global Options.
3. Enable the option Link the MIL representation of all modules.

Static Profiling

When enabling static profiling the compiler will generate profile information through various heuristics and estimates. Static profiling can give you a reasonable impression of te critical parts of the application and does not require any run-time resources, but it is less accurate than dynamic profiling.

See the User Guide, section 6.3. Profiling at Compile Time (Static Profiling) for more information on static profiling.

Changed Section Names

The default compiler section naming convention is changed to {name}_{type} to make it easier to find a section in the map file. The {name} is the name of the C level object (variable or function name) and the {type} is te memory type of the section (bit, bita, near, far, shuge, huge, code). If your project's LSL file relies on the section names as generated in previous versions, you can change the section naming with the --rename-sections={type} C compiler option. Or in Eclipse, goto Project -> Properties -> Settings -> C/C++ Compiler -> Allocation, and add an item {name} to the Rename sections list

Alignment of char Arrays Changed to Byte Aligment

Arrays of the type char are now aligned at a single byte. In previous versions the word alignment could cause problems when code relied on struct field alignment as used in the classic toolset. With this change, the alignment of struct members is now equal to the classic toolset. This change may result in a small decrease of execution speed when copying char arrays from or to the stack, because this will now be done per byte instead of per word.

Clearing of Global and Static Bit Variables

A new option is added:

--no-clear-bit
Don't clear non-initialized global/static bit variables. This option is the same as --no-clear, except that it only applies to __bit variables.

New pragmas:

#pragma clear_bit
Performs 'clearing' of non-initialized global/static bit variables.
#pragma noclear_bit
Performs no 'clearing' of non-initialized global/static bit variables.

Controlling Stack Conversion

A new option is added:

--stack-address-conversion=mode
Control how stack addresses are converted to __far and __(s)huge addresses:

• static: Use the linker generated stack symbol. This is the default and is the same as in previous versions.
• fixed-dpp: Use the DPP register that refers to the linker generated stack symbol.
• dynamic: Determine the used DPP register dynamically.

New pragma:

#pragma stack_address_conversion
Control how stack addresses are converted. Same as compiler option: --stack-address-conversion.

Examples:

__far int *fp;
void foo( void )
{
	int arr[100];
	fp = &arr[10];
	.
	.
	.
}

The code generation for the three variants for the line:

	fp = &arr[10];

With static:

	movw	r11,#0x14
	addw	r11,r15
	movw	r12,#@pag(__lc_ub_user_stack+0xffff)
	movw	_fp,r11
	movw	_fp+0x2,r12

With fixed-dpp:

	movw	r11,#0x14
	addw	r11,r15
	movw	r12,@dpp(__lc_ub_user_stack+0xffff)
	movw	_fp,r11
	movw	_fp+0x2,r12

With dynamic:

	movw	r11,#0x14
	addw	r11,r15
	movw	r12,r11
	shr	r12,#0xe
	shl	r12,#0x1
	addw	r12,#0xfe00
	movw	r12,[r12]
	movw	_fp,r11
	movw	_fp+0x2,r12

With the static setting the DPP that is used for the stack can only be loaded with the page number at startup. With the fixed-dpp or dynamic setting it is possible to change the DPP contents dynamically afterwards. This can be useful in for example an RTOS that uses a separate page for each task's stack.

SFR Byte-Write Problems

In versions prior to v2.1r4 the compiler optimizes a write of an integer or integer bit-field that would only change one of the bytes in the integer to a byte-write operation. This also applies to SFR bitfield writes, but this is not allowed because this clears the complementary byte in the SFR word.

Changed system LSL files

The common derivative definition is moved from the arch_*.lsl files to the derivative lsl files. The moved defition includes the core and bus defition and the reserved memories for the SFR areas. In case you copied the derivative lsl file (e.g., xc167ci.lsl) to your project before you will get a linker error:

E821: syntax error: base derivative common_core not found for derivative derivative

To fix this, copy the new derivative lsl file from the system directory and make apply your changes to the memories again.

Paging Behavior of LSL Changed

In versions prior to v2.1r3, a section lost all page attributes as soon as it was selected with a group...select statement in LSL. It was assumed that the user respected the page restrictions with the new group attributes. In practice this was often forgotten, leading to unexpected problems in the application. Therefore the linker now keeps the section's page restrictions. This may lead to some problems in existing LSL files, where sections are located explicitly on or over a page boundary. When locating a near, far or shuge section exactly at a page start, the linker does not allow that because the first byte of each page is reserved to avoid NULL pointer problems. But in case you know that these problems won't occur with the section that you want to put there, it is possible to overrule the page attributes by adding the page_size=0 and page attributes to the group definition.

Example:

group ( ordered, load_addr = 0xC10000, page_size = 0, page )
{
	select "somesection";
}

New copy Attribute in LSL for vector_table

To make it possible to create a copy of the vector table in LSL, the vector_table statement is extended with the copy attribute. When this attribute is specified the linker makes a ROM copy of the vector table that is copied to the run-time address at startup. The linker creates entries in the copytable for this.

Example:

vector_table "vector_table" ( run_addr = mem:spe:PSRAM[0], vector_size = 4, size = 128,
				template="__vector_template", template_symbol="__lc_vector_target",
				vector_prefix=".vector.", fill=loop, copy)

Change in LSL Editor Reserved Page

The LSL editor now generates reserve statements for reserved ranges. For example:

section_setup ::code
{
    reserved 0x4000 .. 0x7fff;
}

Using __DTC_IGNORE to Avoid Update by Target Board Configuration Wizard

In Eclipse the Project -> Target Board Configuration wizard by default updates the LSL file in your project. If you don't want that to happen, just define the macro __DTC_IGNORE in the LSL file:

#define __DTC_IGNORE

Infineon EasyKit Boards and Wigglers

This version of the TASKING VX-toolset for C166 installs DAS v2.6.2. This enables the support for the new Infineon evaluation boards and the onboard USB wiggler and the Infineon miniWiggler II. To select these wigglers in the TASKING debugger, you should use the Target Board Configuration (Project menu). First select the target board and then select the appropriate wiggler from the "Communication" list.

The DAS parallel port drivers have been updated to v2.4.0 in this version.