NOTICE: The Processors Wiki will End-of-Life in December of 2020. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
Interrupts Disabled by C6000 Compiler
This page discusses the circumstances under which the C6000 C/C++ Compiler may disable interrupts, or even presume interrupts never occur.
This table provides a summary.
|-mi Option||Presume Interrupts May Occur?||How Long Interrupts May Be Disabled?|
|-mi||no||Interrupts are generally not disabled in compiler generated code|
For code outside of software pipeline loops, there are no issues regarding interrupts. Code generated outside of software pipeline loops is always interrupt safe, and interrupts are never disabled. (Of course it is possible for the user to explicitly disable or enable interrupts via mechanisms not discussed here.)
Inside a software pipeline loop, things are quite different. On C6000, during the execution of a branch and its delay slots, 5 cycles total, interrupts are disabled. And with 8-way parallelism, lots of instructions can be scheduled in those 5 cycles. It is common for a software pipeline loop to be completely contained within the the delay slots of the branches. Casual scheduling of such a loop leads to interrupts being disabled during the entire time the loop is running. In addition, other factors may cause the compiler to disable interrupts around a software pipelined loop ("multiple assignment" code).
The -mi option gives you the ability to control how long interrupts may be disabled by a software pipelined loop. The downside is use of -mi can lead to worse loop performance, especially on C6000 devices which do not support the SPLOOP instructions.
The -mi Option
The -mi option may also be specified by the long form option --interrupt_threshold.
There are three states to consider: the option is not specified, it is specified without a value, and it is specified with a value.
Presume Interrupts May Occur?
By default, when no -mi option is specified, the compiler does presume interrupts may occur during execution of a software pipeline loop.
If the -mi option is specified, but no limit is given, the compiler presumes interrupts never occur and therefore will not disable interrupts.
When -mi is specified with a value N, the compiler does presume interrupts may occur.
How Long Interrupts May Be Disabled?
The question here is how long, in terms of CPU cycles, does the compiler allow interrupts to be disabled while a software pipelined loop is executing? When adding up the cycles interrupts may be disabled, the compiler does not account for cycles lost to system effects such as memory latency, cache misses, memory bank conflicts, etc.
By default, when no -mi option is specified, the compiler either allows the loop to execute completely within the delay slots of the branches, or issues instructions to disable interrupts at the beginning of a software pipelined loop and re-enable them at the end. The compiler does not keep track of how long interrupts may be disabled by such a loop.
If the -mi option is specified, but no limit is given, the compiler does not issue instructions to disable or re-enable interrupts around software pipelined loops.
When -mi is specified with a value N, the compiler schedules a loop to insure it disables interrupts for less than N CPU cycles. Using -mi in this manner can lead to worse loop performance.
Effect on Performance
As detailed in C6000 Compiler: Tuning Software Pipelined Loops, performance of software pipelined loops is measured by the initiation interval (ii). The lower the ii, the better the performance.
When the ii <= 5, an optimal schedule places the entire loop in the delay slots of the branches. This has the effect of disabling interrupts while the loop runs. If a -mi value is specified, the compiler has no choice but to schedule the loop with a higher ii of 6. Such a schedule allows the CPU to be interrupted at least once per loop iteration. But the performance of the loop suffers. In cases where the compiler knows how many times the loop iterates, the compiler may still schedule the loop optimally if the overall CPU cycle count is less than the -mi value. However, such cases are not common in practice.
Some C6000 devices, such as the C64+ and C6740, support a special instruction for constructing software pipelined loops called SPLOOP. A loop built with SPLOOP can be interrupted, even if the ii <= 5. Thus, for these devices, the performance degradation associated with using -mi=N is greatly reduced.
RTS Functions May Disable Interrupts
The compiler runtime support (RTS) library supplies functions such as strcpy and memset. The RTS library is not built with any -mi option. Thus, interrupts may be disabled during the entire time an RTS function is executing. Visit this compiler forum thread to see how one user handles this situation.