マセンブラ言語は時代錯誤の生き遅れ

CPUの速度が今以上に上がれば、高速なアプリなんか苦労して作る必要なんか極端に減るよ。
8Bit、16Bit全盛のころはアセンブリ言語で書くのが普通だったのが、32Bitの高速CPUが出てきたころには
Cなどの高級言語で書くのが一般的になった。
今時、アセンブリ言語でプログラムを組む機会はほとんどない。
このまま、CPUの速度が向上すれば、VM上で動作する言語でほとんどのアプリが作成されるようになるんじゃないの？
要するに、ハードウェアの進歩によって、実行速度よりも、簡単に開発できることが優先されるようになるってこと。

【前スレ】
アセンブラ…　(;´Д｀) ﾊｧﾊｧ
http://pc5.2ch.net/test/read.cgi/tech/1087897801/

【過去ログ】
アセンブラ…　(*´д`*)ｱﾊｧ…
http://pc5.2ch.net/test/read.cgi/tech/1076157613/l50
アセンブラ…　(ﾟдﾟ)ｳﾏｰ
http://pc2.2ch.net/test/read.cgi/tech/1060928704/l50
アセンブラヽ(`Д´)ﾉﾓﾙｧ
http://pc2.2ch.net/tech/kako/1040/10402/1040297337.html
アセンブラヽ(`Д´)ﾉﾓﾙｧ
http://pc3.2ch.net/tech/kako/1016/10169/1016991911.html
アセンブラ…　（・∀・）ｲｲ！
http://pc.2ch.net/tech/kako/1002/10022/1002267809.html

マセンブラ

これからはLLの時代

マセンブラって何ですか。
汗んブラなら知ってますが。

>>1
ああ、業務系とかやってる人だとそうなんだろうね。

76

いまどきのCPUはマイクロプログラム方式が主流だから

>今時、アセンブリ言語でプログラムを組む機会はほとんどない。
>このまま、CPUの速度が向上すれば、VM上で動作する言語で
>ほとんどのアプリが作成されるようになるんじゃないの？

っていうのはとっくの昔にそうなっているとも言える

http://www.google.com/search?num=50&hl=ja&inlang=ja&ie=UTF-8&safe=off&c2coff=1&q=%E3%83%9E%E3%82%BB%E3%83%B3%E3%83%96%E3%83%A9&lr=lang_ja

25 ：仕様書無しさん ：03/01/24 23:46
そんなことアリマセンブラ

マセンブラについて教えてください。

>>8
ミラクルブラって何だろ。

>>10
女プログラマはブラをせんと言うことだ。なかなかイイ職場だぞ。

３日帰ってないので汗臭いブラ
むしろそれが獣心を駆り立てていいと言う奴もちらほら

驚異のスピード　魔戦ぶら

こいつらキモイ！！

生き遅れ
ってのもよくわからん

股の間に息送れ

MSILアセンブリ・コードを手書きしてる奇特な香具師はいるか？？！！１

テストコードは書いたことある。けどそれだけ。

コンパイラが出来てくるまでどうすんじゃｳﾞｫｹ

マセンブラなんて知りマセンズラ。

Intelの「アーキテクチャマニュアル上中下巻」の日本語版
ついに落とせなくなったな。
USサイトで４巻verを落とさないといけない

ＧＵＩのプログラムやWebApplicationをアセンブラで書くのは池沼だが、
高速計算が求められる計算ではアセンブラレベルで高速化することもある。
早い話がケースバイケース。

稲メンの車のことだろ。

>16
そこそこ使っている人もいるようだ。
意味は全くわからんが。
http://www.google.co.jp/search?hl=ja&ie=UTF-8&q=%E7%94%9F%E3%81%8D%E9%81%85%E3%82%8C&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja

行き遅れ
だろ？

　　| ＿
　　|　M ヽ
　　|从 ﾘ）〉
　　|ﾟ ヮﾟﾉ| 　………
　　ミ)} i !
　　|_/ヽ|」
　　|'

マセンブラコード書いてみますた
LDA "nullpo"
STA $0000

アセンブラはよく使ってる。ARMのやつだけど。

　　　　　　　　　　　,.ィ'"´ﾞ'"⌒｀`ヽ､
　　　　　　　　　 ／, /,｀　´,ヽﾞ､ i.;　,ﾞヽ,.-一7
　　　　　　　　イ,; ! ,i. iiﾍ./ヾ. ﾞ、 !i .i　 i-‐ /
　　　　　　　　,!i l i !､.!l!_　　l_!l_lリﾘﾉ　 i='"
　　　 　 　 　 _ ﾞ.／,'"､!　　 ﾞ !' '"ﾞi　.r､.!ﾞ､
　　　　　　　 ir'"ｨ,´iﾞ__..;;　　;;..__.　l:　ﾚ/Tﾞ　 ／￣￣￣￣￣￣￣￣￣
　　　　　　 ./　　ﾞi .!i ""' ､._.,"　；.i:　!', .i　＜　時代錯誤・・・
　　　　　／ﾞ｀ヽ、ﾉ.i:::i｀-､.ヽｿ ,..ィilil i ; ; ! 　 ＼＿＿＿＿＿＿＿＿＿
　　 ,.ィ'"￣｀ヽ､.〉_.!::!,,,..:-T ''´　 lili!i i ; ;j
　　 i.:'　　　　　,i!li i::!　/=　,.. ／ili｀ヾﾘﾉ
　 /: :　　　 　 ｲ.!li iﾘ　!ﾞ~ﾞ'.／: jil/: : ,.ヽ

アッセンブラしらずに、C/C++ のデバッグがまともにできるの？

ライブラリや C 自体がおかしいときは、デバッガでアッセンブラ
レベルを追っていくことが多くあるはず。

そんな必要がないプログラマーは幸せだが。

M + assembler で マセンブラ

S + assembler で 左遷ぶら

>>31
>ライブラリや C 自体がおかしいときは、デバッガでアッセンブラ
>レベルを追っていくことが多くあるはず。

で、無駄にアセンブラを追っかけて、最終的に自分のバグだったことに
気づくのが遅れるわけね（最終的に「気づかない」香具師もいるが）。

最初からソースだけを調べていれば、直ぐに解決するはずなのに・・・

じゃ、>>31は、プロセッサの動作がおかしいとき、どうしてる？
シリコンチップのドーパントが足りなかったとき、どうしてる？
マザーボードがマイグレーションを起こしていたとき、どうしてる？
HDD のディスクの表面粗さがやたら大きかったとき、どうしてる？
・・・

そんな必要がないプログラマーは幸せだねっ！

>>34
オレなら、ハード担当に丸投げするけどね

>>1
自分が理解不能なものを全て否定する癖よくない。

時代錯誤と聞いて頭に浮かぶのはJavaだな

>>34
CPU を交換することを知らないのか。幸せだね

33>>最初からソースだけを調べていれば、直ぐに解決するはずなのに・・・

なぜ、そんなことが言える？

通常､アッセンブラー・デバッグに入るのは、ソースだけでは解からないからのはず。

おまえ、本当はアッセンブラ・デバッグなんてできないだろう。

>>39
とりあえず、気持ち悪いから「アセンブラ」と言ってくれ。

>>39
「はず」

結局やったことないらしい

荒唐無稽と聞いて頭に浮かぶのはJAVAだな

>>22
ftp://download.intel.co.jp/jp/developer/jpdoc/から24547?03.pdfをうわｌｔ何をすｒｄｋｗｎｓｇ

>>44
ありがとう

良スレ上げ

>>40
アッセッンブラーのネ申様は絶対だ！
貴様もコーランコードを読め！

おませさんがアセンブラを使うことだとおもった

as mass semble
math e mat ic s

魔腺ブラ

Linux上でnasmを使いアセンブラの勉強をしたいと思っています。その際の教科書とする書籍なのですが、

はじめて読む8086
　　http://www.amazon.co.jp/exec/obidos/ASIN/4871482456/249-8419394-4696315
はじめて読む486
　　http://www.amazon.co.jp/exec/obidos/ASIN/4756102131/249-8419394-4696315

このふたつは内容が古いという話も聞きますけど、同じx86である以上本質はそんなに変わらないと思うのであまり問題ないですよね?
あと486の方は8086を読んだという前提の元話が展開されていくのですか？

#「こっちの方がお薦めだ！」というのがあるのならそれも教えていただけると嬉しい。

ここはマセンブラに関するスレだよ。

ぬぁ、騙された！
アセンブラ…　(;´Д｀) ﾊｧﾊｧ、に行ってきます。

総合スレ氏んだので緊急浮上

あげ

22 ：デフォルトの名無しさん ：04/08/15 00:54
Intelの「アーキテクチャマニュアル上中下巻」の日本語版
ついに落とせなくなったな。
USサイトで４巻verを落とさないといけない

四巻verって？

アセンブラでWindowsが作れるか？
http://pc5.2ch.net/test/read.cgi/win/1090858692/

>>56
ttp://support.intel.com/design/pentium4/manuals/index_new.htm#sdm_vol1

マセンブラってＭＡＳＭのことか？

28 ：名無し~3.EXE ：04/08/31 22:13 ID:jnhLxTSq
いつぞや、アメリカ人に若い人の言葉の乱れはどう思いますかって聞いたら、ほとんどの人が
別にいいんじゃないって言ってた。
言葉は変化するもの。だから何？　って感じ。

さすが多民族国家だと思った。

age

すいませんまじめに質問なんですが、
レジスタの値だけ右(左)シフト、ということはできないのですか？
たとえばshl ebx,ecxのように･･･
今日本買って始めたところなのでやさしくおねがいしますm(__)m

す
レ
た
今


どちらにしろ意味不明

>>62
その本にはshlの説明が乗っていないのか？
clが使えるって書いてあるだろう?

デバッグに>1は必要ないって本当?

高級言語だけですむPC向けプログラマのVBDEL厨には永遠に必要ないでしょうな。

すいませんアセンブラの本じゃなくて
そのうち1章でアセンブラの紹介があっただけなので載ってませんでした。。
ありがとうございますm(__)m

>>62
>今日本買って
｢いま、にっぽん買って｣に見えた

age

「行き遅れ」なら分かるが「生き遅れ」とはなんだ？

>>70
生き急がず、のんびりと人生を送っていて
時代に置いて行かれてしまう様子。または
そうなってしまった人。

オレはパソコンとかＯＳとかまともには買わないのよ。だいたい、もらうか、ジャンク。
本体はまあ古くても別にいいんだけど、ＯＳがね〜。なかなか手に入らない。秋葉原とか近ければよかったんだが。

そんなオレはプログラミングも世間とは5〜10年ズレている。いまだにDOS用MASMを愛用している。(って実はTASMだが(^^;))

Windowsの場合、始めたのは割と最近で、VBSとかでせこいのしか書いてこなかったんだが、この間、ついにC(++ではない)を使うことにした。(Borland C++。無料。)

そこで統合アーカイバDLL内の関数をちょこっと呼び出してみたんだが、呼び出した後のプログラムの挙動がおかしくなった。どうもある変数を破壊しているようなのだ。

コードからはさっぱり予想がつかない。何がまずいのか・・・ プログラムをちょこちょこ書き換えて実行テストした。問題の関数呼び出しの後でprintf()を呼ぶと変数がぶっ壊れていることを確認。

関数を呼ぶと変数が壊れる・・・・スタックか・・・？

そこで、スタックチェックコードを含めたり、スタックサイズを増やしたりした。しかし直らない。

そこでDOSでやっていたいつもの手。コードの徹底追跡である。

DOSで使っていたTurboDebuggerと、新しいTurboDebugger32(やはり無料)は全く同じといっていいインターフェースなので、カンタンに追跡できた。

目的はスタックの位置を監視すること。おそらくどこかでスタックがずれているに違いない。

もちろんCPUレベル(アセンブラ/機械語レベル)ウィンドウを開く。ソースレベルウィンドウでスタックの監視はできないからだ。

問題の関数前後をうろうろとトレースしてスタックを確認した。

あれっ？

・・・この関数がリターンしてきた後、pop ebxでスタック戻しているけど・・・戻しすぎじゃん！？

そこでオレは気付いた。

これパスカル型関数じゃねーか・・・

パスカル型関数はスタック戻しはいらない。

・・・オレはWindowsの関数がたいていC++の関数であり、さらに、C++の関数がパスカル型だということを知らなかったのだった・・・
(もちろんソースの拡張子には.cppではなく.cを付けていたのであった・・・)

そこで問題の関数にPASCALを付けて解決。不審な動作は一切消えてなくなったのであった・・・(.cppにする、という手もあるが・・・)

これはもちろん、オレが間抜けだと言えば間抜けなのだが、オレにアセンブラの知識がなければ、こんなに早く解答にはたどりつかなかっただろう。

コンピュータシステムは今や大変複雑である。
バグはどこにでもひそんでおり、ＯＳになのか、コンパイラになのか、ライブラリになのか、自分のコーディングになのか、予想は全くつかない。

ドライバがおかしいのか？いや、まてよ、このコンパイラ、以前のバージョン、バグあったよな・・・また同じようなバグか？

などと考えてみてもそう簡単に結果なんて出るはずはない。特に本人のコーディングの場合、間違えた本人が考えてるんだから・・・

結局最終的に間違いないのはアセンブラレベルのデバッグ。まあ、と言っても、いわゆる謎バグ、ハングとか、システムに近そうなバグの場合だけかもしれないけどね・・・

そうそう、あと、コンパイラのアセンブリ出力でバグ取りや新発見することも多いよね？オレはあれがないと死。

>>73
PASCALじゃなくてSTDCALL。(引数をどっちから置くのかが違う)
しかもC++にすれば解決という問題ではない。

アセンブラの知識がなくてもDLL関数は大抵STDCALLというWin32の常識を知っていればこんなことにはならない。

つうかDLL付属のヘッダはどうした？

だからWin32の知識が全くないから。
DOS時代のアセンブラの知識が役に立った、という話し。

>>引数をどっちから置くのかが違う
オレもそう思ったんだけど、Cコンパイラだからか何か、最左がスタックトップになってた。
STDCALLか・・・

それと、.cppに変えただけでいけるようになったけど？
というか参考にしたソースがそうなってたのだ。

ヘッダは何かドキュメント見るとダイナミックリンクの場合はいらないみたいなことが書いてあったから無視した。
んで自分でプロトタイプ書いたから苦労・・・
でもダイナミックリンクの場合、ポインタに後から値入れるから同じヘッダだとダメなような・・・？

ゴメン！

.cppにしただけじゃダメだね・・・その通りだった。

でもさ、参考にしたページがそうなってたのよ。
↓
http://www7.plala.or.jp/keny01/windows/win32/
Chapter 3 - 7 　 動的ライブラリ(DLL)を使う

この章の2番目のソースで
typedef WORD (* Func)(void);
となっていて、PASCALもSTDCALLもないんだけど、対象が引数なしだったんで、たまたま動いてるみたい。
このFuncを引数を一つ使うやつに書き換えてみたら見事にスタック戻しすぎな失敗コードが生成された（＾＾；）

要するに、このページの作者もSTDCALLとかよく知らないってことかな・・・？

あと、PASCALなんだけど、windef.hを見ると、
#elif (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED)
...
#define PASCAL __stdcall
...
#else
ってのがあるけど？

つうかVBとかのマクロ高級言語ならまだしも
メモリ操作やポインタ操作をする言語では
書いたコードから
メモリの状態やアセンブラコードを意識できないとまずい。

単なる文字列でしかないコード文章が
プログラミング言語のシステム上でどのように変わるのかを
理解してるやつとしてないやつじゃバグの生み具合が全然違う。

皆わかってるさ

Ｃで書いたプログラムを逆アセンブルしてみたら
びっくりするほどスパゲッティだった
こんなコード書く香具師は絶対クビになるな

組み込み系とかの仕事あるからなくなんないんじゃね？

>>82
いや、でも今は組み込み系もほとんどＣかＣ＋＋でやってるなあ。
ただ、コンパイラのバグが多いから結局アセンブラは使えないとだめだね。
とくに新参者のＣＰＵ＋コンパイラのとき。
そんなの採用するなって思うんだけどね。馬鹿な上司が採用してしまうのよ。

>>73
>バグはどこにでもひそんでおり、ＯＳになのか、コンパイラになのか、ライブラリになのか、自分のコーディングになのか、
>予想は全くつかない。

まあたいていは自分のコードだ。

>>79
>メモリ操作やポインタ操作をする言語では
>書いたコードから
>メモリの状態やアセンブラコードを意識できないとまずい。

メモリの状態は確かにそうだけど、アセンブラコードの方は微妙だと思うなあ。

>>84

＞まあたいていは自分のコードだ。

そうそう。
結構ヘビーなバグに出会って、なかなか気づかなくって「コンパイラバグってんじゃねーの」
って思う１０個のうち９個くらいは自分のコードか結合後のメッセージクロスとかが原因っての
が多いよね。でも残りの1個はやっぱりコンパイラのバグとかＯＳのバグだな。

オレはずーーっと悩んでたとき、ヒョッと回路図見たら、プルダウンしてない線が一本あって
実装パターンみたらやっぱりしてなかった、というバグを見つけたことがある・・・。

気づくのに一週間かかってしもうた。

コンパイラのバグを見つけたとして報告しないの？
しないなら何度でも同じバグに直面じゃん？

>>87
報告はするけどメーカーも即対応はしてくれないからね。
コンパイラがバグコードをはかないようにうまく作るのさ。

http://ZK169144.ppp.dion.ne.jp/
うぇｗｗｗｗｗｗｗｗｗｗｗｗうはっｗｗｗっおｋｗｗｗ

ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
っおｋｗｗｗｗｗｗおｋｗｗｗｗｗｗｗｗｗ

>>81
そりゃ最適化の結果ぢゃないの？

>>81
多分そうだと思う。
オプティマイザをＯＦＦにしてると、だいたいＣソースそのままのアセンブラを
はいてくれるはずだ。

>>90
そらそうだが、いきなり人間がこんなコード書いたらって話しだろ

>>92
でも、それはそれである意味貴重な人材だと思う。
自分の頭の中で、ＣＰＵとその周辺の動作が完璧にシミュレートできて、コンパイラに任せるまでもなく
自身で最適化できるのだから・・・。

>>92
最近のCPUは下手にトリッキーなコード吐くよりも、いい意味でスパゲッティ状
のコードの方が速く走ったりするしな。
いかに分岐を減らすか、が最重要だったりする。

速さよりもメンテナンス性を重要視してくれよう

ゲームプログラマなら普通、外積・内積・行列の掛け算・変換くらいはアセンブラで書くでしょ。

時代遅れとかそういう問題ではないわな。

嫁き遅れ

そもそも、アセンブラじゃ開発効率が悪いから
CやらC++で、実際の開発は行われてると思うのだが。

100^^

プログラムの９５％の実行時間はごく一部に集中してるんだろ。
そこだけマセンブラ化すりゃいいじゃないか。

http://www.google.co.jp/search?hl=ja&q=%E3%83%9E%E3%82%BB%E3%83%B3%E3%83%96%E3%83%A9&lr=
http://www.google.co.jp/search?hl=ja&q=%E7%94%9F%E3%81%8D%E9%81%85%E3%82%8C&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=
どっちもこのスレ1位だｗ

>>96
語弊があると思うな
単機能の関数ならライブラリの使うだろ
組み合わせのときに、中間結果使い回しとか、レジスタ節約とかで書くけど

しばらく休んでましたがまたはじめましょうよ。

パスクラックするプログラムをアセンブラで組んだら速くなりますか？

>ゲームプログラマなら普通、外積・内積・行列の掛け算・変換くらいはアセンブラで書くでしょ。
そんな計算をアセンブラで組んでも実行速度変わらないけど。

電源ONしてからmain関数先頭までは結局アセンブラで書くしかない。
ドライバ書くときもものによっては一部アセンブラで書くはず。
後は低水準ライブラリを自前で用意しなきゃならん場合とか
DSP特有の命令書くときとかかな。

>>96
言ってるのは最後のに近いのかな。
コンパイラはDSP特有命令を有効に使ってくれないから
結局アセンブラで書くしかないんだよ。
経験上コンパイラまかせより1.5〜2倍くらいの実行速度になるよ。

ちなみに実行速度改善を目的でアセンブラで書く場合、
下手にこちょこちょいじって命令数少なくするよりも
パイプラインがつまらない様に分岐なくすことのほうが効果あるな。

ま、こうゆうのはハードウェア依存大きいから一般論には
ならないかもしれんが。

アセンブラで最適化しても、
キャッシュから外れたデータを読みにいった瞬間全てがおじゃんになる。
そういうのはプロセス切り替えの瞬間に相当な確率で起こる。
だから、アセンブラでちょっとだけ最適化できたとしても意味ない。

そんなことするよりは、
Ｃ言語上でメモリアクセスを効率化したり、
データ構造とかアルゴリズムを改善したりする方が
10000000000倍くらい生産的だと思うけど。

つうか普通アセンブラで最適するのは最後の手段

最後の手段でもつかわんなぁ。
使わんし使わせんし使う必要なし。

だからといってわからないのはいかん。
使えんとだめ！！

Z80の時代からずっとアセンブラ。
生産的じゃないけどさ、パズル解くみたいでやってて面白い。

でも、x64になって、インラインアセンブラが使えなくなってしまった...悲しい。

Z89の時代からずっとコンパイラ。
少しでも楽に書ける方がいいから。

でも、スタートアップルーチンみたいにどうしても
アセンブラで書かなくっちゃいけない時もあるし
コンパイラの動作が怪しいときはアセンブラリストで
チェックして解決することもあるしね、
アセンブラを知ってた方が有利ってのはある。

高級言語でドライバのプログラミングができるか！！！

なにをもって高級言語という？

Ｃ、Ｃ＋＋でドライバーは書けるぞ。
インラインアセンブラがほんのわずか入るが。

アセンブラのサービスルーチンとくっつけてゴソゴソやり始めると、結局ある
程度の範囲はアセンブラで書きたくなってくるよ。

>>114
だからそれらは低級言…て、2バイト英字かよ。

Cを高級言語と言うかどうかは別にして
WindowやLinuxのデバイスドライバは殆どCで書かれているわけだが。

マセンブラのおかげでC言語が理解できました。
Cのポインタとか配列とか関数呼び出しとか、
マセンブラレベルで考えないと本質的に理解できんですわ。

ポインタはショートカット