Previous What's New - eTPU_C

eTPU_C

These notes apply to previous versions of eTPU_C.

New ::ETPUmisc parameter

The ::ETPUmisc host interface macro can now optionally accept a parameter in parentheses. If given, ::ETPUmisc expands to the MISC checkword for the program from offset 0 to the given offset, rounded up to the nearest 32-bit program word. For instance:

::ETPUmisc(::ETPUmaxrom)

generates a MISC value for only the generated program (including constants).

::ETPUtype and structures/arrays/unions

::ETPUtype returns enhanced host information about the type of variables.

If the variable given as a parameter to ::ETPUtype is a simple variable, the macro expands to that macro type. If the variable is an array, structure member, or union member, ::ETPUtype expands to a C macro call, one of:

__etpu_struct_data() //for structure members

__etpu_struct_array() //for arrays

__etpu_struct_packed_int() //for integer bit fields

New or Improved Optimization

The eTPU_C compiler implements improved branch chaining: e.g.,

jcc to jmp
jmp to jmp
jmp to end

Improved Functionality

The compiler previously expanded ::ETPUcode32 to an image that was, on occasion, one byte too long. This bug has been fixed.

Constant divides that referenced a register other than the Accumulator were improperly generated. This bug has been fixed.

#pragma fill has been permanently enabled.

FILLROM and FILLROMWORD

Similar to #pragma option FILLROM, #pragma option FILLROMWORD writes a default value to unused program ROM. Its value is a 32-bit integer, and it writes this value to unused 4-byte program words (on 32-bit boundaries). If both are specified in a program #pragma option FILLROMWORD takes precedence.

Changes to ELF/DWARF support

ELF file generation has been enhanced:

  1. eTPU_C now alters the order of DW_LNS_negate_stmt to work with most current source level debugging emulators. This represents a convention in how these tools read ELF/DWARF files.
  2. eTPU_C now modifies generation of .debug_line information when the eTPU generated code is the result of code motion.
  3. eTPU_C now now reports the current version of the compiler, including build number (for example "ETPUC 1.0.7.25") in .debug_info.

#pragma ETPU_function

#pragma ETPU_function name [, standard|alternate] [, LOCAL_LIMIT = local_ram_size] [@ function_number];

The #pragma ETPU_function directive has an added parameter, LOCAL_LIMIT. This allows you to specify the maximum LOCAL memory to be allocated to the ETPU_function. If the compiled code uses more than this amount of local RAM, the compiler issues an error.

Environment Block Additions

The environment block of the .COD file now includes the actual ETPU_function local RAM allocation for each ETPU_function. The environment block entry is as follows:

<location> <message-id> LOCAL_RAM <size in bytes> <RAM/SPRAM>

Field

Description

Location

End of ETPU_function location in HEX

message id

Standard environment block message id of 'e

size in bytes

local RAM allocation requirements

RAM/SPRAM

One of RAM or SPRAM as local RAM location

This is an example environment block entry:

0000 0238 e LOCAL_RAM 24 RAM

This information also appears in the new listing file reports, below.

New Reports

The eTPU_C compiler now issues some new reports in the listing file.

After every entry table report (describing the channel conditions for the thread), the compiler will identify the total local RAM memory used.

ssss Thread Local RAM size

This reports the amount of RAM, used by automatic variables, declared within the thread.

At the end of each ETPU_function, the compiler identifies the total local RAM used by the function (again, for automatic variables).

hhhh Local RAM requirements for ETPU_function name

After every ETPU_function, the local RAM used is compared to the LOCAL_LIMIT declared in the #pragma ETPU_function directive. If the limit has been exceeded, an error is generated:

User Error Local RAM requirements for name exceeds LOCAL_LIMIT declaration

At the end of the listing file, eTPU_C appends a report about RAM usage by each ETPU_function:

eTPU FUNCTION SUMMARY
3 xyz 0200 0288 (34 words) SRAM = 24 Local RAM = 32 4 uvw 0288 02CC (17 words) SRAM = 24 Local RAM = 24

The report describes each ETPU_function, by number and name:

  • The code memory used by the compiler, from start position to end position (in bytes).
  • The number of program words generated, in decimal.
  • The number of SRAM bytes used. These are ETPU_function parameters. The number of bytes here may not agree with the counts from the earlier reports, as parameters must be allocated in blocks of 8 bytes.
  • The number of Local RAM bytes used. The Local RAM bytes from all functions are overlaid, and are not part of the function frame.

Preload Parameter Intrinsic

The following intrinsic is new:

preload_p01(), preload_p23()
preload_p01() and preload_p23() cause the compiler to set the Preload Parameter bit in the entries for threads of the ETPU_function. preload_p01() causes eTPU to preload parameters at offsets 0 and 4 (parameters 0 and 1) into p and diob. preload_p23() causes eTPU to preload parameters at offsets 8 and 12 (parameters 2 and 3).

These built-ins can only be called within the body of an ETPU_function: calls outside eTPU functions will cause the compiler to issue an error. The compiler will issue an error if (either) function is called a second time.

PP's default setting is as if preload_p01() had been invoked.

Macro Assembler

eTPU_C offers full support for eTPU macro assembly. See the documentation for details.