タグ付けされた質問 「low-level」

「ビットマスク」がなぜこのように呼ばれるのですか？ 私はそれらが主にビット単位の操作に使用され、ビットマスクの使用が個別の変数の使用よりも効率的であることを知っています。 しかし、私の質問は、ビットマスクが発明された理由と時期です。初期のコンピューティング以来使用されていましたか？ITドメイン内にビットマスク以外のタイプの「マスク」はありますか？

79 terminology  efficiency  low-level  bitwise-operators 

以前は、命令/レジスタ名を短くする非常に良い理由がありました。これらの理由はもはや当てはまりませんが、低レベルのプログラミングでは依然として短い暗号名が非常に一般的です。 どうしてこれなの？古い習慣が破れにくいからといって、それとももっと良い理由があるのでしょうか？ 例えば： Atmel ATMEGA32U2（2010？）：（のTIFR1代わりにTimerCounter1InterruptFlag）、ICR1H（の代わりにInputCapture1High）、DDRB（の代わりにDataDirectionPortB）など。 .NET CLR命令セット（2002）：（のbge.s代わりにbranch-if-greater-or-equal.short）など。 長くて、暗号化されていない名前を使用する方が簡単ではありませんか？ 回答および投票する際は、以下を考慮してください。ここで提案されている説明の多くは高レベルのプログラミングにも同様に当てはまりますが、コンセンサスは概して、1つまたは2つの単語からなる非暗号化名を使用することです（一般に理解されている頭字語は除外されます）。 また、あなたの主な議論が紙の図の物理的な空間に関するものである場合、これはアセンブリ言語またはCILには絶対に適用されないことを考慮してください。さらに、簡潔な名前が収まるが読みやすいものが図を悪化させる図を見せていただければ幸いです。ファブレス半導体会社での個人的な経験から、読みやすい名前はうまく適合し、より読みやすい図になります。 高レベル言語ではなく、低レベルプログラミングで簡潔な名前を望ましいものにする高レベル言語とは異なる、中核となるものは何ですか？

64 naming  coding-standards  low-level 

アポロの任務には、電卓ほど複雑な技術はなかった。 こちらのリンクから、Apollo Guidance Computer（AGC）に関する情報があります。 オンボードのApollo Guidance Computer（AGC）は約1立方フィートで、2Kの16ビットRAMと36Kのハードコアコアロープメモリで、銅線は小さな磁気コアに通されているか、通されていません。16ビットワードは通常、14ビットのデータ（または2つのオペコード）、1符号ビット、1パリティビットでした。サイクルタイムは11.7マイクロ秒でした。プログラミングはアセンブリ言語と逆ポーランド語の解釈言語で行われました。 そのため、そこにあるものを調査したときにいくつかのソースコードに出くわし、素晴らしいコメントに気付きました（たとえば、TEMPORARY、I HOPE HOPE HOPE） VRTSTART TS WCHVERT # Page 801 CAF TWO # WCHPHASE = 2 ---> VERTICAL: P65,P66,P67 TS WCHPHOLD TS WCHPHASE TC BANKCALL # TEMPORARY, I HOPE HOPE HOPE CADR STOPRATE # TEMPORARY, I HOPE HOPE HOPE TC DOWNFLAG # PERMIT …

57 history  assembly  low-level  imperative-programming  space-technology 

return関数のステートメントで構造全体を返すのではなく、構造へのポインタを返すことの利点は何ですか？ 私はfopen他の低レベル関数のような関数について話しているが、おそらく構造体へのポインタを返す高レベル関数もあるだろう。 これは単なるプログラミングの質問ではなく、設計上の選択であり、2つの方法の長所と短所についてもっと知りたいと思っています。 構造体へのポインターを返すのが利点だと思った理由の1つは、ポインターを返すことで関数が失敗したかどうかをより簡単に判断できることNULLです。 完全な構造を返すのは、NULL私にとっては難しいか、効率が悪いでしょう。これは正当な理由ですか？

49 c  data-structures  functions  low-level  return-type 

予想外のことをせずに、この可能性を検討してほしい。現在、ほとんどのOSはかなり低レベルの言語（主にC / C ++）に基づいています。Androidなどの新しい言語でもJNIを使​​用しており、基礎となる実装はCで行われています 実際、（これは個人的な観察です）Cで書かれた多くのプログラムは、高レベルのものよりもはるかに高速に実行されます（例：Transmission（Ubuntuのbittorrentクライアント）は、Vuze（Java）またはDeluge（Python）よりもはるかに高速です）。PyPyは例外ですが、PythonコンパイラでさえCで書かれています。 これには特別な理由がありますか？優れた「OOP」の概念を備えたいわゆる「高レベル言語」がすべて、堅牢なOSの作成に使用できないのはなぜですか？ 基本的に2つの質問があります。 なぜ低レベル言語で記述されたアプリケーションは、HLLの対応言語よりも効率的ですか？低レベル言語は、低レベルであり、マシンコードへの翻訳が簡単であるという単純な理由により、パフォーマンスが向上しますか？ 完全に高レベル言語に基づいた本格的なOSがないのはなぜですか？

44 programming-languages  operating-systems  efficiency  low-level  high-level 

私は、コンピューティングシステムの要素：First Principlesから現代のコンピューターを構築するという本を読んでいます。これには、ブールゲートから高レベルのアプリケーションまで（その順序で）コンピューターを構築するプロジェクトが含まれています。私が取り組んでいる現在のプロジェクトは、HackアセンブリコードからHackマシンコードに変換するために、選択した高水準言語を使用してアセンブラーを作成しています（Hackは前の章で構築されたハードウェアプラットフォームの名前です）。ハードウェアはすべてシミュレーターで構築されていますが、実際のプロセスのその時点で使用可能なツールのみを使用して各レベルを実際に構築しているふりをしようとしました。 とはいえ、考えさせられました。高級言語を使用してアセンブラーを作成するのは確かに便利ですが、史上初めて記述されたアセンブラー（つまり、歴史上）にとっては、マシンコードで記述する必要はありませんでした。 そして、関連する質問...今日はどうですか？新しい命令セットと新しいアセンブリ構文を備えた新しいCPUアーキテクチャが登場した場合、アセンブラはどのように構築されますか？新しいプラットフォームのアセンブリ言語と機械語の両方の構文を知っている場合、アセンブラーを記述するタスクは実際には単なるテキスト分析タスクであり、本質的にそのプラットフォームに関連していません（つまり、そのプラットフォームの機械語で記述する必要があります）。私を助けるための高水準言語。

41 assembly  low-level 

私は最近いくつかのOpenJDKコードを参照していますが、ビット単位の操作に関係する興味深いコードを見つけました。StackOverflowで質問したこともあります。 ポイントを説明する別の例： 1141 public static int bitCount(int i) { 1142 // HD, Figure 5-2 1143 i = i - ((i >>> 1) & 0x55555555); 1144 i = (i & 0x33333333) + ((i >>> 2) & 0x33333333); 1145 i = (i + (i >>> 4)) & 0x0f0f0f0f; 1146 i = i …

34 low-level  bitwise-operators 

低レベルのものに関する知識が私たちの仕事において非常に重要であることは明らかです。 しかし、あなたはすでに高いレベルでの商用ソフトウェアを開発し、している状況にし、すでに選択した方向性を持っていますが、任意のアセンブリのスキルを持っていない、それはあなたの方向に関連するものを勉強に集中することがより合理的ではないでしょうか？または、とにかく低レベルの基本を学ぶために時間を費やす必要がある理由はありますか？ 遅すぎるときとそうでないとき そして手遅れではない場合、どのようにして最適な学習を行うのでしょうか（ある程度の深みと理解を得るために過度の時間を費やさないという意味で）？

33 assembly  low-level 

何年もの間、「低レベル」言語と考えるものを掘り下げることを考えてきました。私にとって、これはCとアセンブリを意味します。しかし、私はまだこれをする時間がありませんでしたし、これまで必要だったこともありません。 必要性が生じていないので、主題を勉強する予定のある時点をスケジュールするか、永遠に計画を破棄する必要があると感じています。 私の位置 過去4年間、私は変化する可能性のある「Webテクノロジー」に注力してきました。また、私はアプリケーション開発者であり、変化することはほとんどありません。 アプリケーション開発では、ユーザビリティが最も重要だと思います。ユーザーが「消費」するアプリケーションを作成します。これらのアプリケーションが使いやすくなればなるほど、より多くの価値を生み出します。 使い勝手を良くするために、次のことが実行可能であると信じています 優れた設計：よく考え抜かれたユーザーインターフェイスからアクセスできる、よく考えられた機能。 正しさ：正しく実装されていなければ、最高のデザインは価値がありません。 柔軟性：アプリケーションAは絶えず進化する必要があるため、ユーザーは、Aが実装できる新しい機能を備えた別のアプリケーションBに切り替える必要はありません。同じ問題に対処するアプリケーションは、機能ではなく哲学が異なるはずです。 パフォーマンス：パフォーマンスは、優れたユーザーエクスペリエンスに貢献します。アプリケーションは理想的には常に応答性が高く、（頻度に基づいて）合理的に高速にタスクを実行します。ユーザーが認識できる以上のパフォーマンス最適化の価値は疑問です。 パフォーマンスを除いて、低レベルのプログラミングはそれを助けてくれないと思います。しかし、パフォーマンスのために低レベル言語でアプリ全体を書くことは、私にとって時期尚早な最適化です。 私の質問 低レベルのプログラミングは何を教えてくれますか？他の言語は教えてくれませんか？アプリケーション開発にほとんど役に立たない何かが足りないのですか、それとも単なるスキルですか？私がCとアセンブリの価値に疑問を抱いていないことを理解してください。私の日常生活の中で、私はその世界の複雑さをすべて取り除いて、私のために管理していることを非常に嬉しく思っています（ほとんどがC / C ++で記述されたレイヤーとアセンブリ自体によって）。概念がまったく見当たらず、それは私にとっては新しいことかもしれませんが、頭に詰め込む必要のある詳細だけです。それで私にとっては何ですか？ 私の結論 回答ありがとうございます。誰も私を驚かせた人はいませんが、少なくとも今は、この必要な領域が必要になるまでこの領域を削除することを確信しています。 私の理解では、最近のプロセッサーが今日のCPUで使用されているときにアセンブリーを記述することは、不必要に複雑であるだけでなく、Cのカウンターパートよりも実行時のパフォーマンスが低下するリスクがあります。手作業による最適化はOOEによりほぼ不可能ですが、コンパイラーが自動的に実行できるすべての種類の最適化は得られません。また、使用可能なコマンドの小さなサブセットを使用するため、または最適化されているため、コードは移植可能ですが、おそらく1つのアーキテクチャでのみ動作します。 Cを書くことは、以前ほど必要ではなくなった。Cでアプリケーションを作成する場合、テストおよび確立されたライブラリとフレームワークを同様に使用します。これにより、文字列コピールーチン、ソートアルゴリズム、および大学での演習として役立つその他の種類の実装が不要になります。私自身のコードは、タイプセーフを犠牲にして高速に実行されます。私は通常のアプリ開発の過程で車輪を再発明することにも、コアダンプを見てデバッグしようとすることにも熱心ではありません：D 私は現在言語とインタプリタで実験しているので、何か公開したいことがあるなら、私は思うC ++がうまく機能するかもしれませんが、実用的な概念をCに移植します。 繰り返しますが、皆さんの回答と洞察に感謝します。

32 education  c  assembly  low-level 

または、言い換えると、自動化されたガベージコレクションはどのような特定の問題を解決しましたか？低レベルのプログラミングを行ったことがないので、リソースの解放がどれほど複雑になるかわかりません。 GCが対処する種類のバグは、（少なくとも外部の観察者にとっては）自分の言語、ライブラリ、概念、イディオムなどをよく知っているプログラマーがしないようなことのように見えます。しかし、私は間違っている可能性があります：手動メモリ処理は本質的に複雑ですか？

24 low-level  garbage-collection 

私はプログラミングにやや慣れていないので、この質問に答える最良の方法は例です。 JavaとC＃で基本的なことを行う方法を知っています。小さなウィンドウのようなものは、アプリケーションを形成するか、汎用クラスを作成します。私は基本的に学習してきましたが、まだ大きなことをしようとはしていません。とにかく、「フードの下で」物事がどのように行われるかについて、私はいつも興味がありました。 私はそれがすべて1と0に煮詰められ、アセンブリ言語が基本的に1と0のパターンにコマンドを与えることを知っていますが、そこからこのジャンプがあるようです：これにライブラリを使用してください ライブラリを使用せずにすべてのC＃でできることは、算術およびバイナリロジックです。入力または出力を取得するには、ライブラリなどを使用します... おそらくこの質問は一部の人には自明であり、学ぶべきことがたくさんあることは知っていますが、このような質問からどこから始めればよいかさえわかりません。ありがとうございました。 だから私の質問はこれです： 誰かが仮想マシンやプレイステーションエミュレーター、オペレーティングシステム、ドライバーを作成したり、メディアプレーヤーにmp3サポートを追加したり、独自のファイルタイプを作成したりした場合... C＃またはJavaでどのように行われるかわかりません。 言い換えると、WROXのProfessional C＃やOReillyのC＃のプログラミングのような本を読んだ場合、これらの方法を知っていますか？それとも、アセンブリ言語や、C ++のようなより低レベルのものを学ぶ必要がありますか？

20 c#  low-level  assembly  system  systems-programming 

プロセッサが命令を処理する方法についての一般的な考えはありますが、ほとんどの場合、高級言語で作業することに時間を費やしています。鉄の近くで働いている人が貴重な洞察を提供できるかもしれません。 プログラミング言語が基本的にプロセッサの命令セットの非常に高度な抽象化であると仮定すると、チューリング完全なマシンを作成するために必要な命令の最も基本的なセットは何ですか？ 注：ハードウェアアーキテクチャの多様性については何も知りませんが、簡単にするために、ALU（必要な場合）と命令スタックを備えた典型的なプロセッサであると仮定します。*

19 hardware  low-level  turing-completeness 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 TCP / IPを介してLEDディスプレイをリモートコントロールする作業を行うように連絡を受けましたが、私の経験と準備は主に高レベルのプログラミング言語に関するものです。私はそれについて仕事について私に連絡した人に言って、彼は私に言った： 「自分をプログラマと呼ぶなら、これらすべてを知っておくべきだ」 プログラマは、低レベルプログラミングの詳細を本当に知っているべきですか？または、低レベルのプログラミングは私の専門知識ではないことを念頭に置いて、それを理論的な知識としてブラックボックスの概念として扱うことができますが、必ずしもそれを実行したり、低レベルの言語ソリューションを実装したりする必要はありませんか？

18 low-level  high-level 

Cプログラムを作成して.exeファイルにコンパイルすると、ファイル.exeにはCPUへのrawマシン命令が含まれます。（おもう）。 その場合、最新バージョンのWindowsを実行するコンピューターでコンパイルされたファイルを実行するにはどうすればよいですか？CPUの各ファミリには、異なる命令セットがあります。それでは、適切なOSを実行するコンピューターが、.exe物理CPUに関係なく、ファイル内の命令を理解できるのはなぜでしょうか。 また、一部のアプリケーションの「ダウンロード」ページのWebサイトでは、Windows、Linux、およびMac用のダウンロードがあります（各OS、86および64ビットコンピューター用に多くの場合2回ダウンロード）。CPUファミリごとにダウンロードがこれほど多くないのはなぜですか？

16 low-level  cpu  machine-code 

新しいコードベースを見るとき、ボトムアップのアプローチから始めたいと思います。 1つのファイルを理解してから、次の抽象化に移動します。 しかし、多くの場合、低レベルの抽象化が行っていることを忘れています。 だから、私はこの時点で、私が以前完全に理解していたファイルに戻って、それらを再学習しようとするほぼ無限のループにいることに気付くでしょう。私の頭の中で互いに接続する他の多くの抽象化をジャグリングしようとしながら。 この状況に対処するためのより良い戦略はありますか？ 下位レベルの詳細を忘れて、それを当然のことと考えるべきですか？しかし、それでも、現在の抽象化が何をしているのかを理解するには、以前に低レベルの抽象化を理解しておく必要が何度もあります。

15 programming-practices  abstraction  strategy  low-level  high-level