Para DSP, CCS utiliza programación en lenguaje C y programación en ensamblador. ¿Cuál es la diferencia en eficiencia entre los dos?
Yo uso la serie 28XX, no sé si mi experiencia te será útil, porque existen algunas diferencias entre las distintas series de chips.
Las bibliotecas proporcionadas por TI son bastante buenas, teniendo en cuenta la facilidad de uso y la eficiencia. Hice una prueba de este tipo en ese momento
1. Implementado con IQMATH
2 Implementado directamente en lenguaje C
3 Implementación optimizada en lenguaje C
p>
4. Implementación de ensamblaje nativo
El ciclo de ejecución de IQMATH es de alrededor de 1000, que es docenas de ciclos más rápido que la Opción 3 y varios ciclos más lento que la Opción 4. La Opción 2 es más de 10,000 ciclos. .
Además, debido a que es solo un algoritmo separado, la razón por la que el ensamblaje es más rápido es el uso de registros. Sin embargo, los operandos se pueden ingresar directamente en los registros. en lenguaje C, la operación También se agrega el tiempo de pila y no es más rápido que la opción 1. Después de todo, no sé mucho sobre las compilaciones de TI.
En términos de escritura, la Opción 1 sin duda proporciona la implementación más cercana al estilo del lenguaje C, y casi no hay necesidad de considerar problemas de ISA.
Además, en cuanto a la eficiencia de la ejecución, creo que hay tres puntos principales a considerar:
1. Uso de ramas
No he optimizado mucho. del lenguaje C en CCS Compare. De hecho, a juzgar únicamente por los resultados del desmontaje, los compiladores en el entorno de desarrollo integrado con el que he entrado en contacto pueden realizar muy buenas optimizaciones. Pero casi todos los compiladores tienen deficiencias en la optimización lógica: solo pueden optimizar algunas condiciones de juicio obvias, y en el proceso de escribir programas, a menudo lo hacemos por razones de legibilidad o estabilidad, u otras consideraciones, agregando ramas que casi nunca lo harán. Este juicio de rama consumirá una cierta proporción de eficiencia de ejecución del segmento de código, dependiendo de la longitud de las funciones útiles en el segmento de código. Cuanto más larga sea la proporción, menor será la proporción y cuanto más corta sea la proporción.
2. Las operaciones generales son varias operaciones de asignación.
En términos de operaciones generales, la optimización del compilador es muy satisfactoria y básicamente se puede utilizar como plantilla para escribir ensambladores. Creo que la llamada eficiencia puede alcanzar el 90% solo para esta parte.
3. Operaciones especiales, como operaciones en toda la memoria u operaciones de punto flotante.
Para algunas operaciones especiales, depende de si existe una biblioteca lista para usar o si el hardware la admite. Por ejemplo, cuando opere en un bloque completo de memoria, no use un bucle para moverse byte por byte.
Si se pueden tener en cuenta los tres puntos anteriores, creo que no hay mucho margen de mejora en la eficiencia de la ejecución.
Además, si su código ocurre en la parte de inicialización, es decir, solo se ejecuta una vez cuando el sistema comienza a ejecutarse, entonces no hay mucha necesidad de optimizarlo o no, a menos que tenga límites de tiempo estrictos para inicialización del sistema. Pero si su código se va a ejecutar repetidamente como una tarea, entonces es necesaria la optimización.
Hay estadísticas sobre los ciclos de reloj consumidos por el código en CCS. Si cree que un determinado fragmento de código es ineficiente, primero puede calcular los ciclos de reloj consumidos en segmentos, para que la optimización sea más específica. .