なぜ暗号化された短い識別子が低レベルのプログラミングでまだそれほど一般的であるのですか？
very命令/レジスタ名を短く保つための正当な理由がありました。これらの理由はもはや当てはまりませんが、低レベルのプログラミングでは短い不可解な名前が依然として非常に一般的です。
どうしてこれなの？古い習慣が壊れにくいからでしょうか、それとももっと良い理由がありますか？
例えば：
- Atmel ATMEGA32U2（2010？）：
TIFR1（の代わりにTimerCounter1InterruptFlag）、ICR1H（の代わりにInputCapture1High）、DDRB（DataDirectionPortBの代わり）など. - .NET CLR命令セット（2002）：
bge.s（の代わりにbranch-if-greater-or-equal.short）など.
長くて暗号化されていない名前は扱いやすいのではないですか？
回答および投票の際は、次の点を考慮してください。ここで提案されている考えられる説明の多くは高レベルのプログラミングに当てはまるequallyですが、コンセンサスは、概して、1つまたは2つの単語で構成される非暗号化の名前を使用することです（一般に理解されている頭字語は除外されます）。 。
また、あなたの主な議論が約紙の図の物理的なスペースである場合、これは絶対にアセンブリ言語またはCILには適用されないことを考慮してください。さらに、簡潔な名前が適合する図を示していただければ幸いですしかし、読みやすいものはダイアグラムを悪化させます。ファブレスの半導体会社での個人的な経験から、判読可能な名前はぴったり合い、結果として、図がより読みやすくなります。
中核となるものは、高水準言語とは対照的に低水準プログラミングとは異なりますこれにより、簡潔な不可解な名前が望ましい低レベルのプログラミングではなく高レベルのプログラミングですか？
ここには非常に多くの異なるアイデアがあります。 theの回答として既存の回答を受け入れることはできません。最初に、これには多くの要因が関係していると考えられます。次に、おそらく、どれが最も重要なものか知っているでしょう。
だからここに回答の要約がここに他の人によって投稿されました。私はこれをCWとして投稿しています。私の意図は、最終的にそれを受け入れ済みとしてマークすることです。何かを逃した場合は編集してください。それぞれの考えを言い換えて簡潔かつ明確に表現しようとしました。
では、なぜ暗号化された短い識別子が低レベルのプログラミングでそれほど一般的であるのでしょうか。
- それらの多くは、それぞれのドメインで非常に一般的であるため、非常に短い名前を使用する必要があります。これは学習曲線を悪化させますが、使用頻度を考えると価値のあるトレードオフです。
- 通常、smallの可能性のセットが存在するため、fixed（theプログラマーはセットに追加できません）。
- 読みやすさは習慣と実践の問題だからです。
branch-if-greater-than-or-equal.shortはbge.sよりも最初は読みやすくなりますが、一部の方法では状況が逆になります。 - 多くの場合、低レベル言語には優れたオートコンプリート機能を備えた強力なIDEが付属していないため、またはa/cが信頼できないためです。
- 大量の情報を識別子にパックすることが望ましい場合があり、高レベルの標準であっても、読み取り可能な名前は許容できないほど長くなるためです。
- これは、低レベルの環境が歴史的に見てきたものだからです。習慣を破るには意識的な努力が必要であり、古いやり方が好きな人を困らせる危険を冒し、価値があると正当化されなければなりません。確立された方法に固執することが「デフォルト」です。
- それらの多くは、回路図やデータシートなど、他の場所で作成されているためです。これらは、順番に、スペースの制約の影響を受けます。
- 物事に名前を付ける担当者は、読みやすさについてさえ考慮したことがなく、問題が発生していることに気づいていない、または怠惰なためです。
- 場合によっては、名前が一部のコンパイラによる中間表現としてのアセンブリ言語の使用など、データの交換のためのプロトコルの一部となっているためです。
- このスタイルは即座に低レベルとして認識され、マニアにとってクールに見えるからです。
個人的には、これらのいくつかは、新しく開発されたシステムがこの命名スタイルを選択する理由に実際には貢献していないと思いますが、このタイプの回答でいくつかのアイデアを除外するのは間違っていると感じました。
ソフトウェアがこれらの名前を使用する理由は、データシートがそれらの名前を使用するためです。そのレベルのコードは、データシートなしでは理解するのが非常に難しいため、検索できない変数名を作成することは非常に役に立ちません。
これは、なぜデータシートが短い名前を使用するかという問題を提起します。これはおそらく、25文字の識別子を入れる余地のない次のようなテーブルで名前を提示する必要があることが多いためです。
また、回路図、ピンダイアグラム、およびPCB=シルクスクリーンのようなものは、多くの場合、スペースのために非常に窮屈です。
ジップの法則
このテキストを見ると、単語の長さと使用頻度が一般に反比例していることがわかります。 it、a、but、you、andのように、非常に頻繁に使用される単語は非常に短く、 observe、comprehension、verbosityのように使用頻度は低くなります。この観測された周波数と長さの関係は Zipfの法則 と呼ばれます。
特定のマイクロプロセッサの命令セットに含まれる命令の数は、通常数十または数百です。たとえば、 Atmel AVR命令セット には約100の個別の命令が含まれているようです（数えませんでした）が、それらの多くは共通のテーマのバリエーションであり、非常に似たニーモニックを持っています。たとえば、乗算命令には、MUL、MULS、MULSU、FMUL、FMULS、およびFMULSUが含まれます。 「BR」で始まる命令が分岐である、「LD」で始まる命令がロードである、などの一般的な考えを得る前に、命令のリストを長い間見る必要はありません。同じことが変数にも当てはまります。複雑なプロセッサでさえ、値を格納するための限られた数の場所のみを提供します：条件レジスター、汎用レジスターなど。
命令が非常に少ないため、また、長い名前は読むのに時間がかかるため、短い名前を付けることは理にかなっています。対照的に、高水準言語では、プログラマーが膨大な数の関数、メソッド、クラス、変数などを作成できます。これらのそれぞれは、ほとんどのアセンブリ命令よりも使用頻度が低く、読者（およびライター）が何であり、何をしているのかを理解するのに十分な情報を提供するために、より長く、よりわかりやすい名前がますます重要になります。
さらに、異なるプロセッサの命令セットでは、同様の操作に同様の名前が使用されることがよくあります。ほとんどの命令セットには、ADD、MUL、SUB、LD、ST、BR、NOPの操作が含まれており、これらの正確な名前を使用しない場合、通常は非常に近い名前を使用します。 1つの命令セットのニーモニックを習得したら、他のデバイスの命令セットに適応するのに時間がかかりません。したがって、「暗号化」されているように見える可能性のある名前は、低レベルプログラミングの技術に長けているプログラマにとっては、and、or、notなどの単語と同じくらいおなじみです。 。アセンブリレベルで作業するほとんどの人は、コードを読むことを学ぶことは、低レベルのプログラミングにおける大きな課題の1つではないとあなたが言うと思います。
一般に
ネーミングの品質は、説明的な名前を持つことだけでなく、他の側面も考慮する必要があるため、次のような推奨事項につながります。
- スコープがグローバルであるほど、名前はわかりやすくなります
- 使用頻度が高いほど、名前を短くする必要があります
- 同じもののすべてのコンテキストで同じ名前を使用する必要があります
- コンテキストが異なる場合でも、異なるものは異なる名前を持つ必要があります
- 変動は簡単に検出できるはずです
- ...
これらの推奨は矛盾していることに注意してください。
命令ニーモニック
アセンブリ言語プログラマーとして、short-branch-if-greater-or-equalにbge.sを使用すると、ALGOLプログラマーがSUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTSの代わりにdx := p2.x - p1.xを使用して計算ジオメトリを実行するのと同じ印象が得られます。最初の方が私が関心を持っているコンテキストでより読みやすくなっていることに同意できません。
登録名
ドキュメントから公式名を選択します。ドキュメントは、デザインから名前を選択します。設計では多くのグラフィック形式を使用しており、長い名前では不十分であり、設計チームはそれらの名前を数年ではなくても数か月間使用します。どちらの理由からも、「最初のタイマーカウンターの割り込みフラグ」を使用せず、スキーマおよび発言時に略記します。彼らはそれを知っており、TIFR1のような体系的な略語を使用しているため、混乱する可能性が低くなります。ここでの1つのポイントは、TIFR1はランダムな省略形ではなく、命名方式の結果であるということです。
「古い習慣」の理由は別として、30年前に作成され、現在も使用されているレガシーコードは非常に一般的です。経験の浅い人が考えていることにもかかわらず、これらのシステムをリファクタリングして見栄えをよくすることは、わずかな利益のために非常に高いコストがかかり、商業的に実行可能ではありません。
ハードウェアに近く、レジスタにアクセスする組み込みシステムは、非常に正当な理由により、ハードウェアデータシートで使用されているものと同じまたは同様のラベルを使用する傾向があります。ハードウェアデータシートでレジスターがXYZZY1と呼ばれている場合、それを表す変数はXYZZY1である可能性が高いです。
bge.s、それはアセンブラーに似ています-それを知る必要がある少数の人々にとっては、長い名前は読みにくくなります。頭を回せない場合bge.sと考えるbranch-if-greater-or-equal.shortは違いをもたらします-あなたは単にCLRで遊んでいて、それを知らないだけです。
短い変数名が表示されるもう1つの理由は、ソフトウェアが対象としているドメイン内に略語が広まっているためです。
要約すると、業界の規範やハードウェアデータシートなどの外部の影響を反映する短い省略された変数名が期待されます。ソフトウェア内部の短い省略された変数名は、通常あまり望ましくありません。
私はこの混乱に私の帽子を投げます。
高レベルのコーディング規約と標準は、低レベルのコーディング標準と実践と同じではありません。残念ながら、それらのほとんどは、レガシーコードと古い思考プロセスからの引き継ぎです。
ただし、一部は目的を果たします。確かにBranchGreaterThanは[〜＃〜] bgt [〜＃〜]よりもはるかに読みやすくなりますが、今はそこに慣例があります。過去30年間の標準としての牽引力。なぜ彼らはそれから始めるのでしょうか、おそらく命令、変数などのいくつかの任意の文字幅制限です。なぜ彼らはそれを保つのですか、それは標準です。この標準は、識別子としてintを使用するのと同じですが、Integerすべてのケースで、数週間以上プログラミングをしている人には必要ですか...いいえ。どうして？それは標準的な習慣だからです。
第二に、私のコメントで述べたように、割り込みの多くはINTG1やその他の不可解な名前が付けられており、これらも目的を果たします。回路図では[〜＃〜] not [〜＃〜]線に名前を付けるのに適切な規則であり、そのように冗長であるため、図が乱雑になり、読みやすさが損なわれます。すべての冗長性はドキュメントで処理されます。また、すべての配線/回路図には割り込みラインのこれらの短い名前があるため、割り込み自体も同じ名前になり、回路図からプログラムまでのコードに至るまで、組込み設計者が一貫性を保つことができます。
設計者はこれをある程度制御できますが、他のフィールド/新しい言語と同様に、ハードウェアからハードウェアに至るまでの慣習があるため、各アセンブリ言語で同じように保つ必要があります。アセンブリのスニペットを見て、慣例に固執するため、その命令セットを使用せずにコードの要点を取得できます[〜＃〜] lda [〜＃〜]またはそれとのいくつかの関係はおそらくレジスタをロードすることです[〜＃〜] mv [〜＃〜]はおそらくどこかからどこかへ何かを移動しています、それはあなたが良いと思うものではありませんか高度な実践、それはそれ自体が言語であり、それ自体に独自の基準があり、設計者が従う必要があることを意味しますが、これらは見かけほど多くは恣意的ではありません。
私はあなたにこれを任せます：組み込みコミュニティに詳細な高レベルのプラクティスを使用するよう依頼することは、化学者に常に化学物質を書き出すように依頼することに似ています。化学者はそれらを自分たちのために短く書いており、フィールドの他の誰もがそれを理解しますが、新参者が調整するのに少し時間がかかる場合があります。
彼らが不可解な短い識別子を使用する理由の1つは、開発者にとって不可解ではないためです。あなたは彼らが毎日それで動作することを理解する必要があり、それらの名前は本当にドメイン名です。したがって、TIFR1が正確に何を意味するのかを彼らは心から知っています。
新しい開発者がチームに来た場合、彼はデータシート（@KarlBielefeldtで説明されている）を読まなければならないので、彼らはそれらに慣れるでしょう。
確かにあなたの質問は悪い例を使用していると思います。実際、この種のソースコードでは、通常、ドメイン以外のものに不要な暗号識別子がたくさん表示されるからです。
ほとんどの場合、コンパイラーが入力したすべてをオートコンプリートしなかったときに存在する悪い習慣が原因でそうなっていると思います。
概要
イニシャリズムは、多くの技術的および非技術的な分野で蔓延している現象です。そのため、低レベルのプログラミングに限定されません。一般的な議論については、Wikipediaの記事 Acronym を参照してください。私の答えは低レベルのプログラミングに固有です。
不可解な名前の原因：
- 低レベルの命令は強く型付けされています
- 大量の型情報を低レベルの命令の名前にパックする必要がある
- 歴史的には、タイプ情報のパッキングには単一文字コードが好まれていました。
ソリューションとその欠点：
- 歴史的なものよりも一貫性のある現代の低レベルの命名方式があります。
- LLVM
- ただし、多くのタイプ情報をパックする必要はまだあります。
- したがって、不可解な略語は依然として至る所にあります。
- 行から行への読みやすさの向上は、初心者の低レベルプログラマがより速く言語を理解するのに役立ちますが、低レベルのコードの大きな部分を理解するのには役立ちません。
完全な答え
（A）より長い名前が可能です。たとえば、C++ SSE2組み込み関数の名前は、アセンブリニーモニックの7文字と比較して平均12文字です。 http://msdn.Microsoft.com/en-us/library/c8c5hx3b（v = vs.80）.aspx
（B）次に、質問は次のように進みます。低レベルの命令から取得する必要があるのはどのくらい/非暗号化されていないのですか？
（C）次に、そのような命名方式の構成を分析します。以下は、same低レベル命令の2つの命名方式です。
- 命名スキーム＃1：_
CVTSI2SD_ - 命名スキーム＃2：
__m128d _mm_cvtsi32_sd (__m128d a, int b);
（C.1）低レベルの命令は常に強く型付けされます。あいまいさ、型推論、自動型変換、またはオーバーロード（命令名を再利用して、類似しているが同等ではない操作を意味する）はありません。
（C.2）各低レベル命令は、多くの型情報をその名前にエンコードする必要があります。情報の例：
- 建築家
- 操作
- 引数（入力）と出力
- タイプ（符号付き整数、符号なし整数、フロート）
- 精度（ビット幅）
（C.3）各情報を詳しく説明すると、プログラムはより冗長になります。
（C.4）さまざまなベンダーによって使用されているタイプエンコーディング方式には、長い歴史のルーツがありました。例として、x86命令セットでは：
- Bはバイト（8ビット）を意味します
- WはWord（16ビット）を意味します
- Dは、dwordの「ダブルワード」（32ビット）を意味します
- Qはqwordの「クワッドワード」（64ビット）を意味します
- DQは、dqword "double-quad-Word"（128ビット）を意味します
これらの歴史的参考文献には、現代的な意味はまったくありませんでしたが、まだ残っています。より一貫したスキームでは、ビット幅の値（8、16、32、64、128）を名前に含めます。
それどころか、LLVMは低レベルの命令の一貫性の方向への正しいステップです： http://llvm.org/docs/LangRef.html#functions
（D）命令の命名方式に関係なく、低レベルプログラムは実行の細部に焦点を当てているため、すでに冗長で理解しにくいものです。命令の命名体系を変更すると、行間レベルでの読みやすさが向上しますが、大きなコードの操作を理解する難しさは解消されません。
人間は時々アセンブリを読み書きしますが、ほとんどの場合それは単なる通信プロトコルです。つまり、コンパイラとアセンブラの間の中間のシリアル化されたテキストベースの表現として最もよく使用されます。この表現が冗長であるほど、このプロトコルでの不要なオーバーヘッドが多くなります。
オペコードとレジスタ名の場合、長い名前は実際には読みやすさに悪影響を及ぼします。短いニーモニックは、通信プロトコル（コンパイラとアセンブリの間）に適しています。ほとんどの場合、アセンブリ言語は通信プロトコルです。コンパイラー・コードが読みやすいため、短いニーモニックはプログラマーに適しています。
誰も怠惰について言及しておらず、他の科学についても議論されていないことに驚いています。プログラマーとしての私の毎日の仕事は、プログラム内のあらゆる種類の変数の命名規則が3つの異なる側面の影響を受けることを私に示しています。
- プログラマーの科学的背景。
- プログラマーのプログラミングスキル。
- プログラマーの環境。
低レベルまたは高レベルのプログラミングについて議論することは役に立たないと思います。最終的には、常に前の3つの側面に限定できます。
最初の側面の説明：多くの「プログラマ」はそもそもプログラマではありません。彼らは数学者、物理学者、生物学者、さらには心理学者や経済学者ですが、それらの多くはコンピューター科学者ではありません。それらのほとんどには、独自のドメイン固有のキーワードと略語があり、「規約」という名前で確認できます。彼らはしばしば彼らのドメインに閉じ込められ、読みやすさやコーディングガイドを考えずにそれらの既知の略語を使用します。
2番目の側面の説明：ほとんどのプログラマーはコンピューター科学者ではないため、プログラミングスキルは限られています。それが彼らがしばしばコーディング規約について気にしない理由ですが、最初の側面として述べたようにドメイン固有の規約についての詳細です。また、プログラマーのスキルがない場合は、コーディング規約を理解できません。彼らのほとんどは、理解しやすいコードを書く緊急の必要性を理解していないと思います。その火のように、忘れてください。
番目の側面の説明：サポートしなければならない古いコードである可能性のある環境の慣習、会社のコーディング基準（コーディングに関心がないエコノミストが運営）でブレーキをかけることはほとんどありません。またはあなたが属しているドメイン。誰かが不可解な名前を使い始め、あなたが彼または彼のコードをサポートしなければならない場合、不可解な名前を変更することはほとんどありません。あなたの会社にコーディング標準がない場合、ほぼすべてのプログラマーが独自の標準を作成することでしょう。そして最後に、ドメインユーザーに囲まれている場合は、使用している言語以外の言語を書き始めることはありません。
主に慣用的です。 @TMNが他の場所で言うように、あなたが書いていないのと同じようにimport JavaScriptObjectNotationまたはimport HypertextTransferProtocolLibrary Pythonでは、あなたはTimer1LowerHalf = 0xFFFF inC。それは文脈上同様にばかげています。知る必要がある人は誰でも知っています。
組み込みシステムの一部のCコンパイラベンダーが、組み込みプログラミングにより役立つ機能を実装するために言語標準および構文から逸脱しているという事実から、変更に対する抵抗が生じる可能性があります。これは、低レベルのコードを書くときに、お気に入りのIDEまたはテキストエディターのオートコンプリート機能を常に使用できるとは限らないことを意味します。これらのカスタマイズは、コードを分析する機能を無効にするためです。名前、マクロ、定数。
たとえば、HiTechのCコンパイラには、ユーザー指定のメモリ内の位置を必要とする変数の特別な構文が含まれていました。あなたは宣言するかもしれません：
volatile char MAGIC_REGISTER @ 0x7FFFABCD;
これでIDEこれを解析する唯一の存在はHiTech自身のIDE（HiTide）です。他のエディタでは、毎回メモリから手動で入力する必要がありますが、これはすぐに古くなります。
さらに、開発ツールを使用してレジスターを検査しているときに、いくつかの列（レジスター名、16進数の値、2進数の値、最後の16進数の値など）を含むテーブルが表示されることがよくあります。長い名前は、2つのレジスターの違いを確認するために名前の列を13文字に拡張し、繰り返される単語の数十行にわたって「違いを見つける」必要があることを意味します。
これらはばかげた小さな難しさのように聞こえるかもしれませんが、すべてのコーディング規約が目の疲れを減らし、余分なタイピングを減らし、または他の100万の小さな不満に対処するように設計されているわけではありませんか？