======================11/25=======================
meeting投影片
延續上禮拜做的給做完。之前的loop因為寫得太單調了所以感覺沒用到幾個branch instruction，改的複雜一點就可以看出差別:
Function call -> LJMP, RET
while loop -> SJMP, CJNE
For loop -> SJMP, JNC
If-else -> JZ, JNZ
但仍然有少數的branch instruction我試不出來。最後沒辦法只好寫inline assembly自己測試:
ACALL, AJMP, LCALL, DJNZ, JB, JNB, JBC
======================11/18=======================
實作decoder加入判斷branch目標位子的功能。測試程式我是寫了簡單的while loop, for loop, 和function call來測試，但是看了對應的assembly code發現有些branch指令還是沒測到。之後會直接inline assembly繼續測試。
======================11/10=======================
寫了一個簡的測試程式，把每一行C code設breakpoint測試，都有停下來。同理用next step一步步執行也都有停到預期的program address；除了branch instruction。
因為只能根據目前的instruction長度判斷下一個instruction的位子來設定breakpoint，如果停下的點是branch instruction，則設定的breakpoint位子可能是執行不到的。譬如無限迴圈while(1);在assembly code就只是sjmp當下位子，我breakpoint則會設定到迴圈之外。
簡決方法是單步執行的decoder還必須能判斷branch的位子。
======================11/04=======================
原本Breakpoint的指令是用timer達成，現在已經改成學長的建議用software interrupt: SETB TF0。
上禮拜關於GDB的單步執行(next)會卡死的原因，發現單步執行所給予的breakpoint位子不可能走的到，我判斷是GDB端的問題。GDB處理signal step的地方當初是直接延用bbb的risc32，也就是判斷下一個instruction的位子是目前PC直接+4，所以才會造成GDB會產生一個不可能走到的breakpoint。又因為8051是CISC，下一個instruction的位子等於目前PC值加上目前instruction的長度，所以加上一個簡單的decoder判斷目前instruction的長度。
目前build GDB失敗......
======================10/28=======================
主要是實作8051 stub處理breakpoint的問題。8051 stub接到breakpoint指令後，啟動timer0 interrupt。利用timer interrupt每執行一個instruction都進handle_exception()檢查目前PC值和之前設定的breakpoint是否相同。
不同則表示還沒到breakpoint，return。
相同則表示已經走到breakpoint，進入無限迴圈等待GDB的指令。
目前測試看來是成功的，不過奇怪的是GDB的單步執行(next)會卡死，懷疑可能是GDB端給的program memory address有誤，目前還在debug。
======================10/21=======================
處理breakpoint之前，我想先完成單步執行的功能，因為breakpoint可以利用單步執行，每執行一instruction就比對一次目前的PC值是否和breakpoint table裡任一數值相吻合。
另一方面，GDB的單步執行(next)也差不多是如此；GDB的繼續指行(continue)就是跳出handle_exception繼續執行直到遇到breakpoint後又進去handle_exception。GDB的單步執行(next)則是根據symbol table知道下一步instruction的位子，設定breakpoint在那位子後，繼續執行(continue)。
處理單步執行我是用timer0 interrupt，簡單的驗證方式是觀察每一步的PC差距，更進一步應該是要比對binary code的instruction。還沒完成是因為遇到bug，應該只是個小錯誤，還在debug中。======================10/16=======================
我試著插入breakpoint於測試程式中，觀察設定breakpoint後GDB傳給8051 stub的program memory address內容有誤。直到觀察assembly code才發現某些C code沒有對應的assembly code。
因為我的測試程式寫得太簡單，裡面一些簡單的變數運算可能sdcc判斷為無用。更進一步去觀察測試程式所設定的變數，變數設定太簡單，sdcc會直接定為某個register，而不是給予一個記憶體位子。這樣會間接導致那些變數編譯完後也不存在於symbol table中。
後來變數加入volatile的設定而解決，主要目的是程式對volatile的變數作存取時必須直接到他的位子作讀寫而不是經過暫存器或者cache之類的。這樣的設定也會強制sdcc必須安排volatile的變數一個記憶體位子，而不是定為某個register。
======================10/08=======================
paper投影片
BEE2 是由四個user FPGA和一個control FPGA組成，根據FPGA提供的功能如I/O pins和其要求如供電壓等作設計，最後加上其他周邊硬體如usb, rs232等完成整個平台。
平台裡每個FPGA都加入PowerPC的架構並在control FPGA執行Linux，主要用於控制周邊硬體，監控等。
======================10/06=======================
常常會忘記自己做的東西是很底層的，很多是事情其實直接用inline asm解決即可；也有很多問題是必須trace assembly code才會知道錯誤在哪。
上禮拜是驗證8051 stub回傳的PC是否正確，這禮拜是驗證其他registers(r0-r7 sp)。
驗證方法很簡單，在進入function handle_exception()之前用inline asm隨意指定r0-r7的數值，之後觀察8051 stub回傳的r0-r7和之前指定的數值是否一致。
接下來是之前提到的，回傳的memory數值不正確。
原因是為了8051 stub回傳registers方便，我宣告一些全域變數用來儲存registers的參數；並為了inline asm撰寫方便，宣告時也指定那些全域變數的位子。我本來以為compiler會處理其他(如區域變數)的位子並避開前面我指定位子的全域變數，結果並不會。簡單的判斷方法就是宣告幾個同位子的變數看compiler是否有warning或error。我之所以認為compiler會處理這問題是因為Keil C51就會在變數位子的宣告有重疊時會產生warning，但是我目前用的SDCC卻不會。這問題就會影響到8051 stub回傳memory數值的錯誤，我用以下範例說明。
reg_PC一變數是我宣告用來儲存中斷點的位子，也就是handle_exception function return的位子。所以一開始8051 stub與GDB連線時，stub會進入handle_exception function並回傳所有registers的數值，其中包含PC值，所以在這一點我是直接回傳reg_PC的數值，也是上禮拜用來確定回傳的PC值是否正確的依據。
但是reg_PC也是一個變數可以在symbol table找到，所以可以用指令display reg_PC調出他的數值。用display指令和之前回傳register的方式不太一樣，前者是回傳目標記憶體位子的數值；後者則是直接回傳指定變數的數值。之前會回傳錯誤資訊的原因是因為handle_exception function的區域變數會覆蓋到reg_PC的位子。解決方式就是不要指定位子，全部給compiler分配就好了。
======================9/29========================
8051 stub方面，有個問題是不知道怎麼在C程式裡得到processor暫存器(pc，sp，r0-r7)的資料，後來直接寫inline assembly code來解決。首先宣告一個固定位值的變數如: data unsigned char at 0x20 reg_temp[8]，表示變數reg_temp陣列在iram裡的0x20-0x27位子，接著用inline asm 如: mov 0x20, r0 的方式把r0-r7的資料存到reg_temp陣列裡，最後reg_temp就保存了r0-r7的資料了。pc也是用類似的方法，只是inline asm 是用pop push得到進入handle_exception function前的pc值。(handle_exception是stub裡的function，主要是收送GDB端讀寫的封包，一般在程式走到breakpoint會進入的function)
目前我只能驗證stub回傳的pc值是正確的，假設handle_exception function的進入點是在main function裡，可以從symbol table得知main function的起始位子，簡單的計算就可得知stub回傳的pc是否正確了。
接下來的問題是回傳的memory數值不正確，不過應該只是stub哪裡寫錯了，詳細情形我還在找原因。
GDB方面，之前有提到說把register的數值列印出來的指令會導致GDB當掉，原因是出在我GDB裡的TARGET-tdep.c裡對於每個register的宣告上(function enum gdb_regnum)我設定9個register，然而在(function TARGET_analyze_control_transfer)裡分析register裡，也就是switch case裡我少設定一個register，導致找不到那缺少的register case而在default case裡回傳error message的動作。改完後就可以正常的列印出暫存器數值了。
======================8/30========================
debugging stub透過COM port與GDB溝通的方式為RSP(Remote Serial Protocol)，其封包格式很簡單: $ddd...#hh。 '$' 是封包的開頭，'ddd...'是十六進位資料且並無限定長度，'#'表示結尾，'hh'為十六進位的兩個checksum。
GDB遠端連線建立好後，會先送出"qSupport"，stub收到後回傳"T05"表示停下來的原因是breakpoint，接著stub回傳所有register的資料。以上資訊傳輸完後，GDB就會列印出目前的位值和等待使用者的指令，stub也是在一個無線迴圈內等待GDB的封包。
我目前的遇到的問題是，連線建立後，輸入指令如列印出某暫存器的數值後GDB會死當，根據找的文件是說這可能是BFD那邊的問題，也就是symbol table的問題，真正問題的原因我還在尋找。
至於上個禮拜關於debugging stub回傳暫存器的數值有誤的問題，本來以為燒錄器的問題: 因為同一個程式燒入兩次卻有不同的結果。但是後來請aaa幫忙修理才知道燒錄器沒問題，是晶片at89c51燒壞了。
======================8/24========================
GDB for 8051我想粗分成以下幾個階段:
1. GDB透過COM port能與8051硬體相連，傳輸最基本的功能就是讀寫registers和memory。
2. GDB端的symbol table
3. 支援breakpoint
我目前還在第一階段，想說先架起最基本功能的debugger，可以根據兩端傳輸的資料看出我哪一端有修改錯誤。GDB端要做修改的地方應該比較簡單，主要是修改TARGET-tdep.c和TARGET-dis.c對暫存器的宣告(TARGET=8051)讓GDB認得TARGET的架構；8051硬體端，也就是debugging stub，負責與GDB做溝通，目前最基本的功能就是讀寫暫存器和記憶體。
測試程式方面我是用SDCC (small device c compiler)編譯，產生binary執行檔格式為Intel Hex format。GDB認得這格式為executable file，但是卻會顯示找不到symbol table，因為裡面純粹是程式的資料。不過少了symbol table，GDB應該還是可以讀寫暫存器和記憶體。
目前是卡在debugging stub回傳暫存器的數值有誤，我還在尋找出錯的原因。
第二階段是關於GDB需要的symbol table方面。SDCC編譯C程式可以產生8051的執行檔(Intel Hex Format)和symbol table(CDB format)，主要是用於SDCC提供的8051模擬器SDCDB。麻煩的是GDB不支援CDB格式的symbol table，我目前也找不到工具可以將CDB轉成GDB已知的格式如ELF或者COFF等。
GDB認得symbol table的格式定義在BFD，修改BFD讓GDB可以看的懂CDB格式的symbol table，
這應該會是我第二階段要做的。
最後支援breakpoint階段我想等前面的問題釐清後再討論。
======================8/11========================
這是我在meeting時報的paper: Functional Simulation Using Sim-nML
由於時間比較緊迫，我並沒有仔細讀完全部的，上台報告的像是Sim-nML教學。
paper大略的內容是利用Sim-nML語法模擬出一個processor model，作者的Functional Simulator Generator可以parse此model成一個c++的class，並產生一個屬於此processor的simulator。
這simulator可以執行模擬的processor的執行檔，且利用GDB作為介面，remote control這個simulator。
投影片
論文
在meeting的時候提出的討論:
1. (pg. 6) SystemC is targeted more toward system level modeling rather than processor modeling.
對這句話有疑問，systemC不一定就是要用system level來描寫。
2. (pg. 25)—Methods for handling traps and other synchronized events
是指關於interrupt時processor處理的行為，白算盤裡有詳細的解釋。
3. 關於Sim-nML，是有compiler等工具支援，發展至少有十年歷史。
