ccs6編譯匯編

❶ CCS6中同樣一段代碼，選擇TI的編譯器能夠正常編譯，選擇GCC編譯器就報錯（中斷部分），這是怎麼回事

看一下是不是gcc的安裝目錄中有空格，有的話重新裝一下，目錄中不要有空格

❷ 求大神幫助！dsp ccs編程 加法匯編！

1. 用IQMATH實現
2. 直接C語言實現
3. C語言優化實現
4. 原生匯編實現
IQMATH的運行周期在1000左右，比方案3快幾十個周期，比方案4慢幾個周期，方案2是10000多個周期。
另外，因為只是單獨測的演算法，匯編之所以快是快在寄存器的使用上，操作數可以直接入寄存器，但是考慮到程序其他部分是用C語言編寫的話，把操作棧的時間也加上，並不比方案1快。畢竟我對TI的匯編吃的也不透。

❸ 我用CCS6編譯程序沒問題通過了，連接模擬器目標板出現圖中的問題，並且也不能Load Program

func mergeSort(r []int) []int {
length := len(r)
if length <= 1 {
return r
}
num := length / 2
left := mergeSort(r[:num])
right := mergeSort(r[num:])
return merge(left, right)
}
func merge(left, right []int) (result []int) {
l, r := 0, 0
for l < len(left) && r < len(right) {
if left[l] < right[r] {
result = append(result, left[l])
l++
} else {
result = append(result, right[r])
r++
}
}
result = append(result, left[l:]...)
result = append(result, right[r:]...)
return
}

❹ ccs6編譯工程和文件時總出現這個，怎麼辦啊，急

低版本是無法兼容高版本的文件的，只能升級cssv6，下載後，然後在項目右鍵 properties中選到general,選complier version 旁邊的more就可以選你安裝。
利用CCSv5導入之前版本工程（*.pjt）的方法
其實很簡單，使用File-Import

只不過是不要選版擇(General)Existing Projects into Workspace，那裡會提示「Some projects cannot be imported because they already exist in the workspace」，而是要在Import的時候選擇（Code Composer Studio）Legacy CCSv3.3 Projects

進入後直接選擇相應的*.pjt文件

之後沒有特殊要求就權一路Next直到Finish就好啦。導入後Build應該沒問題。
至於Debug的需求，還是需要新建Target Configuration File，按需要選擇模擬器，就可以了。

❺ dsp程序，用匯編編寫，ccs編譯

你好，請問具體要求是

❻ ccs6.0中怎樣使用匯編編程

在 Visual C++ 中使用內聯匯編- -使用內聯匯編可以在 C/C++ 代碼中嵌入匯編語言指令，而且不需要額外的匯編和連接步驟。在 Visual C++ 中，內聯匯編是內置的編譯器，因此不需要配置諸如 MASM 一類的獨立匯編工具。這里，我們就以 Visual Studio .NET 2003 為背景，介紹在 Visual C++ 中使用內聯匯的相關知識（如果是早期的版本，可能會有些許出入）。 內聯匯編代碼可以使用 C/C++ 變數和函數，因此它能非常容易地整合到 C/C++ 代碼中。它能做一些對於單獨使用 C/C++ 來說非常笨重或不可能完成的任務。一、 優點 使用內聯匯編可以在 C/C++ 代碼中嵌入匯編語言指令，而且不需要額外的匯編和連接步驟。在 Visual C++ 中，內聯匯編是內置的編譯器，因此不需要配置諸如 MASM 一類的獨立匯編工具。這里，我們就以 Visual Studio .NET 2003 為背景，介紹在 Visual C++ 中使用內聯匯的相關知識（如果是早期的版本，可能會有些許出入）。 內聯匯編代碼可以使用 C/C++ 變

❼ 匯編語言能在CCS上運行嗎

CCS的全稱是Code Composer Studio，它是美國德州儀器公司（Texas Instrument,TI）出品的代碼開發和調試套件。TI公司的產品線中有一大塊業務是數字信號處理器（DSP）和微處理器（MCU），CCS便是供用戶開發和調試DSP和MCU程序的集成開發軟體。
經典的版本號是CCS 3.1、CCS 3.3，最新版本號已經更新到了4.x。4.x不僅界面上與3.x迥異，內核也大為不同，用戶體驗並不出色，故遷移至4.x的用戶仍很少。
Code Composer Studio™ IDE 提供強健、成熟的核心功能與簡便易用的配置和圖形可視化工具，使系統設計更快。
開發周期中的功能：應用設計 - 包括 DSP BIOS、參考框架和更新顧問
編碼與編譯 - 包括 C/C++ 和匯編語言以及 CodeWright 集成編輯器
調試 - RTDX™ 快速模擬和連接/斷開連接
分析與調優 - 包括實時分析、編譯器分析和回卷

❽ 對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里有代碼消耗時鍾周期的統計，如果你覺得某段代碼效率低下的話，可以先分段進行消耗時鍾周期的計算，這樣優化比較有針對性。

❾ ccs怎麼用匯編語言寫程序

參考例子，CMD和C是要自己編寫的，編寫部分也有相應提示的，除了頭文件外，反正例子看得出來哪些是自己編寫

❿ 高分求助在線等：將2個匯編程序合成一個

在編寫和調試C6000程序時，為了使C6000代碼獲得最好的性能，我們需要按照軟體編程的3個階段進行，每個階段完成的任務如下[4]：

第一階段：開始可以不考慮C6000的有關知識，完全根據任務編寫C語言程序。在CCS環境下用C6000的代碼產生工具，編譯產生在C6000內運行的代碼，證明其功能正確。然後再用CCS的調試工具，如debug和profiler等，分析確定代碼可能存在的、影響性能的低效率段。為進一步改進代碼性能，需要進入第二階段。

第二階段：利用內聯函數、CCS編譯選項和其他具體優化方法改進C語言程序。重復第一階段，檢查所產生的C6000代碼性能。如果產生的代碼仍不能達到所期望的性能，則進入第三階段。

第三階段：從C語言程序中抽出對性能影響很大的程序段，用線性匯編重新編寫，再用匯編優化器優化，鏈接，直到達到所期望的性能要求。

具體到G.729A標准編解碼器的實時要求，第三階段是工作的重點，而且線性匯編的重新編寫要求對程序代碼和DSP的特性有充分的了解。

3. G.729A代碼的剖析

CCS集成開發環境為軟體開發人員提供了高效的開發、調試工具。特別是它提供了評價器（ profiler）的優化工具，通過收集在指定代碼區間程序執行的統計性能，分析確定程序中各個段、各個子函數所花費的處理器時間，從而把程序的優化集中在對程序性能影響最大的代碼段上去[5]。其兩種不同的測試方法是：

（1） 在需要測定復雜度的程序段的開頭和結尾處設定兩個斷點，打開時鍾窗口，運行程序。在第一個斷點處執行停止，這時雙擊時鍾窗口使之清0，接著繼續執行程序，在第二個斷點處停止，這時，時鍾窗口顯示的值便是該段代碼的復雜度。這在測試程序中一個函數的復雜度是非常有用的。

（2） 先打開統計窗口，在需要測試的程序段頭尾設置統計點（（Probe Point）。程序運行結束後，統計窗口內該程序段後面的統計值便是該代碼段的復雜度。這種方法較簡單，統計點自動收集統計信息，無需手工干涉，這在測定程序多段代碼的復雜度是非常有用。

4. 線性匯編的優化

線性匯編是TI提供的一種匯編語言，其指令系統和匯編語言的指令系統完全相同，但在編寫時不需要指定寄存器和操作單元，也不需要考慮延時的問題，因此編寫線性匯編相對要容易一些 [6]。

經過第一階段和第二階段的優化後，音頻編碼程序在DM642上的運行狀況有了很大改善，但是經測試仍然沒有到達實時效果，而高級語言的效率幾乎發揮到了極致，測試的速度達到了36.5幀/s，是未優化之前的10倍。這時，我們採用線性匯編語言重新編寫C代碼的低效率段程序，進一步提高程序的執行效率和充分利用DM642的硬體資源，最終按設計要求在DM642實時實現G.729A編碼。在前面的DSP開發流程已經提過，DSP開發的最後一個手段是用匯編重寫C代碼，它是唯一可以既提高程序執行速度又可以減少程序體積的方法。由於針對並行處理器編寫匯編的難度很大，一般採取的是混合編程的方法，即程序的主要部分用C代碼，部分耗時較大的函數可以用線性匯編改寫。

在編寫線性匯編優化代碼的過程中，為了提高代碼執行效率，我們需要遵循以下原則[7]：

（1）寫並行代碼：通過使用匯編指令並行執行的方法減少循環內的執行周期數，優化線性匯編代碼。這里的關鍵問題是弄清指令相關性，只有不相關的指令才能並行執行。辨別指令是否相關，可以使用相關圖。

（2）處理跳轉指令和轉移指令：匯編程序的一大特點就是頻繁地跳轉，當滿足不同的條件時，要求程序進行不同的操作，或跳到相應的位置。對於「大於」、「大於等於」、「小於」、「小於等於」等較為接近的邏輯判斷和處理，應慎重對待，否則將產生邏輯性錯誤，並且很難調試。當發生溢出需進行相應處理時，這種現象尤為突出。

（3）盡量減少循環體內的指令數：G.729A的演算法實現，有許多是在循環內部完成的，有些地方如固定碼本搜索過程中，為了確定四個非0脈沖的位置和幅度，還用到了多重循環。在循環內部，特別是在嵌套較深的循環內部，減少一條指令可以大大降低程序的操作次數。例如，對於一個每重循環8次的四重嵌套循環，在最內層循環每減少一條指令，整個程序可以少執行84=4096語句。因此在設計程序時，能夠放在循環體外執行的語句，盡量放在循環體外執行。

（4）展開程序體：在一定條件下，盡量展開程序，以減少子程序的調用和返回次數，犧牲空間換取時間。

G.729A演算法中的LPC模塊、LSP量化及激勵碼本搜索耗時最多，為進一步提高代碼效率，對相關計算、FIR濾波等部分函數用線性匯編語言進行了改寫，並用畫相關圖等方法有針對性的進行優化。經匯編優化器優化後，代碼效率比C語言直接編譯有明顯提高。

5. 優化工作的創新點

在對G.729A的優化中，本文在前人研究成果的基礎上，針對TMS320DM642 DSP系列晶元提出了一些有價值的新方法。這些創新點在不同程度上提高了代碼的優化速度和執行效率，在語音編解碼的DSP實時實現中起到了關鍵性作用。下面，以舉例的方式闡明一些經典的方法。

5.1 繪制分析圖，掌握函數結構

對於一個語句較多、結構復雜的函數，為了充分了解其邏輯結構和語句的相關性，我們通常採用畫分析圖的方法。分析圖的形式比較靈活，可以根據具體的情況選用不同的制圖工具。在編寫線性匯編的時候，需要考慮存取數組中的元素，數據打包操作和數據相關性等問題，分析圖有助於正確處理這些問題。

在對函數Cor_h_X（ ）優化過程中，我們遇到了一定的困難，原因在於其中有一個雙層的循環體，內層的次數與外層有關，外層的循環次數為40，並且循環內部的語句有先後的相關性。這樣的結構如果用循環展開的方法將會用到大量的寄存器，數目超出了64個，需要開辟額外的內存空間去存放臨時變數，而讀寫內存會消耗較多的時間，因此這樣執行效率不會有充分的提高。對此，我們利用分析圖描述了函數中關鍵代碼的數組X[ ]，h[ ]的使用情況，如圖1所示：

圖1 cor_h_X（ ）函數分析圖（部分）

圖1直觀地反映了數組16位h[ ]和16位X[ ]之間的乘加關系，從函數cor_h_X（ ）中可知，兩個數組的乘積之和要對應的保存在臨時數組32位Y[ ]中。通過研究此分析圖，我們發現h[ ]與X[ ]中的一些元素進行乘積和處理之後就不再被使用，那麼存儲這些元素的寄存器可以存放中間結果（Y[]的元素），這樣就可節省寄存器的使用個數，免去了開辟內存空間和中間變數的存取指令。

對於函數cor_h_X（ ），利用上述思想編寫線性匯編，只需要定義57個寄存器就可以完成所用的操作，存取指令從1760條優化到30條，僅為原來的1/60。同時執行速度從390072個時鍾減少到35871個，降為原來的1/10。

繪制的分析圖可以包含相關圖，相關表等，使資源安排更加合理。該方法在其他函數的改寫中也多次使用到。

5.2 功能相似的函數或代碼段合並為一個函數

線性匯編在提高代碼效率的同時也成倍的增加了代碼尺寸，以上述cor_h_X（ ）為例，它在該寫後代碼尺寸從660條增大到7776條（該數據由CCS剖析工具分析所得）。在工程應用中，對於有限的內存程序區，我們會適當減少程序佔用的空間。合並功能相似的函數可以達到這一要求。

在LSP量化處理中，源代碼中給出了2個LSP選擇函數：Lsp_select_1（ ）和Lsp_select_2（ ），而我們發現它們具有相同的功能和相似的結構，因此，在對兩者的線性匯編改寫中，我們只需編寫一個函數（命名為Lsp_select）即可實現LSP量化處理中這兩個模塊的功能。

另外，在對於一些數組拷貝，數組初始化的代碼，我們同樣可以用此方法，編寫一個函數實現，這樣可以在提高執行效率的同時，減少程序佔用的內存空間。

5.3 多個循環合並為一個循環

C代碼改寫線性匯編的時候，我們常常會發現，只要作一些調整，兩個或多個循環完成的操作完全可以由一個循環來完成。以LPC子模塊240點加窗語音的自相關計算Autocorr（）函數為例，經過優化改寫的C代碼（部分）如下：

for（i=0; i<L_WINDOW; i++） //第一個循環體

y[i] = （_smpy（x[i], hamwindow[i]）+0x00008000L）>>16;

sum = 1; //避免為0的情況

for（i=0; i<L_WINDOW; i++） //第二個循環體

sum = _sadd（sum,_smpy（y[i], y[i]））;

這段代碼包含了兩個for循環，在CCS中直接編譯運行並行度很差，利用線性匯編重寫代碼。我們發現兩個循環體的循環次數均為60（L_WINDOW=60），所處理的數組不同，並且兩個循環沒有相關性，可以把第一和第二個循環合並成一個循環。前者的功能是對語音信號進行加窗；後者是實現乘累加（Mac）。兩者合並後採用線性匯編編寫，其代碼如下：

mvk 60,i //設置循環次數

loop1: lddw *ham++,hamih:hamil //hamwindow[]指針

lddw *x++,xih:xil //x[]指針

smpy2 hamil,xil,yi1:yi0 //兩對16位操作數相承，並行執行

smpy2 hamih,xih,yi3:yi2

sadd yi0,con0x8000,yi0

sadd yi1,con0x8000,yi1

sadd yi2,con0x8000,yi2

sadd yi3,con0x8000,yi3

packh2 yi1,yi0,yl //數據打包技術

packh2 yi3,yi2,yh

stdw yh:yl,*y++ //雙字存取，提高執行效率

smpy2 yl,yl,yi1:yi0

sadd sum0,yi1,sum0

sadd sum0,yi0,sum0

smpy2 yh,yh,yi3:yi2

sadd sum0,yi3,sum0

sadd sum0,yi2,sum0

add i,-1,i

[i] b loop1 //把第一和第二個循環合成一個大循環，減少轉移次數

產生的匯編代碼並行流水性能大大增加，耗費的時鍾周期數從1310000減少到15000，少於改編前的1/8。

6. 結束語

關於編解碼器執行的時鍾周期，在線性匯編改寫前後，文件版本通過CCS的profiler剖析工具得知：每10幀（100MS）從159700000降至68500000，僅為原來的42%。硬體版本進行測試得：編解碼的幀數提高到了88幀/s以上，鑒於編碼、解碼的時間比例為5:1，所以，本系統編碼已經達到100幀/s，完全符合實時通信的要求。