アカウント名:
パスワード:
アイデアとしては面白いですが、その場合retaddrとデータ部はどこに置くことになりますか?
現状、retaddrはpushすることにより、autoの変数はスタックポインタを減ずることで実現しているわけですが、現状のCPUのSPが1つである以上、retaddrとauto変数を別の場所に置くための仕掛けが必要となります。この場合の実装として考えられるのは、1. 2つのSPコンテキストを維持してリターン直前にretaddr用のaddrをSPにロードする 2. auto 変数をヒープを用いるよう変更してしまう という方法あたりになるかと思いますが、1ならコンテキスト(退避したレジスタの内容)をどこに配置す
それは知りませんでした。こんど注意深くコードを見てみようと思います。ありがとうございました。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
分岐とデータのスタックを分離していないこと (スコア:1, 興味深い)
auto変数の配列を(リターンアドレス等に使う)メインのスタックではなく、別のスタックに置けば
かなりの改善を得られると思うんです。
別のスタックに対する操作はコンパイラが生成したコードでやるわけですから透過的に行えるし、
そのオーバーヘッドは、いちいちヒープを使うよりも遥かに少なくそしてメモリリークのバグをやらかしにくい。
まぁリターンアドレスを細工されることは防げても、他のデータにはみ出して上書きして特権的なフラグを操作する・・・なんてことには対処できませんが。
Re: (スコア:2)
アイデアとしては面白いですが、その場合retaddrとデータ部はどこに置くことになりますか?
現状、retaddrはpushすることにより、autoの変数はスタックポインタを減ずることで実現しているわけですが、現状のCPUのSPが1つである以上、retaddrとauto変数を別の場所に置くための仕掛けが必要となります。
この場合の実装として考えられるのは、1. 2つのSPコンテキストを維持してリターン直前にretaddr用のaddrをSPにロードする 2. auto 変数をヒープを用いるよう変更してしまう という方法あたりになるかと思いますが、1ならコンテキスト(退避したレジスタの内容)をどこに配置す
Re:分岐とデータのスタックを分離していないこと (スコア:0)
CPUが管理するもの・・・x86ならpush/pop/call/retなどで使うもの
ソフトウェアが管理するもの・・・いくらでも実装例ありますね
2つがあるわけです。
レジスタに入らないようなサイズのauto変数(つまり配列や構造体ですね)を、CPU管理のスタックではなく、ソフトウェア(この場合はコンパイラが生成したコードによる)管理のスタックに置くことは、レジスタウィンドウを持つCPU向けのCコンパイラでは、普通に行われていることですよ。
Re:分岐とデータのスタックを分離していないこと (スコア:1)
それは知りませんでした。こんど注意深くコードを見てみようと思います。
ありがとうございました。