マセンブラ言語は時代錯誤の生き遅れ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG8Bit、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
0002デフォルトの名無しさん
NGNG0003デフォルトの名無しさん
NGNG0004デフォルトの名無しさん
NGNG汗んブラなら知ってますが。
0005デフォルトの名無しさん
NGNGああ、業務系とかやってる人だとそうなんだろうね。
0006デフォルトの名無しさん
NGNG0007デフォルトの名無しさん
NGNG>今時、アセンブリ言語でプログラムを組む機会はほとんどない。
>このまま、CPUの速度が向上すれば、VM上で動作する言語で
>ほとんどのアプリが作成されるようになるんじゃないの？
っていうのはとっくの昔にそうなっているとも言える
0008デフォルトの名無しさん
NGNG0009デフォルトの名無しさん
NGNGそんなことアリマセンブラ
0010デフォルトの名無しさん
NGNG0011デフォルトの名無しさん
NGNGミラクルブラって何だろ。
0012デフォルトの名無しさん
NGNG女プログラマはブラをせんと言うことだ。なかなかイイ職場だぞ。
0013デフォルトの名無しさん
NGNGむしろそれが獣心を駆り立てていいと言う奴もちらほら
0014デフォルトの名無しさん
NGNG0015デフォルトの名無しさん
NGNG0016デフォルトの名無しさん
NGNGってのもよくわからん
0017デフォルトの名無しさん
NGNG0018デフォルトの名無しさん
NGNG0019デフォルトの名無しさん
NGNG0020デフォルトの名無しさん
NGNG0021デフォルトの名無しさん
NGNG0022デフォルトの名無しさん
NGNGついに落とせなくなったな。
USサイトで４巻verを落とさないといけない
0023デフォルトの名無しさん
NGNG高速計算が求められる計算ではアセンブラレベルで高速化することもある。
早い話がケースバイケース。
0024デフォルトの名無しさん
NGNG0025デフォルトの名無しさん
NGNGそこそこ使っている人もいるようだ。
意味は全くわからんが。
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
0026デフォルトの名無しさん
NGNGだろ？
0027デフォルトの名無しさん
NGNG| M ヽ
|从 ﾘ）〉
|ﾟ ヮﾟﾉ| ………
ミ)} i !
|_/ヽ|」
|'
0028デフォルトの名無しさん
NGNGLDA "nullpo"
STA $0000
0029デフォルトの名無しさん
NGNG0030デフォルトの名無しさん
NGNG／, /,｀ ´,ヽﾞ､ 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/: : ,.ヽ
0031デフォルトの名無しさん
NGNGライブラリや C 自体がおかしいときは、デバッガでアッセンブラ
レベルを追っていくことが多くあるはず。
そんな必要がないプログラマーは幸せだが。
0032デフォルトの名無しさん
NGNGS + assembler で 左遷ぶら
0033デフォルトの名無しさん
NGNG>ライブラリや C 自体がおかしいときは、デバッガでアッセンブラ
>レベルを追っていくことが多くあるはず。
で、無駄にアセンブラを追っかけて、最終的に自分のバグだったことに
気づくのが遅れるわけね（最終的に「気づかない」香具師もいるが）。
最初からソースだけを調べていれば、直ぐに解決するはずなのに・・・
0034デフォルトの名無しさん
NGNGシリコンチップのドーパントが足りなかったとき、どうしてる？
マザーボードがマイグレーションを起こしていたとき、どうしてる？
HDD のディスクの表面粗さがやたら大きかったとき、どうしてる？
・・・
そんな必要がないプログラマーは幸せだねっ！
0035デフォルトの名無しさん
NGNGオレなら、ハード担当に丸投げするけどね
0036デフォルトの名無しさん
NGNG自分が理解不能なものを全て否定する癖よくない。
0037デフォルトの名無しさん
NGNG0038デフォルトの名無しさん
NGNGCPU を交換することを知らないのか。幸せだね
0039デフォルトの名無しさん
NGNGなぜ、そんなことが言える？
通常､アッセンブラー・デバッグに入るのは、ソースだけでは解からないからのはず。
おまえ、本当はアッセンブラ・デバッグなんてできないだろう。
0040デフォルトの名無しさん
NGNGとりあえず、気持ち悪いから「アセンブラ」と言ってくれ。
0041デフォルトの名無しさん
NGNG「はず」
0042デフォルトの名無しさん
NGNG0043デフォルトの名無しさん
NGNG0044デフォルトの名無しさん
NGNGftp://download.intel.co.jp/jp/developer/jpdoc/から24547?03.pdfをうわｌｔ何をすｒｄｋｗｎｓｇ
0045デフォルトの名無しさん
NGNGありがとう
0046デフォルトの名無しさん
NGNG0047デフォルトの名無しさん
NGNGアッセッンブラーのネ申様は絶対だ！
貴様もコーランコードを読め！
0048デフォルトの名無しさん
NGNG0049デフォルトの名無しさん
NGNGmath e mat ic s
0050デフォルトの名無しさん
NGNG0051デフォルトの名無しさん
NGNGはじめて読む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を読んだという前提の元話が展開されていくのですか？
#「こっちの方がお薦めだ！」というのがあるのならそれも教えていただけると嬉しい。
0052デフォルトの名無しさん
NGNG005351
NGNGアセンブラ… (;´Д｀) ﾊｧﾊｧ、に行ってきます。
0054デフォルトの名無しさん
NGNG0055デフォルトの名無しさん
NGNG0056デフォルトの名無しさん
NGNGIntelの「アーキテクチャマニュアル上中下巻」の日本語版
ついに落とせなくなったな。
USサイトで４巻verを落とさないといけない
四巻verって？
0057デフォルトの名無しさん
NGNGhttp://pc5.2ch.net/test/read.cgi/win/1090858692/
0058デフォルトの名無しさん
NGNGttp://support.intel.com/design/pentium4/manuals/index_new.htm#sdm_vol1
0059デフォルトの名無しさん
NGNG0060デフォルトの名無しさん
NGNG28 ：名無し~3.EXE ：04/08/31 22:13 ID:jnhLxTSq
いつぞや、アメリカ人に若い人の言葉の乱れはどう思いますかって聞いたら、ほとんどの人が
別にいいんじゃないって言ってた。
言葉は変化するもの。だから何？ って感じ。
さすが多民族国家だと思った。
0061デフォルトの名無しさん
NGNG0062旅人達 ◆ahGjnhNBTw
NGNGレジスタの値だけ右(左)シフト、ということはできないのですか？
たとえばshl ebx,ecxのように･･･
今日本買って始めたところなのでやさしくおねがいしますm(__)m
0063デフォルトの名無しさん
NGNGレ
た
今
どちらにしろ意味不明
0064デフォルトの名無しさん
NGNGその本にはshlの説明が乗っていないのか？
clが使えるって書いてあるだろう?
0065デフォルトの名無しさん
NGNG0066デフォルトの名無しさん
NGNG0067旅人達 ◆ahGjnhNBTw
NGNGそのうち1章でアセンブラの紹介があっただけなので載ってませんでした。。
ありがとうございますm(__)m
0068デフォルトの名無しさん
NGNG>今日本買って
｢いま、にっぽん買って｣に見えた
0069デフォルトの名無しさん
05/02/05 10:23:490070デフォルトの名無しさん
05/02/09 13:18:350071デフォルトの名無しさん
05/02/14 15:47:51生き急がず、のんびりと人生を送っていて
時代に置いて行かれてしまう様子。または
そうなってしまった人。
0072デフォルトの名無しさん
2005/04/30(土) 05:43:11本体はまあ古くても別にいいんだけど、ＯＳがね〜。なかなか手に入らない。秋葉原とか近ければよかったんだが。
そんなオレはプログラミングも世間とは5〜10年ズレている。いまだにDOS用MASMを愛用している。(って実はTASMだが(^^;))
Windowsの場合、始めたのは割と最近で、VBSとかでせこいのしか書いてこなかったんだが、この間、ついにC(++ではない)を使うことにした。(Borland C++。無料。)
そこで統合アーカイバDLL内の関数をちょこっと呼び出してみたんだが、呼び出した後のプログラムの挙動がおかしくなった。どうもある変数を破壊しているようなのだ。
コードからはさっぱり予想がつかない。何がまずいのか・・・ プログラムをちょこちょこ書き換えて実行テストした。問題の関数呼び出しの後でprintf()を呼ぶと変数がぶっ壊れていることを確認。
関数を呼ぶと変数が壊れる・・・・スタックか・・・？
そこで、スタックチェックコードを含めたり、スタックサイズを増やしたりした。しかし直らない。
そこでDOSでやっていたいつもの手。コードの徹底追跡である。
DOSで使っていたTurboDebuggerと、新しいTurboDebugger32(やはり無料)は全く同じといっていいインターフェースなので、カンタンに追跡できた。
目的はスタックの位置を監視すること。おそらくどこかでスタックがずれているに違いない。
もちろんCPUレベル(アセンブラ/機械語レベル)ウィンドウを開く。ソースレベルウィンドウでスタックの監視はできないからだ。
問題の関数前後をうろうろとトレースしてスタックを確認した。
007372
2005/04/30(土) 05:45:15・・・この関数がリターンしてきた後、pop ebxでスタック戻しているけど・・・戻しすぎじゃん！？
そこでオレは気付いた。
これパスカル型関数じゃねーか・・・
パスカル型関数はスタック戻しはいらない。
・・・オレはWindowsの関数がたいていC++の関数であり、さらに、C++の関数がパスカル型だということを知らなかったのだった・・・
(もちろんソースの拡張子には.cppではなく.cを付けていたのであった・・・)
そこで問題の関数にPASCALを付けて解決。不審な動作は一切消えてなくなったのであった・・・(.cppにする、という手もあるが・・・)
これはもちろん、オレが間抜けだと言えば間抜けなのだが、オレにアセンブラの知識がなければ、こんなに早く解答にはたどりつかなかっただろう。
コンピュータシステムは今や大変複雑である。
バグはどこにでもひそんでおり、ＯＳになのか、コンパイラになのか、ライブラリになのか、自分のコーディングになのか、予想は全くつかない。
ドライバがおかしいのか？いや、まてよ、このコンパイラ、以前のバージョン、バグあったよな・・・また同じようなバグか？
などと考えてみてもそう簡単に結果なんて出るはずはない。特に本人のコーディングの場合、間違えた本人が考えてるんだから・・・
結局最終的に間違いないのはアセンブラレベルのデバッグ。まあ、と言っても、いわゆる謎バグ、ハングとか、システムに近そうなバグの場合だけかもしれないけどね・・・
そうそう、あと、コンパイラのアセンブリ出力でバグ取りや新発見することも多いよね？オレはあれがないと死。
0074デフォルトの名無しさん
2005/04/30(土) 08:40:35PASCALじゃなくてSTDCALL。(引数をどっちから置くのかが違う)
しかもC++にすれば解決という問題ではない。
アセンブラの知識がなくてもDLL関数は大抵STDCALLというWin32の常識を知っていればこんなことにはならない。
つうかDLL付属のヘッダはどうした？
007573
2005/04/30(土) 10:54:30DOS時代のアセンブラの知識が役に立った、という話し。
>>引数をどっちから置くのかが違う
オレもそう思ったんだけど、Cコンパイラだからか何か、最左がスタックトップになってた。
STDCALLか・・・
それと、.cppに変えただけでいけるようになったけど？
というか参考にしたソースがそうなってたのだ。
007673
2005/04/30(土) 10:58:32んで自分でプロトタイプ書いたから苦労・・・
でもダイナミックリンクの場合、ポインタに後から値入れるから同じヘッダだとダメなような・・・？
007773
2005/05/01(日) 18:41:33.cppにしただけじゃダメだね・・・その通りだった。
でもさ、参考にしたページがそうなってたのよ。
↓
http://www7.plala.or.jp/keny01/windows/win32/
Chapter 3 - 7 動的ライブラリ(DLL)を使う
この章の2番目のソースで
typedef WORD (* Func)(void);
となっていて、PASCALもSTDCALLもないんだけど、対象が引数なしだったんで、たまたま動いてるみたい。
このFuncを引数を一つ使うやつに書き換えてみたら見事にスタック戻しすぎな失敗コードが生成された（＾＾；）
要するに、このページの作者もSTDCALLとかよく知らないってことかな・・・？
007873
2005/05/01(日) 18:42:33#elif (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED)
...
#define PASCAL __stdcall
...
#else
ってのがあるけど？
0079デフォルトの名無しさん
2005/05/01(日) 19:13:48メモリ操作やポインタ操作をする言語では
書いたコードから
メモリの状態やアセンブラコードを意識できないとまずい。
単なる文字列でしかないコード文章が
プログラミング言語のシステム上でどのように変わるのかを
理解してるやつとしてないやつじゃバグの生み具合が全然違う。
0080デフォルトの名無しさん
2005/05/01(日) 21:56:270081デフォルトの名無しさん
2005/05/01(日) 22:40:59びっくりするほどスパゲッティだった
こんなコード書く香具師は絶対クビになるな
0082デフォルトの名無しさん
2005/05/02(月) 06:46:580083デフォルトの名無しさん
2005/05/05(木) 06:37:09いや、でも今は組み込み系もほとんどＣかＣ＋＋でやってるなあ。
ただ、コンパイラのバグが多いから結局アセンブラは使えないとだめだね。
とくに新参者のＣＰＵ＋コンパイラのとき。
そんなの採用するなって思うんだけどね。馬鹿な上司が採用してしまうのよ。
0084デフォルトの名無しさん
2005/05/05(木) 11:17:54>バグはどこにでもひそんでおり、ＯＳになのか、コンパイラになのか、ライブラリになのか、自分のコーディングになのか、
>予想は全くつかない。
まあたいていは自分のコードだ。
>>79
>メモリ操作やポインタ操作をする言語では
>書いたコードから
>メモリの状態やアセンブラコードを意識できないとまずい。
メモリの状態は確かにそうだけど、アセンブラコードの方は微妙だと思うなあ。
0085デフォルトの名無しさん
2005/05/05(木) 15:17:59＞まあたいていは自分のコードだ。
そうそう。
結構ヘビーなバグに出会って、なかなか気づかなくって「コンパイラバグってんじゃねーの」
って思う１０個のうち９個くらいは自分のコードか結合後のメッセージクロスとかが原因っての
が多いよね。でも残りの1個はやっぱりコンパイラのバグとかＯＳのバグだな。
0086デフォルトの名無しさん
2005/05/05(木) 15:21:42実装パターンみたらやっぱりしてなかった、というバグを見つけたことがある・・・。
気づくのに一週間かかってしもうた。
0087デフォルトの名無しさん
2005/05/05(木) 20:46:18しないなら何度でも同じバグに直面じゃん？
0088デフォルトの名無しさん
2005/05/05(木) 21:09:28報告はするけどメーカーも即対応はしてくれないからね。
コンパイラがバグコードをはかないようにうまく作るのさ。
0089デフォルトの名無しさん
2005/05/05(木) 21:18:22うぇｗｗｗｗｗｗｗｗｗｗｗｗうはっｗｗｗっおｋｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
っおｋｗｗｗｗｗｗおｋｗｗｗｗｗｗｗｗｗ
0090デフォルトの名無しさん
2005/05/06(金) 12:05:53そりゃ最適化の結果ぢゃないの？
0091デフォルトの名無しさん
2005/05/06(金) 12:20:41多分そうだと思う。
オプティマイザをＯＦＦにしてると、だいたいＣソースそのままのアセンブラを
はいてくれるはずだ。
0092デフォルトの名無しさん
2005/05/07(土) 14:58:12そらそうだが、いきなり人間がこんなコード書いたらって話しだろ
0093デフォルトの名無しさん
2005/05/07(土) 17:05:33でも、それはそれである意味貴重な人材だと思う。
自分の頭の中で、ＣＰＵとその周辺の動作が完璧にシミュレートできて、コンパイラに任せるまでもなく
自身で最適化できるのだから・・・。
0094デフォルトの名無しさん
2005/05/07(土) 17:22:49最近のCPUは下手にトリッキーなコード吐くよりも、いい意味でスパゲッティ状
のコードの方が速く走ったりするしな。
いかに分岐を減らすか、が最重要だったりする。
0095デフォルトの名無しさん
2005/05/07(土) 17:24:390096デフォルトの名無しさん
2005/05/07(土) 18:28:100097デフォルトの名無しさん
2005/05/07(土) 18:28:320098デフォルトの名無しさん
2005/05/07(土) 18:39:470099デフォルトの名無しさん
2005/05/07(土) 20:34:28CやらC++で、実際の開発は行われてると思うのだが。
0100デフォルトの名無しさん
2005/05/07(土) 20:43:190101デフォルトの名無しさん
2005/05/07(土) 20:57:08そこだけマセンブラ化すりゃいいじゃないか。
0102デフォルトの名無しさん
2005/05/07(土) 21:16:20http://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位だｗ
0103デフォルトの名無しさん
2005/05/11(水) 15:23:23語弊があると思うな
単機能の関数ならライブラリの使うだろ
組み合わせのときに、中間結果使い回しとか、レジスタ節約とかで書くけど
0104デフォルトの名無しさん
2005/06/19(日) 20:02:180105デフォルトの名無しさん
2005/06/19(日) 20:06:230106デフォルトの名無しさん
2005/06/19(日) 20:26:07そんな計算をアセンブラで組んでも実行速度変わらないけど。
0107デフォルトの名無しさん
2005/06/19(日) 21:32:28ドライバ書くときもものによっては一部アセンブラで書くはず。
後は低水準ライブラリを自前で用意しなきゃならん場合とか
DSP特有の命令書くときとかかな。
>>96
言ってるのは最後のに近いのかな。
コンパイラはDSP特有命令を有効に使ってくれないから
結局アセンブラで書くしかないんだよ。
経験上コンパイラまかせより1.5〜2倍くらいの実行速度になるよ。
ちなみに実行速度改善を目的でアセンブラで書く場合、
下手にこちょこちょいじって命令数少なくするよりも
パイプラインがつまらない様に分岐なくすことのほうが効果あるな。
ま、こうゆうのはハードウェア依存大きいから一般論には
ならないかもしれんが。
0108デフォルトの名無しさん
2005/06/19(日) 22:00:22キャッシュから外れたデータを読みにいった瞬間全てがおじゃんになる。
そういうのはプロセス切り替えの瞬間に相当な確率で起こる。
だから、アセンブラでちょっとだけ最適化できたとしても意味ない。
そんなことするよりは、
Ｃ言語上でメモリアクセスを効率化したり、
データ構造とかアルゴリズムを改善したりする方が
10000000000倍くらい生産的だと思うけど。
0109デフォルトの名無しさん
2005/06/19(日) 22:03:050110デフォルトの名無しさん
2005/06/24(金) 17:53:48使わんし使わせんし使う必要なし。
だからといってわからないのはいかん。
使えんとだめ！！
0111デフォルトの名無しさん
2005/06/24(金) 18:02:29生産的じゃないけどさ、パズル解くみたいでやってて面白い。
でも、x64になって、インラインアセンブラが使えなくなってしまった...悲しい。
0112デフォルトの名無しさん
2005/06/24(金) 18:39:06少しでも楽に書ける方がいいから。
でも、スタートアップルーチンみたいにどうしても
アセンブラで書かなくっちゃいけない時もあるし
コンパイラの動作が怪しいときはアセンブラリストで
チェックして解決することもあるしね、
アセンブラを知ってた方が有利ってのはある。
0113デフォルトの名無しさん
2005/06/24(金) 18:55:000114デフォルトの名無しさん
2005/06/25(土) 06:34:28Ｃ、Ｃ＋＋でドライバーは書けるぞ。
インラインアセンブラがほんのわずか入るが。
0115デフォルトの名無しさん
2005/06/25(土) 06:52:26程度の範囲はアセンブラで書きたくなってくるよ。
0116デフォルトの名無しさん
2005/06/25(土) 15:38:22だからそれらは低級言…て、2バイト英字かよ。
0117デフォルトの名無しさん
2005/06/30(木) 14:10:52WindowやLinuxのデバイスドライバは殆どCで書かれているわけだが。
0118デフォルトの名無しさん
2005/10/31(月) 16:56:56Cのポインタとか配列とか関数呼び出しとか、
マセンブラレベルで考えないと本質的に理解できんですわ。
0119名無し募集中。。。
2005/10/31(月) 23:11:02■ このスレッドは過去ログ倉庫に格納されています