アセンブリ言語 利用

アセンブリ言語

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/10/19 10:04 UTC 版)

利用

歴史的観点

アセンブリ言語は、ごく単純なものまで含めれば、プログラム内蔵方式のコンピュータの最初期の1940年代から存在している。EDSAC (1949) の initial orders(現代の用語ではブートローダーに相当するもの)は、テープにパンチされた十進によるアドレスを、内部表現の二進に変換するなどの機能を持っていた(命令については、「1文字のニーモニック」に見えるかもしれないが、それは実際には同機の機械語そのものである)[20]ナサニエル・ロチェスターは1954年に IBM 701 用アセンブラを書いている。1955年、Stan Poley が IBM 650 用言語アセンブリSOAP (Symbolic Optimal Assembly Program) を開発した[21]

アセンブリ言語は、初期のコンピュータでプログラミングの入力ミス削減や時間短縮に貢献し、機械語コード参照やアドレス計算といった退屈な作業からプログラマを解放した。その後高水準言語へ移行していったが、ハードウェアの直接操作、特殊命令の使用、性能向上といった目的で今日でもアセンブリ言語が使われている。特にデバイスドライバ組み込みシステムリアルタイムシステムでよく使われている。

歴史的には多数のプログラムがアセンブリ言語だけで書かれてきた。ALGOLの方言であるESPOLで書かれた Burroughs MCP (1961) が登場するまで、オペレーティングシステムはアセンブリ言語で書くのが普通だった。商用アプリケーションもアセンブリ言語で書かれている。例えば、IBMメインフレーム用ソフトウェアの多くはアセンブリ言語で書かれていた。COBOLFORTRANPL/I などが取って代わっていったが、1990年代になってもアセンブリ言語のコードベースを保守し続けていた大企業も少なくない。

初期のマイクロコンピュータでは、アセンブリ言語がよく使われており、OSやアプリケーションもアセンブリ言語で書かれた。これは、リソースの制約が厳しく、メモリやディスプレイのアーキテクチャが特殊だったからである。また、マイクロコンピュータ向けの高水準言語のコンパイラがなかったという面も重要である。また、初期のマイクロコンピュータのユーザは趣味としての使用が主であり、何でも自前で作るという精神もそれに影響していたと見られる。

1980年代から1990年代にかけて、ホームコンピュータZX Spectrumコモドール64AmigaAtari ST など)でもアセンブリ言語がよく使われていた。というのもそれらのBASICは性能が低く、ハードウェアの全機能を利用できないことが多かったためである。例えば、Amigaにはフリーウェアのアセンブリ言語統合開発環境 ASM-One assembler があり、Microsoft Visual Studio に匹敵する機能を備えていた。

Don French が開発した VIC-20 用アセンブラは 1,639 バイトという小ささで、世界一小さいアセンブラと言われている。アドレスをシンボルで表現でき、各種アドレス計算(四則演算、AND、OR、冪乗など)が可能だった[22]

商用製品でアセンブリ言語を使う最大の理由は、使用メモリ量を最小にし、オーバーヘッドを最小にし、性能と信頼性を向上させるためである。1980年代のビジネスソフトでは、例えば表計算ソフト Lotus 1-2-3 などはアセンブリ言語で書かれていた。日本ではなどが該当[23]する。

1990年代に入っても、コンシューマーゲームの多くはアセンブリ言語でプログラムが書かれていた。しかしゲーム内容が複雑化し、プログラムの規模が増大するにつれて、アセンブラでは開発が困難となり、高水準言語による開発が主流となっていった。例えばプレイステーションではGCCが公式のSDKに含まれていて、標準の開発言語はC言語であった[24][25]。この時代のゲーム機は3次元コンピュータグラフィックスの積極的な導入が始まっており、ハードウェア性能も向上したことから、C言語による開発も十分可能となったが、コンパイラの最適化能力が未成熟だったこともあいまって、ハードウェア性能を最大限引き出すにはアセンブリ言語を駆使した手動最適化や細かなチューニングが必要となることも多かった。セガサターンの最高性能を引き出してプレイステーションに対抗するには、アセンブリ言語を使うしかなかったと述べていた業界関係者もいた[26]。ただし一方で、ファミコン時代すでにメタルスレイダーグローリースーパーファミコンMOTHER 2シムシティ[27]、プレイステーションのクラッシュ・バンディクー[28]、開発の一部にLISPが使われていたという話もあり、当時のコンシューマーゲームの分野ではアセンブリ言語やC言語が全てだったというわけではない。

2000年代初頭、マイクロソフトは原始的なプログラマブルシェーダーに対応したDirectX (Direct3D) 8.0をリリースした。このDirect3D 8.0におけるシェーダープログラムは、グラフィックスハードウェアに依存しない中間言語(バイトコード)を出力することのできるアセンブリ言語(シェーダーアセンブラ)を使用して記述するものだった。2001年には世界で初めてプログラマブルシェーダーに対応したコンシューマーゲーム機として初代Xboxが登場したが、このXboxに搭載されていたグラフィックスAPIもDirect3D 8.x相当のカスタマイズ版[29]であり、CPU上で実行するホストプログラム(ゲームアプリケーション本体のコード)はC++を使って記述する一方、GPU上で実行するシェーダープログラムの記述にはアセンブラを使用していた。のちにHLSLCg (C for Graphics) といった高水準シェーディング言語が開発され、HLSLに対応したDirect3D 9.0以降はシェーダープログラムも高水準言語を利用して記述するようになった。Direct3D 10のシェーダーモデル4.0以降は、シェーダーアセンブラではなくHLSLの使用が必須となっている[30]

ゲーム開発の分野に限った話ではないが、C++C#のような、Cよりもさらに高水準の言語が主流になってからも、コンパイラが出力したアセンブリコードを解析して最適化やチューニングの余地を探るといった手法は一般的に行なわれている[31]

現代における使用

アセンブリ言語と高水準言語を比較した有用性と性能についての議論は、これまでよく行われてきた。アセンブリ言語は、後述するように特定の用途で重要な役割を演じている。しかし、一般的には、最適化コンパイラは人手で書かれたアセンブリ言語のコードと同等の性能を発揮すると言われている[32](例外もある[33][34][35])。最近[いつ?]のプロセッサやメモリサブシステムは複雑化してきたため、コンパイラでもアセンブリ言語でも効果的な最適化がますます困難になってきている[36][37]。さらに言えば、プロセッサが高性能化するにしたがって入出力ページングによる遅延が無視できないレベルとなったため、コーディングによる性能追求は多くのプログラマにとって大きな問題ではなくなってきている。

開発者がアセンブリ言語を選択する状況として、次のようなものがある。

  • 限られた資源で単独で動作する小さな実行ファイルが必要とされ、高水準言語のランタイム環境やライブラリが使えない場合。アセンブリ言語を使う状況としては最も一般的である。例えば、電話機のファームウェア、自動車の燃料・点火システム、空調システム、セキュリティシステム、センサーなどがある。
  • デバイスドライバ割り込みハンドラブートコードBIOSPOSTなど、ハードウェアと直接やりとりするコード。
  • コンパイラでは実装されていないプロセッサ固有の命令を使わなければならないプログラム。例えば、暗号のencryptionとdecryptionに使われるビット単位ローテート命令などといった演算を使うためにアセンブリ言語を使用する。
  • コンパイラの最適化では不可能な、SIMD命令を駆使した最適化などを手作業で行いたい場合。
  • 極端な最適化を必要とするプログラム(例えば、プロセッサ集約型アルゴリズム内の内側のループなど)。例えば、コンピュータゲーム開発においては、システムのハードウェア機能を最大限に発揮するようアセンブリ言語を使うことがある。また大規模な科学シミュレーションでも高度に最適化されたアルゴリズムを必要とする。例えば、線型代数学BLAS[33][38]離散コサイン変換(例えばx264のSIMDアセンブリ版[39])がアセンブリ言語で書かれている。
  • 新たなプロセッサや特殊なプロセッサなど、高水準言語が存在しない場合。
  • 次のような正確なタイミングを必要とするプログラム。
  • 高度なセキュリティが要求され、環境を完全に制御する必要がある場合。
  • コンピュータウイルスブートローダ、一部のデバイスドライバなど、ハードウェアと密接に連携するソフトウェア。
  • 監視・トレース・デバッグのための命令セットシミュレータで、追加のオーバーヘッドを最小に保ちたい場合。
  • 次のようなリバースエンジニアリングまたはプログラムファイルの改造。この場合逆アセンブラが併用される。ただしリバースエンジニアリングが許可されていないものを解析・改造することは法律に抵触する場合がある。
    • ソースコードが失われた(または入手できない)バイナリファイルがあるとき、それを改造する場合。あるいはソフトウェアのコピープロテクトを(不正に)解除する場合。
      • 特にソースコードが公開されていないことが多い商用コンピュータゲームの改造。アセンブリ言語レベルでの改造がよく行われている。
  • 自己書き換えコード
  • グラフ電卓向けのソフトウェア開発[40]

なお一方で、最近[いつ?]のコンピュータの命令セットはその多くはどれも似ている。したがって、どれか1つのアセンブリ言語を学ぶだけで、基本概念、どんなときにアセンブリ言語を使用するのが適しているか、高水準言語から効率的な実行コードを生成する方法をある程度は学習できる[41]

より実践的には、コンパイラが生成したコードを確認したい場合といったようなものがある。コンパイラ最適化によって命令の置き換えや省略がされることもあり、高水準言語で書かれたソースコードをデバッグするだけでは原因がつかめない不具合が発生することもある。普段プログラムを記述するときは生産性や移植性を重視して高水準言語を使っていたとしても、プロセッサごとの命令セット仕様や低水準言語の知識も併せて持っているとデバッグの際に役立つ。普段は意識しないような場所であっても、何か理由があっていざという時には腑分けできるということは重要である。これは、たとえ日常の計算には電卓を使っていたとしても、筆算や暗算などを通じて四則演算の基本原則といった算数を学ぶ必要があることに似ている。また、生産性や移植性は劣るものの、高水準言語では不可能な機械語レベルの操作を直接記述することもできるため、「最適化の最後の手段」でもある。

高水準言語との連携

  • 高水準言語の処理系の呼出規約(言語処理系ではなくOSやハードウェアベンダ側で共通化している場合もある)に従うことで、高水準言語と相互にコードを呼び出すことができる。後述のインラインアセンブラなどにより同一のモジュールに埋め込むこともできれば、別モジュールとしてリンケージエディタでリンクすることもある。
  • 多くのコンパイラは、機械語を直接生成するのではなく、アセンブリ言語のコードを生成し、それをアセンブラに通している。人間によるデバッグや最適化などに便利である(機械による最適化には、内部表現を使ったほうが便利なので、あまり意味がない)。その意味ではアセンブリ言語は、目に見えない形ではあるが最も利用頻度の高いプログラミング言語といえるという主張もあるが、その意味では機械語が絶対的に最も利用頻度の高いプログラミング言語である。
  • インラインアセンブラのある言語ないし処理系では、ソース中にアセンブリ言語による記述を含めることができる。例えばLinuxカーネルではその利用が多い。アセンブリ言語と同様の利点が得られるかわりに、やはりアセンブリ言語と同様にプログラミング言語を使う利点(移植性など)が失われる。

  1. ^ IBMはSystem/360から2011年現在まで一貫してアセンブラ言語 (Assembler Language)と 呼んでいる。例:IBM High Level Assembler
  2. ^ MIPSのアセンブラの一部など、(分岐命令のターゲットアドレスの先頭にある機械語命令を対象として)その分岐命令の遅延スロットへの移動を(副作用がない場合に)アセンブラ疑似命令 (.set bopt) の指示に応じて行うものもある。OPTASM(SLR社)という最適化アセンブラもあった。
  1. ^ アセンブリ言語 - コトバンク
  2. ^ Stroustrup, Bjarne, The C++ Programming Language, Addison-Wesley, 1986, ISBN 0-201-12078-X: "C++ was primarily designed so that the author and his friends would not have to program in assembler, C, or various modern high-level languages." - assemblerassembly language の意味で使っている例
  3. ^ Saxon, James, and Plette, William, Programming the IBM 1401, Prentice-Hall, 1962, LoC 62-20615. - assembly program という用語を使っている例
  4. ^ a b David Salomon (1993). Assemblers and Loaders
  5. ^ bit 編集部 『bit 単語帳』共立出版、1990年8月15日、8頁。ISBN 4-320-02526-1 
  6. ^ J.DONOVAN, JOHN (1972). systems programming. pp. 59. ISBN 0-07-085175-1 
  7. ^ Beck, Leland L. (1996). “2”. System Software: An Introduction to Systems Programming. Addison Wesley 
  8. ^ a b c d Intel Architecture Software Developer’s Manual, Volume 2: Instruction Set Reference. INTEL CORPORATION. (1999). pp. 442 and 35. http://download.intel.com/design/PentiumII/manuals/24319102.PDF 2010年11月18日閲覧。 
  9. ^ Hyde, Randall. "Chapter 12 – Classes and Objects". The Art of Assembly Language, 2nd Edition. No Starch Press. © 2010.
  10. ^ (John Daintith, ed.) A Dictionary of Computing: "meta-assembler"
  11. ^ Intel Architecture Software Developer’s Manual, Volume 2: Instruction Set Reference. INTEL CORPORATION. (1999). http://download.intel.com/design/PentiumII/manuals/24319102.PDF 2010年11月18日閲覧。 
  12. ^ Evans, David (2006年). “x86 Assembly Guide”. University of Virginia. 2010年11月18日閲覧。
  13. ^ The SPARC Architecture Manual, Version 8”. SPARC, International (1992年). 2011年12月10日時点のオリジナル[リンク切れ]よりアーカイブ。2012年10月27日閲覧。
  14. ^ Z80 Op Codes for ZINT
  15. ^ Microsoft Corporation. “MASM: Directives & Pseudo-Opcodes”. 2011年3月19日閲覧。
  16. ^ Macros (C/C++) | Microsoft Docs
  17. ^ Concept 14 Macros”. MVS Software. 2009年5月25日閲覧。
  18. ^ Answers.com. “assembly language: Definition and Much More from Answers.com”. 2008年6月19日閲覧。
  19. ^ NESHLA: The High Level, Open Source, 6502 Assembler for the Nintendo Entertainment System
  20. ^ Salomon. Assemblers and Loaders. p. 7. http://www.davidsalomon.name/assem.advertis/asl.pdf 2012年1月17日閲覧。 
  21. ^ The IBM 650 Magnetic Drum Calculator”. 2012年1月17日閲覧。
  22. ^ Jim Lawless (2004年5月21日). “Speaking with Don French : The Man Behind the French Silk Assembler Tools”. 2008年8月21日時点のオリジナル[リンク切れ]よりアーカイブ。2008年7月25日閲覧。
  23. ^ 松 --- 事実上最初のパソコン用日本語ワープロソフト
  24. ^ Toolchain, libraries and headers relationship - PlayStation Development Network
  25. ^ What were PS1 and N64 games written in? : gamedev
  26. ^ SegaBase Volume 6 - Saturn”. Eidolon's Inn (2008年1月10日). 2014年7月2日時点のオリジナル[リンク切れ]よりアーカイブ。2013年6月27日閲覧。
  27. ^ Lispによるリターゲッタブルコードジェネレータの実装 (PDF) Archived 2008年8月20日, at the Wayback Machine.
  28. ^ OOエンジニアの輪! ~ 第 21 回 川合史朗 さんの巻 ~ | オブジェクトの広場
  29. ^ NVIDIA Xbox GPU Specs | TechPowerUp GPU Database
  30. ^ Using Shaders in Direct3D 10 - Win32 apps | Microsoft Docs
  31. ^ [CEDEC]「FINAL FANTASY XV」の最適化はこうして行われた - GamesIndustry.biz Japan Edition
  32. ^ Rusling, David A.. “The Linux Kernel”. 2012年3月11日閲覧。
  33. ^ a b Writing the Fastest Code, by Hand, for Fun: A Human Computer Keeps Speeding Up Chips”. New York Times, John Markoff (2005年11月28日). 2010年3月4日閲覧。
  34. ^ Bit-field-badness”. hardwarebug.org (2010年1月30日). 2010年2月5日時点のオリジナル[リンク切れ]よりアーカイブ。2010年3月4日閲覧。
  35. ^ GCC makes a mess”. hardwarebug.org (2009年5月13日). 2010年3月16日時点のオリジナル[リンク切れ]よりアーカイブ。2010年3月4日閲覧。
  36. ^ Randall Hyde. “The Great Debate”. 2008年6月16日時点のオリジナル[リンク切れ]よりアーカイブ。2008年7月3日閲覧。
  37. ^ Code sourcery fails again”. hardwarebug.org (2010年1月30日). 2010年4月2日時点のオリジナル[リンク切れ]よりアーカイブ。2010年3月4日閲覧。
  38. ^ BLAS Benchmark-August2008”. eigen.tuxfamily.org (2008年8月1日). 2010年3月4日閲覧。
  39. ^ x264.git/common/x86/dct-32.asm”. git.videolan.org (2010年9月29日). 2012年3月4日時点のオリジナル[リンク切れ]よりアーカイブ。2010年9月29日閲覧。
  40. ^ 68K Programming in Fargo II”. 2008年7月2日時点のオリジナル[リンク切れ]よりアーカイブ。2008年7月3日閲覧。
  41. ^ Hyde, Randall (1996年9月30日). “Foreword ("Why would anyone learn this stuff?"), op. cit.”. 2010年3月25日時点のオリジナル[リンク切れ]よりアーカイブ。2010年3月5日閲覧。
  42. ^ Randall Hyde. “Which Assembler is the Best?”. 2007年10月18日時点のオリジナル[リンク切れ]よりアーカイブ。2007年10月19日閲覧。






固有名詞の分類


英和和英テキスト翻訳>> Weblio翻訳
英語⇒日本語日本語⇒英語
  

辞書ショートカット

すべての辞書の索引

「アセンブリ言語」の関連用語

アセンブリ言語のお隣キーワード
検索ランキング

   

英語⇒日本語
日本語⇒英語
   



アセンブリ言語のページの著作権
Weblio 辞書 情報提供元は 参加元一覧 にて確認できます。

   
ウィキペディアウィキペディア
All text is available under the terms of the GNU Free Documentation License.
この記事は、ウィキペディアのアセンブリ言語 (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。 Weblio辞書に掲載されているウィキペディアの記事も、全てGNU Free Documentation Licenseの元に提供されております。

©2022 GRAS Group, Inc.RSS