2019/5/8

1. パタヘネゼミ第2回
(2.11～2.22)
担当 奥村

2. 2.11 並列処理と命令 : 同期
 同期、協調動作がなぜ必要か
◦ 競合(race condition)が起こるから
◦ OS,シスプロでやった
 atomicな処理
 相互排除(mutual exclusion)
 実現方法は?
◦ OSの授業でやったように様々ある

3. 2.11 並列処理と命令 : 同期
 MIPSでどのように実現されているか
◦ load linked , store conditional
◦ 2つで1組、対をなす命令

4. 2.12 プログラムの翻訳と起動
 Cのコードはどうなって動くか
◦ コンパイラ
◦ アセンブラ
◦ リンカ
◦ ローダ

5. 2.12 プログラムの翻訳と起動
 コンパイラ
◦ アセンブリに翻訳
◦ 昔は色々アセンブリで書かれてたらしい
 アセンブラ
◦ アセンブリ(疑似命令を含む)をオブジェク
トファイルに変換
 機械語命令とそれをメモリに適切に配置するた
めの情報からなるファイル
 未決定な参照とかが残ってる

6. 2.12 プログラムの翻訳と起動
 リンカ
◦ オブジェクトファイルとライブラリを結
びつけ、すべての外部参照を解明する
◦ 出力は実行ファイル(executable file)
 ローダ
◦ ディスク上の実行ファイルをメモリに読
み込む

7. 2.12 プログラムの翻訳と起動
 ライブラリのリンクの問題点
◦ リンクされた後にライブラリが更新され
ても反映されない
◦ 使うのがほんの一部の機能だけでもすべ
てのライブラリをリンクすると実行ファ
イルが巨大に
 DLL(dynamically linked library)

8. 2.12 プログラムの翻訳と起動
 Javaの場合
◦ コンセプト”いかなるコンピュータ上でも
すばやく安全に実行できる”
 コンパイル
◦ Javaバイトコードに
 インタプリタで実行可能な命令セット
 Javaに近くコンパイル負荷が軽い
 最適化もほぼしない
◦ Cとの比較
 アセンブリは”コンピュータ依存”だった

9. 2.12 プログラムの翻訳と起動
 Javaバイトコードのインタプリタ
◦ JVM(Java Virtual Machine)
 インタプリタ
◦ 移植性高い
◦ 速度は遅い
 速度の改善
◦ JIT(Just-in-time)コンパイラ
 プログラムのよく使われてる部分を見つけてコ
ンピュータのネイティブな命令セットにコンパ
イル

10. 2.13 Cプログラムの例題解説
 アセンブリ演習でやったような内容な
ので省略

11. 2.14 配列とポインタの対比
 配列に添え字でアクセスするのとポイ
ンタでアクセスする場合にアセンブリ
はどう異なるか？
 ここでの例は配列をすべて0クリアす
る場合

12. 2.14 配列とポインタの対比
 素朴にアセンブリで書いてみる
◦ ループ内部のみ
 添字ver.
◦ 1. iを4倍
◦ 2. 先頭アドレスに足してアドレスを計算
◦ 3. 0をストア
◦ 4. iをインクリメント
◦ 5. iがサイズより小さいか判定
◦ 6. 判定結果をみて先頭に戻るか終了

13. 2.14 配列とポインタの対比
 素朴にアセンブリで書いてみる
◦ ループ内部のみ
 ポインタver.
◦ 1. pの指す場所に0をストア
◦ 2. pを4増やす
◦ 3. 要素数の4倍を計算
◦ 4. 先頭アドレスと要素数から最後尾のア
ドレスを計算
◦ 5. pが配列の最後尾以前かどうか比較
◦ 6. 判定結果をみて先頭に戻るか終了

14. 2.14 配列とポインタの対比
 どちらもループ内は6命令のみ
◦ 差はない？
 ポインタver.の3,4に着目
◦ 1. pの指す場所に0をストア
◦ 2. pを4増やす
◦ 3. 要素数の4倍を計算
◦ 4. 先頭アドレスと要素数から最後尾のア
ドレスを計算
◦ 5. pが配列の最後尾以前かどうか比較
◦ 6. 判定結果をみて先頭に戻るか終了

15. 2.14 配列とポインタの対比
 ポインタver.の3,4に着目
◦ 3. 要素数の4倍を計算
◦ 4. 先頭アドレスと要素数から最後尾のア
ドレスを計算
 ここで計算される値は定数
◦ ループ内で計算する必要はない
◦ ループ外で1度計算しておけばよい
 ループあたり4命令に減った！
◦ うれしい

16. 2.14 配列とポインタの対比
 添字ver.でも同様に効率化できるか？
◦ 6つともiに依存した計算をしている
◦ 無理そう
 ならばプログラマは積極的にポインタ
で書くべきか？
◦ コンパイラは賢いので最適化してくれる
◦ 変に意識するよりもわかりやすく書くべ
き

17. 2.15 CとJavaの実行
 コンパイラの内部
◦ 言語ごとのフロントエンド
 一般的な中間表現に変換
◦ 高水準オプティマイザ
 ループ展開,インライン展開
◦ グローバルオプティマイザ
 大域的、局所的最適化
 レジスタ割付
◦ コードジェネレータ
 詳細な命令の選択、マシンに依存した最適化

18. 2.15 CとJavaの実行
 フロントエンド
◦ 言語依存
◦ 字句解析,構文解析,…
 言語処理系論でやったやつ
◦ 最終的に中間表現を出力

19. 2.15 CとJavaの実行
 高水準オプティマイザ
◦ ソースレベルでの変形
◦ ループ展開、インライン展開
◦ 多重ループの入れ替えなど
 詳しくは5章

20. 2.15 CとJavaの実行
 局所的最適化
◦ 基本ブロック(スコープ)内での最適化
 いろいろある
◦ 強度低減
◦ 定数伝播
◦ コピー伝播
◦ 不要ストア削除
◦ 不要コード削除

21. 2.15 CとJavaの実行
 大域的最適化
◦ 複数の基本ブロック(スコープ)をまたぐ最
適化
 いろいろある
◦ コード移動
◦ 誘導変数削除
 配列とポインタでやったやつ

22. 2.15 CとJavaの実行
 局所最適化と比較して最適化できるか
どうかの判定が難しい
◦ それはそう
◦ データフロー解析により制御フローグラ
フを構築し依存関係から判断
 当然最悪の場合を想定

23. 2.15 CとJavaの実行
 レジスタ割付け
◦ メモリのロード/ストアをサボりたい
◦ 何度もアクセスするメモリの値はレジス
タに置いときたい
 レジスタはそんなに多くはない

24. 2.15 CとJavaの実行
 レジスタ割付けの判断
◦ 変数の使用情報をデータフロー解析し
リージョンと呼ばれる単位を頂点とした
干渉グラフを作成
 レジスタ割付の問題は干渉グラフのグ
ラフ彩色問題に帰着
◦ 前回すこし触れた…?

25. 2.15 CとJavaの実行
 レジスタの個数以下で彩色できるとは
限らない
◦ 必要に応じてメモリにスピルアウトする
◦ スピルアウトはリージョン(頂点)の分割に
対応
 コンパイラはいい感じにこれらをやっ
てくれてるらしい
◦ すごい

26. 2.16 ARMv7の命令
 ARMv7とは
◦ 組み込み機器用に普及している命令セッ
トアーキテクチャ
◦ 設計思想はMIPSと似ている
 MIPSとの違い
◦ レジスタがMIPSより少ない(半分)
◦ アドレッシングモードが9つもある
 MIPSは3つだった(計算機構成論でやった)

27. 2.16 ARMv7の命令
 比較とOpxフィールド
◦ MIPSでは比較結果はレジスタにある
◦ ARMでは4つの条件コードビットを用いる
 負、ゼロ、桁上げ、オーバーフロー
 PowerPCの演習や計算機システムでやった
CR(Condition Register)みたいなもの?
◦ ARMの命令にはOpxという4ビットの
フィールドがあり、4つの条件ビットとの
組み合わせで命令をnopにすることができ
る

28. 2.17 x86の命令
 Intel x86の発展
◦ 1978年:Intel8086アーキテクチャが発表された。それは、当時成功を収めていた
8ビット・マイクロプロセッサであるIntel8080のアセンブリ言語と互換性のあ
る機能拡張と位置づけられた。8086は16ビット・アーキテクチャであり内部レ
ジスタ長はすべて16ビットであった。MIPSとは異なり,8086のレジスタは専用
化されていた。したがって、8086は汎用レジスタ(general-purpose register :
GPR)アーキテクチャとはみなされていない。
◦ 1980年:Intel8087浮動小数点コプロセッサが発表された。このアーキテクチャは
約60の浮動小数点命令を追加して、8086を拡張したものである。このアーキテ
クチャはレジスタを使用する代わりにスタックに依存していた。
◦ 1982年:80286アーキテクチャを32ビットに拡張した80386が発表された。32
ビット・レジスタおよび32ビット・アドレス空間を備えた32ビット・アーキテ
クチャに加え、80386では新しいアドレッシング・モードと命令操作が追加さ
れた。それによって、80396は汎用レジスタ・マシンに近くなった。80386では、
セグメント方式のアドレシングに加え、ページ方式がサポートされるように
なった。80286と同様、80386には8086のプログラムを修正せずに実行できる
モードが用意されていた。
◦ 1989-95年: 1989年にi486が、1992年にPentinumが、1995年にPentium Proが、
次々と発表された。これは性能の向上を目的としたものであり、命令セット
◦ 上ユーザーに見えるものは4つしか追加されていない。そのうちの3つはマルチ
プロセッシング…

29. 2.17 x86の命令
 Intel x86の発展
◦ 1978年:Intel8086アーキテクチャが発表された。それは、当時成功を収めていた
8ビット・マイクロプロセッサであるIntel8080のアセンブリ言語と互換性のあ
る機能拡張と位置づけられた。8086は16ビット・アーキテクチャであり内部レ
ジスタ長はすべて16ビットであった。MIPSとは異なり,8086のレジスタは専用
化されていた。したがって、8086は汎用レジスタ(general-purpose register :
GPR)アーキテクチャとはみなされていない。
◦ 1980年:Intel8087浮動小数点コプロセッサが発表された。このアーキテクチャは
約60の浮動小数点命令を追加して、8086を拡張したものである。このアーキテ
クチャはレジスタを使用する代わりにスタックに依存していた。
◦ 1982年:80286アーキテクチャを32ビットに拡張した80386が発表された。32
ビット・レジスタおよび32ビット・アドレス空間を備えた32ビット・アーキテ
クチャに加え、80386では新しいアドレッシング・モードと命令操作が追加さ
れた。それによって、80396は汎用レジスタ・マシンに近くなった。80386では、
セグメント方式のアドレシングに加え、ページ方式がサポートされるように
なった。80286と同様、80386には8086のプログラムを修正せずに実行できる
モードが用意されていた。
◦ 1989-95年: 1989年にi486が、1992年にPentinumが、1995年にPentium Proが、
次々と発表された。これは性能の向上を目的としたものであり、命令セット
◦ 上ユーザーに見えるものは4つしか追加されていない。そのうちの3つはマルチ
プロセッシング…

30. 2.17 x86の命令
 レジスタが少ない。GPRが8本しかな
い(ARMv7の半分)
 命令の特徴
◦ 可変長(1～15byte)
◦ オペランドの1つがソースとデスティネー
ションを兼ねないといけない
 オペランドの1つは必ず変更される
◦ オペランドにメモリ中でもいい
 MIPSやARMv7はレジスタか即値だけだった
◦ プレフィックスで命令動作を変えられる

31. 2.18 ARMv8の命令
 ARMv7の64bit版
◦ どんどんアドレス空間がでかくなる
◦ レジスタの大きさもでかくなる
 結構大きく変更されてめっちゃMIPS
に近くなったらしい
 “その結果、ARMv7とARMv8の主な類
似点は、名称となった”
◦ これすき

32. 2.19 誤信と落とし穴
 命令を強力にすれば性能が改善される
◦ クロック数とか増えすぎるとまずい
◦ 命令数と命令の複雑さのトレードオフ
 アセンブリで組むと早い
◦ コンパイラに勝てないか同等なので高級
言語で書こう！(アセンブリ書きたい人とかいるんか…?)

33. 2章の演習問題
 面白そうな問題があればpick up

34. 2章の演習問題
 面白そうな問題があればpick up
◦ ありませんでした