H8 Mailing List archive

hamayan です。

廣田> jsrを実行した後、戻り先をスタックに積むより処理が速くなると言っても
廣田> 飛び先のサブルーチンがさらにjsrをネスティングするためには結局、PRを
廣田> どこかに保存しなければなりません。

必ずしもサブルーチンの中から、またサブルーチンを呼ぶとは限らないからでは？
簡単な関数ならインライン展開されてしまう事が多いです。


廣田> おそらく、Ｃコンパイラも、ある関数を汎用的に作ろうとするなら、結局prを
廣田> スタック上に積んだり、戻したりする処理をつけるでしょう。

コンパイラは何でしょう？
HEWでの結果です。こんなどうでも良い関数をやらせてみました。

int prociduer(int a, int b);

int kotae;

void main(void)
{
    kotae = prociduer(1, 2);
}

int prociduer(int a, int b)
{
    return a + b;
}

アセンブル結果は、
_main:                           ; function: main
                                 ; frame size=4
          STS.L       PR,@-R15
          MOV         #1,R4      ; H'00000001
          BSR         _prociduer
          MOV         #2,R5      ; H'00000002
          MOV.L       L12+2,R6   ; _kotae
          LDS.L       @R15+,PR
          RTS
          MOV.L       R0,@R6
_prociduer:                      ; function: prociduer
                                 ; frame size=0
          ADD         R5,R4
          RTS
          MOV         R4,R0
L12:
          .RES.W      1
          .DATA.L     _kotae
          .SECTION    B,DATA,ALIGN=4 
_kotae:                          ; static: kotae
          .RES.L      1
          .END
でした。
関数prociduerは、関数の内部で完結していると判断できるので、この様な場合
HEWはSPEEDオプションを付けると、徹底的に最適化します。

スタックはメモリ上に詰まれますが、もしかして8bitサイズで、低速なメモリ
かもしれないので、あてには出来なかったのでは？