AN3348

Functional incompatibilities

Doc ID 018510 Rev 2

5/10

3

Functional incompatibilities

After your application builds with EC, it is time to make sure it also does what it meant to do.

This section describes the main topics which should be considered when porting the code.

There are two main reasons for these incompatibilities: previous tools generated code which

do not comply with the standards and code which is written in an unsafe way which is in

times ambiguous and in times incorrect. This document would suggest the best way for

fixing the ambiguity and for writing a safer code which is not implementation dependent.

3.1

C99 and TR18037 compliance

3.1.1

Types

●

int

and fract interaction: applications which are using fract arithmetic should be

reviewed carefully. TR18037 specifically says that a conversion from fract to int

implies rounding towards 0. During porting of several functions we've noticed that

programmers used int and fract variables together as if no conversion occurs

between them (this was the Bytecraft tools behavior). If you want no conversion to

occur use the _int_from_fract intrinsic functions. Notice that the type of a variable

determines the code generated for it, for example if we multiply two fract variables

the compiler would used a fract multiplication instruction and if the variables are of

type int an int multiplication would be generated so a lot of care should be used

when reviewing such code.

●

Specifying a register should be considered as a type modifier and not as a type by

itself. If the type is not specified then the variable would be of default type int24. For

example:

register_diob x;

// x is of type int24 and is stored in diob

register_diob fract8 x; // x is of type fract8 and is stored in

// diob

●

Division of signed variables is correctly handled by the eTPU compiler whereas with

Bytecraft an unsigned division was generated. If the user meant an unsigned division

then he should change the types of variables or use casting before the division.

Note:

Signed division is much more expensive (both code size and cycles) so if you don't really

need it, make sure you use unsigned variables.

Signed bitfields are handled correctly by eTPU compiler whereas with Bytecraft it is treated

as unsigned.

3.2

Inline assembly topics

3.2.1

%hex <opcode>

During porting several applications we've noticed that in some cases users have inserted

hex

directives in their code. Although the converter has successfully converted this to a

.word

directive and the code compiles, this is a non portable feature which relies on

specific code generation. For example, if this opcode was a load from address 9 in memory

in which the user expected that a specific variable was allocated, it might be that it won't be

allocated in this location with EC. If this was a call to a function, then it encodes the address