軟趴趴

    上一篇有講到 0.9.1 之前 dynamic code generation 是用稱為dyngen 的方式(請自已看上篇，我不會做連結)，這個方式有一些問題(我自已掰的，可能是錯的)

1. compiler issue

00000000000001e7 <op_addl_T1_T2>:
     1e7:       45 01 ec                add    %r13d,%r12d
     1ea:       c3                      retq

00000000000001eb <op_subl_T1_T2>:
     1eb:       45 29 ec                sub    %r13d,%r12d
     1ee:       c3                      retq

00000000000001ef <op_addl_T0_T1>:
     1ef:       45 01 e7                add    %r12d,%r15d
     1f2:       c3                      retq

    上面是compile op.c 產生的code，有沒有發現怎麼每個function block 都這麼小呢？一般的function 都有　prolog 和epilog，dyngen 為了精確的決定operation function 所對應host code，所以利用　-O2  -no-strict-aliasing (不知道在幹嘛的)拿掉prolog 和epilog，而且確保 return instruction 是在最後一個，才知道要copy 多少instruction 走。這套方法在gcc 3.x 版運作的很好，但是在gcc 4.x 版，return instruction 會被塞在function block 的中間，那就吃屎啦。可以去看一下maillist 有一堆在哭為什麼 gcc 4 不能用的討論，但隨著linux distribution 都採用gcc 4 為預設compiler，而且這世界上又不是只有gcc，這個問題必需要解決。

2.optimization issue

  假設我們的target code 為

add r1, r2, r3

xor r4, r2, r3

sub r5, r2, r3

則經過dyngen maping 到的host code 大概會像這樣

mov T1, r2

mov T2, r3

add T0, T1, T2

mov r1, T0

mov T1, r2

mov T2, r3

xor T0, T1, T2

mov r4, T0

mov T1, r2

mov T2, r3

sub T0, T1, T2

mov r5, T0

有看到問題嗎？r1, r2 的值本來就在T1,T2為什麼我還要一直重覆搬呢？因為dyngen的scope 只限在單一的target instruction，對於其它人的行為沒有辦法處理

3 porting issue

要將qemu port 到新的target 要做的事情就是先定義opertion function，可是cpu 其實每個都差不多阿，誰家cpu沒有 add, xor, sub, and，等等的東西，

每個都要定義自已的一套非常煩人，是不是可以有一共通的架構呢？

為了以上問題，2008/02/01 Fabrice Bellard 和　Paul Brook 引進了TCG, tiny code generator。

怎麼運作的呢？我也不懂，但是其實就是一個小型的compiler，TCG定義了自已的operation function(intermediate code），可以以basic block 為單位做optimization，比如說(後面的32是指這個是32bit instruction)

and_i32 t0, t0, $0xffffffff

就會被拿掉，或者是

add_i32 t0, t1, t2
add_i32 t0, t0, $1
mov_i32 t0, $1

只有最後一個instruction 會被保留。還有一堆有的沒有的功能，請看這裡

另外作者說，TCG是可以跟dyngen混用的，但還是希望以後所以的target都可以轉到TCK這個framework，目前在cvs看得的只有x86和cris，3/31時Paul Brook已經

把arm由dyngen 轉到TCG了，但他說還需要一些clean up，等他commit 上去再來看看吧，x86你爸很不熟。