dspc語言匯編

Ⅰ dsp的c語言程序為什麼需要優化

曾幾何時匯編編程是dsp工程師的一張名片。很多人到現在談起匯編編程還是頗為自豪的，搞得你想說自己不會都要鼓起點勇氣——那眼神是恨不得把你送回火星去。這主要是因為在最開始的時候DSP上的C語言編譯器不是很普遍，編譯器的水平也還在起步階段，很難用到DSP相應的硬體特性，編譯效率值得商榷。而且那時DSP應用場景和復雜度遠不比今天，基本上限制在數字信號處理的典型演算法上，FFT，FIR，IIR濾波器，等等。這些函數和濾波器的實現相對今天的應用比較簡單，用匯編語言也容易突出DSP的硬體特性。還有一個原因是那時候DSP普遍都跑的很慢，基本上在幾十兆的水平。這也限制了C語言的使用。試想一下一段C代碼跑的比匯編慢十倍，幾十兆的DSP一下就變幾兆了。
但是今天再來看這所有的一切是完全不一樣了。首先是DSP的應用范圍越來越廣，客戶越來越多的希望用同一顆晶元，在同一個平台上實現更多的設計和應用。這對DSP的設計，DSP和MCU的融合都帶來重大影響。DSP和MCU之間也不是過往那井水不犯河水的安寧。隨著DSP和MCU的主頻先後突破1GHz，在很多應用中DSP和MCU相伴相生的場景也開始被一顆強壯的芯代替，或者DSP或者MCU。在這樣的應用中，操作系統，文件系統，USB協議棧，TCP/IP，海量數據存儲，樣樣都會用到。數字信號處理也從骨灰級的濾波器變成全系列音視頻處理，OFDM基帶處理，天線陣列信號處理，彩色圖像重建… 試想一下這些應用哪一個不是成千上萬行代碼。匯編語言在編程復雜度，可移植性和可維護性上真的是遇到了前所未有的挑戰。而與此相對應的是C語言和C語言編譯器的蓬勃發展。今天您可以很容易找到上面提到所有這些應用和演算法的C語言實現，而C語言編譯器在編譯效率和成熟度上都有很大的突破。也讓C語言在DSP上的應用得以受到愈來愈高的重視。

Ⅱ 對DSP而言，CCS用C語言編程和匯編編程，二者的效率相差多少

我用的是28XX系列的，不知道經驗對你有沒有用，因為不同系列的晶元多少有些差別。
TI提供的庫已經相當可以了，兼顧易用與效率。我當時做過這樣的測試
1. 用IQMATH實現
2. 直接C語言實現
3. C語言優化實現
4. 原生匯編實現
IQMATH的運行周期在1000左右，比方案3快幾十個周期，比方案4慢幾個周期，方案2是10000多個周期。
另外，因為只是單獨測的演算法，匯編之所以快是快在寄存器的使用上，操作數可以直接入寄存器，但是考慮到程序其他部分是用C語言編寫的話，把操作棧的時間也加上，並不比方案1快。畢竟我對TI的匯編吃的也不透。
在編寫上，無疑是方案1提供了最接近C語言風格的實現，幾乎不用考慮ISA方面的問題。
另外對於執行效率，我覺得主要考慮三點：
1.分支的使用
CCS對C語言的優化我沒做過太多比對。其實單從反匯編的結果看，我接觸過的嵌入式開發環境的編譯器都能做出很好的優化。但是幾乎每個編譯器都會在邏輯的優化上有欠缺——它只能對一些顯而易見的判斷條件進行優化，而在寫程序的過程中，我們經常出於易讀性的考慮，或者穩定性的考慮，或者其他的考慮加入幾乎不會發生的分支，這樣的分支判斷會消耗一定比率的代碼段執行效率，視乎代碼段內有用功能的長度而定，越長這個比率越小，越短這個比率越高。
2.一般操作，就是各種賦值操作
在一般的操作上，編譯器的優化已經很令人滿意了，基本上可以作為編寫匯編的範本。我覺得所謂效率能達到90%就是針對這個部分說的。
3.特殊操作，比如對整塊內存的操作，或者是浮點運算上。
在一些特殊的操作上，就要看是否有現成的庫，或者看硬體是否支持。比如對整塊內存操作就別用循環一個位元組一個位元組的搬了。
以上三點都能考慮到的話，相信執行效率方面已經沒有太大的提升空間了。

另外如果你的代碼發生在初始化部分，也就是只在系統運行開始的時候運行一次，那麼優化不優化其實沒有太大的必要，除非你對系統初始化的時間有嚴格的要求。但是如果你的代碼是作為任務要被反復運行的，那就有優化的必要了。

在CCS里有代碼消耗時鍾周期的統計，如果你覺得某段代碼效率低下的話，可以先分段進行消耗時鍾周期的計算，這樣優化比較有針對性。

Ⅲ 如何將c語言程序轉換成dsp的匯編語言

第一、自己轉；看懂C之後自己來寫匯編；第二、讓機器轉，編譯連接機器之後，在執行時可以看到轉換後的匯編代碼，不過不是一一對應的。

Ⅳ 如何利用C和匯編語言混合編程實現DSP軟體設計

其中絕大部分功能不屬於標准C語言，因此被稱為C語言擴展。下面列出的是其中有益於DSP編程的一些功能。 內聯匯編(inline assembly)：該功能可以幫助編程人員將匯編指令插入C代碼。 硬體寄存器綁定C變數：該功能經常與匯編指令內聯功能結合在一起，幫助內聯匯編代碼訪問C語言級的變數(見圖3)。圖3：結合內聯匯編和硬體寄存器綁定功能的代碼示例。 存儲區屬性：該功能允許編程人員將上述變數和函數分配到獨特的用戶定義存儲區，可以讓編程人員將C語言級單元分配到實際的存儲器位置，這對DSP應用來說非常關鍵。 用戶定義的調用約定：在某些情況下，匯編函數可以通過用戶定義的調用約定取得更好的優化效果。 編譯器內部函數(Compiler intrinsics)：是指能夠使用專門的宏或函數調用觸發的內建編譯器功能總稱。沒有內部函數支持的編譯器必須調用用戶定義的函數，這樣做可能會令用戶定義函數可能會在一個環路里產生函數調用和返回(見圖4)，從而產生巨大的開銷。圖4：ETSI的mult_r(乘法和取整)基本操作的C代碼實現(左)和對應的由CEVA-TeakLite-III編譯器生成的匯編代碼(右)。 匯編內部函數：是將匯編代碼內聯進C代碼的一種先進方法，下文將有詳細介紹。把匯編指令當作C語句一樣來編寫內聯匯編功能具有顯著的缺點。它會破壞各種編譯器優化操作，因為編譯器不了解內聯代碼的內容，會使用最壞假設；以及它可能迫使編程人員處理底層問題，如寄存器分配和指令調度。匯編內部函數可以幫助編程人員實現內聯匯編代碼，並且不存在這些缺點。從編程人員的角度看，匯編內部函數就像是C語言宏或函數。它們接收C語言變數，返回C語言輸出結果，同時表現為單個匯編指令。由於涉及該功能的所有代碼都在C語言等級，因此編程人員不必擔心寄存器分配、指令調度和其它底層問題。匯編內部函數不僅不會妨礙編譯器優化操作，還會參與優化過程，就像它們是編譯器正常產生的匯編指令一樣。這些特徵使得匯編內部函數的功能非常強大。利用匯編內部函數，編程人員可以從編譯器不可能產生的獨特匯編指令中受益。例如，CEVA-X1641的bitrev(位反向)指令就是為FFT等演算法定製的。由於編譯器不太可能把一個程序看作一個FFT並使用bitrev指令，因此編程人員可以完全把bitrev匯編內部功能嵌入到C代碼中。結合對應用的透徹了解，編程人員還可以使用C應用程序的性能決定段里的精確序列匯編內部函數，從而能夠確保編譯器生成的代碼效率就像手工編寫的一樣高。圖5是CEVA-X1641編譯器與匯編內部函數一起使用的例子。匯編內部函數還受益於由CEVA-X1641編譯器處理的問題所決定的機器，如寄存器分配、指令調度和硬體單元分配。圖5：CEVA-X1641編譯器支持的匯編內部函數的使用。 調試混合代碼的應用程序匯編代碼的調試需要對延遲和存儲器對齊限制等架構和機器級問題有深入的了解。只是簡單地把C代碼和匯編代碼放在一起會使事情更麻煩，因為編程人員現在還必須調試C代碼和匯編代碼之間的連接。調試混合代碼應用程序的第一步就是分隔問題。假設保持匯編代碼的C語言實現不變以及C語言實現方案工作正常，那麼將匯編函數轉換成C語言實現並重新測試應用程序就相對比較容易。為了迅速檢測出問題，編程人員可以在每一步把受懷疑函數的一半轉換為相應的C語言實現方案。一旦有問題的匯編函數被確定，它就應該同時作為獨立的匯編問題和C與匯編的連接問題加以分析。調試獨立的匯編問題對匯編編程人員來說十分簡單明了，但C與匯編的連接問題就有點麻煩。在考慮匯編函數本身時，C與匯編的連接問題是不可見的，這與獨立的匯編問題有所不同。為了找出這些問題，編程人員必須檢查編譯器的約定，比如調用約定和寄存器使用約定。編程人員還必須檢查編譯器假設，比如匯編指令的行蹤。為了節省調試時間，編程人員應該在第一次實現匯編函數時驗證是否遵循所有的編譯器約定和假設。

Ⅳ 關於c語言和dsp編程的問題

這個問題太常見了呀，原因是路徑設置錯了。
進入界面後，選擇OPTIONS--選擇Directories
然後設置路徑,（以下是我的設置，你參考）
1：INCLUDE文件夾所在路徑，Include directories: E:\TC2\INCLUDE
2：Library文件夾所在路徑，Library directories: E:\TC2\LIB
3:OuPut文件夾即文件編譯輸出到哪個目錄下
4：TurbroC程序所在的目錄

最後選擇 OPTIONS下的SAVE OPTIONS即可。一定要SAVE呀。

Ⅵ 在DSP編程中，是否可以在匯編語言中嵌套C語言謝謝

不可以，但是C可以嵌套匯編（僅在某些情況下）

Ⅶ 請問剛開始學習DSP應該怎麼學習，編程應該學習C語言還是匯編語言呢，請高手指點一下。

呵呵，看到這個問題和一些網友的回答，感到走自學成才之路的人真多！
很多人都不懂由淺入深，循序漸進的路子。

C語言是在大一學的，有了初中水平即可掌握C語言。不上大學，也能學會C語言。
學會了C語言，並不能算有什麼成就。

大約在大三、大四，學習了模電、數電等課程之後，才學到單片機和DSP。
學單片機和DSP，目的就是學習硬體和匯編。
在這個期間，怎麼還能提到學C語言？ C語言編程不是在前兩年就會了嗎？
學DSP，如果學不好匯編語言，可以說是根本就沒有學會DSP。

學好了硬體和軟體，用什麼語言編寫程序，並沒有規定。
粗放型的，使用C即可，想要精雕細刻，就必須用匯編語言。

Ⅷ DSP可不可以用C語言寫

當然可以啦... 只要有編譯開發環境，比如Code Composer Studio，編譯就可以了

Ⅸ dsp要用到匯編語言嗎

肯定要匯編，你不用怕，匯編用得很少，你最好學學匯編，至少要看得懂（不難），絕大多數情況都是把匯編COPY過來用，C語言編程占據99%，剩下1%的匯編你搞不定，整個程序你就OVER了。

Ⅹ 如何將匯編語言與C語言整合至DSP

隨著DSP處理器性能的提升以及編譯器最佳化技術的進步，曾經紅極一時、僅用匯編語言編寫DSP應用程序的作法已逐漸被淘汰。今天，幾乎每個DSP應用程序都使用C語言程序代碼和匯編程序碼混合的方式。對於一些性能需求極高的關鍵功能，DSP工程師會繼續使用高度最佳化的匯編程序碼；而一些次要的功能現在也使用C語言編寫，使程序代碼更容易維護和移植。對於C語言和匯編程序碼的結合，每位DSP工程師都需要掌握特殊的工具和方法。 眾所皆知，匯編語言編碼具有更高的性能優勢，而用C語言編碼則較容易且速度也更快。為了解其中原因，以下我們進一步比較匯編語言編碼與C語言編碼的優缺點： 匯編語言編碼的優點： 匯編語言編碼可以充分利用處理器的獨特指令以及各種專門的硬體資源。而C語言程序代碼是通用型程序代碼，必須支持各種硬體平台，因此很難支持特殊平台程序代碼。 匯編程序設計人員通常對應用程序非常熟悉，可以作出編譯器無法作出的假設。 匯編程序設計人員可以發揮人類的創造性；而再先進的編譯器也只是一個自動化的程序。 匯編語言編碼的缺點： 匯編程序設計人員必須解決耗時的機器級問題，如緩存器分配和指令排程。若使用C語言程序代碼，這些問題可以由編譯器解決。 使用匯編語言編碼的程序設計人員必須了解DSP架構及其指令集的專業知識；而C語言編碼只需要掌握相當普及的C語言知識。 若使用匯編語言，將應用程序從一個平台移植到另一個平台非常困難也相當耗時；而C語言應用程序的移植相對而言非常容易。 圖1顯示了如何利用專用硬體機制來獲得高度最佳化的匯編程序碼。左邊的C語言編碼利用模塊演算法設計出一個循環緩沖區P1；右邊高度最佳化的匯編程序碼中，等效的緩沖區是利用CEVA-TeakLite-III DSP核心的模塊運算機制(Molo Mechanism)設計產生的。只要緩沖區指標(本例中的r0)有更新，模塊運算機制便會自動執行模塊運算。這種運算與指針更新在同一個周期發生，因此匯編程序碼比C語言程序代碼更加高效，可為模塊運算產生獨立的指令。 點擊看原圖圖1：右邊的CEVA-TeakLite-III匯編程序碼可以建置成左邊的C語言程序代碼。 為DSP應用選擇C/匯編程序碼 混合使用的問題就在於該如何劃分C語言程序代碼和匯編程序碼的界限，而答案取決於剖析器提供的性能分析結果。然而在使用剖析器之前，DSP工程師需要為應用程序定義清晰的對象，一些典型的對象包括循環數、程序代碼大小和數據大小。一旦這些對象確定後，所有應用程序都應該先以C語言編寫和製作，隨後使用剖析器來分析性能。 在一些極端情況下，如控制應用，用C語言層級的編碼就足夠了；但大多數情況下，原始C語言層級應用程序版本不會遵從一個或多個對象，這也意味著需要使用一些匯編程序碼來完成。在求助於匯編語言編碼之前，C語言編碼可提供許多方法來提高性能，但這些方法不屬於本文討論的范疇。假設所有C語言級的方法全用完了，並且准備使用匯編語言編碼，這時強烈建議將原始C語言程序代碼保存起來。這樣不僅方便除錯，而且一旦條件許可(比如轉移到更強大的平台)還可以回復原始的C語言。 程序代碼中的匯編語言部份應盡可能維持在最少，這樣便能分析從剖析器得到的性能結果，並定義應用程序中的關鍵函數。關鍵函數會佔用大部份執行時間，必須用匯編語言重寫才能滿足性能對象。當兩到三個最關鍵的函數重寫後，需要重新進行性能測量，若應用程序仍然不能滿足對象需求，那麼必須使用匯編語言定義並重寫額外的關鍵函數，這個過程需要不斷地重復直到滿足性能對象需求為止。 匯編語言設計師的編譯器考慮 在編寫會與C語言程序代碼結合的匯編程序碼時，匯編程序設計人員必須了解編譯器的慣例和假設。其中有個重要的編譯器慣例是函數呼叫慣例，也稱為函數參數傳遞慣例。這個慣例描述了編譯器如何在一個函數呼叫另一個函數時傳遞參數。為了使匯編語言函數能被C語言函數成功呼叫；反之亦然；匯編語言函數必須截取參數，然後將參數發送到由函數呼叫慣例定義的硬體資源上，通常為緩存器或堆棧內存。 匯編程序設計人員還必須了解編譯器的緩存器使用慣例。這些慣例將硬體緩存器分成被呼叫者保存(callee-saved；或呼叫者使用，caller-used)；以及被呼叫者使用(callee-used；或呼叫者保存，caller-saved)緩存器。編譯器假設被呼叫者保存緩存器在函數呼叫過程中保持不變的值，若匯編程序設計人員希望使用這種緩存器，他們必須先將緩存器的值備份，然後在返回到C語言程序代碼之前恢復這些緩存器的內容；相反的，被呼叫者使用緩存器被認為在函式呼叫過程中不會保持一定的值。這意味著匯編程序設計人員使用這些緩存器之前無需進行備份，不過他們必須記住，當匯編語言函數呼叫C語言函數時，被呼叫者可以對這些緩存器進行覆寫。 圖2為一個從CEVA-X1641 DSP核心FFT實作中截取的匯編程序碼案例。其中以黃色標示的add指令遵循CEVA-X1641編譯器的呼叫慣例，在r0地址緩存器中傳遞指針參數。標為藍色的pushd指令用於備份，隨後函數會使用的被呼叫者保存緩存器。