Программирование DSP TI - является C достаточно быстро, или мне нужен ассемблер?

Если и если... Я склоняюсь к , предпочитают неподписанный, так как это чувствует больше "сырых данных", менее привлекательных для высказывания "эй, это - просто набор маленьких ints", если я хочу подчеркнуть двоичность данных.

я не думаю, что когда-либо использовал явное signed char для представления буфера байтов.

, Конечно, опция одной трети состоит в том, чтобы представить буфер как void * как можно больше. Много общих вводов-выводов функционируют работа с void *, поэтому иногда решение о том, какой целый тип использовать может полностью инкапсулироваться, который хорош.

7
задан starblue 14 November 2009 в 09:18
поделиться

6 ответов

Я бы придерживался C до тех пор, пока не узнаю, что существует горячая точка, для которой может быть полезно кодирование на ассемблере. Это метод "профилирования", который я использую. Вы можете быть удивлены тем, что есть способы ускорить код, которые не являются горячими точками, а скорее являются промежуточными вызовами функций, которые можно удалить.

1
ответ дан 6 December 2019 в 05:06
поделиться

I've used some other TI DSPs and C was usually fine. The usual approach is to start by writing everything in C and then profile the code to see if anything needs to be hand-optimised.

You can often do the optimisation in C too, by adjusting the C code until you get the assembly output you want. It's important to know how the DSP works and what ways of working are faster or slower.

11
ответ дан 6 December 2019 в 05:06
поделиться

Usually C is a good place to start. You can get the overall framework and algorithms shaken out quickly, and write most of the plumbing that moves the data around between the real math. Once that's in place and you're happy that your data structures are correct, you can look at in a profiler and figure out which routines need to be squeezed by hand.

7
ответ дан 6 December 2019 в 05:06
поделиться

The C-Compiler (as far as I tested) does not take full advantage of the architecture.

But you can get away with it, because the DSP might be fast enough for the operations you need to do.

So it comes down to testing and profiling your code to see the parts which must be speed up to get the system to work.

6
ответ дан 6 December 2019 в 05:06
поделиться

Depends on the C compiler and your definition of "fast enough". Standard C compilers often struggle to make efficient use of special DSP hardware, such as:

  • Multiple memory banks that can be accessed in parallel
  • Fixed point data types
  • Circular buffers
2
ответ дан 6 December 2019 в 05:06
поделиться

Компилятор TI для C64x / C64x + DSP на OMAP3 включает поддержку того, что TI называет «внутренними» вызовами функций. На самом деле они не являются вызовами функций, это просто способ сообщить компилятору, какой код операции сборки использовать для операции, которая может быть не выражена напрямую в C. Это особенно полезно для использования кодов операций SIMD в C64x / C64x + DSP из C.

Примером может быть:

A = _add2 (B, C);

Эта инструкция SIMD складывает младшие / высокие 16 битов B и C вместе и сохраняет результаты в младших / высоких 16 битах. биты A. Вы не можете выразить это на обычном языке C, но вы можете сделать это с помощью внутренних кодов операций C.

Я использовал внутренний C, чтобы очень близко приблизиться к тому, что вы могли бы сделать с полноценным языком ассемблера (в пределах 5-10%).

10
ответ дан 6 December 2019 в 05:06
поделиться
Другие вопросы по тегам:

Похожие вопросы: