feat(blog/nuldoc): merge consecutive text nodes

1 files changed, 12 insertions, 12 deletions

diff --git a/vhosts/blog/public/posts/2025-05-05/make-tiny-self-hosted-c-compiler/index.html b/vhosts/blog/public/posts/2025-05-05/make-tiny-self-hosted-c-compiler/index.html
index 4b7b2a68..299d3f94 100644
--- a/vhosts/blog/public/posts/2025-05-05/make-tiny-self-hosted-c-compiler/index.html
+++ b/vhosts/blog/public/posts/2025-05-05/make-tiny-self-hosted-c-compiler/index.html
@@ -60,7 +60,7 @@
           <section id="section--intro">
             <h2><a href="#section--intro">はじめに</a></h2>
             <p>
-              C コンパイラと言えば、世界三大自作したいソフトウェアの一角である。 というわけで <a href="https://www.sigbus.info/compilerbook" rel="noreferrer" target="_blank">『低レイヤを知りたい人のためのCコンパイラ作成入門』</a> (以下 compilerbook) 片手に作ることにした。
+              C コンパイラと言えば、世界三大自作したいソフトウェアの一角である。というわけで <a href="https://www.sigbus.info/compilerbook" rel="noreferrer" target="_blank">『低レイヤを知りたい人のためのCコンパイラ作成入門』</a> (以下 compilerbook) 片手に作ることにした。
             </p>
             <p>
               実装する機能を適切に絞ってやればゴールデンウィークの間 (2025-05-03 から 2025-05-06) にセルフホストまで持っていけるのではないか？という仮説を立て、ISO 8601 の表記で 4日間を表す “P4D” を冠して P4Dcc と名付けた。
@@ -92,7 +92,7 @@
           <section id="section--design">
             <h2><a href="#section--design">設計</a></h2>
             <p>
-              ゴールデンウィークの4日間で終わらせたいので、実装する言語機能は最低限に絞ることが必要になる。 今回は次のような設計とした (compilerbook の設計を踏襲しているものは除く)。
+              ゴールデンウィークの4日間で終わらせたいので、実装する言語機能は最低限に絞ることが必要になる。今回は次のような設計とした (compilerbook の設計を踏襲しているものは除く)。
             </p>
             <ul>
               <li>
@@ -333,7 +333,7 @@
                 compilerbook のようなインクリメンタルな進め方を取らずに、最初から普通の言語処理系のような構成にしたのには理由がある。
               </p>
               <p>
-                それは、どのくらいの言語機能があればコンパイラを作るのに十分かをこの時点で見積もるためである。 開発を開始する前にも必要な言語機能にはあたりを付けていたが、実際にプロトタイプを作ってみて、これだけの機能セットがあれば足りるだろうという正確な TODO リストを作りたかった。 実際、このとき作ったチェックリストはこのあともほとんど変わっていない (大きな変化点は、配列型をサポートしないと決めたことくらいか)。
+                それは、どのくらいの言語機能があればコンパイラを作るのに十分かをこの時点で見積もるためである。開発を開始する前にも必要な言語機能にはあたりを付けていたが、実際にプロトタイプを作ってみて、これだけの機能セットがあれば足りるだろうという正確な TODO リストを作りたかった。実際、このとき作ったチェックリストはこのあともほとんど変わっていない (大きな変化点は、配列型をサポートしないと決めたことくらいか)。
               </p>
               <p>
                 このあとは、おおむね compilerbook に従って以下のように機能追加を続けた。
@@ -455,13 +455,13 @@
                 <code>&amp;</code>、<code>*</code>、<code>sizeof</code> あたりの実装が終わるとかなり C 言語らしくなっていき楽しい。
               </p>
               <p>
-                このあたりから、セルフホストに向けて逆方向からのアプローチも並行しておこなっている。 セルフホストするためには処理系のソースコードで使っている言語機能をすべて実装する必要があるわけだが、これまでは処理系が扱える機能を拡充していくという方向だった。この逆、つまり処理系のソースコードで使っている機能を減らすことでもセルフホストに近付いていく。
+                このあたりから、セルフホストに向けて逆方向からのアプローチも並行しておこなっている。セルフホストするためには処理系のソースコードで使っている言語機能をすべて実装する必要があるわけだが、これまでは処理系が扱える機能を拡充していくという方向だった。この逆、つまり処理系のソースコードで使っている機能を減らすことでもセルフホストに近付いていく。
               </p>
               <p>
-                例えば、このコンパイラは <code>typedef</code> をサポートしていないが、開発中ずっと <code>typedef</code> を使わないというのは面倒だ。 そこで、セルフホストがある程度現実的になるまでは構造体を <code>typedef</code> しておいて、途中のどこかで <code>typedef</code> を手で脱糖する。
+                例えば、このコンパイラは <code>typedef</code> をサポートしていないが、開発中ずっと <code>typedef</code> を使わないというのは面倒だ。そこで、セルフホストがある程度現実的になるまでは構造体を <code>typedef</code> しておいて、途中のどこかで <code>typedef</code> を手で脱糖する。
               </p>
               <p>
-                これらの作業をおこなうことで、処理系自身のソースコード <code>main.c</code> をパースしてバイナリを出力することができるようになった。 いわゆる第2世代のコンパイラである。この現時点ではまだ第2世代コンパイラは何もできない (何を与えてもクラッシュする)。
+                これらの作業をおこなうことで、処理系自身のソースコード <code>main.c</code> をパースしてバイナリを出力することができるようになった。いわゆる第2世代のコンパイラである。この現時点ではまだ第2世代コンパイラは何もできない (何を与えてもクラッシュする)。
               </p>
             </section>
             <section id="section--development--day3">
@@ -470,7 +470,7 @@
                 さて、第2世代コンパイラが手に入ったので、ここからは地獄のデバッグ作業が始まる。多段になっているために問題が起きている箇所の特定が難しい。
               </p>
               <p>
-                ……と考えていたのだが、実際のところデバッグは1時間ほどで終わってしまった。 修正したのは1点のみ。 なんのことはない、2日目終了時点でほとんど完成していたわけだ。
+                ……と考えていたのだが、実際のところデバッグは1時間ほどで終わってしまった。修正したのは1点のみ。なんのことはない、2日目終了時点でほとんど完成していたわけだ。
               </p>
               <p>
                 記念すべき (?) 最後のバグはこちら。
@@ -485,13 +485,13 @@
 <span class="line"><span style="color:#24292E"> }</span></span></code></pre>
               </div>
               <p>
-                メモリアドレスから参照先の値を得る際、その型によってロードする命令の種類を変える必要があるのだが、その切替をポインタ型でおこなっていた。 正しくは、そのポインタ型が指す型を元にして切り替えなければならない。
+                メモリアドレスから参照先の値を得る際、その型によってロードする命令の種類を変える必要があるのだが、その切替をポインタ型でおこなっていた。正しくは、そのポインタ型が指す型を元にして切り替えなければならない。
               </p>
               <p>
                 これを修正すると、第2世代コンパイラが第3世代コンパイラを出力できるようになり、その後も第N世代が第N+1世代を生成できるようになった。
               </p>
               <p>
-                あとは、第2世代のコンパイラがそれ以降のコンパイラとバイナリレベルで一致するかどうかを確かめればよい。 実際に調べてみると、ほとんどの場所が一致したもののどの世代も 6バイトだけ異なることがわかった。
+                あとは、第2世代のコンパイラがそれ以降のコンパイラとバイナリレベルで一致するかどうかを確かめればよい。実際に調べてみると、ほとんどの場所が一致したもののどの世代も 6バイトだけ異なることがわかった。
               </p>
               <p>
                 一体どこが異なるのか。<code>hexdump</code> の差分がこちら。
@@ -509,7 +509,7 @@
 <span class="line"><span> 00015e10  79 70 65 5f 6e 65 77 00  74 79 70 65 5f 6e 65 77  |ype_new.type_new|</span></span></code></pre>
               </div>
               <p>
-                <code>fatal_error</code>、<code>read_all</code>、<code>tokenize</code> <code>type_new</code> はいずれも <code>main.c</code> で定義された関数の名前である。 このことから考えると、これは GCC が埋め込んだシンボルテーブルである可能性が高い。 わずかに異なっている 6バイトは、ランダム生成された何かのように見える。
+                <code>fatal_error</code>、<code>read_all</code>、<code>tokenize</code> <code>type_new</code> はいずれも <code>main.c</code> で定義された関数の名前である。このことから考えると、これは GCC が埋め込んだシンボルテーブルである可能性が高い。わずかに異なっている 6バイトは、ランダム生成された何かのように見える。
               </p>
               <p>
                 そこで <code>gcc</code> に <code>-s</code> (シンボルテーブルを削除するフラグ) を渡してみると、めでたく2世代目以降のコンパイラのバイナリが完全に一致するようになった。
@@ -525,10 +525,10 @@
               最終的な実装は1900行ほど、所要時間は20時間弱となった。
             </p>
             <p>
-              正直なところ、思ったより早く終わって拍子抜けしている。 これは compilerbook がうまく実装順を整理しているのと、アセンブリの細かい落とし穴を事前に解説して潰していることが大きいと思われる。
+              正直なところ、思ったより早く終わって拍子抜けしている。これは compilerbook がうまく実装順を整理しているのと、アセンブリの細かい落とし穴を事前に解説して潰していることが大きいと思われる。
             </p>
             <p>
-              当初の仮説どおり、サポートする機能を慎重に選ぶことにより短期間でセルフホストまで持っていくことができた。 案外簡単に作れてしまうので、まとまった休みに是非いかがだろうか。
+              当初の仮説どおり、サポートする機能を慎重に選ぶことにより短期間でセルフホストまで持っていくことができた。案外簡単に作れてしまうので、まとまった休みに是非いかがだろうか。
             </p>
           </section>
         </div>