[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]

[OSASK 3163] from OSASK BOARD



このメールは、OSASK伝言板に書き込まれた内容です。
この書き込みに返事を書く場合は、下のURLから書き込みを行なって下さい。


http://www.imasy.or.jp/~mone/osask/index.cgi?REFER=3c646e35_4d87

From: 川合秀実
Message-ID: 3c646e35_4d87
Date: 2002/02/09 09:32
Subject: Re: nikq::osask

[OSASK 3155]へのレスです。

>最初のうちはただのメモ書きのつもりだったんですが
>どうせなのでちょっとがんばってみました。
>今度のはどうでしょうか。

  非常に良くなりました。お手本のような詳しさです。

  ちなみに、些細なミスを発見したのでお知らせしておきます。最後の

>これでhogehoge.bimができます。

は、.binの間違いですよね?・・・というか、これくらいしか問題が無いくらい
によく書けています。とても感謝しています。

  ついでに書いておくと、mallocやstackのサイズの計算方法については、[OSAS
K 2982]が参考になると思います。

>> dataセクション
>-fwritable-stringsは効果がありました。
>きちんとデータセクションに配置されました。

  ご報告ありがとうございます。よかったです。

>しかしgccの日本語訳によれば、
>http://www.sra.co.jp/wingnut/gcc/gcc-j.html (1508kb)
>-fwritable-stringsはあまり薦められていません。

  苦労してダウンロードして読んでみました。

>-fwritable-strings
>     文字列定数を書き込み可能なデータセグメントに格納し、一意化しない。
>     これは、文字列定数に書き込みが可能であると仮定している古いプログラ
>     ムとの互換性を取るためにある。-traditional オプションを指定しても
>     この機能が有効になる。 
>
>     文字列定数に書き込もうとするのは全くの間違いである。「定数」は定数
>     であるべきなのだ。 

  この記述はまったくもってその通りです。一意化できないのはただの無駄です
し、文字列定数を書き換え可能にしなければいけないプログラムは褒められたも
のではありません。lcc-win32では、文字列定数を一意化しますが、.dataセクシ
ョンに置きます。

  しかし言わせてもらえるなら、フラットモデルしか想定していないgccが悪い
のです。IA-32にとってはフラットモデルはページテーブルの無駄使いの原因に
なります。

  結局この文章は、文字列定数を書き換え可能しなければいけないということを
非難しているのであって、.dataセクションに置くことを非難しているわけではあ
りません。.dataセクションに置いたからといって書き換えるという訳ではありま
せんから。

>また、const intはきっちりと.textに配置されました。
>.dataに置き換える方法は見つかりませんでした。

  ああ、そうでしたか・・・。それは残念です。

>OSASK側でサポートする事は不可能でしょうか。

  OSASK側でサポートすることはもちろんできます(もともとフラットも使える設
計なので)。できますが、今までとはだいぶ違った配置になるために、OSASK側の
機能追加だけではなく、obj2bimやbim2binもいじらなくてはいけません。結構面
倒です。

  また.textに置かれてしまうとstaticデーター圧縮対象からも外れてしまい、
コードサイズが肥大化するようになるでしょう。いいことは一つもありません(
とはいっても他のOSと同レベルになるというだけなんですが)。

  とりあえずは、文字列定数については-fwritable-stringsでしのいで、const
な変数はMinGWでは極力作らないようにするしかありません。エディターの文字
列置換で「const」をスペースと置換した方がいいかもしれません(引数リスト内
のconstは害が無いので置換する必要はありません。・・・C++ではオブジェクト
を変更しないことを明示するためにconstを書かなければいけない時もあります)
。取り除くのは変数宣言にくっついたconstだけです。

  どうしてもOSASK側のサポートがほしいということになれば、やります。いつ
かやるつもりだったんですし、これでフラットモデル用のプログラムの移植が格
段にやりやすくなりますから。でもそれは、具体的に「〇〇というアプリを移植
するために」のような要望が出るときまで、後回しにしたいです。これでいいで
しょうか?

  なんというか、フラットモデルの受け入れは効率悪化の容認でしかないので、
非常に気分が乗らないんです。これが逆で、フラットしかサポートしていなくて
新たに今のメモリモデルを導入するということならすぐに着手するんですが。

  でももしかしたらdoubleやfloatの定数も.textに置かれるかもしれませんね。
いや、きっと置くでしょう。これを回避するには、これらも全部static変数にし
てやらなければいけません。つまり、

double func1();

double func2()
{
    double a;
    a = func2() * 43.21 + 12.34;
    return a;
}

などというプログラムでは、この12.34などが引っかかるでしょう。回避するに
は、

double func2()
{
    static double C1234 = 12.34, C4321 = 43.21;
    double a;
    a = func2() * C43.21 + C1234;
    return a;
}

などとしなければいけません。・・・これは不便すぎますね。

  ということでどうしても必要なったらやりますので、そのときは申し出てくだ
さい(できればVCなどで回避してもらえると助かるんですが)。>みなさん