1.不要假設dsp6000上的int型別與long長度相同，在dsp6000上，int型別佔32bits，而long型別佔40bits，另有一種long long型別為64bit長度
2.定點乘法最好使用short型別，這樣只需要1個時鐘週期，使用int型別需要5個時鐘週期
3.使用int或unsigned int作為迴圈計數變數的型別，這樣可以避免無謂的符號擴充套件指令
4.在c6700上使用浮點指優化mv6700編譯優化選項
5.在dsp6000上，各種儲存型別及其長度分別是：
short 16 bits -32768~32767
int 32 bits −2147483648~2147483647
long 40 bits −549755813888~549755813887
指標 40 bits 0000:0000h~ffff:ffffh
long long 64 bits -9223372036854775808~9223372036854775807
float 32 bits 1.17549435e−38~3.40282347e+38
double 64 bits 2.2250738585072014e−308~1.7976931348623157e+308
注意：儘管float與int的單位儲存長度一樣，但由於記憶體儲存的資料表達方式不同，float的儲存資料範圍要比int型別大得多。
DSP6000的上電及供電
dsp的確是個怪胎，常見的兩個問題就是 1 連線不上ccs開發環境 2 燒晶元。我現在使用的是tms320c6713，以下經驗都基於dsp6000，其它系列或有不同。似乎現在晶元效能變好了，也沒燒過晶元，但ccs還是經常出現連線不上的情況。其中一部分原因與硬體的穩定性有關，注意在設計電源電路時就最好...
DSP6000的上電及供電
dsp的確是個怪胎，常見的兩個問題就是 1 連線不上ccs開發環境 2 燒晶元。我現在使用的是tms320c6713，以下經驗都基於dsp6000，其它系列或有不同。似乎現在晶元效能變好了，也沒燒過晶元，但ccs還是經常出現連線不上的情況。其中一部分原因與硬體的穩定性有關，注意在設計電源電路時就最好...
MongoDB調優的幾個要點
前提 不考慮shard 使用場景受限,運維成本比較高 mongo例項的庫規模超過百g,單個collection 超過千萬 未達到這個規模的集群,效能不會太差,維護的手段可以選擇使用,降低維護成本 使用層面 生產環境應預設開啟journal log write reference 使用 journal...