 |
|
|
MAEC TOOL NEWS:
MAECT-M3T-NC308WA-020901D
Notes on C compiler
M3T-NC308WA V.5.00 Release 1
|
|---|
Please take note of the following problems in using C compiler (with an assembler and integrated development environment) M3T-NC308WA V.5.00 Release 1 for the M32C/80 and M16C/80 series of MCUs:
- On bit fields in a structure declared using the volatile qualifier
- On defining arrays with a list of about 6200 or more initializers
- On interrupt handling functions
- On using bit fields and _Bool type variables
- Problem on Bit Fields in a Structure Declared Using the Volatile Qualifier
- 1.1 Description
- When compiling the source program that assigns constants to bit fields in a structure declared using the volatile qualifier, codes that do not assign the specified constants may be generated.
- 1.2 Conditions
- This problem occurs if the following three conditions are satisfied:
| (1) | A structure is declared using the volatile qualifier. |
| (2) | The structure in (1) above contains a bit field of two or more unsigned bits.
Note: In M3T-NC308WA, bit fields without a type specifier of "signed" are interpreted as of type unsigned. |
| (3) |
To the bit field in (2) is assigned a constant whose value is different from either of the following:
* The maximum unsigned integer constant expressed by the total bits of the bit field concerned (For example, 7 for 3 bits.)
* Zero |
- 1.3 Example
[C-language source program]
-----------------------------------------------------------------------
volatile struct { /* Condition (1) */
int m:3; /* Condition (2) */
} vs;
void func(void)
{
vs.m = 5; /* Condition (3) */
}
-----------------------------------------------------------------------
[Incorrectly generated codes]
-----------------------------------------------------------------------
mov.w _vs:16,R0
and.w #0ffffH,R0 ; Assignment has no effect.
mov.w R0,_vs:16
-----------------------------------------------------------------------
[Codes to be correctly generated]
-----------------------------------------------------------------------
mov.w _vs:16,R0
and.w #0fff8H,R0
or.w #05H,R0
mov.w R0,_vs:16
-----------------------------------------------------------------------
- 1.4 Workaround
- This problem will be circumvented in any of the following ways:
| (1) |
Declare a temporary structure of the same type as the structure concerned but not volatile, assign the whole of the original structure to the temporary one, and then assign a constant to the bit field in the temporary structure. Finally, assign the whole temporary structure to the original one. |
| (2) | Declare the bit field to be of type signed, if possible. |
| (3) |
Once assign the constant to a temporary variable of type int and then assign it from this variable to the bit field. At this time, be sure to place a dummy asm function immediately after the assignment of the constant to the variable. |
[Example of workaround (1)]
-----------------------------------------------------------------------
volatile struct tagA {
int m:3;
} vs;
void func(void)
{
struct tagA tmp = vs; /* The whole structure assigned
to the temporary one */
tmp.m = 5; /* A constant assigned to the bit field
in the temporary structure */
vs = tmp; /* The whole temporary structure assigned
to the original one */
}
-----------------------------------------------------------------------
[Example of workaround (2)]
-----------------------------------------------------------------------
volatile struct {
signed int m:3; /* Bit field declared to be of type signed */
} vs;
-----------------------------------------------------------------------
[Example of workaround (3)]
-----------------------------------------------------------------------
volatile struct {
int m:3;
} vs;
void func(void)
{
unsigned int tmp = 5; /* A constant assigned
to the temporary variable */
asm(); /* A dummy asm function placed */
vs.m = tmp; /* The temporary variable assigned
to the bit field */
}
-----------------------------------------------------------------------
- 1.5 Schedule of Fixing the Problem
- We plan to fix this problem in our next release.
Notes on C compiler M3T-NC308WA V.5.00 Release 1
MAECT-M3T-NC308WA-020901D
- Problem on Defining Arrays with a List of About 6200 or More Initializers
- 2.1 Description
- When the source program that defines arrays with a list of about 6200 or more initializers is compiled, the compilation may be forced to terminate.
- 2.2 Conditions
- This problem occurs if the following two conditions are satisfied:
| (1) | An array with initializers is defined as an external variable. |
| (2) |
About 6200 or more consecutive initializers are written within a pair of braces.
Note:
In OSes other than Windows, the smallest number of initializers at which the problem arises varies with operating environments such as memory size and versions of each OS, so this problem might not occur even if the number of initializers is about 6200.
We have confirmed that in our operating environments on Solaris, this problem occurs if the number of initializers exceeds about 37000. |
- 2.3 Examples
-----------------------------------------------------------------------
/* Example in a one-dimensional array */
const unsigned int array1[] = {
0, 1, 2, . . . , 6199 /* 6200 initializers */
};
/* Example in a two-dimensional array */
const unsigned int dim2[5000][3] = {
0, 1, 2, 3, 4, . . . , 14999 /* 15000 initializers */
};
-----------------------------------------------------------------------
- 2.4 Workaround
- This problem will be circumvented in either of the following ways:
| (1) | In a one-dimensional array, split the array into several arrays with about 5000 elements or less each. If the split arrays are of the same type, they can be continuously arranged by defining them successively. |
| (2) |
In a multi-dimensional array, if the number of elements referred to by the last subscript is 5000 or less, enclose the initializer list for the number of elements referred to by each subscript within a pair of braces.
If the number of elements referred to by the last subscript exceeds 5000, split its initializer list into several ones the same way as explained in (1). |
[Example of workaround (1)]
-----------------------------------------------------------------------
const unsigned int array1[] = {
0, 1, 2, . . . , 4999 /* 5000 elements
in the first split array */
};
const unsigned int array1_2[] = {
5000, 5001, . . . , 6200 /* The remaining elements
in the second split array */
};
-----------------------------------------------------------------------
[Example of workaround (2)]
-----------------------------------------------------------------------
const unsigned int dim2[5000][3] = {
{ 0, 1, 2 }, /* The number of elements enclosed in each of
the innermost pairs of braces is made 5000 or less */
{ 3, 4, 5 },
. . . . . . ,
{ 14997, 14998, 14999 }
}
-----------------------------------------------------------------------
- 2.5 Schedule of Fixing the Problem
- We plan to fix this problem in our next release.
Notes on C compiler M3T-NC308WA V.5.00 Release 1
MAECT-M3T-NC308WA-020901D
- Problem on Interrupt Handling Functions
- 3.1 Description
- At the entering and the exiting process of an interrupt handling function, the R0 register may not be saved on and recovered from the stack even though it must be done so.
- 3.2 Conditions
- This problem may occur if any of the following functions is used:
- (1) A function defined by #pragma INTERRUPT (/B not used)
- (2) A function defined by #pragma INTHANDLER
- (3) A function defined by #pragma HANDLER
- (4) A function entered in the interrupt vector definition table (interrupt_vector) in the configuration file of M3T-MR308
- 3.3 Example
[C-language source file]
-----------------------------------------------------------------------
#pragma INTERRUPT intfunc
int i, j;
void intfunc(void)
{
if (i == 0)
i = i << j;
}
-----------------------------------------------------------------------
[Generated codes in assembly language after compilation]
-----------------------------------------------------------------------
.glb _intf
_intf:
pushm R1 ; R0 is not saved on the stack.
mov.w _i:16,R0 ; A write is made into R0.
jne L1
mov.b _j:16,R1H
neg.b R1H
sha.w R1H,_i:16
L1:
popm R1 ; R0 is not recovered from the stack.
reit
-----------------------------------------------------------------------
- 3.4 Workaround
- If this problem arises, compile source programs using option "-fSARII(-fsave_all_register_in_interrupt)". Though this option is not found in the user's manual, it can save and recover all the registers at interrupt services the same way as the previous versions.
However, note that this option makes interrupts serviced much slower, so use it only when this problem should be circumvented.
- 3.5 Schedule of Fixing the Problem
- We plan to fix this problem in our next release.
Notes on C compiler M3T-NC308WA V.5.00 Release 1
MAECT-M3T-NC308WA-020901D
- Problem on Using Bit Fields and _Bool Type Variables
- 4.1 Description
- When a bit field or a_Bool type variable declared to be an external variable is referenced after a constant is assigned to the variable and then a function is called, the variable may not correctly be referenced even if its value is rewritten by the function called.
- 4.2 Conditions
- This problem may occur if the following six conditions are satisfied:
| (1) | Any of the -O, -O[1-5], -OR, and -OS optimizing options is used. |
| (2) |
A structure containing a bit field or a _Bool type variable is declared to be an external variable without the volatile qualifier. |
| (3) | A constant is assigned to the variable in (2). |
| (4) | After the assignment in (3), a function is called. |
| (5) | After the function call in (4), the variable to which a constant is assigned in (3) is referenced. |
| (6) |
The value of the variable in (2) is rewritten only by the function in (4) or its inner functions during the sequence from (3) to (5); no other rewrites are made. |
- 4.3 Example
-----------------------------------------------------------------------
struct { /* Condition (2) */
char bf:3;
} s;
int i;
void sub(void)
{
s.bf = 0; /* Condition (6) */
}
void func(void)
{
s.bf = 5; /* Condition (3) */
sub(); /* Condition (4): s is rewritten in sub() */
if (s.bf == 5) { /* Condition (5) */
i = 0;
}
}
-----------------------------------------------------------------------
- 4.4 Workaround
- This problem will be circumvented in either of the following ways:
- (1) Place a dummy asm function immediately before referencing the variable in (5).
- (2) Declare the structure or _Bool type variable using the volatile qualifier.
- 4.5 Schedule of Fixing the Problem
- We plan to fix this problem in our next release.
|
|
