※面白半分な質問です。(ネタ歓迎! 勉強になるコンテンツの紹介も猶歓迎)
http://www9.plala.or.jp/sgwr-t/index.html
初心者のためのポイント学習C言語
プログラムを作るということが目標であるならば、多数のライブラリが用意されているCのほうが断然簡単でしょうね。
単語を覚えるって事ならばアセンブリ言語のほうが少なくて良いけど・・・
ロボットやOSを作るならアセンブリ。
しかし、近年の技術革新により計算処理能力が上がっているため、C言語でもあまり変わらなくなっている。
C言語なら、PHPやJAVAなどのプログラミングに応用できる。
ダミーURLってトコロはちょいと残念です。
組み込みのOSのようなものでも、端から端まで全てアセンブリ言語で書く事例は近代的ではないような気がします。でも確かにOSの中の一番低レベルな部分はアセンブリ言語の方が簡単(と言うか高級言語では本質的に記述できない)な部分もありますね。
ところで、waooooooさんのおっしゃるアセンブリ言語が適するロボットって、どんな種類のものでしょう?一口にロボットと言っても非常に幅広いですよね?>再回答は遠慮なさらずに!
http://www.mikrocontroller.net/articles/HLL
HLL - www.mikrocontroller.net
google:asembler vs Cgoogle:asembler vs Cgoogle:C vs ASMgoogle:ASM vs C
等などから それっぽいものをURLに記述しました。記載したURL先の内容は良く分かっていません。おrz
http://homepage2.nifty.com/m_kamada/bbslog06.htm#686
掲示板の過去ログ(プレーン 601〜700)
個人的には・・・算数や数学と同じような記法が使えるCの方が直感的と思います。
しかし、算数をまだ習っていない場合はアセンブリ言語の方が覚えやすいと思います。
言語の勉強し始めの頃はよくタイプミスをします。タイプミスをして、コンパイルエラーになってもどこの個所がおかしいのかが分からないというのをC言語初心者から良く聞きます。
言語の文法だけを取り上げると私はアセンブリ言語の方がタイプミスが少なく、かつ、どこでタイプをミスしているのかが分かりやすいのでアセンブリの言語の方に軍配が上がると思います。
しかしながら、ソフトウェアを作る場合、簡単な言語と言えば何が何でも私は経験上C言語を推します。
ドイツ語(?)はキツイっすね。(そう言えば私以前にドイツの職業プログラマさんと協業したこともありましたっけ)
2番目に紹介頂いたURLのLeDAさんの発言、的を射てますね。私もそんな風に思います。
>個人的には・・・算数や数学と同じような記法が使えるCの方が直感的と思います。
…とのことですが、信号処理分野のツールには「代数表記アセンブラ」なんてものも存在しています。私にとっては却って難しくなっちゃいますけれども。
「どこの個所がおかしいのかが分からないというのを…」聞きますね。取り敢えず若い者には「コンパイラの気持ちになって考えてみろ」と諭したりします。
http://www.orchid.co.jp/computer/cschool/cschool.html
C言語学習塾(C言語を入門からわかりやすく解説)
断然C言語でしょう。
上のサイトはゲームを作って楽しみながら学習できると思いますよ
純粋にCをやるぞっていう方はkn1967さんの紹介されたサイトがいいと思います
C言語は英語の綴りが多いのでアセンブリよりもとっつきやすいと思います
そして、かなり普及している言語ですし
文法もC++やJAVAなどと近い部分があるのでC言語を勉強しておいた方がいいかもしれません
「掲示板C言語クイズ」面白いですね。
気の利いたコンパイラなら、「defualt:ラベルはどのgotoからも参照されていない」とか警告を出してくれても良さそうですが。
…ん? switch文の外から中へgotoって一般的には出来るのかな?(一般的にそんなコーディングする奴はいないと思うけれど、その辺のコンパイラに喰わせたら無難なコードが出てくるのかな?)
http://www.tokumaru.org/yacc/kmyacc.htm
kmyaccについて
アセンブリ言語です。
アセンブリ言語は比較的簡単なので、並みのプログラマーでも二、三日で処理系を実装できるでしょう。
C言語の処理系の作成はかなり優秀なプログラマーでも一ヶ月以上かかるものと思われます。
プログラマとして言語処理ツールを使う立場ではなくて、言語処理系を作るほうの身になって考える…と言う回答がやっと出ましたね。
アセンブリ言語処理系だとしても、2〜3日では、個人的に使うと言う意味でさえ実用になるレベルのものは私には実装出来ないと思います。
C言語処理系を実装するよりはアセンブリ言語処理系を実装するほうが簡単だと言われると、直感的にはうなづいてしまいそうになります。
条件が揃っていた場合はアセンブリ言語処理系を作る方が簡単な気が、確かにします。
…でも揃うべき条件って何だろう?
完全な言語仕様が与えられていること?
C言語でなら処理系依存とされる項目の詳細であり、アセンブリ言語処理系であれば擬似命令の類…? ターゲット・プロセッサのためのアセンブリ言語処理系が既存でなければ、C言語処理系の実装に着手する気にはならないだろうから、それも条件の1つかな…。
簡単に考えるために、関連ツール(C言語のプリプロセッサなど)の存在は無視するとします。
Cコンパイラ本体とアセンブラ本体とで考えたとき、どちらも入力はプレーンテキストのファイルと考えられるけれども、Cコンパイラの出力がプレーンテキスト(アセンブリ言語ソースコード)で良いのに対してアセンブラの出力はリロケータブル・オブジェクト(多分ややこしい形式のバイナリファイル)と考えられたりして、この点ではアセンブラのほうが敷居が高そうです。
お手本になるソースコードの入手/調達を考えたときも、Cコンパイラのお手本のほうがずっと幅広く手に入りそうな気がします。
突き詰めて考えてみるとどっちも同じくらい難しいかも知れませんね。
※紹介して頂いたkmyacc。今は特に用事がありませんが、何かの時に思い出すかも知れません。
http://wisdom.sakura.ne.jp/programming/asm/index.html
�A�Z���u����������
DOS時代なら、アセンブリ言語の方が簡単だよ、
と言ってたでしょうね。
昔は機種依存バリバリのプログラムが多かったですから、
どうせCで書いても、インラインアセンブラ使いまくり。
いちいち頭を切り換えながら書くのも面倒だし、
それなら最初からアセンブリ言語でいいじゃん、
というのが通り相場でした。
それにMS-DOS Ver.3.1には標準でMASMが付いていましたから、
みんなCより先にMASMでプログラムを憶えていきましたしね。
symdebも使用頻度が高かったですから、
当時としてはアセンブリ言語の方が
Cなんかよりずっと身近にあったわけです。
言語の仕様としても、
「お茶」「メシ」「風呂」「寝る」
の倦怠期の夫婦みたいな会話で成り立つアセンブリ言語の方が、
当時はストレートで分かりやすかった、
という部分がありました。
また、Cも普通に書く限りプロシージャ指向言語のひとつであり、
Cで行う構造化プログラミングの技法は、
そのままアセンブリ言語でもたやすく行っていけるものでした。
これが大きく変化してきたのは、それまでは
マシンとプログラマの対話であったプログラミングが、
会話の主役をオブジェクトたちに譲り、
プログラマは議長役を務めるといった感じの
オブジェクト指向が台頭しはじめてからでしょうね。
いつの間にかCにSIMULAの霊魂が乗りうつったような
C++が主流になってきて、あれ? 最近俺達別世界にいない?
と気が付くに至って、アセンブリ言語が急に
遠い世界の物になってきたような気がします。
ま、そんなこんなで、ただ処理の手続きを順序立てて書いていくだけなら
アセンブリ言語はとてもストレートで簡単です。
言語仕様としては憶えることがほとんどなく、
興味深いマシンのことだけ憶えていけばいいわけですから、
楽しくもありました。
結論。
ターゲットとするマシンが定まっていて、
アセンブリ言語で書いて苦にならない程度の処理なら、
アセンブリ言語の方が楽しく分かりやすく簡単です。
と書き殴って逃げます。さささっ((((((( ;^-^)
>と書き殴って逃げます。さささっ((((((( ;^-^)
ナイス回答だと思います。
この一文が秀逸ですよね!?
C言語は、書いててどのようなアセンブラに展開されるか何となく想像がつきます。
C++言語は、書いててどのようなCソースに展開されるか何となく想像がつきます。
でも、C++言語⇒アセンブラはストレートには想像しないですね。
MASMは強力なツールでしたね。(Ver.3.1に標準でついてましたっけ? 拡張機能セットとかではなかったでしたっけ? それともPC/AT用のDOSの話?)
但し私は実は、MASMでなくてOPT-ASMなるツールを愛用していました。(TomCatさんならOPT-ASMもご存知そうですね?)
但し私はアセンブリ言語ツールとしてではなくて、汎用バイナリ・ファイル作成ツールとして使うことが殆どでした。(アセンブラ使って書いた実用のDOSプログラムは多分1本きりと記憶しています。PC-9801用のTSRでした。)
実は私は組み込みの職業プログラマでして、「あれ? 最近俺達別世界にいない?」と言うのはあまり身に覚えがなかったりします。
21世紀になった今日でも、C言語とアセンブリ言語のミックスランゲージが主です。
ターゲット・ハードウェアは原則的に毎回違いますし、ターゲット・プロセッサも様々です。
「アセンブリ言語で書いて苦にならない程度の処理なら、アセンブリ言語の方が楽しく分かりやすく簡単です」とのことですが、職業プログラマとしては「C言語で(色々な意味で)間に合うなら、なるべくC言語で書いておこう」と思うのです。
まぁ簡単かどうかとはチト違いますが。
【そろそろ就寝します。続きは(あれば)明晩オープンしま〜す。】
http://ray.sakura.ne.jp/asm/index.html
最適化の為のアセンブラ入門
私は、アセンブラの方が好きだぁ~。
ぶっちゃけ、どっちも覚えれば、食いっぱぐれ、は無いと思われます。
高給目指すなら、両方が良いね。
Cだって、アセンブラ判れば、理解しやすいし。
ご紹介頂いたURLのコンテンツ、「最適化のためのアセンブラ入門」と言う表題に名前負けしてますよ!?
…と思って「トップ」のページへのリンクを辿ったら、「Windows で C のインラインアセンブラを使ったプログラミングが出来るようになることを…」と断ってましたね。
賜ったご意見「Cだって、アセンブラ判れば、理解しやすいし」は、概ね分かります。
私の質問に対する答えとして「アセンブラがわかればCは簡単」と言う意味に(勝手に)解釈致します。
http://books.yahoo.co.jp/book_detail/03079177
Yahoo!ブックス - はじめての"C" / 椋田実/著
一般的にではなく、“私にとって”と言う事で.... (^^)
もうそれは、何と言っても“アセンブリ言語”でーす。
理由は、痒い所に手が届くからです。
自分も組込みのプログラマです。 (でした、かなぁ)
全部自分でしくみを組立てなければならない所は大変ですが、
アセンブラでしたらマシン語と一対一ですので実際どう動くの
かが手に取る様に分かります。 と言うか、その物ですよね。
“倦怠期の夫婦みたいな会話”と言うコメントがTomCat-san
からありましたけれども、アセンブラは一から十まで全部自分
で準備しなければなりません。 少しでも欠けると“Error”。
どこが伴侶の機嫌に添えなかったのか、全部自分で考えなければ
なりません。 ですので、倦怠期の夫婦の会話(知らないけれど)
では成り立たないと私は思いますね。
と言う意味では、C語の方が倦怠期の夫婦の様な気がします。
Cは真意が伝わっていなくても(間違っていても)取り敢えず
コードが生成されてしまうので、表面上はOKですから。
またアセンブラは頑固親父の様に「俺はこれしか許さん!!」と
言うやり方にも対応可能です。 switch分の外から中へのgoto
だって、できますよね。 そもそもswitch分と言う概念もない
訳ですから。 但しその分、責任は全部プログラマですが....
C言語でもプログラムを書きましたが、最終的にどんなマシン語
になるのかがプラグロム中には想像つかず、常に不安でしたね。
なんたって私は、アセンブラで書いたプログラムの最終debugを
マシン語でしていた位ですので。 アセンブラでもタイポがあり
ますが、Cだったらもっと有り得ますからね。
Cで書いたプログラムのマシン語を見て「あー、もったいない」
なんて感じるのは、今の時代では異常なんだと思っています。
如何に少ないバイトで望みのプログラムを効率良く書くかが、私
の頃は腕の見せ所でしたからねー。 (--;)
でもCも勉強したし実践もしましたよ。 URLは、そんな私の
C言語の先生です。 と“はじめてのC”を挙げたかったのですが、
昔の物なのでまともなリンクが見つかりませんでした。
でもこれは、Kityo-sanには紹介不要の様ですので免じてお許しを。
ボロボロになってセロハンテープで補修された私の先生は、今でも
本棚に鎮座していて、時々開かれています。 いつまで経っても
理解できない持ち主の手に依って....
では
魂の入ったご回答、楽しかったです。
「ボロボロになってセロハンテープで補修された私の先生」…いいですねぇ。
私にも、そう言う一冊があります。BASICですけれども。
組み込みをやっておると、コンパイラの生成した機械語と向き合う必要があるときは確かにありますね。
現在のルネサス(http://japan.renesas.com/homepage.jsp)のコンパイラの最適化の度量に関して、個人的には高く評価しています。
別にルネサスのに限った事ではないですが、最適化がかかっちゃった部分が向き合う必要のある部分になったとき、最適化が優秀過ぎて困るぅと悲鳴を上げちゃうときもありますね。
>Cは真意が伝わっていなくても(間違っていても)取り敢えず
>コードが生成されてしまうので、表面上はOKですから
表面上はOKだけど、よ〜く見たら「Cコンパイラが生成したアセンブリ言語ソースが、アセンブラによって警告を受けていた」と言う事態を経験したことがあります。
プログラマ(=高級言語ユーザー)の通常の期待としては、コンパイラはターゲット・プロセッサの内部詳細を知り尽くして最適な機械語の組み合わせを生成する筈なので、そんな警告は普通は表示しない訳なのですが…。
コンパイラの噴出した野心的なニーモニックの組み合わせ(=並みのアセンブリ言語プログラマなら無意識に別な組み合わせにするような)について、それが本当に大丈夫かどうか、顧客に説明を求められて窮しました。
※タイポ(typo)と言う用語を覚えました!
アセンブリはプログラムを高速化するのがいとも簡単に出来ます
一方C言語はコーディングとデバッグが簡単です
例えば、DirectXを使わずに、ハードウェアに依存しないフェードイン、フェードアウト、モザイクの動的生成ソフトを作った場合、C言語では、スムーズな動作は期待できませんが、アセンブラならば、サンプルのように比較的スムーズに動作します
FORTRANではポインタを意識しなくてもプログラムができるように
C言語ではスタックポインタやレジストリの退避を意識しないでプログラムができるので、コーディングやデバッグが容易になります
アセンブラは、ハードウェアに強く依存しますからCPUが変わってしまったり、ハード構成が変わってしまうと、動作しない場合が多いので、”移植”という点でもC言語の方が簡単です
プログラムのサイズを小さくしたい場合、C言語では限界があります
アセンブラでは無駄な部分を省くのが簡単に出来ます
添付したHELLO.COMは Hello World! をわずか、23バイトで実現したアセンブラのプログラムです C言語だとココまでは小さくなりませんね
というわけで、優位性がどの部分に注目するかで違ってくるので、いいとこ取りしてプログラムするのが理想なんじゃないでしょうか
例えば、複雑な処理をライブラリ(関数部分)としてアセンブラで作成して、C言語でその関数だけ呼び出してプログラミングする手法も在ります
http://www.kumei.ne.jp/c_lang/
猫でもわかるプログラミング
http://www.e-net.or.jp/user/missing-link/assembler/
Technical Assembler
http://x68000.q-e-d.net/~68user/net/
ネットワークプログラミングの基礎知識
http://hp.vector.co.jp/authors/VA016117/index.html
���v���O���~���O
http://www7.plala.or.jp/keny01/
プログラマの隠れ里
WisdomSoft
リンクは私がよく利用しているC/アセンブラに関するサイトです
直球な回答ですね!
筆頭のURLがlzhっ。
速くするのも小さくするのも一般的には高級言語のほうが簡単…だと、私は思います。
究極を求める場合は機械語と直接向き合うアセンブリ言語のほうが可能性は残りますが、それは簡単な領域では明らかにないです。
HELLO.COMは確かに小さいですが、AH=9, INT 21H(多分)の向こう側をリンクしていないからですし、現実的なボリュームの機能を持ったプログラムを速く/小さくするのであれば、高級言語のほうが簡単かとやっぱり思うのです。
(おっしゃる通り、現実解は「いいとこ取り」だと思います。
※最短Hello World!案(笑):HELLO.bat(21 byte CR+LF EOF付)
@echo Hello World!
http://www7.plala.or.jp/keny01/asm/
Assemble Programming
とてつもなく簡単なプログラムでない限り、構造化されたC言語の方が断然簡単です。
アセンブリは、読むのも一苦労です…。
ただ、一部の簡単なルーチンで、アセンブリで作った方が良い場合もありますね。(むしろそうじゃないと出来なかったり。)
でも最近の流れだと、ご法度ですね。
オブジェクト指向、抽象化、万歳!
構造化アセンブリ言語と言うのは以前に存在していましたが、オブジェクト指向アセンブラと言うのはそう言えば聞いたことがありませんね。
総称プログラミング(template<>的なこと)は、大抵のアセンブリ言語でマクロと言う形でサポートされていますね。
オブジェクト指向は、言語処理系によるサポートがなくても表現可能な筈ですが、嬉しいことは起きないでしょうね。
…って、アセンブリ言語&C言語の話題じゃないじゃん。
【そろそろ出社します。続きは(あれば)今晩オープンしま〜す。】
http://home.netyou.jp/gg/ugpop/academy002-037.htm
高級、低級の意味とレジスタ、mov、add
純粋にアセンブリ言語とC言語なら、C言語が簡単でしょう。簡単に、効率的に、ってのがC言語ですから、だけど効率の事を無視すればアセンブラが簡単とも言えるかもしれませんね。
えぇと。最初に断っておきますが、私はneoneatさんのコメントに賛成です。
開発時の効率で考えても、実行時の効率で考えても、保守時の効率で考えても、概ね全ての局面で、現実的に、アセンブリ言語よりはC言語のほうが効率的だと思います。
資源がタイトで制約の多い組み込みの現場に身を置いていてさえ、心からそう思います。
下記の否定的にも読めるコメントは、ネット上や最近の書籍で出回っている情報内容の一般的な実情についての、私の個人的な感想です。
ご紹介頂いたURLの先のコンテンツ(全部は読んでいません、最初のページと目次を眺めた程度です)もそうですが、世間一般ではアセンブリ言語についての理解がとても貧しくなっているなぁ…と思います。
アセンブラ(アセンブリ言語ツール)にプログラマが期待するべき機能の要(かなめ)は、1対1に対応するニーモニック⇒機械語の変換ではないと思います。
その程度のことだけが出来れば良いのであれば、PC用でも数千円から数万円するような高価なソフトウェアのライセンスを購入するプログラマは滅多にいないと思います。(最近はアセンブリ言語ツールが単体で製品になっているのを見かけない気がするのは置いといて)
そんな単純なツールで良ければ、コンピュータの使い方を熟知しているであろうアセンブリ言語を使おうとするほどのプログラマなら、自分で作ることを検討しますよ、多分。
ニーモニック⇒機械語の変換程度はそれほど難しくないとして(※実際に作ろうとすると、これとてたっぷり2〜3日はかかる程度には難しいですが)、それ以外にアセンブラに期待するべきことは、例えば次のようでしょうか?
・アドレスや数値を、ラベル乃至はシンボルとして抽象化すること
・ユーザ定義シンボルのうち少なくともグローバルラベルを、リンカ/ライブラリアン/デバッガ等に引き渡せるようにすること
・アドレスの計算(所謂ショートジャンプ系の命令の分岐先が分岐可能な範囲に収まっているかどうかの確認、相対分岐命令の分岐先をラベルで記述出来るようにすること、コードもデータも配置しない「空間」を空けること、など)
・外部参照などの未解決ラベルの類を未解決のまま保留にしてリンカに委ねられるようにすること(これが出来ないと全部のソースが揃わないと機械語に変換することを試すことも不自由になる⇒分業できない!)
・最終的・物理的にはかけ離れた場所に配置する予定のデータやコードであっても、論理的なまとまり毎にソースコード上1箇所に記述出来るようにする(セクションとかセグメントとか)
…(はぁはぁぜぃぜぃ)。こーゆー事柄への理解や敬意をすっ飛ばしてアセンブラを語るなよと言ったら言い過ぎかも知れませんが、せめてアセンブリ言語とディスアセンブルされた機械語やニーモニックの羅列とはきっちり区別するところから説明を始めて欲しいなぁ…と思うのです。
そうであってくれないと、若い奴らが正しい方向に育ちにくくなると思うので。
(あぁ、年寄りの戯言ですね。ニーモニックの羅列のことをアセンブラと呼ぶのが通りが良いのは分かります。「…と言うのが技術的に正しい用語の意味ですが、通りが良いこともありますし、本稿ではニーモニックの羅列のことをアセンブラと呼びます。」とかが1ページ目の締めくくりの文章だったら安心して読めるかも知れないのになぁ)
http://www5c.biglobe.ne.jp/~ecb/index.html
�ڎw���v���O���}�[�I
実際の答えは「作るモノによるのでは?」と思います。
ステーキを切るのに、ドライバーを使うかナイフを使うかな感じ?
ドライバーとナイフほどは違わないと思いますけれど。
言語を何かに喩えるなら、私はこれが好きです。⇒http://www.page.sannet.ne.jp/mnagai/msj/pgm_lang.htm
私見ですが、C言語が簡単です。
書籍やWWWサイト、有識者からのサポートが受けやすくお勧めです。
しかし、それ以外でいうならば、言語の違いというのはプログラムの本質とはあまり関係がない…と個人的には考えています。
例えていうならば、自分の考えを文章にして書くのに、英語が適しているか日本語が適しているかというようなものだと思います。
まぁ、記述したい内容によって向き不向きはあるでしょうが、それもまた似たようなものだと思います。
※URLは見たままダミーです
確かに。
先生を探すことについて考えると、圧倒的にC言語のほうが簡単ですね。
同じ視点で、C言語とC++言語とだったらどうでしょうか?⇒http://www.hatena.ne.jp/1140102271
※ダミーURLは残念です。
URLはダミーです。
一般的にアプリケーションをつくるにはどう考えてもCのほうが簡易でしょう。Cを知っていれば、C++やD、Javaなどにも応用可能です。(もちろん覚えなおすことは多いですが)すでにほかの言語を経験していなくてもすぐにわかるでしょう。
お答えは、一般的な見解だと思います。
出来ればダミーでないURLを紹介して下されば嬉しかったのですが。
C言語を知っていれば、C++やJavaに応用可能と言うコメントについては、にわかには同意しづらいですね。
自分の経験では、BASICからCに移行した時の苦労を1として、CからC++に移行した時の苦労は5〜10ありました。
【苦労と言うのはある意味嘘で、どちらも刺激に満ちた楽しい体験でしたが。】
枝葉の構文が似ている(構文を似せる)ことは、言語の提供側には実際にもの凄く重要な意味があると思いますが、言語ユーザ(プログラマ)にとっての恩恵は入り口の安心感程度だと思います。
ここはあえて、アセンブラ。
但し、プログラム初心者が基本情報技術者を受けるという前提ですが。
命令数の少なさが第一。
その関係上、あまり難しい問題が出せないのでアセンブラの問題はかなり易しいです。
プログラムはよーわからんけど、基本情報を取りたいという人に向けるならば、
アセンブラが簡単ということで。
確かに。
昔の情報処理技術者試験(10年くらい前まで)では、絶対的にアセンブリ言語が簡単でしたね!
今のは昔に比べると難しくなったなぁと思いますが、他に出題される高級言語のどれも知らない子を合格させるために教育するなら、迷わずCASLを教えますね。
※ご紹介頂いたURLは11番のかたのとカブったコンテンツですが、「2ページ目以降が面白いからもっと読め」の意味でしょうか?
http://www.watalab.cs.uec.ac.jp/students/yuke/
yuke@watalab
アセンブリ言語(以下、長いのであえてアセンブラと略)っていうのはマシンによってものが変わるので一概にどちらが簡単、なんて言えません。
が、やはりCがいいでしょう。書籍が多く出回ってますから、取っつきやすいと思います。
対するアセンブラは、今となってはCASLを除くとx86のものが数えるほどしかありません(ネット上には腐るほどあると思いますが)。
そのほか、アセンブラの場合、MacのようにCPUの乗り換えが多いと、いままでの苦労が水の泡になってしまうことがあります(エミュレータがありますが)。
そう考えても、やはりCを覚えておくのが吉でしょう。
ちなみに、URLはPowerPCのアセンブラです。見ただけでも複雑で、しかもCASLなどと違って連想しにくい名前がついています(一応、例えば b 命令ならbranch、li は load immediate と、略語ではあるらしいですが)。こんなのを使って書けなんていわれた日には死にたくなります(^^;
ご回答ありがとうございます。
直球なご意見、マシンによってニーモニックが違う!
その意見が今まで1つもなかったのは、実は不思議でした。(直球過ぎて皆避けていた?)
>(以下、長いのであえてアセンブラと略)
この辺は、ニヤリとしてしまいます。
そうかぁ、言われてみるとMacのアプリ屋さんは大変だったのですね。(OS屋さんも大変だろうけれど)
私にとっては彼岸(対岸より遠いのニュアンス)の出来事なので、特需があったんだろうなぁ程度にしか考えていませんでした。
Macがあーゆー風にCPUを変えて来ることが出来たのは(厳密には、CPUを変えてもMacと言うシリーズとして成立したのは)、凄く不思議ですね。
最近のものなら大半の部分が高級言語で書かれているでしょうが、だからと言って再コンパイル一発で済むわけがないでしょうし、新プロセッサのMac本体が売れるか流行るか分からない時期に<それ>をやる訳ですから、相当にタイトな仕事でしょうね。
Macにも非力だった頃(6502辺りからでしたっけ?)がある訳で、その頃にはアセンブラ(敢えて)率も高かったンでしょうしね。
インテル方面が非力だった頃の8ビットCPU→16ビットCPUの移行期(CPM→DOSの移行期)には、ニーモニックレベルの互換と言うのもありましたね。
※PowerPCをターゲットにした開発(略して「PowerPCの開発」)は、やったことがないですね。趣味と実益を兼ねて何冊かの解説本は買ったのですが、何年も積読状態です。
http://iwatam-server.dyndns.org/column/88/
コラム: ブラックボックスのリスク
アセンブリ言語のほうが簡単ですよ。出力される答えが正解と同じなら、途中の処理がちょっぴり間違っててもめったにバレませんからね。(笑)
確かにバレづらいですが、数年越しで見過ごされていたのがバレたとき(と言うよりも見つけてしまったとき)のインパクトは絶大です。
http://www.watch.impress.co.jp/av/docs/20021022/sharp.htm
�V���[�v�A�t���K���X������8bit CPU�uZ80�v���`��
私は、8ビットのCPUでアセンブラのみ扱ったことがあります。
ハードウエア仕様を公開していればかなり簡単でした。当時、SONYが公開して、NECは暴露本のようなのが
一時発売されて買った方には内容が分かるといった仕様公開の程度でしたね。
20年ほど前なので、昔話にしかなりませんが。
一方のCは、未だに扱ったことがありません。
Cからアセンブラに持って行き最適化などやってみたいけど、他に覚えることが多くて手が回っておりません。
文字通り夢のあるURLを紹介して頂いて、ありがとうございます。
※質問の趣旨とは微妙にズレているのですが、嬉しくなっちゃいました。
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%BB%E3%83%B3%E3%83%9...
アセンブリ言語 - Wikipedia
C言語の方が簡単です。
C言語の1文を、アセンブリ言語であらわすと1~数文必要ですから。
http://ja.wikipedia.org/wiki/C%E8%A8%80%E8%AA%9E
C言語 - Wikipedia
その論法ですと、漢語だと2文字/和語だと4文字/外来語(カタカナ語)だと7文字の事柄は漢語で綴るのが簡単と言うことになりますが、必ずしもそうとは思えません。よって私はこの回答に不満足です。(笑)
良かったらリターンマッチ(再回答)をどうぞ。
http://www.atmarkit.co.jp/fpc/rensai/zunouhoudan007/pipline.html
頭脳放談 : 第7回 パイプラインと動作クロックの密かな関係?
Z80や68000ならアセンブラ、そのほかのCPUなら要相談。RISCでなければC言語がいいかなぁ、と思います。パイプライン持ってるMPUのアセンブラなんて絶対に書けない。
インテルの魑魅魍魎が跳梁跋扈を見るにつけ、モトローラはなんと美しい石と言葉(アセンブラ)を創造したのか、と思わずにはいられません。
とはいえ、今となってはC++、小さなプログラムならスクリプトがいいなぁ、と思います。
Pentiumのような石のパイプラインの構造を踏まえて、効率の良い機械語を効率良くGetするんだったら、コンパイラに任せたほうが良い…とはよく聞きますね。
モトローラ(68000系)は美しいと感じますか?
まぁ汚れてはいないですね。
私にとってはそれ程でもなく、美しいと言うよりもむしろ無個性な印象の石に感じます。(失礼かな?)
私は最近NECのV850と言う石(V850Eではない、無印の奴)と出会って、とても綺麗な命令セットだと感じました。
http://homepage2.nifty.com/sak/w_sak3/doc/syspc/c_k01.htm
パソコン基礎知識 C 言語編 (その一) プログラミング言語 C - SAK Streets
個人的にCの方が好きです^^;
直感的というか、文章的でわかりやすいのはCかなーみたいな感じで。
詳しいことはわかりませんが。。。
基本情報処理の問題ではCよりもアセンブラの方が簡単でした(笑)
C++言語の標準となるようなプログラムで…(http://www.hatena.ne.jp/1141028372)のほうでは、ずれた回答をしてしまったようで失礼しました。
※URLの先のコンテンツは、読み応えはありそうですね。
作るソフトによってどちらが簡単か決まります。
ROMに焼いて使うようなソフトは、アセンブラのほうが向いてますね。
Windowsのソフトなどは、C言語のほうが簡単です。
まだ真面目に吟味していないですが、凄いページを紹介して頂きました!
バスの動きを見せるとは…!
※なお、私は「ROMに焼いて使うようなソフト」を職業として専ら作成しておりますが、アセンブラのほうが向いていると言い切れる部分など殆どありません。
♪この辺りで終了します! 回答して下さった皆さんありがとうございます!
見た目にもカラフルだし、閲覧し易いライトな感じのページですね。