私はあなたの本を読んで読んでいませんでした。そして、当時のアセンブラとリンカの歴史について、それが正しく話していることが大好きですが、ツールは今より良くなっています。
あなたはかなり正しいです。私は、いくつかの命令セットは、特定のものにする必要がなく、基本的には参照によって参照されているバージョンの近似バージョンを提供していることが、プログラムカウンタに適用されるいくつかのオフセットが、また、（可変長）命令でエンコードされた絶対アドレスを使用する方法や、ある場所（PC相対）からロードされたレジスタ、または即時のmovなどのアドレスにジャンプする方法もあります。この著者が示唆していることは、一度あなたがそのアドレスをハードコードすると、それは永遠に固定され、絶対的であり、リンカーはそれを再び変更することができないということです。
リンカが今日できることを実証するのに数秒しかかかりません。命令を変更したり、変更したり、すべての命令生成を行うアセンブラではなく、必要な命令を生成したりできます。あなたがアセンブラを持っているときでさえ、あなたはまだ立ち往生していませんが、アセンブラはすべてを行いません。例えば、アセンブラは、近くの場所のPC相対読み取りを行い、その場所はアセンブラとリンカに知られていますこのオブジェクトに含まれていないラベルのアドレスになる。アセンブラは、近くのすべてのCODEをレジスタに書き込んでレジスタにジャンプさせ、リンカがそのアドレスを埋めます。リンカは絶対アドレスのように見えますが、リンカがそれを再配置する可能性があり、使用されるバイナリ形式が、あるラベルのアドレスであることを示すことができます。
一部の命令セットでは、絶対アドレスを命令に入れることができ、リンク時にリンカが命令のその部分を満たすことができない本当の理由はありません。
私は唯一の問題の状況は、単に1つのオブジェクト内でラベルを解決してpc相対ジャンプを使用した場合ですが、どういうわけかツールチェーンはそのオブジェクトの一部を切り離して残り。それはちょうど悪いデザインです。 gnuツールが少なくともきわめてうまく処理する状況と、他の人がcan notを取ってbl命令でモードを変更できない理由がないので、アセンブラはあるラベルのblを同じモードにすると仮定しますプログラマがblxまたはbxを使用していないためです。リンカーは、ラベルが他のモードにあると判断した場合、到達可能なスペースを見つけることができれば、機能的には見えない同じモードでトランポリンをいくつか追加します（戻りアドレスは保存され、モードは変更され、宛先ラベル/アドレスに達する）。本当に涼しいと私はここにこれの例を掲載している。
問題は、リンカーがコーナーにペイントするスペースを見つけることができず、トランポリンを作ることができず、オブジェクトに挿入する必要のある命令がその命令セットのルール内でトランポリンを傾けることができず、リンカーは脱出する必要があります。私は、今日救済するための閾値は当時の閾値と大きく異なっていると思います。上のblケースでも、gnuリンカーや他の人たちは、ほんの数年前のほんの数年前のスマートではなかったが、それを直すのではなく、その状況で救済するだろう。私は腕の場合、同じモードに留まり、アドレス空間をあまりにも遠くに広げようとすると、それを直すのではなく救済すると思います。それだけでも簡単にその状況を修正することができます。
「再配置ビット」とは本が何を考えているかについて、より多くの文脈なしには言い難い。推測すると、アーキテクチャは絶対アドレスと相対アドレスに異なる命令エンコーディングを採用しています。そうであれば、プログラム内で相対オフセットが発生し、修正なしで任意のプログラムの再配置が可能になります。逆に、TOがオペレーティングシステム内のROMベクトルを絶対アドレス（「TO equ $ 1000」）で参照すると、絶対アドレス指定モードが適切である。 – doynax
これは非常に昔ながらの問題です。まあ、本は "アセンブラー、リンカーとローダー"と呼ばれていません。誰もがもう一度1パスのアセンブラを使用することはありません。それは、アセンブラが何をすることができるのかという深刻な限界であった60年代の重要なことでした。 –