CS on blog.kyu08.com

『プログラミング言語C 第2版』を読んだ

Sun, 12 Apr 2026 17:48:08 +0900

Operating Systems: Three Easy Pieces(以下、OSTEP)に取り組むにあたって、C言語の知識があるとスムーズそうだったので読んだ。

プログラミング言語C - 共立出版

Brian W.カーニハン著

https://www.kyoritsu-pub.co.jp/book/b10011596.html

Cに関してはCS50で基本的な文法を学んだ程度であまり体系的には学んでいなかったので、CS50の内容を補完するような感じで読んだ。

CS50.jpでCSに入門した

CS50.jpの気になっていたトピックを学んでみたので振り返っておく。 CS50.jpとは CS50.jpの説明はサイトから引用する。このページ

https://blog.kyu08.com/posts/cs50-jp/

どんな本か

C言語の開発者であるB.W.カーニハンとD.M.リッチーによるC言語の解説書。

1989/06/15発売と、約40年前の本だが入門書としての評価が未だに高いようだったので買ってみた。(結果的にも普通に勉強になったので良かった)

二人のイニシャルをとってK&Rと呼ばれることもあるらしい。

ちなみに、

1.1 Getting Started に、例として掲載されている"hello, world"プログラムは、あらゆる「プログラミングの最初の例題」として定番となった。

https://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9EC

とあるように、hello, worldの生みの親としても有名らしい。（！）

各章に演習問題が豊富に用意されているので手を動かしながら学びやすかった。

また、付録を除くと231ページと比較的コンパクトなので、Cの全体像をざっと把握するのにちょうどいいボリューム感だった。

読み方

1,2章は演習問題をやりつつ読み、他の章は演習問題をスキップして本文だけ読んだ。
- Cを完全理解したり人に教えられるレベルになりたい、というよりはOSTEPでの実装がスムーズになれば嬉しいなーくらいの温度感だったのと、手を動かすのはOSTEPでできそうだったので知らない文法や仕組みを軽く頭に入れておくくらいの感じで読んだ。
#includeなしでboolが使えると多少楽そうだったのでC23で動かした。
- 演習問題を解いた実装はこちら。

sunaba/c/k_and_r at d15fb4fa20d3e478cc0f5ac6f9e89e7d0c668b21 · kyu08/sunaba

Personal sandbox. Contribute to kyu08/sunaba development by creating an account on GitHub.

https://github.com/kyu08/sunaba/tree/d15fb4fa20d3e478cc0f5ac6f9e89e7d0c668b21/c/k_and_r

学び

変数、関数の可視性の制御方法(static、extern)
#includeの機能("foo.h"と<foo.h>の違いなど)
aが配列のときa[i]と*(a + i)は同じ
共用体
- 結構使うのが難しそうなので相当パフォーマンスを重視したいときにしか使わないかも…?
関数ポインタ
マクロの基礎
etc.

まとめ

(すべての演習問題をやったわけではないのもあって)1週間ちょっとでCについて一通り簡単に学べて、ちょうどいいボリューム感だった。

ということでOSTEPに取り組む準備ができたので次は実際に着手していこうと思う。

『ネットワークはなぜつながるのか』を読んだ

Sat, 04 Apr 2026 16:45:52 +0900

ネットワークはなぜつながるのか第2版を読んだので感想などをまとめる。

どんな本か

ブラウザにURLを入力してからサーバーから返ってきたレスポンスをブラウザで表示するまでの間に起きることを順を追って説明してくれる本。

章の構成は以下。

Chapter Number	Title	Summary
第1章	Webブラウザがメッセージを作る―ブラウザ内部を探検	ブラウザにURLを入力してからブラウザがIPアドレスを解決し、HTTPメッセージを作成してプロトコルスタックに渡すまでに行うこと
第2章	TCP/IPのデータを電気信号にして送る―プロトコル・スタックとLANアダプタを探検	ブラウザから依頼を受けたプロトコルスタックがソケットを作成してから通信を終えてソケットを抹消するまでの流れ
第3章	ケーブルの先はLAN機器だった―ハブとスイッチ、ルーターを探検	LANケーブルへと送り出されたパケットがリピータハブ、スイッチングハブ、ルーターなどの機器を経由してインターネットに向かって進んでいく流れ
第4章	アクセス回線を通ってインターネットの内部へ―アクセス回線とプロバイダを探検	パケットがインターネット接続用ルーターを経由してインターネットの中に入って進んでいく様子
第5章	サーバー側のLANには何がある	サーバー側のPOPに入ったパケットがサーバーの手前にあるファイアウォール、キャッシュサーバー、負荷分散装置などを通過する様子
第6章	Webサーバーに到着し、応答データがWebブラウザに戻る―わずか数秒の「長い旅」の終わり	サーバーがリクエストを受信してからクライアント側のブラウザが結果を表示するまでの流れ

特に第1章 ~ 第3章の内容が普段のWeb開発と関わりが大きいかつ自分の知識が浅い領域だったのでとても面白かった。

なぜ読んだか

そもそも自分はコンピューターサイエンスをこれまで(大学などで)体系的に学んできていないのもあり、以下の目的でコンピューターサイエンスの勉強を隙間時間に進めている。

ソフトウェアエンジニアリング文脈の問題解決やスキル獲得の速度を上げたい
知的好奇心を満たしたい

去年はコンピュータシステムの理論と実装を読んでコンピューターについて広く浅く理解することができたので次はネットワーク周りを強化しようと思い、読んでみた。(他にはセキュリティ、データ構造とアルゴリズム、データベース、プロトコルスタック、シェルなどが気になっている)

『コンピュータシステムの理論と実装第2版』を読んだ

『コンピュータシステムの理論と実装第2版』を読んだので感想を書く。割と長いので得られた学びだけ読みたい方は## 学び、得た経験までジャンプして

https://blog.kyu08.com/posts/nand2tetris/

学びや気付き

「ブラウザにURLを打ち込んでエンターキーを押すと何が起こるか」という質問に暗記ではなく理解をもとに答えられるようになった。(はず) 特に以下に関しては今までより詳しく理解できた。

ブラウザが何をしているか
DNSが何をしているか
TCP接続においてプロトコルスタックが何をしているか
IPが何をしているか
イーサネットとは何か
インターネットとは何か

ネットワークの基礎を学んだことで今後の問題解決や技術理解の助けにもなってくれそう。

それぞれ現時点での自分の理解を書いてみる。

1. ブラウザが何をしているか

FQDNをもとにDNSにIPアドレスを問い合わせて解決する
HTTPリクエストを作成する
ソケットを作成する
プロトコルスタックにTCPコネクションの確立を依頼する
プロトコルスタックにリクエストの送信を依頼する
通信が終わったらソケットを抹消する

どんなシステムコールを呼ぶ必要があるのか気になったのでCで簡単なHTTP Clientを書いてみた。

sunaba/network/how_networks_work/myhttpclient-c/main.c at ea1ba354678e5c1616ea13a62ddcdb04ed34859f · kyu08/sunaba

Personal sandbox. Contribute to kyu08/sunaba development by creating an account on GitHub.

https://github.com/kyu08/sunaba/blob/ea1ba354678e5c1616ea13a62ddcdb04ed34859f/network/how_networks_work/myhttpclient-c/main.c

今回自分が実装したHTTP Clientでは以下のような流れでシステムコールや関数が呼ばれる。

getaddrinfo(3) を使ってドメイン名に合致するIPアドレス(の配列)を取得
socket(2)でソケットを作成しソケットへのファイルディスクリプタを取得する
connect(2)サーバーへの接続を確立する
2.で取得したファイルディスクリプタに対してwrite(2) でリクエストを書き込む
read(2) でレスポンスを読み込む
サーバー側がソケットをクローズしたらクライアント側でもclose(2)を使ってソケットをクローズする

なお、実装はgetaddrinfo(3)のEXAMPLESを参考にしたらほとんど完成してしまった。

getaddrinfo(3) - Linux manual page

https://man7.org/linux/man-pages/man3/getaddrinfo.3.html#EXAMPLES

比較のためにGoでもsyscallパッケージを使って書いてみた。

sunaba/network/how_networks_work/myhttpclient-go/main.go at ea1ba354678e5c1616ea13a62ddcdb04ed34859f · kyu08/sunaba

Personal sandbox. Contribute to kyu08/sunaba development by creating an account on GitHub.

https://github.com/kyu08/sunaba/blob/ea1ba354678e5c1616ea13a62ddcdb04ed34859f/network/how_networks_work/myhttpclient-go/main.go#L1

2. DNSが何をしているか

DNSサーバーに格納されているデータ

DNSサーバーには以下のようなデータが格納されている。

名前
- サーバーやメール配送先の名前
クラス
- 常にINが格納される。
- DNSができた当初はインターネット以外のネットワークでも利用も検討されていたが、現在はインターネット以外のネットワークが消滅したのでINしか入らない。
タイプ
- 名前にどのようなタイプの情報が対応付けられているかを表現した値。
- 具体例
  - A
    - IPアドレス(AddressのAらしい)
  - MX
    - メール配送先
  - CNAME
    - 名前にエイリアスを設定する

以下はDNSレコードの例。

名前	クラス	タイプ	クライアントに返答する項目
example.com	IN	A	192.0.2.226
example.test	IN	MX	10 mail.example.test
mail.example.test	IN	A	192.0.2.227

世界中のDNSサーバーが協調する仕組み

blog.example.comというドメインのIPアドレス解決を例に考える
DNSサーバは階層構造でレコードを分散管理しており、以下のように階層ごとに別々のDNSサーバーに格納されている(同じになることもあるが)
- ルートドメイン
- .com
- example.com
- blog.example.com
問い合わせはルートドメインから順番にたどるので以下のような流れになる
1. 最寄りのDNSサーバがルートドメインのDNSサーバにblog.example.com のIPアドレスを問い合わせる
  - レコードのIPアドレスはわからないが、comドメインのDNSサーバのIPアドレスはわかるからそっちに聞いてくれ、とcomドメインのDNSサーバのIPアドレスが返ってくる
2. 最寄りのDNSサーバがcomドメインのDNSサーバにblog.example.com のIPアドレスを問い合わせる
  - 同じ要領で example.com のDNSサーバのIPアドレスが返ってくる
3. 最寄りのDNSサーバがexample.comドメインのDNSサーバにblog.example.com のIPアドレスを問い合わせる
  - 同じ要領で blog.example.com のDNSサーバのIPアドレスが返ってくる
4. 最寄りのDNSサーバがblog.example.comドメインのDNSサーバにblog.example.com のIPアドレスを問い合わせる
  - blog.example.com のIPアドレスが返ってくる
DNSサーバにはキャッシュ機能があるので必ずしも毎回このようなステップになるとは限らない。
- 当然TTLも存在するので最新のデータが返ってくるとも限らない。

3. TCPでの接続の場合にプロトコルスタックが何をしているか

プロトコルスタックとはプロトコル(e.g. TCP, UDP, IP, etc.)を役割ごとに階層化して積み重ねたソフトウェア群を指す。ネットワークの文脈では主にSocketライブラリとLANドライバの橋渡しの役割を担う。

                   +---------------------------------------------------+
Application Layer->|  +---------------------------------------------+  |
                   |  | Network Applications                        |  |
                   |  | (Web Browser, Mailer, Web Server, etc.)     |  |
                   |  +----------------------------+----------------+  |
                   |  | Socket Library             | Resolver       |  |
                   |  +----------------------------+----------------+  |
                   +---------------------------------------------------+
OS Layer---------->| Protocol Stack                                    |
                   |  +----------------------+  +--------------------+ |
                   |  | TCP                  |  | UDP                | |
                   |  | (Connection-based)   |  | (Connectionless)   | |
                   |  +----------------------+  +--------------------+ |
                   |  +---------------------------------------------+  |
                   |  | IP (Route & Forward)                        |  |
                   |  |  +------------+              +------------+ |  |
                   |  |  | ICMP       |              | ARP        | |  |
                   |  |  +------------+              +------------+ |  |
                   |  +---------------------------------------------+  |
                   +---------------------------------------------------+
Driver Layer------>|  +---------------------------------------------+  |
                   |  | LAN Driver (Controls LAN Adapter)           |  |
                   |  +---------------------------------------------+  |
                   +---------------------------------------------------+
Hardware Layer---->|  +---------------------------------------------+  | 
                   |  | LAN Adapter                                 |  |
                   |  +---------------------------------------------+  |
                   +---------------------------------------------------+

『ネットワークはなぜつながるのか第2版』P96 図2.1 をもとに再構成

getaddrinfo(3) を使ってドメイン名に合致するIPアドレス(の配列)を取得
1. UDP担当部分にDNSサーバーへの問い合わせを依頼する
socket(2)でソケットを作成しソケットへのファイルディスクリプタ(以下fd)を取得する
1. ソケット1つ分のメモリを確保しそこに初期状態であることを記録して
2. アプリケーションにfdを返す。
connect(2)サーバーへの接続を確立する
1. アプリケーションからsocketのfdとサーバー側のIPアドレスとポート番号を受け取る
2. 以下の手順で3ウェイハンドシェイクを行う
  1. (クライアント側)送信元と宛先のポート番号やコントロールビット(SYN=1, ACK=0)を含んだTCPヘッダーを作成する
  2. (クライアント側)IP担当部分に送信を依頼する
  3. (サーバー側)IP担当部分がパケットを受け取ってTCP担当部分に渡す
  4. (サーバー側)TCP担当部分がTCPヘッダーを調べてそこに記載されている宛先ポート番号に相当するソケットを探し出す
  5. (サーバー側)該当するソケットに必要な情報を記録して、接続動作が進行中だという状態にする
  6. (サーバー側)送信元と宛先のポート番号やコントロールビット(SYN=1, ACK=1)を含んだTCPヘッダーを作成する
  7. (サーバー側)IP担当部分に送信を依頼する
  8. (クライアント側)IP担当部分がパケットを受け取ってTCP担当部分に渡す
  9. (クライアント側)TCP担当部分がTCPヘッダーを調べてサーバー側の接続動作が成功なら(SYN=1, ACK=1)「サーバーのIPアドレスやポート番号」と「接続完了を示す制御情報」等をソケットに記録する
  10. (クライアント側)サーバー側に接続成功を示すTCPヘッダー(SYN=0, ACK=1)を送り返す
2.で取得したfdに対してwrite(2) でリクエストを書き込む
1. 送信データを受け取ったプロトコルスタックはデータを相手に送る
  1. データが大きいときは分割して送る
  2. ウィンドウ制御方式(ACK番号の到着を待たず、複数のパケットを連続して送る方式) で効率化を図る。ウィンドウの大きさは受信側のバッファの空き容量をもとに調整される。
2. 送信するすべてのパケットにシーケンス番号(何バイト目か)を付与し、受信側はACK番号(受け取ったシーケンス番号の中でその時点で最大のものに1を足した数値)を返し、「ここまでは受け取ったのでこの番号のパケットを送ってください」というメッセージを伝える
3. 送信側はACK番号を見て必要に応じてパケットを再送する
データを受信した場合、受信したデータ断片とTCPヘッダーを途中でデータが抜けていないか検査し、問題なければACK番号を送り返す
read(2) でレスポンスを読み込む
1. 受信バッファに積まれたデータをアプリケーションに渡す
サーバー側がソケットをクローズしたらクライアント側でもclose(2)を使ってソケットをクローズする(なお、クライアントが先にソケットをクローズすることもあり、どちらになるかはアプリケーション次第になる。)
1. (サーバー側)がcloseを呼び出す
2. (サーバー側)プロトコルスタックがコントロールビットのFINを1にセットしたTCPヘッダーを作成し、IP担当部分に送信を依頼する
3. (クライアント側)FIN=1であるTCPヘッダーが届いたのを確認して、自分のソケットにサーバー側が接続動作に入ったことを記録する
4. (クライアント側)FIN=1であるパケットを受け取ったことをサーバー側に知らせるためにACK番号をサーバー側に送り返す
5. (クライアント側)サーバーからすべてのデータを受け取ったことをアプリケーション側に知らせる
6. (クライアント側)コントロールビットのFINを1にセットしたTCPヘッダーを作成し、IP担当部分に依頼してサーバーに送ってもらう
7. (サーバー側)クライアント側からFIN=1なパケットを受け取ったらACK番号を返す
8. (クライアント側)サーバーからACK番号が返ってきたことを確認し、サーバーとのやり取りを終了する

4. IPが何をしているか

IPの主な役割は宛先IPアドレスをもとにパケットの転送先を決定し、次のホップへ届けること。

IPヘッダー、MACヘッダーの作成
- 送信元・宛先IPアドレス、TTL(Time To Live)などを含むIPヘッダーをTCPパケットに付与する
  - TTLはルーターを経由するたびに1減らされ、0になったらパケットは破棄される(ループ防止)
- IPヘッダーの前にMACヘッダーを付与する
  - MACヘッダーには宛先MACアドレスと送信元MACアドレスが含まれる
- MACアドレスの解決にはARPを使う
  - ARPとは、IPアドレスからMACアドレスを解決するためにLAN内でブロードキャストを行い、対象IPアドレスのMACアドレスを特定するためのプロトコルである
  - キャッシュ機能もあるので毎回ブロードキャストするわけではない
ルーティング
- ルーティングテーブルを参照して「次にどのルーターにパケットを渡すか」を決定する
- 宛先IPアドレスとルーティングテーブルのエントリを比較し、最長プレフィックスマッチで転送先を選ぶ
- 宛先が同一LAN内であればそのままL2で届けられる
- あくまでIPは「どこに届けるか」を決める仕組みで、実際の転送はイーサネットを用いて行うためMACアドレスが必要になる

IPはベストエフォートの転送のみを担い、信頼性の保証はしない(それはTCPの責務)

ICMPとARPはIPの動作を補助する形で動く。

ICMP: エラー通知(宛先到達不能など)や疎通確認(ping)に使われる
ARP: IPアドレスからMACアドレスを解決するためにLAN内でブロードキャストされる

5. イーサネットとは何か

イーサネットはLAN内の機器間でデータをやり取りするための規格。IPがネットワーク間の転送を担うのに対し、イーサネットは同一LAN内の転送を担う。

アドレス体系
- MACアドレス(48ビット)を使って送受信先を識別する
- MACアドレスは原則的にはNICに割り当てられた固有の識別子
- IPアドレスが「建物の住所」なら、MACアドレスは「人の名前」に相当する
フレーム
- イーサネットではデータを「フレーム」という単位で送受信する
- フレームには送信元MACアドレス、宛先MACアドレス、データ、エラー検出用のFCSが含まれる
スイッチングハブ
- MACアドレスと接続ポートの対応表(MACアドレステーブル)を持ち、宛先MACアドレスに対応するポートにだけフレームを転送する
- 最初は対応表が空なのでブロードキャストし、応答を受け取ることでテーブルを学習していく

6. インターネットとは何か

なお「インターネット」は広範な意味を持つ言葉だが、ここでは本書のスコープ(ISP・POP・IXあたりの話)に限定して整理する。

インターネットとは、世界中のISP(インターネットサービスプロバイダ)のネットワークが相互接続された巨大なネットワークの集合体。

ISPとPOP
- ISP(Internet Service Provider)はインターネット接続サービスを提供する事業者
- POP(Point of Presence)はISPの設備が置かれた接続拠点。ユーザーのパケットはまずここに届く
- POP内にはルーターが置かれており、パケットを次の拠点に転送する
NOC
- POPから入ってきたパケットが集まる
- プロバイダの中核となる設備
- データ転送能力が数テラビット/秒を超えるルーターが使われることもある
IX(Internet eXchange)
- 複数のISPが相互に接続するための中立的な施設
- IXを介することでISP間のパケットのやり取りが効率化される
パケットの経路
- ユーザーのパケットはISPのPOP → ISPバックボーン → IX → 相手ISP → サーバーという流れで届く
- 経路上のルーターがBGP(Border Gateway Protocol)で経路情報を交換し合うことでインターネット全体のルーティングが成立している

Q&Aメモ

こちらのポストを参考にしてClaudeに質問を作成してもらい、都度Claudeに相談しながら回答を考えてみた。

あくまで「この質問に対しては暗記ではなく理解をもとに答えられるようになった」ということをメモしておくための自分用学習メモです。

No	質問	回答
1	TCPの3ウェイハンドシェイクはなぜ「2ウェイ」ではダメなのか	サーバーからクライアントへの経路が機能しているかどうかをサーバーが確認できないため。双方向の疎通を双方が確認するには3メッセージ必要になる。
2	DNSキャッシュのTTLを短くするデメリットは何か	キャッシュDNSサーバーから権威DNSサーバーへのリクエスト数が増加する。その結果以下が発生する。 • 権威DNSサーバーが処理しなければならないリクエストの量が増えるため、権威DNSサーバーのレイテンシが増加する • キャッシュDNSサーバーがキャッシュを返す割合が減るため権威DNSサーバーへのリクエスト分のレイテンシが増加する
3	NATがエンドツーエンド通信に何をしているか図で説明せよ	送信時はプライベートIPとポート番号をルーターのグローバルIP+任意のポート番号に変換し、受信時はその逆の変換を行う。結果として通信相手はNATを意識することなく、単一のグローバルIP+ポート番号とやりとりをしているように見える。
4	TCPとUDPの使い分けを「信頼性」以外の観点で説明せよ	前提として、UDPは接続確立や再送のオーバーヘッドがなく、輻輳制御も行わないため高速に通信を行うことができる。信頼性を多少犠牲にしてでも高速性を重視したい場面ではUDPの利用が有効なケースがある。たとえば遠隔運転システムでは、一瞬映像が途切れたとしてもリアルタイムに映像が表示され続けることが重要になるためUDPのメリットを享受しやすいと考えられる。
5	ルーティングテーブルの「最長プレフィックスマッチ」とは何か、なぜその方式か	ルーティングの際にルーティングテーブルの中から宛先IPアドレスとマッチする範囲が一番長いレコードにあるネットワークを次のルーティング先とする方式。 `10.0.0.0/8`に向けるデフォルト経路と`10.1.2.0/24`に向ける特定経路が存在する場合は後者を優先しないと意図したルーティングにならないため。
6	HTTPSでサーバー証明書が必要な理由を、鍵交換から説明せよ	MITMへの対策のため。証明書がないと鍵の交換相手が本物のサーバーなのか攻撃者なのかわからないため必要になる。
7	パケットロスが0%でもアプリが遅い理由を説明せよ	ここでは「アプリが遅い」 == 「クライアント側で見ているWebアプリの動作が想定よりも遅い」と仮定する。 • DNSサーバーのレイテンシが大きい • クライアントのマシンの動作が遅く、リクエスト送信までに時間がかかっている • アクセス回線にADSLが含まれるなどがそもそも低速な回線がボトルネックになっている • クライアントとサーバーが地理的に離れており、そもそも通信に時間がかかる • 経路上のネットワーク機器が古く、非効率な通信を行っている • サーバーの負荷が高く、CPUがスロットリングした結果、サーバーの処理全体が遅くなっている • マイクロサービス構成になっておりそもそも必要なネットワークIOの数が多い
8	サブネットマスクはなぜ必要か、IPアドレスだけでは何が足りないか	IPアドレスのうち、どこまでがネットワーク部でどこからがホスト部なのかがわからなくなるため。
9	ARPはなぜIPレイヤーではなくL2に属するのか	ARPはIPアドレスをMACアドレスに解決するプロトコルだが、L2のフレームで直接ブロードキャストし、IPルーティングを経由しない。つまりL3の仕組みに依存せずに動作する必要があるためL2に属する。
10	ping が通るのにHTTPが失敗するとき、最初に何を疑うか	ファイアウォールによるポートのブロックを疑う。 pingはICMPプロトコルを利用しており、そもそもポート番号を指定する必要がない。一方でHTTPはポート番号を指定する必要があるため。他にはサーバー側でサーバープログラムが起動していない可能性やTLSの証明書エラーの可能性も考えられる。

まとめ

読む前の期待以上にネットワークの解像度を上げられたので読んでよかった。

次はOperating Systems: Three Easy PiecesでOS周りの深堀りをしていこうと思っている。メモリ管理やプロセス、スレッド周りの解像度を上げたい。あと課題でCを書く必要があるのも若干良さそうに感じたポイントでもある。(Cを書くのは辛いが、その分頑張りが身になる感覚があり…)¹

Operating Systems: Three Easy Pieces

https://pages.cs.wisc.edu/~remzi/OSTEP/

軽く読んだ感じ、英語ではあるもののかなり平易に書いてくれているので読みやすそうだった。やっていく。²

(C言語はCS50で軽くさらった程度なのでせっかくなので『プログラミング言語C 第2版』あたりの入門書を一冊読むのもいいかもしれない)

“you will also learn the practical, including how an operating system does things like schedule the CPU, manage memory, and store files persistently.” とのこと。 ↩︎
なお、内容は無料でWebで公開されているので無課金で学習することも可能。自分は移動時間に読んだり書き込んだりしたかったのでPDFを購入した。(それでも$10という破格) ↩︎

『コンピュータシステムの理論と実装第2版』を読んだ

Tue, 29 Apr 2025 15:00:00 +0000

『コンピュータシステムの理論と実装第2版』を読んだので感想を書く。割と長いので得られた学びだけ読みたい方は## 学び、得た経験までジャンプしてください。

本書の構成

本書はnand2tetrisという通称の通り、NANDゲートからスタートして、CPUやコンパイラやOSなどを実装し、最終的にはそのプラットフォーム上でテトリス(のようなアプリケーション)¹が動くところまで実装するという内容のコースになっている。

lecture 7.pdf

https://drive.google.com/file/d/1BPmhMLu_4QTcte0I5bK4QBHI8SACnQSt/view

P3より引用

上図のとおりだが、大まかな流れとしては以下。

NANDゲートを使ってnot, and, orなどの基本的なチップを実装
加算機やALUを実装
レジスタ、RAM、Program Counterを実装
Memory、CPU、Computerを実装
アセンブラを実装(機械語の記号表現をバイナリ表現に変換する)
仮想マシンを実装
コンパイラを実装
OSを実装

各章末に課題とそれをパスしたことを確認するテストがある。基本的にはテストコードを使って動作確認ができるようになっているため、自分の実装が合ってるかを機械的に確認できるようになっており、手を動かしながら理解を深めやすいようになっている。

参考までに各章の実装に用いる言語を記しておく。

章	実装言語
第1章ブール論理	HDL(Hardware Description Languageの略で論理回路の構造を記述できる言語)
第2章ブール算術	HDL
第3章メモリ	HDL
第4章機械語	アセンブリ言語(Hackプラットフォーム独自の仕様)
第5章コンピュータアーキテクチャ	HDL
第6章アセンブラ	任意の言語
第7章仮想マシンI：処理	任意の言語
第8章仮想マシンII：制御	任意の言語
第9章高水準言語	Jack言語(本書で実装するJavaライクな独自言語)
第10章コンパイラI：構文解析	任意の言語
第11章コンパイラII：コード生成	任意の言語
第12章 OS	Jack言語

第6章 ~ 第8章と第10章 ~ 第11章は決められた入出力を持つCLIツールを書けばいいので任意の言語で書くことができる。筆者はRustで実装した。特にEnumとパターンマッチのおかげで構文解析関連の処理が書きやすかった。

ここからは各章の学びを簡単に書いていく。

第1章ブール論理

NANDを使って以下の論理回路をHDLを使って実装した。

not
and
or
xor
マルチプレクサ
デマルチプレクサ
not(16bit)
and(16bit)
or(16bit)
マルチプレクサ(16bit)
8入力or
4入力マルチプレクサ(16bit)
8入力マルチプレクサ(16bit)
4入力デマルチプレクサ
8入力デマルチプレクサ

マルチプレクサの実装に悩んだがいい感じの実装を思いついたときの爽快感がすごかった。

真理値表を丁寧めに書きながら進めた結果マルチプレクサの実装以外はそこまで悩まなかった。

第2章ブール算術

以下の論理回路を作成した。

半加算器
全加算器
16bit同士の加算
16bitの入力に1をインクリメントする回路
ALU(Arithmetic Logic Unit: 算術論理演算装置)

学び:

内部ピンにインデックスアクセスするには次のように書く必要がある。

Mux16(a=calculateResult, b=notCalculateResult, sel=no, out=out, out[0..7]=out0To7, out[8..15]=out8To15, out[15]=ng);

愚直な実装をしている箇所があったが、Mux16でスマートに書き直せることを知って感動した。

第3章メモリ

この章では、DFF(Data Flip-Flop)を用いて1-bit registerを作成し、それを組み合わせて16-bit registerを作成し、さらにそれを組み合わせてRAMを作成した。

lecture 3.pdf

https://drive.google.com/file/d/1boFooygPrxMX-AxzogFYIZ-8QsZiDz96/view

P47より引用

読み書き可能なメモリを作成したことで、コンピュータを作っている感が強まってきた。

作成した回路は具体的には以下。

Register(1bit)
Register(16bit)
RAM(8bit)
RAM(64bit)
ProgramCounter
RAM(512bit)
RAM(4K-bit)
RAM(16K-bit)

学びメモ

第2章までは時間に依存しない回路のみを扱っていたがこの章では過去の状態を保持する回路を作成した。
ここでは時間をクロックという単位で区切って扱う。
非同期チップ(組み合わせチップ): 入力値の組み合わせのみに反応し時間の進行には影響を受けない
同期チップ(順序チップ): 以前の時間単位での変化に対応する用に設計されたチップ
同期チップを利用することでシステム内のチップ間で信号が伝播するのにかかる時間を無視できる。
ただしクロックサイクルは「システム内のチップ間で信号が伝播するのにかかる時間の最大値」と「1チップ内で最も処理時間がかかる演算を完了するのにかかる時間」の合計値よりも大きく設定する必要がある。

DFFはout(t+1) = in(t)で表される出力を持つ。DFFを用いることで過去の状態を論理回路上で表現できる。

lecture 3.pdf

https://drive.google.com/file/d/1boFooygPrxMX-AxzogFYIZ-8QsZiDz96/view

P41より引用

次のようにマルチプレクサとDFFを組み合わせることで1-bit registerを作成できる。

CHIP Bit {
    IN in, load;
    OUT out;

    PARTS:
    Mux(a=dffOut, b=in, sel=load, out=mux);
    DFF(in=mux, out=out, out=dffOut);
}

1-bit registerは時刻tにおいてloadビットがアサートされるとout(t+1)がin(t)の値になり、アサートされていない場合はout(t+1)はout(t)の値になる。換言するとレジスタを利用することで過去の状態を保持できる。

lecture 3.pdf

https://drive.google.com/file/d/1boFooygPrxMX-AxzogFYIZ-8QsZiDz96/view

P25より引用

第4章機械語

第4章では以下のプログラムを機械語で書いた。

掛け算を行うプログラム
キーボードが押されているときだけ画面を黒くするプログラム

機械語

ハードウェアプラットフォームが実行するように設計されている基本的な命令セット
高水準言語は表現力やプラットフォーム間の互換性を目標に設計される一方で機械語は特定のハードウェアで直接実行され、そのハードウェアを完全に制御できるように設計されている。
機械語は決められた形式に従いプロセッサとレジスタを用いてメモリを操作するように設計されている。
バイナリ形式、記号形式の2パターンで記述できる。

メモリ

データや命令を保存するハードウェアデバイス。各セルはメモリ位置やメモリレジスタと呼ばれ、それぞれ固有のアドレスを持つ。

プロセッサ

プロセッサは中央演算装置(CPU) と呼ばれ、あらかじめ決められた基本的な命令セットを実行できる。
プロセッサは選択されたレジスタとメモリ位置からデータを取り出し、選択されたレジスタとメモリ位置に出力を書き込む。
プロセッサはALUとレジスタ、バイナリ命令の解析と実行を可能にする論理ゲートによって構成される。

レジスタ

プロセッサとメモリはそれぞれ独立したチップとして実装されており一方から他方へデータを移すには比較的時間がかかる。そのためほとんどのプロセッサにはいくつかのレジスタが備わっており、高速なローカルメモリとして機能する。
CPUに存在するレジスタは2つのタイプに分類される。
- データを保持するデータレジスタ(Dレジスタ)
- アドレスを保持するアドレスレジスタ(Aレジスタ)

Hackコンピュータのアーキテクチャ

Hackコンピュータは以下のようなアーキテクチャを持つ。

lecture 4.pdf

https://drive.google.com/file/d/1HxjPmIZkFHl-BVW3qoz8eD9dqEuEyuBI/view

P23より引用

アセンブラの役割

機械語はバイナリ形式、記号形式の2パターンで記述できると書いたが、記号形式で@xのように変数を宣言した場合にその変数を実際のメモリのどこに置くかを知るのがアセンブラである。アセンブラのおかげで記号形式のプログラム側は実装詳細を意識することなく変数を初期化、利用できる。

命令タイプ

Hack言語には2つの命令タイプがある。

A命令
- A命令はAレジスタに15ビットの値を設定する。
- A命令は1ビットのオペコード + 15ビットの値で構成される。(Hack機械語ではA命令のオペコードは0)
- A命令は3つの目的で使用される。
  - プログラムによってコンピュータに定数を入力する
  - Aレジスタのアドレスを設定することでその次のC命令でRAMレジスタを操作できる
  - Aレジスタにジャンプ先のアドレスを設定することでその次のC命令でジャンプを実行できる
C命令
- C命令では次の3つを指定する。
  - どういう計算をするか(comp)
  - 計算された値をどこに保存するか(dest)
  - 次に何をするか(jump)
- Hack機械語では一番左端の1ビットが1
- C命令は次のような形式で構成される。111accccccdddjjj
  - 111: 先頭の1がオペコードで、左から2,3ビット目は使用されないが慣例として1が設定されている。
  - a: ALUへの入力がAレジスタからの値化Mからの値か決定する(1ビット)
  - c: compフィールド。(6ビット)ALUに対して計算内容を指定する。
  - d: destフィールド。(3ビット)計算結果の値をどこに保存するかを表現する。左から順にDレジスタ、Aレジスタ、RAM[A]に値を保存するかを表現する。

lecture 4.pdf

https://drive.google.com/file/d/1HxjPmIZkFHl-BVW3qoz8eD9dqEuEyuBI/view

P129より引用

外部デバイス

Hackのハードウェアプラットフォームでは画面とキーボードの2つの外部デバイスに接続できる。どちらのデバイスもメモリマップを通してコンピュータと会話する。(メモリの中に画面とキーボード用のメモリ領域があり、そこに画面の各ピクセルの値や押下されているキーのキーコードが格納される。)

Hackプログラムの例

以下は掛け算を行うHackプログラムのソースコード。(Hackアーキテクチャで動作する機械語で書かれている) ハードウェアの構成要素を理解しながら手続き型チックに記述する必要があるため難しかったが理解が進んだ。

// 0に対して(R0-1)回R1を足すことで掛け算を実現する

  // n = 0
  @n
  M=0

  // R2 = 0
  @R2
  M=0
(LOOP)
  // if n == R0 then goto END
  @n
  D=M
  @R0
  D=D-M
  @END
  D;JEQ

  // R2 += R1
  @R2
  D=M

  @R1
  D=D+M

  // R2 = D
  @R2
  M=D

  // n++
  @n
  M=M+1

  // go to LOOP
  @LOOP
  0;JMP
(END)
  @END
  0;JMP

第5章コンピュータアーキテクチャ

第5章では、これまでの章で作成した論理回路を組み合わせてついに1つの汎用コンピュータを作成する。このコンピュータは第4章に登場した機械語のプログラムを実行できる。

ノイマン型アーキテクチャ:
- CPUがメモリデバイスと相互作用する。
- 入力デバイスからデータを受け取り出力デバイスへデータを送信する。
- コンピュータのメモリに保存されるデータはコンピュータが計算したデータだけではなくコンピュータに何を行うべきかを指示する「命令」も含まれる。
メモリ:
- 物理的にはアドレス指定可能な固定サイズのレジスタの並びで、それぞれが固有のアドレスを持つ。
- 概念的にはアドレス空間はデータと命令の保存という2つの役割を果たす。
- ランダムに選択されたメモリレジスタに瞬時に到達できるという要件からRandom Access Memoryと呼ばれている。
  - たしかにRAMはレジスタの木構造になっていたのである程度大きいRAMでも少ないホップ数で指定したレジスタにアクセスできそうだ。
- データ専用のメモリ領域をデータメモリ、命令専用のメモリ領域を命令メモリと呼ぶ。
CPU:
- CPUは現在読み込まれているプログラムの命令を実行する。
- 各命令はCPUに対して以下を指示する。
  - どの計算を実行するか
  - どのレジスタにアクセスするか
  - 次のどの命令をフェッチして実行するか
- CPUはこれらのタスクをALU、レジスタ、制御ユニットを使って実行する。

第5章の課題ではこれまでの章で作成した論理回路を組み合わせて以下を作成した。

Memory
CPU
Computer

正直CPUの実装、デバッグがはかなり大変だったが公式が提供してくれているテストツールとデバッガのおかげで効率的にバグを見つけることができた。

こんな感じで各ピンの出力や期待する結果とのdiffを比較的見やすい形式で表示してくれるのでありがたかった。

ここで作成したCPUの回路は次のようなもの。ここではヒントとして大まかな回路設計が与えられておりそれを参考にしつつ足りない部分を埋めていく形で実装を進めた。

lecture 5.pdf

https://drive.google.com/file/d/1Z_fxYmmRNXTkAzmZ6YMoX9NXZIRVCKiw/view

P31より引用

第6章アセンブラ

第6章では第5章で書いた機械語の記号表現をバイナリ表現に変換するアセンブラを開発する。

変数やラベルのアドレス管理を行うためにシンボルテーブルを利用する。シンボルテーブルには以下のような情報が格納される。
- ラベルの位置 e.g. (LOOP)
- 変数のアドレス e.g. @i(Hack機械語では変数は16以降のアドレスに順に割り当てられる)
- 定義済みシンボルのアドレス e.g. @SCREEN, @KBD

シンボル処理

アセンブリプログラムではシンボルが定義される前にシンボルラベルを使用できる。(goto命令の行き先を指定するのに利用する)

この挙動も考慮しつつバイナリを生成するには2パス・アセンブラと呼ばれる手法を用いる。

第1パス: シンボルテーブルを作成しすべてのラベルシンボルをテーブルに追加する。
第2パス: 変数シンボルを処理し、シンボルテーブルを使用してバイナリコードを生成する。

第6章からは好きな言語で実装できるのでRustで実装した。構文解析系はenumがある言語だと書きやすくて良い。

第7章仮想マシンI：処理

第7章ではVM変換器の一部を実装した。第8章で残りの部分を実装してVM変換器が完成する。ここまでの課題の中では一番大変で丸3日かかった。

HackプラットフォームのVMアーキテクチャとその利点

Hackプラットフォームにおいて、Hackプログラムは2段階コンパイルによって機械語に変換される。(更にその後アセンブラが機械語(記号表現)を機械語(バイナリ表現)に変換する)

    graph LR
    A[Jackコード
e.g. Foo.jack] -->|コンパイラが変換| B["VMコード(中間コード)
e.g. Foo.vm"]
    B -->|VM変換器が変換| C["機械語(記号表現)
e.g. Foo.asm"]
    C -->|アセンブラが変換| D["機械語(バイナリ表現)
e.g. Foo.hack"]

中間コードは仮想マシン(Virtual Machine; VM) と呼ばれる抽象化されたコンピュータ上で実行されるように設計されている。

高水準言語のプログラムを直接機械語に変換する方式だとハードウェアプラットフォームごとにコンパイラを作成する必要がある。この場合、コンパイラはソース言語(高水準言語)とターゲット言語(機械語)の両方に依存するためそれぞれの変更に追従する必要がある。

2段階でコンパイルする方式を採用するとコンパイラはソース言語の詳細に、VM変換器はターゲット言語の詳細にのみ依存するため変更への追従コストを下げることができる。 この方式ではコンパイラはハードウェアプラットフォームによらず利用することができ、ハードウェアごとにVM変換器さえ実装すればよい。そのためクロスプラットフォーム対応が比較的容易になるという利点がある。

VMフレームワークは上記の利点の代償として効率性が低下するという欠点がある。2段階の変換プロセスで生成するコードは直接コンパイルで生成するコードよりも冗長なことが多く、効率性が落ちる。

VM言語の設計

VM言語の設計にはバランスが重要で以下の要求を同時に満たす必要がある。

高水準側からの要求: 高水準言語のコードを表現できるだけの表現力と構造性を持たなければならない
低水準側からの要求: VMコードから生成される機械語がコンパクトで効率的になるようにVMコードは十分に低水準でなければならない

このような一見矛盾するような要件をスタックマシンが解決する。スタックマシンに基づく中間のVM言語を用いることで高水準言語の表現力と低水準言語の効率性という相反する要求を満たすことができる。

スタックマシンの挙動

スタックマシンの中心はスタックと呼ばれるLIFOのデータ構造にある。ここではいくつかの操作について説明する。(ここではスタックは下方向に成長するように記述する)

push操作の例

graph LR
    A[Stack: empty] -->|push 10| B[Stack:
10]

pushを行うとスタックの先頭に値が追加される。スタックではSP(スタックポインタ) という値を使ってスタックの先頭位置を保持している。SPはpush操作を行う際に値を追加する領域を指し示している。スタックのメモリアドレスが0からスタートすると仮定すると今回の例ではアドレス0に値がpushされたときにSPの値が0から1になる。

アドレス	値
0	10
1

graph LR
    A[Stack: empty] -->|push 10| B[Stack:
10]
    B -->|push 20| C[Stack:
10
20]

push操作を行うとスタックの先頭に値が追加される。このときSPの値は1から2になる。(補足:ここではSPは0-originとする)

pop操作の例

graph LR
    A[Stack:
42] -->|pop local 0| B["Stack: empty
local[0] = 42"]

pop segment_name indexと記述するとスタックの先頭の値を取り除き、指定したメモリセグメント、インデックスの位置に値を書き込む。

pop操作はスタックの先頭の値を取り除く。

算術演算(add)の例

graph LR
    A[Stack: empty] -->|push 10| B[Stack:
10]
    B -->|push 20| C[Stack:
10
20]
    C -->|add| D[Stack:
30]

算術演算の例としてx+yを行うケースを考える。

この処理は次のような流れで行われる。

スタックからオペランドx, yをpopする
x+yを計算する
計算結果をスタックにpushする

graph LR
    A[Stack:
10
20] -->|pop y=20| B[Stack:
10]
    B -->|pop x=10| C[Stack: empty]
    C -->|push x+y=30| D[Stack:
30]

この方法を拡張することで一般的な算術演算をスタックマシンで評価できる。

第7章では、以下の演算子を実装した。

push
pop
算術演算子
- add
- sub
- neg
- eq
- gt
- lt
- and
- or
- not

仮想メモリセグメント

ここで実装するVMにはシンボル変数は存在しない。そのかわりに変数はstatic, local, argument, this, that, pointer, tempのような名前を持つ仮想セグメントの要素として表現される。たとえばコンパイラは高水準言語プログラムで見つかった最初のスタティック変数をstatic 0に、その次に見つかったスタティック変数をstatic 1に、というように変換する。

ここでのVM実装では以下のような仮想メモリセグメントを持つ。

名前場所使用法

SP RAM[0] スタックポインタ：スタック最上位の次のメモリアドレス

LCL RAM[1] localセグメントのベースアドレス

ARG RAM[2] argumentセグメントのベースアドレス

THIS RAM[3] thisセグメントのベースアドレス

THAT RAM[4] thatセグメントのベースアドレス

TEMP RAM[5-12] tempセグメントを保持

R13, R14, R15 RAM[13-15] VM変換器が生成するアセンブリコードに変数が必要な場合、これらのレジスタを使用可能

P175より引用

名前	場所	使用法
SP	RAM[0]	スタックポインタ：スタック最上位の次のメモリアドレス
LCL	RAM[1]	localセグメントのベースアドレス
ARG	RAM[2]	argumentセグメントのベースアドレス
THIS	RAM[3]	thisセグメントのベースアドレス
THAT	RAM[4]	thatセグメントのベースアドレス
TEMP	RAM[5-12]	tempセグメントを保持
R13, R14, R15	RAM[13-15]	VM変換器が生成するアセンブリコードに変数が必要な場合、これらのレジスタを使用可能

LCL, ARG, THIS, THATには各セグメントのベースアドレスが格納されている。たとえば次のように指定されていた場合、pop this 2はスタックの先頭の値をRAM[2202]に書き込む。

アドレス	値	備考
0	256	SP
1	2000	LCL
2	2100	ARG
3	2200	THIS
4	2300	THAT

VM変換器の動作例

例として実際の変換例を示す。

push constant 7
push constant 8
add

今回作成した実装では上記のvmコードは次のようなアセンブリコードに変換される。

// init
@256
D=A
@SP
M=D
// body
// push
@7
D=A
@SP
A=M
M=D
@SP
M=M+1
// push
@8
D=A
@SP
A=M
M=D
@SP
M=M+1
// add
@SP
A=M
A=A-1
A=A-1
D=M
@SP
A=M
A=A-1
D=D+M
@SP
A=M
A=A-1
A=A-1
M=0
@SP
A=M
A=A-1
M=0
@SP
M=M-1
M=M-1
@SP
A=M
M=D
@SP
M=M+1
// end
(END)
@END
0;JMP

VM変換器の実装はハードウェアの構造を意識しながらだいぶ手続き的なコードを書く必要があるので大変だった。(記述量も多いしミスるポイントも多い。)

現代のおいては低レイヤを隠蔽してくれる便利な仕組みがあるおかげでソフトウェアエンジニアが少ない記述量でアプリケーションを動かすことができていることを実感した。

ただ、隠蔽されているからこそ自主的に潜っていかないと構造の理解を深めるのが難しかったりするので引き続きやっていきたい。

第8章仮想マシンII：制御

第7章では

push

pop

算術演算子

add

sub

neg

eq

gt

lt

and

or

not

以下の演算子を実装したが、第8章では以下の演算子を実装し、VM変換器を完成させた。

label
goTo
ifGoTo
call
function
return

これを実装することで次の操作が可能になりよりプログラムっぽい処理を行えるようになる。

任意のラベル位置へのジャンプ
if分岐
関数の宣言と呼び出し

関数の呼び出し(`call`)

Hackプラットフォームにおいてはcall {function_name}コマンドを使って関数呼び出しを行う。

スタックを利用することで関数の呼び出しと戻り値の取得をシンプルに行うことができる。

ここではfunc_aからfunc_bを呼び出すシナリオを例に関数呼び出しをスタックで実現する際の操作を説明する。

(func_aからfunc_bを呼び出す)
func_aの以下の呼び出し側の情報をスタックにpush(これらの情報はフレームと呼ばれる)(画像の灰色の部分)
1. リターンアドレス(: func_bの呼び出しが完了してreturnする際に戻るアドレス)
2. func_aのLCLセグメントのベースアドレス
3. func_aのARGセグメントのベースアドレス
4. func_aのTHISセグメントのベースアドレス
5. func_aのTHATセグメントのベースアドレス
ARG, LCLセグメントの値を更新
func_bのコマンドが定義されているアドレスにジャンプ
リターンアドレスラベルをコードに挿入

lecture 8.pdf

https://drive.google.com/file/d/1BexrNmdqYhKPkqD_Y81qNAUeyfzl-ZtO/view

P58より引用

関数からのreturn(`return`)

呼び出された関数の終了はreturnコマンドで行う。このコマンドが呼ばれることで呼び出し側に処理が戻る。

ここではfunc_aからfunc_bを呼び出した際にfunc_bからfunc_aに戻るシナリオを例にスタックの操作を説明する。

frameのアドレスを一時変数に格納
リターンアドレスを一時変数に格納
ARGに返り値を格納
SPをARG+1に設定
THAT, THIS, ARG, LCLを復元
リターンアドレスにジャンプ

lecture 8.pdf

https://drive.google.com/file/d/1BexrNmdqYhKPkqD_Y81qNAUeyfzl-ZtO/view

P73より引用

第9章高水準言語

第10章、第11章でコンパイラを実装するJackの言語仕様を解説した章。

Javaに近い感じの文法。

class Main {
   function void main() {
      var Array a; 
      var int length;
      var int i, sum;

      let length = Keyboard.readInt("How many numbers? ");
      let a = Array.new(length); // constructs the array
     
      let i = 0;
      while (i < length) {
         let a[i] = Keyboard.readInt("Enter a number: ");
         let sum = sum + a[i];
         let i = i + 1;
      }

      do Output.printString("The average is ");
      do Output.printInt(sum / length);
      return;
   }
}

第10章コンパイラI：構文解析

第10章の内容に入る前にJackのソースコードが実行可能な形式になるまでの流れをおさらいしておく。

    graph LR
    A[Jackコード
e.g. Foo.jack] -->|コンパイラが変換| B["VMコード(中間コード)
e.g. Foo.vm"]
    B -->|VM変換器が変換| C["機械語(記号表現)
e.g. Foo.asm"]
    C -->|アセンブラが変換| D["機械語(バイナリ表現)
e.g. Foo.hack"]

Jackコンパイラは構文解析器とコード生成器からなり構文解析器はトークナイザとパーサ²からなる。

lecture 10.pdf

https://drive.google.com/file/d/1CM_w6cxQpYnYHcP-OhNkNU6oD5rMnjzv/view

P4より引用

トークナイザはソースコードをトークンと呼ばれる「プログラムにおいて意味を持つコードの最小単位」に変換する処理を担う。

トークンのような表現に変換してからパースを行うことでプログラムの複雑性を軽減することができる。

例として以下のJack言語のコードのトークン列をXMLで表記すると以下のようになる。

class Main {
    static boolean test;

    function void main() {
      do Output.printString("Hello world!");
      return;
    }
}

<class>
  <keyword> class </keyword>
  <identifier> Main </identifier>
  <symbol> { </symbol>
  <classVarDec>
    <keyword> static </keyword>
    <keyword> boolean </keyword>
    <identifier> test </identifier>
    <symbol> ; </symbol>
  </classVarDec>
  <subroutineDec>
    <keyword> function </keyword>
    <keyword> void </keyword>
    <identifier> main </identifier>
    <symbol> ( </symbol>
    <parameterList>
    </parameterList>
    <symbol> ) </symbol>
    <subroutineBody>
      <symbol> { </symbol>
      <statements>
        <doStatement>
          <keyword> do </keyword>
          <identifier> Output </identifier>
          <symbol> . </symbol>
          <identifier> printString </identifier>
          <symbol> ( </symbol>
          <expressionList>
            <expression>
              <term>
                <stringConstant> Hello world! </stringConstant>
              </term>
            </expression>
          </expressionList>
          <symbol> ) </symbol>
          <symbol> ; </symbol>
        </doStatement>
        <returnStatement>
          <keyword> return </keyword>
          <symbol> ; </symbol>
        </returnStatement>
      </statements>
      <symbol> } </symbol>
    </subroutineBody>
  </subroutineDec>
  <symbol> } </symbol>
</class>

パーサはトークン列を言語の構文ルールに照らし合わせその構造を構文上の要素に変換する処理を担う。

ここでは再帰下降構文解析というアルゴリズムを使って構文解析を行った。

ちなみに、Jack言語の構文は次のように定義されている。簡単な部類の言語とはいえ実装量はこれまでの課題と比べると多めだった。趣味でCコンパイラを書く人をたまにTwitterで見かけたりするがすごいなぁという気持ちになった。

第11章コンパイラII：コード生成

第11章では、コード生成器を実装する。具体的には構文解析した結果をもとにVMコードを生成する。

lecture 10.pdf

https://drive.google.com/file/d/1CM_w6cxQpYnYHcP-OhNkNU6oD5rMnjzv/view

P4より引用

一般的にはソースコードをVMコードに変換する層をフロントエンド、VMコードを機械語に変換する層をバックエンドと呼ぶらしい。本書では第10章と第11章の内容がフロントエンドに、第6章~第8章の内容がバックエンドに該当する、と言えそう。

シンボルテーブル

コンパイラがlet y = foo(x);のような文に遭遇するたびにx, yが何を表しているのかを知る必要がある。

Jackではクラススコープとサブルーチンスコープの2つのスコープがある。クラススコープの変数にはフィールド変数、スタティック変数の2種類があり、サブルーチンスコープの変数にはローカル変数、引数の2種類がある。

ここではこれらの変数の情報はシンボルテーブルと呼ばれるデータ構造に格納することで管理する手法が紹介されていた。シンボルテーブルは変数の名前、型、スコープ、種類、インデックスを保持する。

lecture 11.pdf

https://drive.google.com/file/d/1CYOcXKxfAwRHaOERvoyuNKSwdlxMo_e3/view

P6より引用

Jackではクラススコープとサブルーチンスコープの2つのスコープがあるのでそれぞれ別のシンボルテーブルを保持する必要がある。Jackでは内側のスコープが外側のスコープよりも優先されるため、コンパイラはxという変数に出会ったときにまずサブルーチンスコープのシンボルテーブルを検索し、見つからなければクラススコープのシンボルテーブルを検索する。

コンストラクタのコンパイル

特定のクラス型の変数を宣言する。e.g. var Point p
クラスのコンストラクタを呼び出して実際にインスタンス化する。 e.g. let p = Point.new(2, 3)
1. 新しいPointインスタンスを表現するために必要な2ワード分のメモリブロックをヒープ上に確保する
2. 確保された2ワードがコンストラクタの引数として与えられた2と3で初期化される
3. pに新しく確保したメモリブロックのベースアドレスを割り当てる

実装自体が難しいというケースは少なかったが、純粋にVM変換器の仕様を忘れて思い出すのに時間がかかったりしたので可能な方は時間を開けずにやると思い出しにかかるコストを減らせておすすめです。

第12章 OS

第12章では最小限のOSを実装した。

ここではOSは以下の役割を果たす。

ハードウェア操作の抽象化
Jack言語でよく使われる処理を関数/メソッドとして提供

それぞれ具体的には次のようなクラスによって実現されている。

ハードウェア操作の抽象化
- Outputクラス: printString, printlnなどのスクリーンへのテキストの書き込み処理を提供
- Screenクラス: drawLine, drawCircleなどのスクリーンへの図形の書き込みを処理を提供
- Keyboardクラス: keyPressed, readLineなどのキーボードからの入力の読み取り処理を提供
- Memoryクラス: alloc, deAlloc, peek, pokeなどのメモリアクセス処理を提供
- Sysクラス: プログラム実行に必要な処理の提供
Jack言語でよく使われる処理を関数/メソッドとして提供
- Mathクラス: abs, devideなどの基本的な算術演算を提供
- Stringクラス: 文字列データ型とlength, setCharAtなどの関連処理を提供
- Arrayクラス: 配列の初期化とメモリの解放を行う機能を提供

この章ではこれまでまったく意識したことがなかったメモリ操作によってハードウェアを制御するという経験が得られた。クラスインスタンスの初期化のためにメモリから任意の大きさの空き領域を探して確保する処理や、2点の座標が与えられたときにそれらを結ぶ直線をスクリーン上に描画する処理など。想像に難くない通り、基本的にかなり泥臭い実装が多かったがその泥臭さを吸収するための層でもあるので仕方ないとは思う。

その過程でメモリ操作やビットを扱う処理に少し慣れられたのは大きな収穫の1つだった。普段のWeb開発ではbit演算やメモリ操作をする機会はなかなかないので貴重な経験だった。

軽く調べた感じでは、現実世界では(Linuxでは)システムコールやデバイスドライバがそれらを担っているらしい。

実装に関しては整数型のオーバーフローが原因で数時間費やしてしまった。CS50でC言語で課題を解いていたときも同様のハマりがあったのであるあるかもしれない。普段書いている言語は簡単にオーバーフローしなかったり場合によっては静的解析で指摘してくれたりするのでなかなか気付くことができなかった。

学び、得た経験

普段はWebアプリケーションばかり触っているので、それよりも数段下のレイヤーの解像度を上げることができた。今後新しい知識の習得やトラブルシューティングがスムーズになるといいなと思う。
- あとは普段触っているソフトウェア、ハードウェアの仕組みを知ることができて純粋に楽しかった。
難しい概念に出会ったときに「順を追って理解を整理したり、労を惜しまずに手を動かしていけばきっと体得できるはず」という感覚を持てるようになった。
- 自分のコンピュータサイエンスの知識と経験が薄いのもあり、本書を通して未知の概念とのたくさんの出会いがあった。
- まったく知らない概念でも、順を追って理解を進めて手を動かすことで知識を自分のものにすることができた。その過程で未知の技術に対する恐れや及び腰になる感覚が減った。
- 余談だが、大学受験のときにセンター試験の数2Bで一見すると難しそうな問題が出ることが多いように感じていて「いけるいける難しくない落ち着いて考えればわかる」と何回も念じながら問題文を読んでいたのを思い出した。「難しそう」と考えるよりも「わかりそう」とか「なんかいけそう」みたいな方向性のマインドを持っていたほうがパフォーマンスも高くなるなーと改めて思うなどした。³
難しい課題も小さい部分に分割して段階的に進めるとうまくいくことを実感できた。
- 0からコンパイラを実装するのは気が引けるが、仕組みを理解していくつかの部品に分解して進めることで、複雑なソフトウェアを着実に構築する経験を得ることができた。
コンパイラやアセンブラの実装で泥臭い処理をたくさん書いたおかげで泥臭さへの耐性が多少ついた。そもそも複雑なものは実装も複雑になりうるのでそういうケースでは特に実装力が大事だなーと思うなどした。

おわりに

『Goならわかるシステムプログラミング』を読んでからかなり気になっていた本だったので無事完走できてよかった。

最近のテーマであるCS力の強化をまた一歩進めることができた。

次は『体験しながら学ぶネットワーク技術入門』でネットワークの理解を深めていこうかなと思う。

あとはソフトスキル系でいうと『エンジニアリングチームのリード術-―Googleに学ぶインディビジュアルコントリビューターとマネージャーのための実践ガイド』も良さそうなので読んでみようと思う。

実際はテトリスではなく別のブロック崩しのようなゲームではある ↩︎
Twitterを見ているとパーザと表記する流派も存在する模様 ↩︎
近い話が何かがそれほど得意でなくても、世の中の平均よりは得意だと思っておいたほうがよい - Lambdaカクテルで綺麗に言語化されている。 ↩︎

『Goならわかるシステムプログラミング第2版』を読んだ

Sun, 03 Nov 2024 12:42:30 +0000

『Goならわかるシステムプログラミング第2版』をサンプルコードを手元で実行しつつ一通り読んだ。(期間としては2024/6/8 ~ 2024/11/4でコミットした日数としてはおおよそ24日ほどだった。)

筆者は情報系の学部を出ておらず、CSなどの基礎知識があまりないので大変勉強になった。また、サンプルコードが豊富なので実際に自分のマシン上で動かしながら学ぶことができ解像度を上げながら理解を深めることができた。

低レイヤ、コンピューターサイエンスの学習に興味がある方にはとてもおすすめなのでぜひ買って読んでみてください。

Goならわかるシステムプログラミング第2版

Go言語による新時代のコンピュータシステム入門渋川よしき著 424ページ A5判 ISBN：978-4-908686-12-2 2022年3月23日第2版第1刷発行いつも開発に使っている言語やライブラリの裏側は、いったいどうなっ

https://www.lambdanote.com/products/go-2

手元で実行したコードは以下のリポジトリにまとめた。

GitHub - kyu08/go-system-programming: 『Goならわかるシステムプログラミング』の写経リポジトリ

『Goならわかるシステムプログラミング』の写経リポジトリ. Contribute to kyu08/go-system-programming development by creating an account on GitHub.

https://github.com/kyu08/go-system-programming

以下読書メモ。

第1章 Go言語で覗くシステムプログラミングの世界

デバッガを使ってfmt.Printlnの動作をシステムコールまで追った。¹
当然だがデバッガを使うと変数の中身に何が入ってるかがわかって便利。
デバッガを使ってみて別パッケージのprivate変数の中身を見ることができるのはプリントデバッグにはないデバッガの利点だと気づいた。

第2章低レベルアクセスへの入口1：io.Writer

io.WriterはOSが持つファイルのシステムコールの相似形
OSでは、システムコールをファイルディスクリプタと呼ばれるものに対して呼ぶ。
ファイルディスクリプタ(file descriptor)は一種の識別子（数値）で、この数値を指定してシステムコールを呼び出すと、数値に対応するモノへとアクセスできる。
ファイルディスクリプタはOSがカーネルのレイヤーで用意している抽象化の仕組み。
OSのカーネル内部のデータベースに、プロセスごとに実体が用意される。
OSはプロセスが起動されるとまず3つの擬似ファイルを作成し、それぞれにファイルディスクリプタを割り当てる。
- 0が標準入力、1が標準出力、2が標準エラー出力。
- 以降はそのプロセスでファイルをオープンしたりソケットをオープンしたりするたびに1ずつ大きな数値が割り当てられていく。

複数のファイルf1, f2をos.Create()する処理をデバッガーで追ってみたところ、それぞれファイルディスクリプタの値が3, 4²となっておりファイルディスクリプタの値が3からインクリメントされる様子を確認できた。

第3章低レベルアクセスへの入口1：io.Reader

エンディアン変換

リトルエンディアンでは、10000という数値(0x2710)をメモリに格納するとき下位バイトから順に格納する。
ビッグエンディアンでは、上位バイトから順に格納する。
現在主流のCPUではリトルエンディアンが採用されている。
ネットワーク上で転送されるデータの多くはビッグエンディアンが用いられている。
そのため多くの環境ではネットワークで受け取ったデータをリトルエンディアンに変換する必要がある。

`io`パッケージのいくつかの関数 / 構造体 / インターフェースの使い方

io.Pipe³
io.LimitReader: 先頭のnバイトだけ読み込む
io.MultiReader: 複数のio.Readerを1つのio.Readerにまとめる
io.SectionReader: offsetとnを指定して一部のデータだけ読み込む

第4章チャネル

普段goroutineを全然使わないので忘れていることが多かった。以下学んだことメモ。

バッファなしチャネルでは、受け取り側が受信しないと、送信側もブロックされる。⁴
for task := range tasks // tasksは任意のchのように書くと、チャネルに値が入るたびにループが回り、チャネルがクローズされるまでループが回る。

第5章システムコール

システムコールとは特権モードでOSの機能を呼ぶこと。

CPUの動作モード

OSの仕事は以下の2つ
- 各種資源（メモリ、CPU時間、ストレージなど）の管理
- 外部入出力機能の提供（ネットワーク、ファイル読み書き、プロセス間通信）
動作モード
- 実行してよいハードウェアとしての機能がソフトウェアの種類に応じて制限されている
- OSが動作する特権モード
- 一般的なアプリケーションが動作するユーザーモード

システムコールが必要な理由

通常のアプリケーションでメモリ割り当てやファイル入出力、インターネット通信などの機能を使うために必要なのがシステムコール
システムコールがなくてもCPUの命令そのものはほとんど使うことができる
しかし、ユーザーモードでは計算した結果を画面に出力したり、ファイルに保存したり外部のWebサービスに送信したりできない。

dtrussコマンドを使ってシステムコールの呼び出しを確認しようとしたがmacOSのセキュリティの設定上何も表示されなかったのでDocker上でLinuxを起動して確認してみることにした。

docker run -it --name stracetest golang:1.22.4-alpine3.19
apk add strace

go mod init kyu08/stracetest
# 任意のgoファイルを作成
go build ./...
strace -o strace.log ./実行ファイル
less strace.log

今回はf, _ := os.Create("test_file.txt")とdefer f.Close()を実行するだけのgoプログラムを実行したときのシステムコールのログを確認した。以下はその一部。

rt_sigaction(SIGRT_32, {sa_handler=0x70d90, sa_mask=~[], sa_flags=SA_ONSTACK|SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, ~[], [], 8) = 0
clone(child_stack=0x400001c000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 890
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGURG {si_signo=SIGURG, si_code=SI_TKILL, si_pid=889, si_uid=0} ---
rt_sigreturn({mask=[]})                 = 1139696
rt_sigprocmask(SIG_SETMASK, ~[], [], 8) = 0
clone(child_stack=0x4000062000, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM) = 891
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0x4000080148, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x4000048948, FUTEX_WAKE_PRIVATE, 1) = 1
prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
fcntl(0, F_GETFL)                       = 0x20002 (flags O_RDWR|O_LARGEFILE)
futex(0x4000049148, FUTEX_WAKE_PRIVATE, 1) = 1
fcntl(1, F_GETFL)                       = 0x20002 (flags O_RDWR|O_LARGEFILE)
fcntl(2, F_GETFL)                       = 0x20002 (flags O_RDWR|O_LARGEFILE)
openat(AT_FDCWD, "test_file.txt", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 3
futex(0x115ea0, FUTEX_WAKE_PRIVATE, 1)  = 1
futex(0x115db8, FUTEX_WAKE_PRIVATE, 1)  = 1
fcntl(3, F_GETFL)                       = 0x20002 (flags O_RDWR|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
epoll_create1(EPOLL_CLOEXEC)            = 4
pipe2([5, 6], O_NONBLOCK|O_CLOEXEC)     = 0
epoll_ctl(4, EPOLL_CTL_ADD, 5, {events=EPOLLIN, data={u32=1549912, u64=1549912}}) = 0
epoll_ctl(4, EPOLL_CTL_ADD, 3, {events=EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET, data={u32=3997171713, u64=18446585726557487105}}) = -1 EPERM (Operation not permitted)
fcntl(3, F_GETFL)                       = 0x20802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_LARGEFILE)   = 0
close(3)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

openat(AT_FDCWD, "test_file.txt", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 3の部分でファイルが作成され、ファイルディスクリプタに3が割り当ている
close(3) = 0の部分でdefer f.Close()に相当する処理が行われている

ということを確認できた。

第6章 TCPソケットとHTTPの実装

ソケットとは

ほとんどのOSではアプリケーション層からトランスポート層のプロトコルを利用するときのAPIとしてソケットという仕組みを利用している
HTTP/1.0と1.1はこのソケットのバイトストリーム上に作られたテキストを使ったプロトコル

ソケットの種類（本書で説明するもののみ）

TCP：一番使われている。安定性が高い。
UDP：通信開始が早い。相手に一方的に送りつける。
Unixドメインソケット：ローカル通信でしか使えないが最速。

ソケット通信の基本構造

どんなソケット通信も基本となる構成は次のような形態
- サーバー：ソケットを開いて待ち受ける
- クライアント：開いているソケットに接続し、通信する
GoではTCP通信が確立されると、送信側、受信側の両方に相手との通信するnet.Connインタフェースを満たすオブジェクトが渡ってくる

Goに組み込まれているTCPの機能（`net.Conn`）だけを使ってHTTPによる通信を実現する

net.Connだけを使ってTCPソケットの初期化や通信の確立などの普段ならnet/httpがやってくれている部分を実装した。
http.ListenAndServe()のコードを読んでみたら、golang/go/src/net/http/server.go#L3258で本書のハンズオンと同じようにTCPソケットの初期化を行っていることを確認できた。

素朴な実装の速度改善

①Keep-Aliveへの対応
- HTTP/1.1から入った規格
- HTTP/1.0ではセットの通信が終わるたびにTCPコネクションが切れる仕様になっていたが、Keep-Aliveを使うことで、しばらくの間はTCP接続のコネクションを維持して使い回すことができる。
- TCP接続の通信には一定のオーバーヘッドがあるが、Keep-Aliveを使うことでそのオーバーヘッドを削減できる。
②レスポンスの圧縮
- レスポンスを圧縮することで、通信量を削減でき速度向上につながる。
- レスポンスヘッダーは圧縮されないため、少量のデータを通信する場合は効率が悪くなる。そのため実際のデータ量に応じて圧縮するかどうかを判断する必要がありそう。
③チャンク形式のボディー送信
- 動画など大きいデータを送信する場合、データを分割して送信することでデータの送信が完了する前に受信側でデータを処理できるようになる。また、すべてのデータをメモリに展開する必要もなくなるのでメモリの使用量を抑えることができるというメリットもある。
- チャンク形式ではヘッダーに送信データのサイズを書かないかわりにTransfer-Encoding: chunkedというヘッダーを付与する。
④パイプライニング
- 送受信を非同期化する方法

第7章 UDPソケットを使ったマルチキャスト通信

UDPとTCPの用途の違い

UDPはTCPと同じトランスポート層のプロトコルで以下のような特徴がある。

誰と繋がっているか管理しない
データロスの検知をすることも通信速度の制限をすることもしない
パケットの到着順序も管理しない
複数のコンピュータに同時にメッセージを送ることが可能な「マルチキャスト」と「ブロードキャスト」をサポートしている。（TCPにはない機能）
UDPの利用例としてはDNSやNTP, WebRTCなどがある。

UDPのマルチキャストの実装例

マルチキャストはリクエスト側の負担を増やすことなく多くのクライアントに同時にデータを送信できる仕組み。

UDPとTCPの機能面の違い

TCPには再送処理とフロー処理がある。

再送処理

TCPでは送信するメッセージにシーケンス番号が入っているので、受信側ではこの数値をみることでパケットの順序を管理できる。
受信側はメッセージを受け取ると、受信したデータのシーケンス番号とペイロードサイズの合計を確認応答番号として返信する。
送信側はこの応答確認番号が受け取れなかった場合に再送処理を行う。

フロー処理

受信側がリソースを用意できていない状態で送信リクエストが集中して通信内容が失われるのを防ぐための仕組みをウィンドウ制御という。
- 具体的には、受信用のバッファ（ウィンドウ）をあらかじめ決めておき送信側ではそのサイズまでは受信側からの受信確認を待たずにデータを送信できる。
受信側のデータの読み込みが間に合わない場合には、受信できるウィンドウサイズを受信側から送信側に伝えて通信量を制御できる。これをフロー制御という。

フレームサイズ

UDPレイヤーで取り扱えるデータは約64キロバイトまで。
UDPではデータの分割などはアプリケーションで面倒を見る必要がある。

輻輳制御とフェアネス

輻輳制御とは、ネットワークの輻輳（渋滞）を避けるように流量を調整し、そのネットワークの最大効率で通信できるようにするとともに複数の通信をお互いにフェアに行うための仕組み。
TCPには輻輳制御が備わっており、そのアルゴリズムにはさまざまな種類がある。
UDPにはTCPのような輻輳制御の仕組みはなく、流量の制御はUDPを利用する各プログラムに委ねられている。そのため、UDPとTCPを利用するアプリケーションがそれぞれあって、UDPを利用するアプリケーションでフェアネスが考慮されていない場合には、両方の通信が重なった時に遠慮する機能が組み込まれたTCPの通信速度だけが極端に落ち込むこともある。

第8章高速なUnixドメインソケット

UnixドメインソケットはPOSIX系OSで提供されている機能で、コンピュータ内部でしか使えない代わりに高速な通信が可能。
Unixドメインソケットには、TCP型（ストリーム型）とUDP型（データグラム型）の両方の使い方ができる。

Unixドメインソケットの基本

TCPとUDPによるソケット通信が外部のネットワークにつながるインターフェースに接続するのに対し、Unixドメインソケットはカーネル内部で完結する高速なネットワークインターフェースを作成する。
Unixドメインソケットを使うことで、ウェブサーバーとNGINXなどのリバースプロキシとの間、あるいはウェブサーバーとデーターベースとの間の接続を高速にできる場合がある。
Unixドメインソケットを開くには、ファイルシステムのパスを指定する。サーバープロセスを起動するとファイルシステム上の指定したパスにソケットファイルが作成される。
Unixドメインソケットで作成されるのはソケットファイルと呼ばれる特殊なファイルであり、通常のファイルのような実体を持たない。あくまでもプロセス間の高速な通信としてファイルというインターフェースを利用するだけ。

以下はソケットファイルが作成されている様子。ソケットファイルは先頭が"s"で始まる。

UnixドメインソケットとTCPのベンチマーク

Unixドメインソケットを使った実装とTCPを経由した実装のベンチマークの比較をすると筆者の環境だとUnixドメインソケットの方が10倍ほど高速だった。

$ go test -bench . -benchmem
goos: darwin
goarch: arm64
pkg: github.com/kyu08/go-system-programming/bench
BenchmarkTCPServer-8                4165            327038 ns/op           52175 B/op        110 allocs/op
BenchmarkUDSStreamServer-8         42742             27837 ns/op           16762 B/op         59 allocs/op
PASS
ok      github.com/kyu08/go-system-programming/bench    4.788s

第9章ファイルシステムの基礎とGo言語の標準パッケージ

この章ではosパッケージとpath/filepathパッケージの主要な関数の使い方が紹介されていた。

ファイル/ディレクトリを扱うGo言語の関数たち

2つのファイルの同一性の判定: os.Samefile()
ファイルのパーミッション、オーナー、タイムスタンプの変更: os.Chmod(), os.Chown, os.Chtimes()
ハードリンク、シンボリックリンクの作成: os.Link, os.Symlink()
ファイル一覧の取得: dir, _ := os.Open(path) -> dir.Readdir()

OS内部におけるファイル操作の高速化

CPUにとってディスクの読み書きはとても遅い処理であり、なるべく最後までやらないようにしたい。LinuxではVFSの内部に設けられているバッファを利用することでディスクに対する操作をなるべく回避している。

`path/filepath`パッケージの関数たち

パスの最後の要素を返す: filepath.Base()
パスのディレクトリ部分を返す: filepath.Dir()
パスをディレクトリとパス名に分割する: filepath.Split()
ファイルの拡張子を返す: filepath.Ext()
/some/../pathやanother//pathのような形式のパスを整える: filepath.Clean()
パターンにマッチするファイルの判定: filepath.Match()
ディレクトリのトラバース: filepath.Walk()

想像よりも標準パッケージでいろんなことができるのでこの辺りの操作をしたくなったら自作関数を書く前に標準パッケージを探してみるのが良さそうだと思った。

第10章ファイルシステムの最深部を扱うGo言語の関数

ファイルの変更監視（`syscall.Inotify`）

プログラムでファイルを監視する方法には次の2種類がある。

監視したいファイルをOS側に通知しておいて、変更があったら教えてもらう（パッシブな）方式
タイマーなどで定期的にフォルダを走査し、os.Stat()などを使って変更を探しに行く（アクティブな）方式

アクティブな方式の方がコード量は少ないが監視対象が増えるとCPU負荷やIO負荷が増える。

パッシブな方式はファイルの変更検知が各OSでシステムコールやAPUIとして提供されている一方で環境ごとのコード差は大きくなる。

ここでは fsnotify/fsnotify.v1を用いてファイルの変更検知プログラムを作成した。

fsnotify.v1では、Linuxの場合はinotify系APIが、BSD系OSの場合はkqueueが使われている。

ファイルのメモリへのマッピング（`syscall.Mmap()`）

syscall.Mmap()を使うことでファイルの中身をそのままメモリ上に展開したり、メモリ上で書き換えた内容をそのままファイルに書き込むことができる。

edsrzf/mmap-goではmmap.Map()を使うことでファイルをメモリに展開できる。mmap.Map()は次のようなシグネチャを持つ。

func Map(f *os.File, prot, flags int) (MMap, error)

2つ目の引数に次のような値を指定することでメモリ領域に対して許可する操作を設定できる。

mmap.RDONLY: 読み込み専用
mmap.RDWR: 読み書き可能
mmap.EXEC: 実行可能にする
mmap.COPY: コピーオンライト

コピーオンライトが指定されると、複数のプロセスが同じファイルをマッピングしているときに、カーネル上は1つ分のみメモリ領域が使用され、それ以上のメモリを消費しない。

しかし、その領域内でメモリ書き換えが発生すると、その領域がまるごとコピーされる。このようにすることでメモリ消費量をうまく節約できる。

同期・非同期 / ブロッキング・ノンブロッキング

同期処理: OSにI/Oタスクを投げて、入出力の準備ができたらアプリケーションに処理が返ってくる
非同期処理: OSにI/Oタスクを投げて、入出力の準備ができたら通知をもらう
ブロッキング処理: お願いしたI/Oタスクの結果の準備ができるまで待つ（自分は停止）
ノンブロッキング処理: お願いしたI/Oタスクの結果の準備ができるのを待たない（自分は停止しない）

select属のシステムコールによるI/O多重化

非同期・ブロッキングは1スレッドでたくさんの入出力を効率よく扱うための手法でありI/O多重化とも呼ばれる。それを効率よく実現するAPIのことを本書ではselect属と総称する。

並行処理を使うことで小さい規模のI/Oの効率化は十分に行えるが、select属はC10K問題と呼ばれる、万の単位の入出力を効率よく扱うための手法として有効。

第11章コマンドシェル101

シェルとは、ユーザーがコンピューターを操作するために使う接点となるシステムにおいてコンピューターシステムの殻（shell）となるプログラムのこと。

シェルがないシステム

Distrolessと呼ばれるコンテナイメージはシェルがないため、セキュリティホールをついてシステムに侵入されることがない。⁵（当然攻撃の脅威がゼロになるわけではない）

シェルがコマンドを起動するまで

シェルがコマンドを起動するまでには次のようなことを行っている。

ユーザーの入力を受け付ける
入力されたテキストの分解
コマンドと引数の前処理
実行ファイルの探索
ワイルドカードの展開
プロセスの起動

「11.5.3コマンドと引数の前処理」で紹介されていたが、$(which nvim)と同様に`which nvim`でもコマンドの実行結果を変数に代入できるのは知らなかった。

第12章プロセスの役割とGo言語による操作

OSが実行ファイルを読み込んで実行するには、そのためのリソース（CPU、メモリ）を用意する必要がある。そのようなリソースをまとめたプログラムの実行単位のことをプロセスと呼ぶ。プロセスはOSが実行ファイルを読み込んで実行するときに新しく作られる。
プロセスにはプロセスごとにユニークな識別子がある。（プロセスID）。Go言語ではos.Getpid()で取得できる。

プロセスの入出力

すべてのプロセスは少なくとも次の3つの入出力データを持っている。

入力：コマンドライン引数
入力：環境変数
出力：終了コード

OSから見たプロセス

OSの仕事はたくさんあるプロセスに効率よく仕事をさせること
Linuxではプロセスごとにtask_struct型のプロセスディスクリプタと呼ばれる構造体を持っている。
- 基本的にはプロセスから見た各種情報と同じ内容だが、そこには含まれていない要素もいくつか存在する。
- 例えば、どこからどこまでが自分のメモリ領域かというメモリブロックの情報やスタック領域がどこにありプログラムが静的に確保するデータや動的に確保するデータがどのようにレイアウトされるかもOSが持つプロセスの情報の中にある。

プロセスの出力に色づけをする

プロセスの出力に色をつけたい場合にはANSIエスケープシーケンスを使うことができる。

自分が利用したことある⁶Rustのcoloredクレートも確認したところ実際にANSIエスケープシーケンスを使ってターミナルに色をつけていた。

    #[cfg_attr(feature = "no-color", ignore)]
    #[test]
    fn compute_style_simple_fg_blue() {
        let blue = "\x1B[34m";

        assert_eq!(blue, "".blue().compute_style());
    }

colored/src/lib.rs at 775ec9f19f099a987a604b85dc72ca83784f4e38 · colored-rs/colored

(Rust) Coloring terminal so simple you already know how to do it ! - colored-rs/colored

https://github.com/colored-rs/colored/blob/775ec9f19f099a987a604b85dc72ca83784f4e38/src/lib.rs#L805-L811

より

調べてみたところ\x1Bでも\eでもエスケープシーケンスを表現できるらしい。⁷

外部プロセスに対して自分が擬似端末だと詐称する

ライブラリによっては、自分が繋がっている先が擬似端末かどうかでエスケープシーケンスを出力するかどうかを決定している。

子プロセスの出力を色づけするためには、親を擬似端末だと詐称することでエスケープシーケンスを出力させることができる。

デーモン化

普通のプログラムはシェルのプロセスの子になってしまうので、ログアウトしたりシェルを閉じたりするだけで終了してしまう。

そのような場合でも終了しないように下記のような特別な細工が施されたプロセスがデーモンである。

セッションID、グループIDを新しいものにして既存のセッションとグループから独立
カレントのディレクトリはルートに移動
フォークしてからブートプロセスのinitを親に設定し、実際の親はすぐに終了
標準入出力も起動時のものから切り離される(通常はdev/nullに設定される)

第13章シグナルによるプロセス間の通信

シグナルには主に2つの用途がある。

プロセス間通信: カーネルが仲介してあるプロセスから別のプロセスへとシグナルを送るケース。自分自身にシグナルを送ることもできる。
ソフトウェア割り込み: システムで発生したイベントがシグナルとしてプロセスに送られる。シグナルを受け取ったプロセスは現在置くなっているタスクを中断してあらかじめ登録しておいた処理を実行する。

システムコールはユーザー空間で動作しているプロセスからカーネル空間にはたらきかけるためのインターフェースだが、その逆方向がシグナルだと考えることができる。

システムコールでは最大7つほどの引数を指定できるのに対し、ソフトウェア割り込みとしてのシグナルで送信できるのはその種類のみ。
プロセスは受け取ったシグナルを無視するか補足して処理する。

シグナルのハンドラを書く

Goでは次のようにsignal.NotifyContext()を使ってシグナルを受け取ることができる。

package main

import (
	"context"
	"fmt"
	"os/signal"
	"syscall"
	"time"
)

func main() {
	ctx := context.Background()
	sigctx, cancel := signal.NotifyContext(ctx, syscall.SIGINT, syscall.SIGTERM)
	defer cancel()
	toctx, cancel2 := context.WithTimeout(ctx, time.Second*5)
	defer cancel2()

	select {
	case <-sigctx.Done():
		fmt.Println("signal")
	case <-toctx.Done():
		fmt.Println("timeout")
	}
}

KubernetesやDockerでは外からタスクを終了させるとき、まずSIGTERMをアプリケーションに対して送信する。(SIGTERM: kill()システムコールやkillコマンドがデフォルトで送信するシグナル。プロセスを終了させるもの)

(GoアプリケーションのGraceful Shutdownの実装例でSIGTERMをハンドリングするのをよく見るのはだからか、と納得した。)

第14章 Go言語と並列処理

並行処理と並列処理の違い

並行処理: 1つのコアで複数のタスクを素早く切り替えながら処理すること
並列処理: 複数のコアを使って複数のタスクを同時に処理すること

チャネル

Go言語で簡単に並列処理を書くための道具としてgoroutineとチャネルがある。
チャネルを使うことでデータの入出力を直列化できる。

スレッドとgoroutineの違い

スレッドとはプログラムを実行するためのものであり、OSによって手配される。
プログラムからみたスレッドは「時間が凍結されたプログラムの実行状態」で、CPUが演算に使ったり計算結果や状態を保持したりするレジスタと呼ばれるメモリとスタックメモリが含まれる。
OSは凍結状態のプログラムの実行状態を復元して各スレッドに短時間ずつ処理をさせる。実行予定のスレッドはランキューと呼ばれるリストに入っている。
スレッドがCPUコアに対してマッピングされるのに対し、gouroutineはOSのスレッドにマッピングされる点が通常のスレッドとgoroutineとの最大の違い。
- goroutineはOSスレッドの1~2MBと比べると初期スタックメモリのサイズが小さい(2KB)ため起動処理が軽い。
- また、gouroutineはOSに処理を渡さずに作成できるのでカーネルとのタスク切り替えのコストも小さい。

goroutineのメリット

大量のクライアントからのリクエストを効率よく捌きたいとき（いわゆるC10K）に、クライアントごとに1つのgoroutineを割り当てたとしても少ないメモリ消費量で処理できる（前述の通りgoroutineは起動時の初期スタックメモリのサイズが小さいため）

第15章並行・並列処理の手法と設計のパターン

代表的な並行・並列処理の手法

マルチプロセス
イベント駆動
マルチスレッド
ストリーミング・プロセッシング

イベント駆動

主に並列化ではなく並行処理のために使われる。
I/Oバウンドなプログラムで用いられる。
OSに依頼したデータ受信の仕事が終わるたびにコールバックが返ってくる仕組み。
単体ではCPUを使いこなしにくい点が欠点。

マルチスレッド

同じメモリ空間内で多くのCPUが同時に実行するための仕組み
- Linuxではプロセスもスレッドもカーネル上は同じ構造体として表現されている。親のプロセスとメモリ空間を共有していなければプロセス、共有していればスレッド。
利点はCPUのパフォーマンスを引き出すことができる点。
欠点はプロセスほどではないが、OSのスレッドの場合は比較的大きなスタックメモリ（1~2MB）を必要とし、起動時間もややかかる。そのためスレッドプールを作っておき、必要になったらすぐ使えるようにする、ということが行なわれている。

Goにおける並行・並列処理のパターン集

アムダールの法則: 並列化を導入するとどれだけ効率が改善するかを表す数式

S(N) = 1 / ((1 - P) + P/N)

ここでPは並列化できる仕事の割合、Nは並列数である。

P = 0.5, N = ∞のとき、S(N) = 2倍になり、P = 0.9, N = ∞のとき、S(N) = 10倍になる。このことからもわかるように、並列数よりも並列化できるタスクの割合が支配的になる。

Pを改善するためのアイディアとして次のような手法が考えられる。

同期処理を非同期にする
非同期にしたものを同期化する
タスク生成と処理を分ける（Producer-Consumerパターン）
開始した順で処理する（チャネルのチャネル）
タスク処理が詰まったら待機（バックプレッシャー）
並列なForループ
決まった数のgoroutineでタスクを消化する（ワーカープール）
依存関係のあるタスクを表現する（Future/Promise）
イベントの流れを定義する（ReactiveX）
自立した複数のシステムで協調動作（アクターモデル）

同期 -> 非同期化

I/O処理などの重いタスクを非同期化する

非同期 -> 同期化

非同期化したタスクはどこかで同期化する必要がある。そのための一番簡単な手法がチャネル。

タスク生成と処理を分ける（Producer-Consumerパターン）

GoではチャネルでProducerとConsumerを接続することで簡単に実現できる。

開始した順で処理する（チャネルのチャネル）

チャネルを用いると複数の処理を終了した順に取り出すことができる。

// 終了した順に書き出し
// チャネルに結果が投入された順に処理される
func writeToConn(responses chan *http.Response, conn net.Conn) {
	defer conn.Close()
	// 順番に取り出す
	for response := range responses {
		response.Write(conn)
	}
}

チャネルのチャネルを使うと処理を開始した順で処理をできる。

// 開始した順に書き出し
// チャネルにチャネルを入れた(開始した)順に処理される
func writeToConn(sessionResponses chan chan *http.Response, conn net.Conn) {
	defer conn.Close()
	// 順番に取り出す
	for sessionResponse := range sessionResponses {
		// 選択された仕事が終わるまで待つ
        response := <-sessionResponse response.Write(conn)
	}
}

タスク処理が詰まったら待機（バックプレッシャー）

以下のようなバッファ付きチャネルを使うことで実現できる。

tasks := make(chan string, 10)

並列Forループ

forループ内の処理をgoroutineで実行することでループ処理を並列化できる。
ループ内部の処理が小さすぎるとオーバーヘッドのほうが大きくなり効率が上がらないことがあるので注意が必要。

決まった数のgoroutineでタスクを消化する（ワーカープール）

特にCPUバウンドな処理ではCPUのコア数以上にgoroutineを作ってもスループットは上がらないため、CPUコア数分のワーカーを作成してタスクを消化するのが効果的な場合がある。

依存関係のあるタスクを表現する（Future/Promise）

Futureをチャネルで表現すると、必要なデータが揃ったらタスクを逐次実行できる。

後続の処理に結果を引き継ぎたいが、処理自体は可能な限り非同期で実行したい場合に有効そう。

func readFile(path string) chan string {
	// ファイルを読み込み、その結果を返すFutureを返す
	promise := make(chan string)
	go func() {
		content, err := os.ReadFile(path)
		if err != nil {
			fmt.Printf("read error %s\n", err.Error())
			close(promise)
		} else {
			// 約束を果たした
			promise <- string(content)
		}
	}()
	return promise
}

func printFunc(futureSource chan string) chan []string { 
    // 文字列中の関数一覧を返すFutureを返す
	promise := make(chan []string)
	go func() {
		var result []string
		// futureが解決するまで待って実行
		for _, line := range strings.Split(<-futureSource, "\n") {
			if strings.HasPrefix(line, "func ") {
				result = append(result, line)
			}
		}
		// 約束を果たした
		promise <- result
	}()
	return promise
}

func main() {
	futureSource := readFile("main.go")
	futureFuncs := printFunc(futureSource)
	fmt.Println(strings.Join(<-futureFuncs, "\n"))
}

また、次のような構造体を定義することで上記のFutureの値を複数回読み取ることができる。（上記の実装ではバッファなしチャネルを使っているので複数回受信してしまうと処理がブロックされてしまう）

type StringFuture struct {
	receiver chan string
	cache    string
}

func NewStringFuture() (*StringFuture, chan string) {
	f := &StringFuture{
		receiver: make(chan string),
	}
	return f, f.receiver
}

func (f *StringFuture) Get() string {
	r, ok := <-f.receiver
	if ok {
		close(f.receiver)
		f.cache = r
	}
	return f.cache
}

func (f *StringFuture) Close() {
	close(f.receiver)
}

イベントの流れを定義する：ReactiveX

ここではRxGoを使ってイベントの流れを定義する方法が紹介されていた。まずこのようにwatcherを定義する。

watcher := observer.Observer{
    NextHandler: func(item any) {
        line := item.(string)
        if strings.HasPrefix(line, "func ") {
            fmt.Println(line)
        }
    },
    ErrHandler: func(err error) {
        fmt.Printf("Encountered error: %v\n", err)
    },
    DoneHandler: func() {
        fmt.Println("Done!")
    },
}

以下のようにするとNextHandlerに登録された関数にlineが渡される。

emitter <- line

そして次のようにするとErrHandlerに登録された関数が呼ばれる。

emitter <- err

渡ってきた値に応じて処理を分岐させたく、かつ何度も同一のイベントが発生するケースではこの方法を使うと良さそう。

自律した複数のシステムで協調動作：アクターモデル

アクターと呼ばれる自律した多数のコンピューターが協調して動作するというモデル。
各アクターは別のアクターから送られてくるメッセージを受け取るメッセージボックスを持つ。

第16章 Go言語のメモリ管理

仮想メモリ

現代のOSではプロセスはメモリを読み書きするのに物理的なアドレスを直接扱うのではなく、プロセスごとに仮想的なメモリアドレス空間があり、それを使ってメモリにアクセスしている。この仮想的なメモリアドレス空間のことを仮想メモリという。

仮想メモリのアドレスから実際の物理メモリにアクセスするためにページテーブルというデータ構造が使われる。ページとはメモリを管理する単位のこと。

仮想メモリのおかげで実際の保存領域が飛び飛びになっていたとしてもプロセスからはフラットなメモリ領域が確保されているように見える。

仮想メモリは物理メモリのアドレスと1対1対応しているわけではなく、物理メモリのあるアドレスが複数の仮想メモリから参照されることもある。こうすることで共有ライブラリなどを複数のプロセスで利用でき省メモリになる。

OSカーネルがプロセスのメモリを確保するまで

プロセスは起動時にOSからメモリをもらう。OSはプロセスごとに仮想メモリの領域を確保する。

ユーザーのメモリ空間は大きく3つの連続したメモリ領域に分かれる。3つの領域の間の空きスペース分はメモリの確保が行われない。

| ①プログラム + 静的データ | ヒープとして使われる領域 | ②共有ライブラリ |      | ③スタックなど |
小さいアドレス                                                                大きいアドレス ->

スタック

関数を呼ぶとリターンアドレスや新しい関数のための作業メモリ領域としてスタックフレームと呼ばれるメモリ領域が確保される。

スタックフレームはスレッドごとにあらかじめ確保されているメモリブロックに対して順番に追加したり削除されたりされるだけなので割当のコストはほぼゼロ。

Go言語でのスタックとヒープの使い分け

Go言語では変数のデータをヒープに置くかスタックに置くかはコンパイラが自動的に判断する。以下はその一部。

newで初期化してもその関数内でしか利用されなければスタックに確保される。
ローカル変数として宣言してもそのポインタを他の関数に渡したり、関数の返り値として返すような場合にはヒープに確保される。

Go言語でメモリがスタックとヒープのどちらに確保されるかを知りたい場合にはビルド時に-gcflags -mを渡すことで確認できる。

ということで次のコードを使って上記の挙動を確認してみる。

package main

import "fmt"

func main() {
	strValue := "Hello, World!" // スタックに確保される(関数内でしか利用されていないため)
	_ = strValue + ""

	strPtr := new(string) // スタックに確保される(関数内でしか利用されていないため)
	_ = *strPtr + ""

	strPtr2 := new(string) // ヒープに確保される(他の関数に渡されているため)
	receiveStrPtr(strPtr2)

	strPtrFromFunc := returnStrPtr() // スタックに確保される(関数内でしか利用されていないため)
	_ = *strPtrFromFunc + ""
}

func receiveStrPtr(argStrPtr *string) {
	fmt.Printf("argStrPtr: %v\n", argStrPtr)
}

func returnStrPtr() *string {
	str := "Hello, World!" // ヒープに確保される(関数の返り値として返されているため)
	return &str
}

-gcflags -mをつけてビルドしてみると次のようになりコードコメント通り、strPtr2とstrがヒープに確保されていることがわかった。

$ go build -gcflags -m main.go
# command-line-arguments
./main.go:19:6: can inline receiveStrPtr
./main.go:23:6: can inline returnStrPtr
./main.go:13:15: inlining call to receiveStrPtr
./main.go:15:32: inlining call to returnStrPtr
./main.go:13:15: inlining call to fmt.Printf
./main.go:20:12: inlining call to fmt.Printf
./main.go:7:15: strValue + "" does not escape
./main.go:9:15: new(string) does not escape
./main.go:10:14: *strPtr + "" does not escape
./main.go:12:16: new(string) escapes to heap
./main.go:13:15: ... argument does not escape
./main.go:16:22: *strPtrFromFunc + "" does not escape
./main.go:19:20: leaking param: argStrPtr
./main.go:20:12: ... argument does not escape
./main.go:24:2: moved to heap: str

ガベージコレクタ

Goをはじめとして多くの言語ではマークアンドスイープという方式が採用されている。

マークアンドスイープ方式では、まずメモリの領域をスキャンして必要なデータか否かをマークしていき、次のフェーズで不要なものを削除する。

マークアンドスイープ方式では、不要なメモリを削除する間にプログラム全体を停止する必要がある。（これをストップザワールドと呼ぶ）

Goではバージョンを重ねる事にストップザワールドの時間の短縮化が進んでいる。

第17章実行ファイルが起動するまで

最終的にCPUで実行されるバイナリはメモリ空間に単に命令が並んだもので、そこにはブロックのような概念は存在しない（Goでいうと{と}で囲まれた処理の塊）。

アセンブリ言語には関数のブロックのような概念はないが、その代わりにラベルという概念がある。

ランタイムの役割

Goに限らずC言語でもRustでも何かしらのプログラミング言語で生成したアプリケーションは「ランタイム」と呼ばれるライブラリを利用したプログラムになるのが一般的。

ラインタイムライブラリが最終的にはOSのカーネルにシステムコールを発行して仕事を依頼し、メモリ管理やファイルやネットワークアクセスを実現する役割を担う。

ラインタイムライブラリがなければ、OSに仕事を依頼するところも自分で作成する必要がある。

リンカーの役割

以下はWikipediaによるリンカーの説明。

a computer program that takes one or more object files generated by a compiler or generated by an assembler and links them with libraries, generating an executable program or shared library

Linker - Wikipedia から引用

上記を翻訳すると「コンパイラまたはアセンブラによって生成された1つ以上のオブジェクトファイルをライブラリと結合し実行可能ファイルまたは共有ライブラリを生成するプログラム」といった感じだろうか。

OSはリンカーが生成した実行ファイルがシェルから起動されると、実行ファイルの内容をメモリに配置する。

ロードが終わったら決め打ちされた「特定のアドレス」からCPUが命令を読み込んで実行が開始される。

実行中に発生する関数呼び出しはすでにリンカーによってアドレスが解決されているので示されたアドレスにジャンプするだけで高速に実行される。

実行ファイルのメモリ配置

OSがアプリケーションの実行ファイルを最初にロードしてくる部分についての解説。

まず、実行ファイルのフォーマットはOSによって異なる。

LinuxなどのPOSIX系OS: ELF形式
Windows: PE(Portable Executable)形式
macOS: Mach-O形式

また、実行ファイルには次のようなデータが格納されている。

この実行ファイルが対象としているCPUアーキテクチャの種類
実行ファイル中に含まれるセクションをどのメモリアドレスに配置するか、そのときのセクション名と実行権限
プログラム起動時に最初に呼び出す命令が格納されているアドレス
実行ファイルの実行に必要な共有ライブラリの情報
実行コードのセクション
静的に初期化された変数のセクション

セクションは実行ファイルフォーマットを構成するバイナリデータのブロックのことで以下のようなものがある。

TEXT: 機械語の実行コードが格納されるセクション
DATA: 実行コードを含まない静的に確保された初期化済み（データがすでに入っている）のメモリ領域
BSS: 変数が置かれる領域で初期化されていない（すべてゼロ）メモリ領域

OSはこの実行ファイルフォーマットに従って実行ファイルに含まれるセクションを適切なアドレスに配置していく。⁸その後実行ファイルフォーマットに書かれた初期実行アドレスを実行することでアプリケーションが起動する。

Goのプログラムの起動

Goで書かれたソースコードが実行されるまでの流れは以下。

Goで書かれたアプリケーションをコンパイルすると実行ファイルが作成される
コンパイル済みのGoプログラムを実行すると実行環境のランタイムにある$GOROOT/src/runtime/asm_(ARCH名).sというファイルのなかにある_rt0_(ARCH名)という関数が呼ばれる。このプロシージャの中では以下のような処理が実行される。
1. 最初のgoroutineの初期化
2. OSから渡されるコマンドライン引数os.Argsのパース
3. コンピュターで利用可能なCPUコア数の取得
$GOROOT/src/runtime/proc.goのschedinit()関数の中で以下のような処理が実行される。
- スタックを初期化
- メモリマネージャを初期化し、Mを初期化
- mapの内部で使われるハッシュアルゴリズムの初期化
- モジュール機能向けのモジュール情報や型情報の取得
- シグナルハンドラの初期化
- コマンドライン引数と環境変数の初期化
- ガベージコレクタの初期化

次に新しいgoroutineを作って$GOROOT/src/runtime/proc.goのmain()関数が呼び出される。そこでは以下のような流れで処理が進む。

runtime.lockOSThread()
(ランタイムの)init()
main・init()(アプリケーションのmainパッケージのinit()関数)
runtime.unlockOSThread()
main・main()(アプリケーションのmainパッケージのmain()関数)

まとめ

ここまでの理解をもとにいくつかの質問に対する答えを書いてみる。

プロセスとスレッドの違いは何か

プロセスはプログラムの実行単位であり他のプロセスとはメモリを共有していない。
プロセスは起動時に仮想メモリが割り当てられるためスレッドに比べて起動コストが高い
スレッドはプロセス内で実行される軽量な実行単位でプロセス内のメモリ空間やリソースを共有する。
複数のスレッドが同じメモリを操作する可能性があるためデータ競合を防ぐ必要がある。

プログラムはどのような流れで実行されるか

コンパイラがソースコードをコンパイルする
リンカーがコンパイル済みのオブジェクトファイルをリンクし実行可能ファイルを生成する
ユーザーが実行可能ファイルを実行する(e.g. ターミナルから呼び出す)
OSがプロセスを生成し、プロセスの実行に必要な仮想メモリ空間を割り当てる
OSが実行ファイルの内容をディスクからメモリに読み込み、仮想アドレス空間に適切に配置する
メインスレッドでプログラムが実行される(プロセスが生成されると自動的にメインスレッドが作成される)

感想

冒頭にも書いた通りCSを体系的に学んだ経験がない自分にとってはとても勉強になった。

次はこのあたりの書籍を読んでみようとおもう。

コンピュータシステムの理論と実装
Go言語による並行処理
つくって、壊して、直して学ぶ Kubernetes入門
Linuxで動かしながら学ぶTCP/IPネットワーク入門
体系的に学ぶ安全なWebアプリケーションの作り方

あるいは、 Webサーバーアーキテクチャ進化論2023 - blog.ojisan.ioを参考に学習ロードマップを立ててみるのもいいかもしれない。

Neovimでのデバッガの環境構築は nvim-dapでGolangのデバッグ環境構築を参考にした ↩︎
Sysfdの定義はgolang/go/src/internal/poll/fd_unix.go#L23(https://github.com/golang/go/blob/c83b1a7013784098c2061ae7be832b2ab7241424/src/internal/poll/fd_unix.go#L23) にある。 ↩︎
io.Pipeの使いどころに関しては Go言語のio.Pipeでファイルを効率よくアップロードする方法が大変参考になった。 ↩︎
cf. kyu08/go-system-programming/4-channel/unbufferedchannel/main.go#L8 ↩︎
Distrolessに対して「コンテナイメージが軽量になる」以外のメリットを感じていなかったが書かれている通りセキュリティ面でもメリットがあると気付いた。 ↩︎
fzf-makeの出力の一部に色を付けるために使っている。 https://github.com/kyu08/fzf-make/blob/12789acd19bc24daa60ba7eb84973dab18fe7a52/src/usecase/execute_make_command.rs#L5 ↩︎
https://ufcpp.net/blog/2023/12/escape-escape/ ↩︎
仮想メモリ空間についてはκeenさんのこちらの記事がとてもわかりやすかった。メモリとスタックとヒープとプログラミング言語 ↩︎

CS50.jpでCSに入門した

Sun, 12 May 2024 06:32:42 +0000

CS50.jpの気になっていたトピックを学んでみたので振り返っておく。

CS50.jpとは

CS50.jpの説明はサイトから引用する。

このページは、ハーバード大学 CS50 の日本語版翻訳プロジェクトのページです。当サイトのドメインに掲載されているコンテンツは、Creative Commons ライセンスが適用されています。個人利用のほか、非営利に限って教材として利用することができます。

（中略）

ハーバード大学の CS50x は、コンピュータサイエンスとプログラミング技術を紹介するコースで、プログラミングの経験の有無にかかわらず、経験者と未経験者の両方を対象としています。David J. Malan が担当するエントリーレベルのコースである CS50x では、アルゴリズム的に考え、問題を効率的に解決する方法を学びます。テーマは、抽象化、アルゴリズム、データ構造、カプセル化、リソース管理、セキュリティ、ソフトウェアエンジニアリング、ウェブ開発など。言語は C、Python、SQL、JavaScript に加え、CSS と HTML を使用します。問題集は、生物学、暗号、金融、科学捜査、ゲームなどの実世界の領域からヒントを得ています。CS50x の学内版である CS50 は、ハーバード大学で最大のコースです。

カリキュラムは次のような構成になっている。

Week0 Scratch
Week1 C
Week2 Arrays
Week3 Algorithms
Week4 Memory
Week5 Data Structures
Week6 Python
Week7 SQL
Week8 HTML, CSS, JavaScript
Week9 Flask
Week10 Ethics
Security
Artificial Intelligence
Final Project

各章はレジュメと課題で構成されている。

課題を解いてコードを提出するとリモート環境でテストが実行され結果を確認できる。¹

正直にいうと日本語訳がなかったら取り組もうと思わなかったと思うのでCS50.jpの翻訳コントリビュータであるCODEGYM社には感謝してもしきれない。本当にありがとうございます。

そもそもなぜCSを勉強しているか

前提として筆者について補足しておくと筆者は電気系の学部・大学院を卒業しておりコンピューターサイエンスのバックグラウンドを持っていない。（かつSaaS企業でソフトウェアエンジニアとして働き初めて現在4年目）

「〜という分野に精通して自分の業務パフォーマンスを向上させる」のような明確な目的意識はないがおおむね以下のような理由でやっている。

CSの知識を習得することでソフトウェアエンジニアとして見える世界がどう変わるのか知りたい
普段触っている技術の裏側を理解することでよりよい選択ができたり、より素早い問題解決ができるのではないか、という仮説がある
知的好奇心を満たすことができて単純に楽しい

やったこと

Week6 Python以降は自分にとって大きな学びはなさそうだったのでWeek5 Data Structuresの課題（Lab & Problem Set）までを取り組んだ。2024/3/8~2024/5/3まで平日夜や土日の時間を使って取り組んだ。

自分のメモ用のリポジトリは以下。（解いた課題のコードも載っているのでネタバレ（？）注意）

GitHub - kyu08/cs50: https://cs50.jp/

https://cs50.jp/. Contribute to kyu08/cs50 development by creating an account on GitHub.

https://github.com/kyu08/cs50

学びや得たもの

CSの基礎

CSの基礎の導入部分くらいには触れることができたと思う。たとえばこのあたり。

ASCIIとは
Cで記述したプログラムが実行可能になるまでの流れ
アルゴリズム
- O記法とΩ記法
- 代表的なソートアルゴリズム
データ構造
- 連結リスト(課題ではダイレクトチェイニング法を用いた連結リストを使ってハッシュテーブルを実装した)

ただ、各週の講義動画は1.5hくらいのボリュームなのであくまでそれぞれのトピックの序章（または序章の導入部分）くらいの内容だとは思う。

C言語の基礎

あとはWeek1 ~ Week5までの課題はすべてC言語で課されたのだが、C言語の経験が得られたのは自分にとって貴重だった。(各Weekの課題が2~3問あり合計で14問の課題をC言語で解いた。)

特に

文字列の扱い（終端文字）
数値型のオーバーフロー

あたりが印象に残っている。（課題を解いていてこれらに起因するバグに何度か悩まされた）

C言語を触ることで現在自分がよく触っている言語であるGoやRustがいかに便利かを思い知った。

あとはC言語で書かれたOSSやサンプルコードの理解を多少は深めやすくなったので今後の学習・調査の助けになってくれそう。

まとめ

全体感としてはCSの勉強をやっていく上での基礎的な知識を学ぶことができ、今後の学習の足がかりになってくれそうだったので取り組んでみてよかった。あとはC言語の経験が得られてよかった。

やはり新しい分野や言語を習得するには時間を投資して手を動かすのが自分にはあっているように思った。引き続きやっていき。

テストケースはcs50/problemsにあるので参考にしながら課題を進めた。 ↩︎

CS on blog.kyu08.com

『プログラミング言語C 第2版』を読んだ

どんな本か

読み方

学び

まとめ

『ネットワークはなぜつながるのか』を読んだ

どんな本か

なぜ読んだか

学びや気付き

1. ブラウザが何をしているか

2. DNSが何をしているか

DNSサーバーに格納されているデータ

世界中のDNSサーバーが協調する仕組み

3. TCPでの接続の場合にプロトコルスタックが何をしているか

4. IPが何をしているか

5. イーサネットとは何か

6. インターネットとは何か

Q&Aメモ

まとめ

『コンピュータシステムの理論と実装 第2版』を読んだ

本書の構成

第1章 ブール論理

第2章 ブール算術

第3章 メモリ

学びメモ

第4章 機械語

機械語

メモリ

プロセッサ

レジスタ

Hackコンピュータのアーキテクチャ

アセンブラの役割

命令タイプ

外部デバイス

Hackプログラムの例

第5章 コンピュータアーキテクチャ

第6章 アセンブラ

シンボル処理

第7章 仮想マシンI：処理

HackプラットフォームのVMアーキテクチャとその利点

VM言語の設計

スタックマシンの挙動

push操作の例

pop操作の例

算術演算(add)の例

仮想メモリセグメント

VM変換器の動作例

第8章 仮想マシンII：制御

関数の呼び出し(call)

関数からのreturn(return)

第9章 高水準言語

第10章 コンパイラI：構文解析

第11章 コンパイラII：コード生成

シンボルテーブル

コンストラクタのコンパイル

第12章 OS

学び、得た経験

おわりに

『Goならわかるシステムプログラミング 第2版』を読んだ

第1章 Go言語で覗くシステムプログラミングの世界

第2章 低レベルアクセスへの入口1：io.Writer

第3章 低レベルアクセスへの入口1：io.Reader

エンディアン変換

ioパッケージのいくつかの関数 / 構造体 / インターフェースの使い方

第4章 チャネル

第5章 システムコール

CPUの動作モード

システムコールが必要な理由

第6章 TCPソケットとHTTPの実装

ソケットとは

ソケットの種類（本書で説明するもののみ）

ソケット通信の基本構造

Goに組み込まれているTCPの機能（net.Conn）だけを使ってHTTPによる通信を実現する

素朴な実装の速度改善

第7章 UDPソケットを使ったマルチキャスト通信

UDPとTCPの用途の違い

UDPのマルチキャストの実装例

UDPとTCPの機能面の違い

再送処理

『コンピュータシステムの理論と実装第2版』を読んだ

第1章ブール論理

第2章ブール算術

第3章メモリ

第4章機械語

第5章コンピュータアーキテクチャ

第6章アセンブラ

第7章仮想マシンI：処理

第8章仮想マシンII：制御

関数の呼び出し(`call`)

関数からのreturn(`return`)

第9章高水準言語

第10章コンパイラI：構文解析

第11章コンパイラII：コード生成

『Goならわかるシステムプログラミング第2版』を読んだ

第2章低レベルアクセスへの入口1：io.Writer

第3章低レベルアクセスへの入口1：io.Reader

`io`パッケージのいくつかの関数 / 構造体 / インターフェースの使い方

第4章チャネル

第5章システムコール

Goに組み込まれているTCPの機能（`net.Conn`）だけを使ってHTTPによる通信を実現する

第8章高速なUnixドメインソケット

第9章ファイルシステムの基礎とGo言語の標準パッケージ

`path/filepath`パッケージの関数たち

第10章ファイルシステムの最深部を扱うGo言語の関数

ファイルの変更監視（`syscall.Inotify`）

ファイルのメモリへのマッピング（`syscall.Mmap()`）

第11章コマンドシェル101

第12章プロセスの役割とGo言語による操作

第13章シグナルによるプロセス間の通信

第15章並行・並列処理の手法と設計のパターン

第17章実行ファイルが起動するまで