Selecting data types

In this section:

For efficient treatment of data, you should consider the data types used and the most efficient placement of the variables.

Using efficient data types

The data types you use should be considered carefully, because this can have a large impact on code size and code speed.

Use small and unsigned data types, (unsigned char and unsigned short) unless your application really requires signed values.
Try to avoid 64-bit data types, such as double and long long.
Bitfields with sizes other than 1 bit should be avoided because they will result in inefficient code compared to bit operations.
When using arrays, it is more efficient if the type of the index expression matches the index type of the memory of the array.
Using floating-point types on a microprocessor without a math co-processor is very inefficient, both in terms of code size and execution speed.
Declaring a pointer parameter to point to const data might open for better optimizations in the calling function.

For information about representation of supported data types, pointers, and structures types, see Data representation.

Floating-point types

Using floating-point types on a microprocessor without a math coprocessor is inefficient, both in terms of code size and execution speed. Therefore, you should consider replacing code that uses floating-point operations with code that uses integers, because these are more efficient.

The compiler supports two floating-point formats—32 and 64 bits. The 32-bit floating-point type float is more efficient in terms of code size and execution speed. The 64-bit format double supports higher precision and larger numbers.

In the compiler, the floating-point type float always uses the 32-bit format. The format used by the double floating-point type depends on the setting of the ‑‑double compiler option.

For more information about floating-point types, see Basic data types—floating-point types.

Alignment of elements in a structure

The RL78 microcontroller requires that data in memory must be aligned. Each element in a structure must be aligned according to its specified type requirements. This means that the compiler might need to insert pad bytes to keep the alignment at 2.

There are situations when this can be a problem:

There are external demands, for example, network communication protocols are usually specified in terms of data types with no padding in between
You need to save data memory.

For information about alignment requirements, see Alignment.

Use the #pragma pack directive or the __packed data type attribute for a tighter layout of the structure. The drawback is that each access to an unaligned element in the structure will use more code.

Alternatively, write your own customized functions for packing and unpacking structures. This is a more portable way, which will not produce any more code apart from your functions. The drawback is the need for two views on the structure data—packed and unpacked.

For more information about the #pragma pack directive, see pack.

Anonymous structs and unions

When a structure or union is declared without a name, it becomes anonymous. The effect is that its members will only be seen in the surrounding scope.

Example

In this example, the members in the anonymous union can be accessed, in function F, without explicitly specifying the union name:

struct S
{
  char mTag;
  union
  {
    long mL;
    float mF;
  };
} St;

void F(void)
{
  St.mL = 5;
}

The member names must be unique in the surrounding scope. Having an anonymous struct or union at file scope, as a global, external, or static variable is also allowed. This could for instance be used for declaring I/O registers, as in this example:

__no_init volatile __sfr
union 
{
  unsigned char IOPORT;
  struct
  {
    unsigned char way: 1;
    unsigned char out: 1;
  };
} @ 0xFFF80;

/* The variables are used here. */
void Test(void)
{
  IOPORT = 0;
  way = 1;
  out = 1;
}

This declares an I/O register byte IOPORT at address 0xFFF80. The I/O register has 2 bits declared, way and out. Note that both the inner structure and the outer union are anonymous.

Anonymous structures and unions are implemented in terms of objects named after the first field, with a prefix _A_ to place the name in the implementation part of the namespace. In this example, the anonymous union will be implemented through an object named _A_IOPORT.

IAR Embedded Workbench for RL78 5.20