アセンブリはまだ関連していますか？[閉まっている]

プロジェクトのコーディングや管理に関して、アセンブリ言語と高レベル言語の間に大きな違いはありますか？明らかに、他のほとんどの言語よりも特定の操作を実行するためにアセンブリ言語でより多くのステートメントが必要ですが、ターゲットアセンブリ言語（特にx86 / x64アセンブリ言語）に基づいてプロジェクトを実行する必要がある（またはする必要がある）方法に影響する違いがあります？

アセンブリ言語と他の言語との違いがある限り、これらの言語の少なくとも一部が他の言語の利点であると推測することは理にかなっています。アセンブリ言語の特定の欠点と、それらの欠点を軽減する方法を誰かが指摘できますか？

具体的な例の1つは、スタッフの空室状況です。経験豊富なアセンブリ言語プログラマを見つけるのに苦労した人はいますか？もしそうなら、この問題を軽減するためにどのような手順を踏むことができますか？

はい-しかし頻繁ではありません。

ある意味では、アセンブリは実際には機械語の単なるプロキシであるため、もちろん、より高いレベルの言語でできることはアセンブリで何でもできます。

その反対は常にそうではありません。たとえば、数年前、カーネルモードからしか使用できないグラフィックスの状態を変更するためのファンキーなオペコードを備えたARM CPUを開発しました。それらは、より高いレベルの言語では直接相当するものを持たず、これらの状態を変更するためのLinuxカーネルドライバーの機能には、いくつかのアセンブリが含まれていると確信しています。

80年代から90年代前半に戻ったマイクロプロセッサでは、非常に高速に実行する必要のあるコードがある場合は、アセンブリで記述することがよくあります。熟練した人間は、ほとんどのCコンパイラが生成できます。初期のMacプログラムの中には、完全にアセンブリで記述されたものもあり、その時代には驚くほど高速でした。プログラム全体をアセンブリで記述しなくても、組み込みアセンブリを介してCの内部ループを最適化するという共有を確かに行いました。

しかし、1990年代半ばに状況が変わり始めました。CPUにはパイプライン処理や分岐予測などの機能が含まれるようになったため、最も効率的な命令の順序は人間には必ずしも明らかではありませんでした。さらに悪いことに、最も効率的な順序付けは、同じファミリーのCPUによって異なりました。たとえば、PowerPCコンパイラは通常、G3、G4、およびG5シリーズのターゲットスイッチを提供していました。同じオブジェクトコードはそれらすべてで実行されますが、これらのシリーズのいずれかでより効率的に実行されます。

それ以降、特にx86、PowerPC、SPARCなどのアーキテクチャが複雑なCPUでは、命令の順序が次第に複雑になっています。（ARMはまだそのようにかなりシンプルだと思います。）大きな追加要因はコードサイズです。CPUサイクルをより多く使用するがCPUキャッシュに残せるコードは、CPUサイクルはより少ないがメモリフェッチが遅いコードよりもはるかに速く実行されることがよくあります。主要な最新のコンパイラーは、これらのCPUでコードを最適化するという、人間が合理的にできるよりもはるかに優れた仕事をすることができます。

少なくとも15年間、アセンブリを記述する正当な理由を見つけていません。2011年のアセンブリの主な用途は次のとおりだと思います。

• デバッグ時に逆アセンブリダンプを読み取ること。これは今日でも時々行います。
• ファンキーなグラフィックモードなど、非標準のCPU機能を処理します。
• コンパイラの作成-中間言語で人間が読める形式を提供して、高レベルの言語に翻訳します。

アセンブリを使用せずに、カーアラームリモコン、電話のバッテリーモニター、キーボードコントローラー、ファン速度レギュレーターなどの「小さな組み込み」用にマイクロコントローラーをプログラミングしてみてください。

境界線が移動する間、常に組み立ての余地があります。

15年前、自転車の走行距離計は機械式で、電子レンジはアナログ回路で、テレビのリモコンはデジタル回路で、衛星テレビチューナーはアセンブリで、電話のファームウェアはCで、コンピューターアプレットはJavaでした。

7年前、電子レンジはデジタル回路で、テレビのリモコンはアセンブリで書かれ、テレビのセットトップボックスはCで書かれ、携帯電話はJavaベースのUIを実行していました。

現在、自転車の走行距離計はデジタル回路で、電子レンジはアセンブリでファームウェアを取得し、テレビのリモコンはCでファームウェアを取得し、テレビのセットトップボックスはJavaを実行し、電話はLinuxを取得しました。

次の7年間に賭けたいですか？より多くの技術がより高度な制御言語を取得するにつれて、アセンブリは新たな基盤を獲得し、それらを取得し続けます。機械回路またはアナログ回路で今日行われていることを見てください。数年でそこにアセンブリを賭けることができます。あなたのライトスイッチ？あなたの水道は？やかん？あなたの歯ブラシ？

アセンブリでプログラムされる新しいデバイス、アプライアンス、玩具、日常生活用のアイテムが常にあります。

これは、主に私が使用したアセンブラー、主にMASM、NASM、および（程度は低いが）TASMに基づいています。TASMの後のバージョンのいくつかには、オブジェクト指向をサポートする機能がありました（ありましたか？）が、私はそれらをあまり使用しておらず、それらについてコメントしようとはしていません。

まず、ほとんどの言語は、少なくともややツリーのような構造に移行しています。オブジェクト指向であろうとオブジェクトベースであろうと、正確に何であろうと、システムの異なる部分間の関係についてはかなり定義されています。また、システムの一部を偶発的な「調整」以外の部分から「保護」することもかなりあります（保護は通常、必要に応じてバイパスできますが）。対照的に、アセンブリ言語は比較的「フラット」です。システムのさまざまな部分のコード（およびデータ）間の関係のほとんどは、主にドキュメントによって、あまり命名されていない命名規則によって確立されます。

この結果、多くの場合、理想よりもはるかに緊密にコードを結合する方がはるかに簡単です。最初にアセンブリ言語の選択を促した要件（より高いパフォーマンス、より小さなサイズなど）も、多くの場合、これに報います-承認済みのインターフェイスをバイパスすることにより、多くの場合、より小さく、より高速なコードを取得できます（通常はそれほど多くありませんが）あらゆる次元でより良い）。言語とツール自体は、あなたがすること（良いことも悪いことも）を制限するためにはるかに少ないです。質的に異なるとは言いませんが、量的には違います。つまり、管理者はどちらの方法でも問題を防ぐために努力する必要がありますが、アセンブリ言語の場合は、一般に、より多くの（そしてより厳しい）ガイドラインが必要です許容できます。

これを緩和するには、主に、より慎重なガイドライン、経験豊富な担当者からのより多くのガイダンス、およびより具体的で慎重に実施される命名規則の問題があります。

スタッフの配置は問題です。しかし、私が遭遇した問題は、主に私が期待したものではありませんでした。アセンブリ言語のコードに飛び込んで喜んでいる、「ファイタージョック」性格の人を見つけるのはかなり簡単でした。アセンブリ言語を使用した経験がほとんどないにもかかわらず、ほとんどはかなり合理的な仕事をしました。

私が遭遇した難しさは、プロジェクトを少なくともある程度の管理下に置くことができ、コードを合理的に維持するために必要なガイドラインを提供する（そして主に強制する）言語に完全に慣れていない上級者を見つけることでした保守可能で理解しやすい。

振り返ってみると、私はその点で最大の問題のいくつかを引き起こした/引き起こした可能性があります。私には2つの問題の原因があります。最初に、私が考えているプロジェクトの時までに、私はかなり長い間、主に高レベル言語でコーディングし、アセンブリ言語のみを使用していました最後の手段として。そのため、私がそれを使用したとき、パフォーマンスを得るためのほぼすべての可能なトリックは、公正なゲームであるだけでなく、期待されていました。第二に、完全に（または主に）アセンブリ言語で書かれたいくつかのシステムで作業していたとき、それはかなり鉄骨のプロジェクトマネージャーの下にありました。当時私は比較的若く、率直に言って彼らが物事を実行する方法に腹を立てていたので、反対をする傾向がありました。振り返ってみると、彼らが本当にやっていることは重要であり、彼らが古くて柔軟性に欠けるという理由だけで行われたのではありません（当時、私は物事をどのように見ていたかは確かです）。

私の意見では、開発プラットフォームとしてのアセンブリは日常の使用には関係ないかもしれません。この意見の主な理由は、特定のプロセスから削除される計算能力の量と、同じ特定のプロセスを最適化するのに必要な開発時間の量は、通常、時間とエネルギーの価値がないためです（これには特定の用語があります..それは人/時間または何かのように聞こえます。私の話を知っていれば編集してください..）上記の明らかな例外がありますが、主流のプログラミングに関しては、アセンブリはあまり使用されません。

これは言われています。アセンブリは、ソフトウェアエンジニアリング研究のコンテキストでプログラミングを学習する際に、今日でも関連性があります。続けて、最近の授業で使用するものの例を挙げます。Stanley Warford（Pepperdine University USA）によって開発されたpep / 8アセンブリと、ここに記載されているオープンソースソフトウェアを使用します。主に使用されるのは、CPUを仮想化し、実行中にコードをステップ実行しながらメモリの内容を表示するためです（学習、デバッグに非常に役立ちます）。

私の意見では、アセンブリは用途に応じて関連する場合と関連しない場合があります。

「私たちが車を持っているなら、トラックはまだ関係があるのですか？」とあなたは尋ねていると思います。つまり、アセンブリには非常に幅広い用途がありますが、高レベルのプログラミングほど広くはありません。これは、トラックが車よりもはるかに少ないことと同じです。

アルゴリズムの最適化などの分野では、画像/ビデオ処理アルゴリズムを改善するためにプロセッサレジスタを直接使用できます。

暗号化などの分野では、同じように使用できます。

新しいアーキテクチャを備えた新しいプロセッサ（Cellマイクロプロセッサがリリースされたときを思い出してください）では、確実にアセンブリでブートローダーなどを記述する必要がありました（古いプロセッサも同様ですが、長時間使用されるプロセッサは非常に安定した基盤を持ち、改善が困難です）それ）。

さらに多くの例を挙げることができるので、あなたの会社が焦点を当てている分野に依存します。もしあなたの会社がウェブ/モバイル開発に専念しているなら、あなたはそれを必要としないでしょう。組み込みシステムなどは、あなたがそれを必要とする可能性が非常に高いです。

スタッフの空き状況は、QualcommのIntelで尋ねる場合、彼らが大規模なアセンブリプログラマーのリストを持っている必要があると思います（職場で「この辺りにトラックドライバーは何人いますか？」あまり考えていませんが、他の場所にいないという意味ではありません。「この辺りに車のドライバーは何人いますか？」

アセンブリを学ぶことが最善の策である理由を本当に知りたい場合。ここに理由があります。

1. Visual BasicおよびそのMSのプログラミングを行う場合は、アセンブリを学ぶ必要はありません。
2. 本格的なマイクロコントローラガジェットを作成する必要がない場合は、アセンブリを学ぶ必要はありません。
3. マイクロコントローラでの作業中に自由にメモリを使用できる場合、アセンブリを学習する必要はありません（メモリをマイクロコントローラに接続する際に役立ちます）
4. あなたがマイクロコントローラ/マイクロプロセッサを介して神のような力を望まない場合、アセンブリを学ぶ必要はありません。
5. アセンブリを知らないことは、氷山を知ることに似ています。あなたのものとあなたのマイクロ能力の25％を見ることができ、75％は決して知ることも理解することもありません
6. 完全にアセンブリで書かれたKolibris OSを実行してみてください!!! 5秒未満で起動し、1秒のマウスクリックでアプリケーションの実行を開始するOSを見ましたか。
7. 最新のコンパイラは、バックエンドに汎用機能を備えているため、生成される最終コードはアセンブリに比べて非常に大きくなります。

集会はアベンジャーズのナターシャ・ロマノフのようなものです。それは魅力と魔法です。最初に、それはあなたを噛みますが、味を決して忘れないだろうと私を信じてください。