Programmazione TI DSP - C è abbastanza veloce o ho bisogno di un assemblatore?

Question

Ho intenzione di scrivere alcuni programmi di elaborazione delle immagini per la piattaforma DaVinci di Texas Instruments. Esistono strumenti appropriati per la programmazione in linguaggio C, ma mi chiedo se sia davvero possibile sfruttare appieno il processore DSP senza ricorrere a un linguaggio assembly. Conosci qualche confronto di velocità tra programmi scritti in C e in assembler su questa piattaforma DSP?

Answer 1

Il C-Compiler (per quanto ho provato) non sfrutta appieno l'architettura.

Ma puoi farla franca, perché il DSP potrebbe essere abbastanza veloce per le operazioni che devi fare.

Quindi si tratta di test e profiling del codice per vedere le parti che devono essere velocità fino a ottenere il sistema per funzionare.

Answer 2

Ho usato altri DSP TI e C di solito andava bene. L'approccio abituale è iniziare scrivendo tutto in C e quindi profilare il codice per vedere se qualcosa deve essere ottimizzato manualmente.

Spesso è possibile eseguire l'ottimizzazione anche in C, regolando il codice C fino a ottenere l'output di assieme desiderato. È importante sapere come funziona il DSP e quali modalità di lavoro sono più veloci o più lente.

Answer 3

Dipende dal compilatore C e dalla definizione di "abbastanza veloce". compilatori C standard spesso hanno difficoltà a fare un uso efficiente di hardware speciale DSP, come ad esempio:

• più banchi di memoria che può essere letta in
• tipi di dati in virgola fissa parallele
• buffer circolari

Answer 4

In genere C è un buon punto di partenza. È possibile ottenere la struttura generale e gli algoritmi scossi rapidamente e scrivere la maggior parte degli impianti idraulici che spostano i dati tra la vera matematica. Una volta che questo è a posto e sei felice che le tue strutture dati siano corrette, puoi guardare in un profiler e capire quali routine devono essere schiacciate a mano.

Answer 5

Vorrei attenermi a C finché non so che esiste un hotspot che potrebbe trarre vantaggio dalla codifica di assieme. This is the "profiling" method I use. Potresti essere sorpreso dal fatto che ci siano modi per accelerare il codice che non sono hotspot, ma piuttosto chiamate di funzioni intermedie che potrebbero essere rimosse.

Answer 6

Il compilatore TI per la C64x/C64x + DSP sulla OMAP3 include il supporto per quello TI chiama chiamate di funzione "intrinseche". Non sono chiamate di funzione, sono solo un modo per dire al compilatore quale codice operativo di assembly utilizzare per un'operazione che potrebbe non essere direttamente esprimibile in C. È particolarmente utile per sfruttare gli opcode SIMD in C64x/C64x + DSP da C.

Un esempio potrebbe essere:

A = _add2 (B, C);

Questa istruzione SIMD somma i 16 bit basso/alto di B e C insieme e memorizza i risultati nei 16 bit bassi/alti di A. Non è possibile esprimerlo in C normale, ma è possibile farlo con il opcodes C intrinseci.

ho usato intrinseca C per arrivare molto vicino a quello che si potrebbe fare con il linguaggio conclamata assemblaggio (entro 5-10%). È particolarmente utile per le funzioni video come il filtro e la compensazione del movimento (_dotpsu4!).

Di solito compilo con l'opzione -al e guardo la pipeline per cercare di identificare quali unità funzionali sono sovraccariche e poi guardare i miei elementi intrinseci per vedere se riesco a riequilibrare il ciclo (se sto usando troppe unità S , Potrei vedere se potrei cambiare l'opcode per usare un'unità M).

Inoltre, è utile ricordare che il C64x DSP ha 64 registri, in modo da caricare le variabili locali e mai assegnare l'uscita di un'istruzione di nuovo nella stessa variabile - che sarà influenzare negativamente del compilatore capacità di pipeline correttamente.

Answer 7

il semplice confronto della velocità non significa nulla. Decisamente c se più conveniente di un assemblatore. Devi misurare il costo del tempo del tuo sistema, se il codice c soddisfa le tue esigenze di velocità, non devi usare l'assemblatore. Se la velocità non è sufficiente, puoi profilare il tuo codice, scoprire il codice sorgente che richiede più tempo come il codice di loop, quindi ottimizzarlo!