アセンブリはまだ関連していますか？
プロジェクトのコーディングや管理に関して、アセンブリ言語と高水準言語の間に大きな違いはありますか？明らかに、他のほとんどの言語よりも特定の操作を実行するためにアセンブリ言語でより多くのステートメントが必要ですが、アセンブリ言語（特にx86/x64アセンブリ言語）に基づいてプロジェクトを実行する必要がある（または実行する必要がある）方法に影響する違いがあります。 ？
アセンブリ言語と他の言語の間で違いがある限り、これらの少なくともいくつかは他の言語にとっての利点であると推測するのは理にかなっているようです。誰かがアセンブリ言語の特定の欠点を指摘し、それらの欠点を軽減する方法を教えてください。
具体的な例の1つは、スタッフの空き状況です。経験豊富なアセンブリ言語プログラマを見つけるのに苦労した人はいますか？その場合、この問題を軽減するためにどのような手順を実行できますか？
はい-頻繁ではありません。
ある意味では、Assemblyは実際には機械語のプロキシにすぎません。したがって、アセンブリでは、より高水準の言語でできることなら何でも実行できます。
逆は常に当てはまるとは限りません。たとえば、数年前、私はARMのCPUに取り組みました。CPUは、カーネルモードからのみ使用できるグラフィックス状態を変更するためのファンキーなオペコードがありました。レベル言語、そしてそれらの状態を変更するためのLinuxカーネルドライバーの関数には、アセンブリが含まれていると思います。
80年代から90年代初頭から中期にかけてのマイクロプロセッサでは、非常に高速に実行する必要があるコードがある場合、熟練した人間がほとんどのCよりも最適化されたアセンブリを簡単に作成できるため、多くの場合、それをアセンブリで記述します。コンパイラが生成する可能性があります。初期のMacプログラムの中には完全にアセンブリで記述されたものもあり、当時としては驚くほど高速でした。プログラム全体をアセンブリで記述していなくても、組み込みアセンブリを介してCの内部ループを最適化するという私の役割は確かに行いました。
しかし、物事は1990年代半ばに変化し始めました。 CPUには、パイプライン処理や分岐予測などの機能が組み込まれ始めたため、最も効率的な命令の順序が常に人間に明らかであるとは限りませんでした。さらに悪いことに、最も効率的な順序は同じファミリのCPU間で異なりました。たとえば、PowerPCコンパイラは通常、G3、G4、およびG5シリーズ用のターゲットスイッチを提供していました。同じオブジェクトコードがそれらすべてで実行されますが、これらのシリーズの1つでより効率的に実行されます。
それ以降、特にx86、PowerPC、SPARCなどのアーキテクチャが複雑なCPUでは、命令の順序が徐々に複雑になっています。 （ARMはまだそのように非常に単純です）より少ないCPUサイクルを使用しますが、遅いメモリフェッチをトリガーします。最近の主要なコンパイラは、人間が合理的に実行できるよりもはるかに優れたCPU上のコードを最適化できます。
少なくとも15年間でアセンブリを作成する正当な理由は見つかりませんでした。 2011年の総会の主な用途は次のとおりです。
- デバッグ時に逆アセンブリダンプを読み取るため。
- ファンキーなグラフィックモードなど、非標準のCPU機能を扱う。
- コンパイラー書き込み-中間レベルの人間が読める形式を提供して、高水準言語を翻訳します。
アセンブリを使用せずに、マイクロコントローラーを「小さな組み込み」-車のアラームリモート、電話のバッテリーモニター、キーボードコントローラー、ファン速度レギュレーター用にプログラミングしてみてください。
国境が動く間、常に集会の余地があります。
15年前、自転車の走行距離計は機械式、電子レンジはアナログ回路、TVリモコンはデジタル回路、衛星TVチューナーはアセンブリ、電話のファームウェアはC、コンピュータアプレットはJavaでした。
7年前、電子レンジはデジタル回路であり、テレビのリモコンはアセンブリで記述され、テレビのセットトップボックスはCで記述され、携帯電話はJavaベースのUIを実行していました。
現在、自転車走行距離計はデジタル回路にあり、電子レンジはアセンブリでファームウェアを取得し、TVリモコンはCでファームウェアを取得し、TVセットトップボックスはJavaを実行し、携帯電話はLinuxを取得します。
今後7年間で賭けをしたいですか？より多くの技術がより高度な制御言語を取得するにつれて、Assemblyは新しい根拠を獲得し、それはそれらを得続けます。機械回路またはアナログ回路で今日行われていることを見てください。あなたは数年後にそこに集会を賭けることができます。あなたの光スイッチ？水道水？あなたのやかん？歯ブラシ？
Assemblyでプログラムされる新しいデバイス、アプライアンス、おもちゃ、日常生活のアイテムが常に存在します。
私はこれを主に、私が使用したアセンブラー（主にMASM、NASM、および（それほどではないが）TASM）に基づいています。 TASMの新しいバージョンの一部には、OOをサポートするためのいくつかの機能が（ありましたか？）ありましたが、私はそれらをあまり使用していません。コメントを付けようとはしていません。
まず、ほとんどの言語は、少なくともいくらかツリーのような構造に移行しています。オブジェクト指向であるか、オブジェクトベースであるか、または正確に何であるかにかかわらず、システムのさまざまな部分間の関係についてはかなり定義されています。システムの一部を偶発的な「干渉」から「保護」することはかなりありますが、他の部分は（必要に応じて通常は保護をバイパスできる場合でも）あります。対照的に、アセンブリ言語は比較的「フラット」です。システムのさまざまな部分にあるコード（およびデータ）間のほとんどの関係は、主にドキュメントによって確立され、命名規則はそれほどではありません。
この結果、多くの場合、コードを理想よりも密に結合する方がはるかに簡単です。アセンブリ言語の選択を始めるための要件（より高いパフォーマンス、より小さなサイズなど）は、多くの場合、これにも報います-承認されたインターフェイスをバイパスすることにより、多くの場合、より小さくてより速いコードを得ることができます（通常、多くはありません）あらゆる次元で優れています）。言語とツール自体は、あなたが行うこと（良いか悪いか）を制限するためにはるかに少ないことを行います。これは、問題を防ぐためにマネージャーにはるかに大きな負担をかけます。質的に異なるとは言えませんが、量的には異なります。つまり、経営陣は問題を回避するためにいずれかの方法で作業する必要がありますが、アセンブリ言語の場合、一般的には、何であるか、または何でないかについて、より多くの（そしてより厳しい）ガイドラインを必要とします。許容できる。
これを軽減することは、主により注意深いガイドライン、経験豊富なスタッフからのより多くのガイダンス、そしてより具体的で注意深く実施された命名規則の問題です。
スタッフの配置には問題があります。しかし、私が遭遇した問題は、主に私が期待したものではありませんでした。アセンブリ言語のコードに飛び込んで喜んでいる、「ファイタージョック」の性格が少しある人を見つけることは、かなり簡単でした。アセンブリ言語の使用経験がほとんどないにも関わらず、ほとんどがかなり合理的な仕事をしました。
私が遭遇した困難は、より多くの上級職員を見つけることでした-少なくともある程度の統制の下でプロジェクトを維持することができ、コードを合理的に維持するために必要なガイドラインを提供する（そして主に実施する）言語に完全に慣れていない人々保守可能で理解可能です。
振り返ってみると、私はその点で最大の問題のいくつかを引き起こした/引き起こしたかもしれません。私には、2つの問題の原因が見られます。まず、私が考えているプロジェクトの時までに、私はかなり長い間主にを高水準言語でコーディングし、アセンブリ言語onlyを使用していた最後の手段。そのため、私がそれを使用したとき、パフォーマンスを得るためのほぼすべての可能なトリックは、公正なゲームであるだけでなく、期待されていました。第二に、私が完全に（または主に）アセンブリ言語で記述されたいくつかのシステムに取り組んだとき、それはかなり鉄拳のプロジェクトマネージャーの下にありました。当時、私は比較的若かったし、率直に言って、彼らが物事を実行する方法に憤慨していたので、反対の傾向がありました。振り返ってみると、彼らがやっていることは本当に重要であり、彼らが古くて柔軟性がないからといって行われたのではありません（当時、私が当時どのように見ていたのかはかなりわかります）。
「もし車があれば、トラックはまだ関係があるのですか？」つまり、アセンブリはアプリケーションの範囲が非常に広いですが、高レベルのプログラミングほど広くはありません。これは、トラックが自動車よりもはるかに少ないのと同じです。
アルゴリズムの最適化などの分野では、プロセッサレジスタを直接使用して、画像/ビデオ処理アルゴリズムを改善できます。
暗号化などの分野でも同じように使用できます。
新しいアーキテクチャの新しいプロセッサ（Cellマイクロプロセッサがリリースされたときを思い出してください）では、必ずアセンブリでブートローダーなどを作成する必要がありました（古いプロセッサでも同様ですが、長期間使用されているプロセッサは非常に安定したグラウンドを備えており、改善が困難ですそれ）。
さらに多くの例が示される可能性があるため、会社が注力している分野によって異なりますが、会社がWeb /モバイル開発に専念している場合は、それを必要としない可能性が高くなりますが、会社がマイクロコントローラーに注力している場合は、組み込みシステムなどが必要になる可能性は非常に高いです。
スタッフの対応状況は状況によって異なりますが、インテル、クアルコムなどで尋ねた場合、彼らには大規模なアセンブリプログラマーリストが必要です（職場で「ここにトラック運転手は何人いますか？」あまり考えませんが、他の場所にないという意味ではありません。「このあたりに車の運転手は何人いますか？」.
私の意見では、開発プラットフォームとしてのアセンブリは日常的な使用には関係がないかもしれません。この意見の主な理由は、特定のプロセスから削除される計算能力の量と、同じ特定のプロセスを最適化するために必要な開発時間の量は、通常、時間とエネルギーの価値がないためです（これには特定の用語があります） ..それは人/時間か何かのように聞こえます..私が何を言っているかを知っている場合は編集してください..）上記の明白な例外がありますが、主流のプログラミングが行く限り、アセンブリは頻繁には使用されません。
これは言われています。アセンブリは、今日でもソフトウェアエンジニアリングの研究のコンテキストでプログラミングを学ぶときに関連性があり、低レベルのプログラミング言語がどのように感じられ、どのように動作するかを教えます。続けて、最近のクラスで使用するものの例を示します。私たちは、スタンリーウォーフォード（Pepperdine University USA）によって開発されたpep/8アセンブリと、そのオープンソースソフトウェア here を使用しています。主に、CPUを仮想化し、実行中にコードをステップ実行しながらメモリの内容を表示するために使用されます（学習、デバッグに非常に役立ちます）。
ですから、あなたの使用法に応じて、アセンブリは私の意見では関連があるかもしれませんし、そうでないかもしれません。