★アセンブリ言語とＣ言語、どちらが簡単ですか？

見た目にもカラフルだし、閲覧し易いライトな感じのページですね。

　ダミーＵＲＬってトコロはちょいと残念です。

　組み込みのＯＳのようなものでも、端から端まで全てアセンブリ言語で書く事例は近代的ではないような気がします。でも確かにＯＳの中の一番低レベルな部分はアセンブリ言語の方が簡単(と言うか高級言語では本質的に記述できない)な部分もありますね。

　ところで、waooooooさんのおっしゃるアセンブリ言語が適するロボットって、どんな種類のものでしょう？一口にロボットと言っても非常に幅広いですよね？＞再回答は遠慮なさらずに！

　ドイツ語(？)はキツイっすね。(そう言えば私以前にドイツの職業プログラマさんと協業したこともありましたっけ)

　２番目に紹介頂いたＵＲＬのLeDAさんの発言、的を射てますね。私もそんな風に思います。

＞個人的には・・・算数や数学と同じような記法が使えるＣの方が直感的と思います。

　…とのことですが、信号処理分野のツールには「代数表記アセンブラ」なんてものも存在しています。私にとっては却って難しくなっちゃいますけれども。

　「どこの個所がおかしいのかが分からないというのを…」聞きますね。取り敢えず若い者には「コンパイラの気持ちになって考えてみろ」と諭したりします。

　「掲示板C言語クイズ」面白いですね。

　気の利いたコンパイラなら、「defualt:ラベルはどのgotoからも参照されていない」とか警告を出してくれても良さそうですが。

　…ん？　switch文の外から中へgotoって一般的には出来るのかな？(一般的にそんなコーディングする奴はいないと思うけれど、その辺のコンパイラに喰わせたら無難なコードが出てくるのかな？)

　プログラマとして言語処理ツールを使う立場ではなくて、言語処理系を作るほうの身になって考える…と言う回答がやっと出ましたね。

　アセンブリ言語処理系だとしても、２〜３日では、個人的に使うと言う意味でさえ実用になるレベルのものは私には実装出来ないと思います。

　Ｃ言語処理系を実装するよりはアセンブリ言語処理系を実装するほうが簡単だと言われると、直感的にはうなづいてしまいそうになります。

　条件が揃っていた場合はアセンブリ言語処理系を作る方が簡単な気が、確かにします。

　…でも揃うべき条件って何だろう？

　完全な言語仕様が与えられていること？

　Ｃ言語でなら処理系依存とされる項目の詳細であり、アセンブリ言語処理系であれば擬似命令の類…？　ターゲット・プロセッサのためのアセンブリ言語処理系が既存でなければ、Ｃ言語処理系の実装に着手する気にはならないだろうから、それも条件の１つかな…。

　簡単に考えるために、関連ツール(Ｃ言語のプリプロセッサなど)の存在は無視するとします。

　Ｃコンパイラ本体とアセンブラ本体とで考えたとき、どちらも入力はプレーンテキストのファイルと考えられるけれども、Ｃコンパイラの出力がプレーンテキスト(アセンブリ言語ソースコード)で良いのに対してアセンブラの出力はリロケータブル・オブジェクト(多分ややこしい形式のバイナリファイル)と考えられたりして、この点ではアセンブラのほうが敷居が高そうです。

　お手本になるソースコードの入手／調達を考えたときも、Ｃコンパイラのお手本のほうがずっと幅広く手に入りそうな気がします。

　突き詰めて考えてみるとどっちも同じくらい難しいかも知れませんね。

※紹介して頂いたkmyacc。今は特に用事がありませんが、何かの時に思い出すかも知れません。

＞と書き殴って逃げます。さささっ((((((( ；^-^)

　ナイス回答だと思います。

　この一文が秀逸ですよね！？

　Ｃ言語は、書いててどのようなアセンブラに展開されるか何となく想像がつきます。

　Ｃ＋＋言語は、書いててどのようなＣソースに展開されるか何となく想像がつきます。

　でも、Ｃ＋＋言語⇒アセンブラはストレートには想像しないですね。

　MASMは強力なツールでしたね。(Ver.3.1に標準でついてましたっけ？　拡張機能セットとかではなかったでしたっけ？　それともPC/AT用のＤＯＳの話？)

　但し私は実は、MASMでなくてOPT-ASMなるツールを愛用していました。(TomCatさんならOPT-ASMもご存知そうですね？)

　但し私はアセンブリ言語ツールとしてではなくて、汎用バイナリ・ファイル作成ツールとして使うことが殆どでした。（アセンブラ使って書いた実用のＤＯＳプログラムは多分１本きりと記憶しています。PC-9801用のＴＳＲでした。）

　実は私は組み込みの職業プログラマでして、「あれ？　最近俺達別世界にいない？」と言うのはあまり身に覚えがなかったりします。

　２１世紀になった今日でも、Ｃ言語とアセンブリ言語のミックスランゲージが主です。

　ターゲット・ハードウェアは原則的に毎回違いますし、ターゲット・プロセッサも様々です。

　「アセンブリ言語で書いて苦にならない程度の処理なら、アセンブリ言語の方が楽しく分かりやすく簡単です」とのことですが、職業プログラマとしては「Ｃ言語で(色々な意味で)間に合うなら、なるべくＣ言語で書いておこう」と思うのです。

　まぁ簡単かどうかとはチト違いますが。

【そろそろ就寝します。続きは(あれば)明晩オープンしま〜す。】

　ご紹介頂いたＵＲＬのコンテンツ、「最適化のためのアセンブラ入門」と言う表題に名前負けしてますよ！？

　…と思って「トップ」のページへのリンクを辿ったら、「Windows で C のインラインアセンブラを使ったプログラミングが出来るようになることを…」と断ってましたね。

　賜ったご意見「Ｃだって、アセンブラ判れば、理解しやすいし」は、概ね分かります。

　私の質問に対する答えとして「アセンブラがわかればＣは簡単」と言う意味に(勝手に)解釈致します。

　魂の入ったご回答、楽しかったです。

　「ボロボロになってセロハンテープで補修された私の先生」…いいですねぇ。

　私にも、そう言う一冊があります。ＢＡＳＩＣですけれども。

　組み込みをやっておると、コンパイラの生成した機械語と向き合う必要があるときは確かにありますね。

　現在のルネサス(http://japan.renesas.com/homepage.jsp)のコンパイラの最適化の度量に関して、個人的には高く評価しています。

　別にルネサスのに限った事ではないですが、最適化がかかっちゃった部分が向き合う必要のある部分になったとき、最適化が優秀過ぎて困るぅと悲鳴を上げちゃうときもありますね。

＞Ｃは真意が伝わっていなくても(間違っていても)取り敢えず

＞コードが生成されてしまうので、表面上はＯＫですから

　表面上はＯＫだけど、よ〜く見たら「Ｃコンパイラが生成したアセンブリ言語ソースが、アセンブラによって警告を受けていた」と言う事態を経験したことがあります。

　プログラマ(＝高級言語ユーザー)の通常の期待としては、コンパイラはターゲット・プロセッサの内部詳細を知り尽くして最適な機械語の組み合わせを生成する筈なので、そんな警告は普通は表示しない訳なのですが…。

　コンパイラの噴出した野心的なニーモニックの組み合わせ(＝並みのアセンブリ言語プログラマなら無意識に別な組み合わせにするような)について、それが本当に大丈夫かどうか、顧客に説明を求められて窮しました。

※タイポ(typo)と言う用語を覚えました！

　直球な回答ですね！

　筆頭のＵＲＬがlzhっ。

　速くするのも小さくするのも一般的には高級言語のほうが簡単…だと、私は思います。

　究極を求める場合は機械語と直接向き合うアセンブリ言語のほうが可能性は残りますが、それは簡単な領域では明らかにないです。

　HELLO.COMは確かに小さいですが、AH=9, INT 21H(多分)の向こう側をリンクしていないからですし、現実的なボリュームの機能を持ったプログラムを速く／小さくするのであれば、高級言語のほうが簡単かとやっぱり思うのです。

（おっしゃる通り、現実解は「いいとこ取り」だと思います。

※最短Hello World!案(笑)：HELLO.bat(21 byte CR+LF EOF付)

@echo Hello World!

　構造化アセンブリ言語と言うのは以前に存在していましたが、オブジェクト指向アセンブラと言うのはそう言えば聞いたことがありませんね。

　総称プログラミング(template<>的なこと)は、大抵のアセンブリ言語でマクロと言う形でサポートされていますね。

　オブジェクト指向は、言語処理系によるサポートがなくても表現可能な筈ですが、嬉しいことは起きないでしょうね。

　…って、アセンブリ言語＆Ｃ言語の話題じゃないじゃん。

【そろそろ出社します。続きは(あれば)今晩オープンしま〜す。】

　えぇと。最初に断っておきますが、私はneoneatさんのコメントに賛成です。

　開発時の効率で考えても、実行時の効率で考えても、保守時の効率で考えても、概ね全ての局面で、現実的に、アセンブリ言語よりはＣ言語のほうが効率的だと思います。

　資源がタイトで制約の多い組み込みの現場に身を置いていてさえ、心からそう思います。

　下記の否定的にも読めるコメントは、ネット上や最近の書籍で出回っている情報内容の一般的な実情についての、私の個人的な感想です。

　ご紹介頂いたＵＲＬの先のコンテンツ(全部は読んでいません、最初のページと目次を眺めた程度です)もそうですが、世間一般ではアセンブリ言語についての理解がとても貧しくなっているなぁ…と思います。

　アセンブラ(アセンブリ言語ツール)にプログラマが期待するべき機能の要(かなめ)は、１対１に対応するニーモニック⇒機械語の変換ではないと思います。

　その程度のことだけが出来れば良いのであれば、ＰＣ用でも数千円から数万円するような高価なソフトウェアのライセンスを購入するプログラマは滅多にいないと思います。（最近はアセンブリ言語ツールが単体で製品になっているのを見かけない気がするのは置いといて）

　そんな単純なツールで良ければ、コンピュータの使い方を熟知しているであろうアセンブリ言語を使おうとするほどのプログラマなら、自分で作ることを検討しますよ、多分。

　ニーモニック⇒機械語の変換程度はそれほど難しくないとして(※実際に作ろうとすると、これとてたっぷり２〜３日はかかる程度には難しいですが)、それ以外にアセンブラに期待するべきことは、例えば次のようでしょうか？

・アドレスや数値を、ラベル乃至はシンボルとして抽象化すること

・ユーザ定義シンボルのうち少なくともグローバルラベルを、リンカ／ライブラリアン／デバッガ等に引き渡せるようにすること

・アドレスの計算（所謂ショートジャンプ系の命令の分岐先が分岐可能な範囲に収まっているかどうかの確認、相対分岐命令の分岐先をラベルで記述出来るようにすること、コードもデータも配置しない「空間」を空けること、など）

・外部参照などの未解決ラベルの類を未解決のまま保留にしてリンカに委ねられるようにすること（これが出来ないと全部のソースが揃わないと機械語に変換することを試すことも不自由になる⇒分業できない！）

・最終的・物理的にはかけ離れた場所に配置する予定のデータやコードであっても、論理的なまとまり毎にソースコード上１箇所に記述出来るようにする（セクションとかセグメントとか）

　…(はぁはぁぜぃぜぃ)。こーゆー事柄への理解や敬意をすっ飛ばしてアセンブラを語るなよと言ったら言い過ぎかも知れませんが、せめてアセンブリ言語とディスアセンブルされた機械語やニーモニックの羅列とはきっちり区別するところから説明を始めて欲しいなぁ…と思うのです。

　そうであってくれないと、若い奴らが正しい方向に育ちにくくなると思うので。

（あぁ、年寄りの戯言ですね。ニーモニックの羅列のことをアセンブラと呼ぶのが通りが良いのは分かります。「…と言うのが技術的に正しい用語の意味ですが、通りが良いこともありますし、本稿ではニーモニックの羅列のことをアセンブラと呼びます。」とかが１ページ目の締めくくりの文章だったら安心して読めるかも知れないのになぁ）

　ドライバーとナイフほどは違わないと思いますけれど。

　言語を何かに喩えるなら、私はこれが好きです。⇒http://www.page.sannet.ne.jp/mnagai/msj/pgm_lang.htm

　確かに。

　先生を探すことについて考えると、圧倒的にＣ言語のほうが簡単ですね。

　同じ視点で、Ｃ言語とＣ＋＋言語とだったらどうでしょうか？⇒http://www.hatena.ne.jp/1140102271

※ダミーＵＲＬは残念です。

　お答えは、一般的な見解だと思います。

　出来ればダミーでないＵＲＬを紹介して下されば嬉しかったのですが。

　Ｃ言語を知っていれば、Ｃ＋＋やＪａｖａに応用可能と言うコメントについては、にわかには同意しづらいですね。

　自分の経験では、ＢＡＳＩＣからＣに移行した時の苦労を１として、ＣからＣ＋＋に移行した時の苦労は５〜１０ありました。

【苦労と言うのはある意味嘘で、どちらも刺激に満ちた楽しい体験でしたが。】

　枝葉の構文が似ている(構文を似せる)ことは、言語の提供側には実際にもの凄く重要な意味があると思いますが、言語ユーザ(プログラマ)にとっての恩恵は入り口の安心感程度だと思います。

　確かに。

　昔の情報処理技術者試験(１０年くらい前まで)では、絶対的にアセンブリ言語が簡単でしたね！

　今のは昔に比べると難しくなったなぁと思いますが、他に出題される高級言語のどれも知らない子を合格させるために教育するなら、迷わずＣＡＳＬを教えますね。

※ご紹介頂いたＵＲＬは１１番のかたのとカブったコンテンツですが、「２ページ目以降が面白いからもっと読め」の意味でしょうか？

　ご回答ありがとうございます。

　直球なご意見、マシンによってニーモニックが違う！

　その意見が今まで１つもなかったのは、実は不思議でした。（直球過ぎて皆避けていた？）

＞（以下、長いのであえてアセンブラと略）

　この辺は、ニヤリとしてしまいます。

　そうかぁ、言われてみるとＭａｃのアプリ屋さんは大変だったのですね。（ＯＳ屋さんも大変だろうけれど）

　私にとっては彼岸(対岸より遠いのニュアンス)の出来事なので、特需があったんだろうなぁ程度にしか考えていませんでした。

　Ｍａｃがあーゆー風にＣＰＵを変えて来ることが出来たのは（厳密には、ＣＰＵを変えてもＭａｃと言うシリーズとして成立したのは）、凄く不思議ですね。

　最近のものなら大半の部分が高級言語で書かれているでしょうが、だからと言って再コンパイル一発で済むわけがないでしょうし、新プロセッサのＭａｃ本体が売れるか流行るか分からない時期に＜それ＞をやる訳ですから、相当にタイトな仕事でしょうね。

　Ｍａｃにも非力だった頃(６５０２辺りからでしたっけ？)がある訳で、その頃にはアセンブラ(敢えて)率も高かったンでしょうしね。

　インテル方面が非力だった頃の８ビットＣＰＵ→１６ビットＣＰＵの移行期(ＣＰＭ→ＤＯＳの移行期)には、ニーモニックレベルの互換と言うのもありましたね。

※ＰｏｗｅｒＰＣをターゲットにした開発(略して「ＰｏｗｅｒＰＣの開発」)は、やったことがないですね。趣味と実益を兼ねて何冊かの解説本は買ったのですが、何年も積読状態です。

　確かにバレづらいですが、数年越しで見過ごされていたのがバレたとき（と言うよりも見つけてしまったとき）のインパクトは絶大です。

　文字通り夢のあるＵＲＬを紹介して頂いて、ありがとうございます。

※質問の趣旨とは微妙にズレているのですが、嬉しくなっちゃいました。

　その論法ですと、漢語だと２文字／和語だと４文字／外来語(カタカナ語)だと７文字の事柄は漢語で綴るのが簡単と言うことになりますが、必ずしもそうとは思えません。よって私はこの回答に不満足です。(笑)

　良かったらリターンマッチ(再回答)をどうぞ。

　Ｐｅｎｔｉｕｍのような石のパイプラインの構造を踏まえて、効率の良い機械語を効率良くＧｅｔするんだったら、コンパイラに任せたほうが良い…とはよく聞きますね。

　モトローラ(６８０００系)は美しいと感じますか？

　まぁ汚れてはいないですね。

　私にとってはそれ程でもなく、美しいと言うよりもむしろ無個性な印象の石に感じます。（失礼かな？）

　私は最近ＮＥＣのＶ８５０と言う石(Ｖ８５０Ｅではない、無印の奴)と出会って、とても綺麗な命令セットだと感じました。

　C++言語の標準となるようなプログラムで…(http://www.hatena.ne.jp/1141028372)のほうでは、ずれた回答をしてしまったようで失礼しました。

※ＵＲＬの先のコンテンツは、読み応えはありそうですね。

　まだ真面目に吟味していないですが、凄いページを紹介して頂きました！

　バスの動きを見せるとは…！

※なお、私は「ＲＯＭに焼いて使うようなソフト」を職業として専ら作成しておりますが、アセンブラのほうが向いていると言い切れる部分など殆どありません。

♪この辺りで終了します！　回答して下さった皆さんありがとうございます！