アセンブラ☆with C

#asm
#endasm

アセンブラでプログラム組んでやったぞ。ほめろ。

86系のアセンブリ言語とH8系のものとの違いが分からない

その二つだけを比べてもだめだ。
もっと色々知ってれば分かるよ。

>>74
ソースとディスティネーションの順序が逆
■86系
mov dst,src
■H8系(モトローラ系)
mov src,dst
CELLのアセンブラ仕様書見たけどさっぱり分からなかった。

ときどき表見ながらアセンブラ使います。
命令表をでっかく印刷して壁に貼ろうかな。
左手に持ってると邪魔。

↑ブゲラ

アセンブラやＣ言語は 独学で勉強できますか？ おすすめの参考書とかありますか？

独学出来ますが、言語だけじゃなくハードウェアや
コンピュータサイエンスのバックグラウンド的知識を
同時に増やすことが言語を覚えることより重要です。

とにかくたくさん実際に使われているソース読むのがいいよ。

つまりは 電気・電子工学(ハードウェア)＋アセンブラ・Ｃ言語 コンピューター(ソフトウェア) を勉強したほうがいいと ハードウェアの独学勉強は難しそうですね 専門学校等に行くのがいいですかね できたら

話豚切るけど、アセンブリ言語でプログラムしたたくさんいると思うけど、
その「アセンブラ」自身を作ったことある人いる？

ディスアセンブラとデバッガなら作ったことあるす。

>>83
即レスサンクス。
頼もしいですね。漏れも逆アセンブラはＺ８０用を作ったことあるよ。
モニタＲＯＭに入れたもので、わずか２Ｋだけど、ちゃんとラベル付き
だった。
デバッガは、まあ、「モニタ」と呼べるものなら作ったかな。ブレーク
ポイントとかシングルステップとか、そんな機能を作るのも楽しかった。
マルチタスクモニタでもそれを出来るようにしたこともあったっけ。

んで、アセンブラ作ったことある人、さらに募集！

>>82
クロスアセンブラなら作ったことある。
プログラムの構造はさほど難しくないけど、
全命令に対応しようとすると、単純コーティングの繰り返しで飽きてくる.w

>>85
おおっ、こちらさんも即レスサンクス。
そうですね、アセンブラは、作ったことのない人から見ると、ちょっと難しいように
感じるかもしれないけど、一度そのやり方（パス１とかパス２とかの分担）が分かれば、
比較的簡単ですものね。
私も、Ｚ８０用、６５０２用、Ｚ８用など、いくつか作りました。もう二十年以上も昔
の話です。当時は、開発ソフトそのものにも事欠くことが多かったので、アセンブラ
をまず作ってから、それを元にして開発するということもありました。
初めて作ったときは二、三週間かかったのですが、２回目以降は手慣れてきて、
早いときは二、三日で出来たりしてましたね。
一番面白かったのは、被演算子の処理で、逆ポーランド記法に変換して数式を
使えるようにするような処理でしたね。あれは勉強になりました。

>>86
動作する機種は？やっぱりPC-9801かな。

おいらはZ-80と6502のエミュレータも作ったす。
MSXエミュとファミコンエミュなんすけどネ。

逆ポーランド・・・・高齢者スレですか。(w

私も20年ほど前、高校に入った頃にMZ上でZ80用のアセンブラを作ったな。

私も、最初にBASICで多用する命令だけに対応したアセンブラを作り、
それを使って、アセンブリ言語で書いた一部の命令だけに対応した
アセンブラをアセンブル。
今度はそれを使って対応する命令を増やしたものをアセンブル・・・・
という風に次第に対応命令を増やしていった。
もちろんOSなんて持ってないからソースはBASIC自身のエディタで
入力してASCIIセーブ。

なにしろ最初のBASICで書いたものはその次の一部命令にしか対応していないものを
アセンブルするのにも20分も30分もかかっていたのでデバッグが大変だった。
次にアセンブリ言語で書いたものは自身を1分かからずにアセンブルしてくれたので
一気に作成がはかどるようになったっけ。

ついでに、作るのに使った資料が何かの雑誌に載ってた数ページの
インストラクションセット表だけ。
これからコードマップ作ってビットパターン抽出して・・・と
まっとうな資料さえ手に入っていたら必要ない手間までかけてでも
作れたのも若かったからでしょう。

その後はオリジナル言語のコンパイラを作ったりもしましたが、
最終的に行き着いた先はゲームのプロテクト解析とかエロゲの
CGフォーマット解析とか.....orz

おまいらお取り込み中のところ申し訳ないが禿しく板違いだ

以降はこちらで
http://pc8.2ch.net/test/read.cgi/tech/1132761638/

>>88
なんか勘違いしてんでない？　逆ポーランド記法への変換は
現在の進化したコンパイラでも必ず採用されているんだけど……。

今時は二分木ですね。
逆ポーランドと等価だから変換されてると言えなくは無いが違う。

>>92
？？　
二分木は逆ポーランド記法に変換するための手段のひとつとして使われる
が、逆ポーランドが使われないというのはおかしいと思うが？

二分木は逆ポーランド記法に変換するための手段のひとつとして使われる
ことには同意しますが、逆ポーランド記法が使われている訳ではないでしょ

コンパイラ言語は、一旦、中間言語であるアセンブリ言語に変換され、それを
さらにアセンブラにて機械語に変換します。
アセンブリ言語に変換される前段階として、一時的に逆ポーランド記法に変換
されるのが普通です。その変換の手段としては、二分木もあれば、他の方法も
あります。

それを中間言語というのは抵抗ありますなあ。

>>96
考え方次第でしょ。
あなたは、インタプリタがご専門かな？　だとすると、ワード数の少ない中間言語に
変換するというのが普通ですから、それがあなたにとっての「中間言語」なのかもしれ
ませんね。
コンパイラ作ってる会社は少ないので、事業所毎に呼び名は変わりますから。

4つ組みたいなのを逆ポーランドって言ってる？
(+ op1 op2 result) <- こういうの

op1 op2 + .

↑こういうのですよ

Forthﾅﾂｶｼ

>>99
そんな逆ポーランド中間語でどんな処理をするの?
出てくる状況が分からない…

>>101
コンパイラが扱う式
c = a + b;
をアセンブラに展開するときに
b a + c （Forth忘れたので記述違ってたらごめんなさい）
というように逆ポーランド記法に直すと
記述の順番にアセンブラ命令で書いていけばいいということ。

つまりコンパイラの内部処理で使われているだけなので
中間語なんていうと誤解しやすいかも。

最適化用の中間語からアセンブラコードを吐くのに大した苦労も要らない
が、いちいち逆ポーランドに直すとそれよりいいことがあるのか？
現代の進化したコンパイラというのは分からんなあ。

もしかして FORTH が中間言語だと勘違いしてるアフォ (== >>102) がいる？

>>104
>>102のどこをどう読んだらそんな解釈になるんだ？

とりあえず>>88から一通り読んで理解できてない奴は勉強不足だ。もっと本読め。
課題図書はコレだ。
ttp://www.iwanami.co.jp/.BOOKS/01/5/010341+.html

>>105
全部読むのは面倒だから、逆ポーランドに変換するとどんな利点があるのか
書いてよ。必ず採用されているような一般的な処理なんでしょ。

>>106
（逆）ポーランド記法 ＞ http://ja.wikipedia.org/wiki/%E5%89%8D%E7%BD%AE%E8%A8%98%E6%B3%95
なにもむずかしく考える必要はない。
一般的な数式を、機械語に直す手前の段階に変換したときの状態をあらわす記法が
逆ポーランド記法というだけのこと。
コンパイラはどんどん進化しているから逆ポーランド記法が厳密にコンパイラの処理状態を
表しているわけでもないが、教科書的にその状態を表現するなら逆ポーランド記法、ってことかな。

ちなみに

中間言語 ＞ http://ja.wikipedia.org/wiki/%E4%B8%AD%E9%96%93%E8%A8%80%E8%AA%9E
もとは言語学分野の専門語でありコンピュータ分野ではあいまいな意味で使われているので
この言葉に条件反射的に反応すると突っ込まれやすいから注意。

Forth ＞ http://www2.airnet.ne.jp/sardine/langs/Forth.html
逆ポーランド記法をベースにした文法のコンパイラ。
実装が簡単なことからコンパイラの黎明期に有名だったが今は殆ど死滅している。
ただし文法がユニークなのでHPの逆ポーランド記法電卓と同様根強いファンがいる模様。

言葉足らずだったが こんなところで理解してもらえるかな >>105

失礼、最後は
言葉足らずだったが こんなところで理解してもらえるかな >>104
の間違いでした。

>>107
ドラゴンブックの頃の知識しかないのだが、数式などは構文解析後に直接
中間語(仮想マシン命令みたいな物)に落ちる。その間に逆ポーランドは
でてこない。
その中間語をいじくって最適化した後に対象マシンのアセンブリ言語命令
列などを出力するわけだが、手間などほとんどない(そのように中間語を
設計する)。

進化したコンパイラで逆ポーランドが必ず出てくるのはなぜ？
なにか利点があるからなんだろう。利点を説明してよ。

>>109
うはｗｗｗおｋｗｗｗ把握

うむ数式なら構文解析の時点で優先順位を判定するからなぁ。
逆ポーランド記法ってどの時点で使うんだろう？
まぁ解析完了時のスタック状態は逆ポーランド記法的な状態になってるわけだが。

数式以外は知らん。実装してみようとしたこと無いからな。

＞ まぁ解析完了時のスタック状態は逆ポーランド記法的な状態になってるわけだが。

ようするにそういう状態を表現するために逆ポーランド記法って言葉が使われるだけですね
コンパイラは作ったことないけどプログラム中で数式解析をするときもYacc＆Lexを使うから
逆ポーランド記法なんて意識することないしな。

age

>>111
言ってることわからん

逆ポーランドの利点は書かれた順番に実行すればよいという単純さで条件分岐が必要ないので
現在のCPUのパイプラインにもやさしい、つまり高速化に貢献できるってことじゃねえ？

ヒント：２年前

アセンブラ言語でスイッチの二度押し、長押しを判定する入力を考えているんだけど
フローチャート(概念)でやるのが一般的なんでしょうか？
趣味レベルの電子工作なので、改めてC言語を覚えようとは考えてません。
pic、H8はなんとか使えます。

普通に考えると
スイッチ入力→タイマー500msec以内→スイッチ入力→二度押し
スイッチ入力→タイマー500msec以上→スイッチ入力が続く→長押し
とかでなく、バックグランドでカウントさせるようなのを考えてます。

訂正

フローチャート(概念)でやるのが一般的なんでしょうか？
↓
どのようなフローチャート(概念)でやるのが一般的なんでしょうか？

判りにくい文章ですみませんm(_ _)m

>>116
忘れた頃にレス。

他のこともしなきゃいけないから、インターバル割り込みで、数を数えさせる。
それで一定数数えたら、状態遷移させる。
キーのイベントで割り込みかけると、想像以上に面倒。
概念の整理に、フローチャートは、あまりお勧めしない。

趣味なら、アセンブリ言語でガリガリプログラムしても、あまりメリットがない。
プロなら1ランク下のCPU 使ってコストダウンとか、銭金の賭かった話だが、
アマなら、C言語で楽した方が良い。特に癖のあるPICやH8は、ミスしやすい
ので、設備と腕のないアマチュアだと、デバッグで地獄を見るかも。

Cで書くと、フローチャートなんか書かなくていいし、コード生成も、実際には
ズブの素人の書くアセンブリ言語のコードよりコンパクトで高速のことが多い。

アセンブラで
0b00000001→0b00100000
0b00000100→0b00001000
のように6bitのbitの入れ替えでスマートな書き方ありませんか？

CPU次第（というか使える命令セット次第）

32ビットの乗算と剰余算が使えるなら

　　mul acc, 0x0008 2082 ; 0x0008 2082を掛ける
　　and acc, 0x0112 2408 ; 0x0112 2408のbitwise-and
　　rem acc, 0x0000 00ff ; 0xffの剰余

の3命令で、accの下6ビットのビット順を反転できるらしい。
もし8ビットマイコンレベルでやるなら、6ビット程度なら素直にテーブル引いたほうが
いいと思うが。

>>120-121
PICです、無い頭使っても思いつかなかったのも
無かったということですね、ありがとうございました