-1

アセンブリ コードを C コードに変換する必要がありますが、次の 2 行で問題が発生しています。

 804842d:   c7 44 24 18 00 00 00    movl   $0x0,0x18(%esp)
 8048434:   00 
 8048435:   c7 44 24 1c 00 00 00    movl   $0x0,0x1c(%esp)
 804843c:   00

これは私が与えられたアセンブリコードです。

したがって、CI では main 関数のこの部分を作成しました。

 int main(){
   int x, y;
   x=0;
   y=0;
  }

しかし、このコードをアセンブリに変換すると、次のようになります。

804842d:    c7 44 24 1c 08 00 00    movl   $0x0,0x1c(%esp)
8048434:    00 
8048435:    c7 44 24 18 07 00 00    movl   $0x0,0x18(%esp)
804843c:    00

アセンブリ バージョン (0x1c(%esp) と 0X18(%esp)) で 2 つのアドレスが反転するのはなぜですか? それを修正する方法はありますか？

4

1 に答える 1

4

私は、これが疑わしい分別の努力であることに同意します。

ただし、少なくとも、生成されたアセンブリ コードを正しく理解できると便利です。ここでの主な問題は、x86 ではスタックが下向きに成長することです。つまり、スタックの上位にある変数 (最適化を行わないと仮定し、実装固有の詳細を掘り下げると、後で宣言される変数) は、以前に宣言された変数よりもアドレスが低くなります。

これを念頭に置いて、xのアドレスが であるのに対し、yのアドレスは であることは理にかなっています。わかりやすくするために、常に変数に異なる値を入力するようにしてください。0x18(%esp)0x1c(%esp)

スタックが下向きに成長するのはかなり混乱しているように見えますが、Intel アーキテクチャの初期には意味がありました。コードと動的に割り当てられたデータは可能な限り低いアドレスにロードされ、スタックはアドレス空間の最上位に基づいていました。 . このように、スタック用に確保するメモリ量とヒープ用に確保するメモリ量について明示的な妥協をする必要はありません.2つの合計がアドレス空間の合計サイズを下回る限り、それらはアドレス空間をうまく共有できます.

于 2012-09-30T12:01:20.433 に答える