K.Maebashi's BBS

たびたび細かい話をもうしわけありません。(件名、変えて投稿します) 同書では、図時する場合、アドレスが増える方向は、多くの場合図の下方になっていると思います(例えば、Fig. 1-6)。そして、配列に関しても、Fig. 1-8では、array[]の添え字が増えるのは下方に向かって、になっています。 ところが、Fig. 2-7では、スタックの伸長方向の矢印は、上方に向かって書かれています。 また、Fig. 2-9 では、hoge[]の添え字が増えるのは、下方に向かって、なのですが、やはり伸長方向の矢印は上向きになっています。 これは、「スタックは、番地が減る方向に利用範囲を広げていく」という事なのでしょうか? 積む、というイメージからは、番地が増える方向に利用範囲を広げていくように感じたのですが…(ある領域に固定長の配列をひとまとめに確保する、という場合でも、それは、番地の低い側に?) あ、いや、実験してみればよいのですね…　試してみます。

>たびたび細かい話をもうしわけありません。(件名、変えて投稿します) > >同書では、図時する場合、アドレスが増える方向は、多くの場合図の下方になっていると思います(例えば、Fig. 1-6)。そして、配列に関しても、Fig. 1-8では、array[]の添え字が増えるのは下方に向かって、になっています。 > >ところが、Fig. 2-7では、スタックの伸長方向の矢印は、上方に向かって書かれています。 >また、Fig. 2-9 では、hoge[]の添え字が増えるのは、下方に向かって、なのですが、やはり伸長方向の矢印は上向きになっています。 > >これは、「スタックは、番地が減る方向に利用範囲を広げていく」という事なのでしょうか? >積む、というイメージからは、番地が増える方向に利用範囲を広げていくように感じたのですが…(ある領域に固定長の配列をひとまとめに確保する、という場合でも、それは、番地の低い側に?) > >あ、いや、実験してみればよいのですね…　試してみます。 お騒がせして申し訳ありません。 intの10要素の配列を3つほど宣言し、先頭アドレスを表示させてみたところ、たしかに、あとから宣言したものほど、低いアドレスに置かれていますね… (linux x86_64, gcc 14.2.1) 不思議…　なんでなのでしょう?

>intの10要素の配列を3つほど宣言し、先頭アドレスを表示させてみたところ、 >たしかに、あとから宣言したものほど、低いアドレスに置かれていますね… > (linux x86_64, gcc 14.2.1) >不思議…　なんでなのでしょう? これはCの問題でもOSの問題でもなく、CPUの問題です。 たいていのCPUにはサブルーチンコールのためのCALL命令があり、戻り先をスタックに 積みます。これは機械語レベルの命令なのですが、この時、スタックはアドレスが小さい方に 向けて伸びるCPUが多いと思います。たとえば、おっさんプログラマならだれでも知っている 大昔の8ビットCPU Z80(1976年発表)でも、CALLすると、スタックの先頭を指しているレジスタで あるSPの値は減ります。 http://www.yamamo10.jp/yamamoto/comp/Z80/instructions/index.php#CALL_RETURN スタックがどちら向きに伸びるのかは、どっちでもよいようなものではありますが、 限られたメモリの中でプログラムを書く場合、プログラマが管理する領域は上から下に、 スタックは下から上に伸ばすようにしていけば、最後までメモリを使い切れる、という 事情はあったのではないかと思います。 今のCPU/言語でも、ポインタ完全制覇のFig2-3にあるように、malloc()で伸びる領域と スタックの領域の間には広大な空間があるわけです。 Wikipediaを見てみたら、以下の記述がありました。 | 昔のコンピュータで、ヒープ領域をアドレスの小さいほうから大きいほうへ伸ばし、 | スタックを大きいほうから小さいほうへ伸ばす（そのようにすると、メモリが足りない場合は | どちらを伸ばす余裕もなく、完全にメモリを使い切って計算続行不可能となる）という | 設計にした名残りから、アドレスの大きいほうから小さいほうへ伸びるものが多いが、 | PA-RISCは逆である。 逆のものもあるようですね。 もっとも、Cの場合、スタックを「アドレスの小さい方へ」伸ばすようにした結果、 バッファオーバーフロー脆弱性がずいぶんと狙いやすくなった、という実害が出ていますが……

>Wikipediaを見てみたら、以下の記述がありました。 すみません、Wikipediaのリンクを貼り忘れてました。 https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF

奇遇？ですがこんな記事も書いたことがあります。 https://ja.stackoverflow.com/questions/61298/ PA-RISC な hpux がウチの部内サーバとして今でも現役っス。

>intの10要素の配列を3つほど宣言し、先頭アドレスを表示させてみたところ、 >たしかに、あとから宣言したものほど、低いアドレスに置かれていますね… すみません、ここをよく読んでいなかったようですが、 ひとつの関数の中でのローカル変数がメモリ上にどんな順に並ぶかは、 スタックの伸長方向とは無関係で、コンパイラ次第です。 たとえばintが4バイトとして、int a, b, c;という宣言なら、12バイト分の 領域を確保すればよいだけで、a, b, cの順に何かをする必要はありません。

>奇遇？ですがこんな記事も書いたことがあります。 >https://ja.stackoverflow.com/questions/61298/ >PA-RISC な hpux がウチの部内サーバとして今でも現役っス。 なるほど。確かに奇遇というか、さすがです。 ちょっと調べた範囲だと、HP-UXだからといってsbrkが逆に伸びるわけではなさそうですね。、 https://community.hpe.com/t5/operating-system-hp-ux/sbrk-value/td-p/4961203 | current sbrk value = 0x15A4E000 | Maximum sbrk value = 0x7A000000 どのみちスタックサイズに制限をかけるなら、ヒープとスタックが同じ方向に 伸びようが無問題、という気はしますが。

> ヒープとスタックが同じ方向に伸びようが無問題、という気はしますが。 御意。 ヒープとスタックが逆向きに伸びる＝残り RAM を最大限に利用可能、ってのはシングルタスクシングルスレッド限定の話。今どきはマイコンでもマルチスレッドマルチタスクを使う関係でスタック領域も事前に確保した固定長ですから。 ---- 世の中に x86 系が普及した（普及しすぎた）関係で x86 と違う仕様の CPU はみなゲテモノ扱いされちゃってるのが PC 業界の常識となっちゃっています。でもマイコン業界だとその辺のゲテモノがいっぱい残っていますし面白いですよ。 最近オイラが使った例だと TI 社の C2000 系マイコンなんかまさにゲテモノです。もともとが 16bit な DSP を無理くり 32bit CPU 化したという代物で、そのため (1) char=16bit　/ short=16bit / int=16bit / long=32bit C 言語仕様書 ISO/IEC 9899:1999 6.5.3.4 が sizeof(char)==1 を要求しているので sizeof(char)==1 / sizeof(short)==1 / sizeof(int)==1 / sizeof(long)==2 (2) スタックは高いアドレスに進む 既存コードが char=8bit を前提に書かれていたりするので、移植の際にはアセンブラ出力の読解が必須だったりします。他人に任せられない（自分自身も信頼できない）という罠

>(1) char=16bit　/ short=16bit / int=16bit / long=32bit > C 言語仕様書 ISO/IEC 9899:1999 6.5.3.4 が sizeof(char)==1 を要求しているので > sizeof(char)==1 / sizeof(short)==1 / sizeof(int)==1 / sizeof(long)==2 となるとCHAR_BITが16で、malloc(1)で取れるのは16ビットで、となりますかね。 マイコンだと、UCS2までcharで使えてべんり! とはきっとならずに、 8bit単位で読み書きする必要があるたびにビット演算、となるのですかね。 お疲れ様です。