エントリーの編集
![loading...](https://b.st-hatena.com/f27c0b793148c4c51ce0d5c7a77dd5e10c208478/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/f27c0b793148c4c51ce0d5c7a77dd5e10c208478/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
2472212.html
アセンブラレベルでは、アドレスの指定方法が大きく分けて相対アドレスと絶対アドレスがあることは知っ... アセンブラレベルでは、アドレスの指定方法が大きく分けて相対アドレスと絶対アドレスがあることは知っていますか? プログラムが1000番地から1999番地にロードされることを期待していて、goto命令の飛び先が絶対アドレス指定で1500番地だとします。 リロケータブルでない場合、プログラムが2000番地から2999番地にロードされても飛び先は1500番地のまま調整されないので、1500番地に飛びます。が、1500番地にはプログラムが無い=何があるかは不定なので、その後どうなるかは不定=ほぼ暴走になります。 リロケータブルの場合、大抵は相対アドレス指定されているはずなので、2500番地に飛ぶことになり、ここにはプログラムがあるので正常に処理が続けられます。 飛び先だけでなく、作業用のメモリも同様にでたらめな所を参照することになるので、誤動作の原因となります。