読むに至ったきっかけ
『翔泳社ブックアンバサダー』に応募した結果、当選したので読むに至る。
いくつか候補があったが、一番興味を引いたので選んだ。
目次
第1章 序論と概要
■第1部 基礎
第2章 デジタル論理回路の基礎
第3章 データとプログラムの表現
■第2部 プロセッサ
第4章 さまざまなプロセッサと計算エンジン
第5章 プロセッサの種類と命令セット
第6章 データパスと命令実行
第7章 オペランドのアドレッシングと命令表現
第8章 CPU：マイクロコード、保護、プロセッサモード
第9章 アセンブリ言語とプログラミングパラダイム
■第3部 メモリ
第10章 メモリとストレージ
第11章 物理メモリと物理アドレッシング
第12章 キャッシュとキャッシング
第13章 仮想メモリ技術と仮想アドレッシング
■第4部 入出力
第14章 入出力の概念と用語
第15章 バスとバスアーキテクチャ
第16章 プログラム駆動と割り込み駆動の入出力
第17章 デバイスと入出力とバッファのプログラミング
■第5部 高度な話題
第18章 並列処理
第19章 パイプライン処理
第20章 電力とエネルギー
第21章 性能評価
第22章 アーキテクチャのサンプルと階層構造
第23章 ハードウェアのモジュール化
リンク
コンピュータアーキテクチャのエッセンス［第2版］（Douglas E. Comer 吉川 邦夫）｜翔泳社の本
感想
献本頂いた本なので、若干贔屓目で読んでいるかも。
また、ＩＴエンジニアと仕事に従事しているので、そういう視点から見ての感想である点を考慮して感想を見ていただければと思う。
ざっくり呼んだ感想としては、非情に内容が濃い本であったと思う。
１度ですべてを理解するのは不可能。何度も読み返したり、ネットで調べながらの作業になる。
実際、読むのがかなり大変だった。書いてある内容を吟味して、自分の中に落とし込むのが大変な１冊だったと思う。
学校で習った知識の深堀り的な意味合いが強い印象だった。
デジタル回路の仕組みや理論は、読み返しても難しい。AND、OR、NANDは、電子回路で理解はしているのだが、電子回路の設計にどう役立っているのか、学生時代はよく分からなかった。
本書を呼んで、実際に電流や時間の流れを考慮してくると、ANDとかの単純なものより、XORとかの方が使いやすいという考え方が腑に落ちた。情報処理技術者試験とかでもXORで難解なものが出てくることがあるが、どちらかというと、実務に近い方の問題だったのかもしれない。
メモリやデータの扱いに関しては、ハードよりの記載が多く、Javaエンジニアである自分には、少しハードルが高かった。学生時代にC言語を少しやっていたので、ある程度の話にはついていけたが、メモリの扱いやポインタとかを使ってない言語系の人には、かなり難解かもしれない。
本書を通して一番感じたのは、人間にとっての分かりやすさが、そのままコンピュータにとっての分かりやすさ、効率化ではないことだと感じた。
プログラマーとしてハードの知識を知っていることで、効率化に活かせるような気がするが、個人的には、最適化よりも、まずは理解しやすいものを作るべきだと思っている。
人間に理解しやすいものから、どれだけハードに寄せるかは、作ったあとに考える必要があるので、ハードの知識は、そのときに必要になってくる。
本書の知識が必要になってくるのは、そういった当たり前ができるようになってからだと思う。
自分の知識レベルを吟味した上で、本書は読むべきだと思った。
※自分に対しては、早かった気がする。。。
まとメモ
デジタル論理回路の基礎
学生の頃、論理回路を習ったが、使う機会がどんなときなのか、よく分からなかった。
if文くらいだろって思っていたが、電子回路作る際に必須の知識になるんだね。
AND・ORとかを主軸に使うのかと思ったが、電子回路設計だと、その逆が多いのが意外だった。
プログラミングだと、可読性を挙げるために、AND条件になるようにしているのだが、電子回路だとその逆が多いのが、立場によって観点が変わってくるのが面白かった。
電子回路を設計している人は、頭を悩ませてることが多そう。。。
- ラッチ→状態の保持
- 回路上、伝送遅延がある（ミリ秒以下）
- レジスタにはラッチが複数使われて構成されている
たまに情報処理技術者試験で出てくる意味がわからない論理回路って、ラッチだったんだな。。。
パターン書いてたら、値変わらないやんけって思ってた。
- ムーアの法則
- 毎年性能２倍
- 今は18ヶ月で２倍に改定
- IC
- 設計にコストがかかる
- 製造は比較的安価
データとプログラムの表現
プログラムに重要なこと＝抽象化
抽象化で重要なこと
- データ
- アルゴリズム
16進記法のメリット
- 2進より短く表現可
- 16→2のべき乗＝比較的容易に計算可
１文字４ビットで計算できるから、算出は比較的楽。
同じ理屈で８進表記もできるけど、表現の幅が狭い。
３２進数が、登場しないのは、何か理由があるのだろうか？
Ascii：1バイトでの文字表現
Unicode：全世界共通の文字表現を目指したもの
アンダーフロー：表現可能な数値より小さい計算結果がでること
データ送信
リトルエンディアン
最下位→最上位の順で送信する。
最下位が先に決まるので、メモリ空間を小さく使うことができる（メモリを使うような言語だと分かりやすい？少なくともJavaエンジニアでは分かりにくい。。。）
２進数の表現
- 符号＋絶対値
- １の補数
- ２の補数
データの表現方法
柔軟性や速度に多大な影響が出る。
少しの違いでも、チリ積で、最終的に差が大きく出る。
アーキテクチャ
人間のわかりやすさ≠コンピュータのわかりやすさ
ハーバード型
プログラムとデータを別メモリに格納
最適化しやすいが、メモリが分割されているため、メモリ不足が発生した場合、メモリの増設が必要になってくる。
フォンノイマン型
プログラムとデータが同じメモリに格納
メモリが共有しているので、用途が変わっても対応しやすい。
プロセッサ
複数ステップの計算を行う。
トレードオフでやれることが変わる。ex：機能が増える＝電力消費、処理時間増
命令セット
プログラミング可能＝メモリ読みだした命令を実行できる構造が必要＝大きな計算力と柔軟性が必要
オペランド
演算実行に必要な値
オペランドの選択で影響するもの
CPU
複雑
複雑さの要因
- マルチコア
- 役割多
- 保護と特権の管理
- ハードウェアの優先度管理
プログラミング言語
役割が違うので、適材適所が必要
高水準
- １分で複数の命令実行可
- ハードに依存しない
- アプリ指向
- 強力な抽象化
低水準
- １文１命令
- ハード依存
- システム指向
メモリ
主となるテクノロジー要素
- 揮発性
- アクセス
- 永続性
仮想メモリ
抽象化メモリ。物理メモリの実態を隠す
使う理由
- ハードの統合
- プログラミングの容易可
- プログラムとデータの保護
バス
各種機器を接続するための機構
デバイスドライバ
デバイス固有の実装を利用者が理解しなくてもいい
並列処理
ミクロとマクロの考えがある。
ミクロ：ハードに対する並列化
マクロ：システムに対する並列化
アムダールの法則
頻繁に使う処理を重点的に最適化
