THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

THE SHARC IN THE C

by Michael Smith

Start ý Register Comparison ý Memory Access ý Modify and Volatile Registers ý Length and Base Registers ý Hardware and Software ý Interrupt Handling ý Sources and PDF

INTERRUPT HANDLING

In this article, I am more interested in the C programming side of interrupt handling on the SHARC rather than specific hardware details. However, it is not possible to completely separate the two.

With the SDS 68K compiler, the statement #pragma interrupt() must be added before the code for the C interrupt service routine (ISR). This informs the compiler that the ISR must be handled differently from a subroutine. In particular, volatile registers must be saved/recovered, and an RTI (rather than an RTS) instruction is needed at the end of the routine.

During the 68K main function, the starting address for the ISR routine must be placed at the appropriate location in the vector table. Then the interrupt must be activated. The equivalent of these events must be present with the SHARC chip and compiler. However, the implementation details are different.

Unlike the 68K with its interrupt vector table, the starting addresses of the SHARC interrupt service routines begin at a fixed location in memory. Each interrupt is provided with a fixed number of instructions within this area. For longer routines, a jump must occur to code elsewhere in memory.

There is no 21K #pragma interrupt() preprocessor command to designate an ISR as something other than a subroutine. Instead, there are three different approaches within the SHARC C code that can be used to link an interrupt to a specific ISR routine. The following code links the IRQ1 interrupt with the C subroutine (or C-compatible assembly subroutine) DoSomething( ):

#include <signal.h>
interrupt(SIG_IRQ1, DoSomething);

The call interrupt( ) modifies a lookup table used to inform the interrupt handler that IRQ1 interrupts will require that all possible registers (Rx, Ix, Bx, Lx, Mx, and others) be saved to external memory. Then, the table is further modified to ensure that the DoSomething( ) routine is called as a subroutine from within the IRQ1 ISR routine. This adds 250 cycles to the interrupt overhead. The overhead is less than expected because the SHARC super-scalar capability is bought to bear.

Note, there are programming quirks that occur when saving the index and other DAG1 registers. Because of architectural constraints, the DAG1 registers canýt be saved directly to the C-stack in data memory using instructions involving DAG1 registers.

The IRQ1 interrupt is automatically activated by calling the interrupt( ) routine. Calling interruptf( ), rather than interrupt( ), changes the lookup table so that a faster interrupt register saving routine will become active. In this case, 60 cycles are added to the interrupt overhead because only the volatile registers are saved and recovered. There is also an even smaller interrupt overhead option, interrupts( ).

SUMMING UP

This article is directed towards the developer planning to use low-level assembly code in conjunction with C code. I covered a brief overview of the C programming environment for the Analog Devices SHARC 2106X DSP processor. Many of the similarities and differences of C coding on the 68K processor using the SDS development environment were discussed.

The SHARC has many interesting architectural features designed to optimize DSP algorithms. These include hardware stacks for loop and subroutine handling with zero-overhead circular buffer capability. You must understand the consequences of activating these features from within an assembly code routine called from C.

For more information on the SHARC internal register operations, use "SHARC Navigator LIVE" or contact Talib Alukaidey at T.Alukaidey@herts.ac.uk. Look for my next article in the August issue (121) of Circuit Cellar magazine, where Laurence Turner and I will look at how to get the best performance out of your processors when handling DSP algorithms.

PREVIOUS • NEXT