「プログラマーはマシン語を理解しておくべき？」記事へのコメント

言語の弊害でしょう

[Anonymous Coward]

そもそも、高級言語は「プログラマに低級言語を意識させないこと」を目的に作られているので
機械語を理解しなきゃいけない高級言語は欠陥言語です。
この前提からすると、プログラマはマシン語を理解する必要はない！
理解しなければならないとすると、使ってる言語が悪い

Re:言語の弊害でしょう

[firewheel (31280)]

>そもそも、高級言語は「プログラマに低級言語を意識させないこと」を目的に作られているので
>機械語を理解しなきゃいけない高級言語は欠陥言語です。
それは流石に言い過ぎかと。

パイプラインストール一つとってみても、下位レイヤーの影響が
完全になくなるということはあり得ない。

Re:言語の弊害でしょう

[Anonymous Coward]

元記事の人じゃありませんが、
「影響がなくなる」なんて言ってませんよね。「意識しないで済む」ということです。

たとえば、Squeak/Smalltalkでプログラミングするとき、
x86なんて知っていてもほとんど無意味でしょう。
もちろん、パイプラインがどうこうなんてのも無意味。
そんなのは、「Squeak/Smalltalkでプログラミングする」ために必要な知識じゃなくて
VMをつくるために必要な知識なんです。
で、VMの知識が必要か？というと微妙ですが、ほとんど要らない。

「プログラミング言語が提供するモデル」に対する知識が必要なのです。
C/C++系(Java/C#/Perlも？)言語の提供するモデルはノイマンアーキテクチャが直に見える、
かつ、C/C++系が主流。
だから、機械語やVMレベルの知識が必要とかいう話になるんでしょう。

List系とかSmalltalk系とかを考えたら、下層レイヤはLispマシン系？のVMになるけど
そんなところの知識なんかなくても、大抵デバッグできるし、困らない。
言語仕様やクラスライブラリなど知識のほうが圧倒的に重要でしょう。

Cが欠陥言語とは思わないけど、提供するプログラミングモデルの差だと思いますよ。
「高級アセンブラ」とか言われるゆえんでしょう。

Re:言語の弊害でしょう

[Anonymous Coward]

いまだに結構使われていると思われる C は「低級言語」とか「高級アセンブラ」とか呼ばれたりすることがありますが、やはりアセンブリ言語レベルでの理解はいくらかは必要なものと思います。

たとえば、メモリがどのように使われるかを理解していないと、

char* int2str(int n)
{
    char str[100];
    sprintf(str, "%d", n);
    return str;
}

上記のようなコードがなぜ問題なのか理解できないことでしょう。こーゆーのは多少高級になった C++ でも同様ですね。まあ欠陥言語ですけど。

Re:言語の弊害でしょう

[Anonymous Cowpat (32210)]

それは、C 言語のレベルでもわかると思う。
以下のようなプログラムだと、マシン語というか OS の知識が必要になるかもしれないけど。

#define ARYLSIZ 4096
#define ARYHSIZ 10240

int main()
{
    char ary[ARYHSIZ][ARYLSIZ];
    int h, l;
#if 1
    for ( h = 0; h < ARYHSIZ; ++h ) {
        for ( l = 0; l < ARYLSIZ; ++l ) {
            ary[h][l] = 1;
        }
    }
#else
    for ( l = 0; l < ARYLSIZ; ++l ) {
        for ( h = 0; h < ARYHSIZ; ++h ) {
            ary[h][l] = 1;
        }
    }
#endif
    return 0;
}

Re:言語の弊害でしょう

[Anonymous Coward]

何が問題なのかマジわからん。使えるスタックのサイズなら(40MBが現実的に大きめだとしてもそれは)環境に拠る話だし。

Re:言語の弊害でしょう

[Anonymous Cowpat (32210)]

スタックでなくても良いし、ARYHSIZ を 1024 にしても古いマシンならたぶん違いが出ます。（私のマシンでははっきり出ました^^;）

Re:言語の弊害でしょう

[Anonymous Coward]

OSの知識とか言ってるあたり、君も理解してないようだ。
CPUのキャッシュにのったまま処理されるかどうかが問題であってOSは一切関係ない。
簡潔に理解するためにCPUキャッシュが4096バイト×1しかないとしよう。

#if 1 から #else までの場合、

1.メモリからCPUキャッシュに4096バイト読み込む。
2.4096バイトを全部1にしてキャッシュからメモリに戻す。
3.1～2を10240回繰り返す。

となるけど、#else から #endif までは

1.メモリからCPUキャッシュに4096バイト読み込む。
2.1バイトを1にして(次の1バイトでキャッシュヒットしないために)キャッシュからメモリに戻す。
3.1～2の処理を4096回繰り返す。
4.1～3の処理を10240回繰り返す。

となって大幅にパフォーマンスが低下する。

Re:言語の弊害でしょう

[Anonymous Coward]

いや、それで差が出るかはキャッシュの構成に寄るんだが。
必ずしもOSは関係無いとは言えないよ。
MMUとかTLBとか知ってる？

Re:言語の弊害でしょう

[Anonymous Coward]

で、何の関係がある話なんでｽｶ?

Re:言語の弊害でしょう

[Anonymous Coward]

実行速度かな？
そうだとしてもOSの知識が必要というのが良くわからんが。

Re:言語の弊害でしょう

[Anonymous Coward]

仮想記憶のページングサイズを問題にしているのでしょう。

Re:言語の弊害でしょう

[Anonymous Coward]

カラムアクセスのこと言いたいんじゃないの?

Re:言語の弊害でしょう

[Anonymous Coward]

> C は「低級言語」とか「高級アセンブラ」とか

Cだとsetjmpなどを理解するにはアセンブラレベルの理解は必要でしょう。
でも、Prologくらい高級言語だとアセンブラは不要かな？
Lispだと？？？

Re:言語の弊害でしょう

[Anonymous Coward]

リンク [srad.jp]だけ

Re:言語の弊害でしょう

[Anonymous Coward]

Lispマシンを使ってる場合にはどうなんだろう？
Lispマシンがどんな実装になってるのか知らないけど。

Re:言語の弊害でしょう

[Anonymous Coward]

LispマシンはプロセッサがLispプリミティブ(CONSとかCARとか)をインストラクションとして持っています。
チューニングのためにdisassembleしたり、デバッガでステップ実行するときはこのインストラクションレベルを普通に読んだり触ったりします。

これらのインストラクションはマイクロコードで実装されていて、OSのスピードクリティカルな部分等は直接マイクロコードで書かれていたりしたらしいので、OS実装者はマイクロコードの知識も必要だったのかもしれませんが、普通はそこまで見えなかったと思います。

Re:言語の弊害でしょう

[Anonymous Coward]

スコープの問題、で理解出来るんでは？ ＃むしろ抽象度が下がるのでアセンブラ（というかコンパイラの実装）での理解のほうがたやすいのは確かだけど。

Re:言語の弊害でしょう

[Anonymous Coward]

このようにアセンブラでたやすく理解できると言いつつも
「スコープ」と「オブジェクトの生存期間」の区別もつかない人がいるわけで、
まずは自分の使っている言語を知ることが最も重要なのだと思います。