アセンブラ初心者スレッド 2©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>726
8bit整数を扱うだけで済む処理なら簡単だが、8bitを超える可能性がある処理だと途端に面倒になる。
8bitなんてすぐ溢れる。 簡単さだったら新しいCISCに分があるんじゃね
ttps://uploader.purinka.work/src/17167.png
R0はスタックポインタ。呼び出し規約の都合上引数の一部が
スタックに積まれている以外はamd64と同じ感じか
同じ8bitでも8051とAVRじゃ大分違うと思う 命令を覚える命令を使うのが簡単か
同じ機能を実現するのが簡単か
で結果が180度違う 8bitCPUのソフトエンジニア
64bitCPUのソフトエンジニア
どちらがより多くの知識や経験が必要か
一般的には64bitの方が必要 本当はわかっていて、ちょっと言い合いたいだけだろうな >>731
規模が小さいなら64bitでも簡単。Intel系なら命令も上位互換だからほぼ同じ命令が使える。 IA-32よりAMD64の方が簡単なんじゃないか説(汎用レジスタの本数的に) 8bitが簡単と言われるのは命令の数が限られてるのと、簡単なことしかしないから
64bitでもよく使われる限られた命令だけ使って、8bitと同じことをやれば
8bitよりも簡単
実際は周辺や割り込みコントローラなんかもリッチになるので大変だけどね
Arduinoみたいにそのあたりを意識しないなら64bitの方が8bitよりも簡単 >>739
Arduinoだと普通はArduino IDE使うからほぼCで書けるよね
わざわざアセンブラ使うかな それ言い出したら
そもそも普通はアセンブラなんか使わん アセンブラでしか書けない特殊処理(特殊命令、特殊レジスタへのアクセスなど)
速度やリソースのチューニング
趣味 まあ趣味だな。Cで書けない処理をアセンブラで書けたら「やった」て気になるしな。 それはアセンブラでしか書けない特殊処理ではなくて? 趣味だからどういう処理でも自分が満足できればそれでいいんじゃね?
簡単な処理から始めてだんだん難しい処理に挑戦するのも面白いし 組み込みで非標準的な実装をしたい場合はアセンブラを使ったりするな 仮にアセンブラの本を書くとして、その題材になにを選ぶか、アセンブラだからこそできる!というナイスな題材がほとんど思いつかないのです… 思いつかないってことは、本当にやりたいと思ってないってことだろうな。
たとえば部屋で飼ってる猫の様子を出先から監視したいと思ったらArduinoとカメラユニットを組み合わせて
スマホから見られる制御ソフトを作るだろう。 >>749
それはアセンブラだからこそできる、という題材ですか? スタートアップコードの記述
OS作成
くらいじゃね? パフォーマンス系なら
DSP制御とか
リアルタイム系の重い処理とか ペリフェラルAとペリフェラルBを同期させて動かしたいなんて場合はアセンブラの使用を検討する えらい抽象的だな
タイミングにシビアなのはコンパイラに依存しないようにアセンブラで書くってのはある
もちろんシビアな部分だけ >>747
これも抽象的で何の実装だかさっぱりわからん >>748
やっぱり、SIMD命令とか組み込みだとDSP命令を使いたい時とかじゃないの? 最近ではSIMDやDSP命令はCの文法で記述出来るのが普通
もちろんガチガチのチューニングはアセンブラが一番だから
結局チューニングという範疇 >>750
俺は「アセンブラだからこそ」という制限など付けていない。そういう制限はあんたが勝手に付けたものだ。
作りたいものを作る。それが趣味だ。
違うと思うなら自分で考えてアセンブラだからこそというものを作ればいい。 >>753
趣味なんだから適すかどうかは関係ない。適さないと思うなら作らなければいい。
人それぞれだ。 趣味ならアセンブラを使う理由なんて何でも良い
でもどうせならアセンブラを使うことでメリットが何かしら得られる方が良い
そのメリットは大きい方が良い
と思うのは普通かと >>761
趣味は一般的なメリットなんか考えてたらできない。
鉄ヲタなんか、自分で電車運転したいためだけにパソコンのシミュレータを自作してる。
それも20年もかけて作って値段は0。タダで配ってる。金銭的なメリットはゼロだ。
窓から見える信号機や駅のデータも手間暇かけて現地に行ってパソコンのデータに変換してる。
運転席の計器類やすれ違う電車のモデルやデザイン、色まで正確に再現してる。
とてもこれだけの手間に見合うメリットがあるとは思えない。
でもこれだけの無駄をしてもやりたいのが趣味なんだよ。
鉄ヲタがアセンブラを使うとしたら、電車が動くスピードが少し遅く感じるから本物と同じくらい反応を早くしたいと
思ったらすぐ使うだろう。とにかくやりたいからやる。それ以外のことは考えないのが趣味だよ。 再現性がメリット
ならそれでいいじゃん
アセンブラを使うことで
高速化とか
リソースの節約とか
それもメリット
高速化もせず
リソースも変わらず
質が落ちる
だと何のためのアセンブラ? amd64+Linuxでアセンブラを始めたのですが、スタックの状態を勘違いしてのバグや
システムコール時のレジスタの退避し忘れのバグ等に悩まされてます
スタックの利用状況を分かりやすく表示してくれたり、レジスタの状態をチェックしてくれたり
するような、統合開発環境みたいなのはありませんでしょうか アセンブラだと自己書き換えコードが出来るぞ
それによる考えられるメリットは様々あり、ここでは書きにくいこともあるw
あと、正確なことは分からんが、OS開発ではアセンブラがしばしば使われていて、特にブートローダーの開発で使われていると聞いたことがあるな
他にはマイコンだとアセンブラの方が開発しやすいこともあったりするのか?知らんけど
俺は、スレッドセーフなプログラミングにはアセンブラの知識が不可欠だと思っているが、これは他者の意見も聞きたいところだな
他にもアセンブラでしか出来ないことはあるのにアセンブラは趣味の為ときたもんだ(怒)
まずコンパイラは確実
エミュレータなんかもそうじゃないのか?知らんけど >>767
Linuxでは知らんが、VSのデバッガだと、EAXなどのマシンレジスタの内容を常時
表示できる。
スタックに関しては、push、pop を組にすることと、ちゃんと数える習慣を
付けるしかない。
アセンブラは、言語仕様は簡単に思えるかもしれないが、頭脳が必要。
それはちょうど、数学が小学生でも理解できる四則演算だけを組み合わせているだけ
なのに、大部分の人がどこかで難しくなってしまうのと同じようなもの。 >>771
おまえが数学を知らないという事は良くわかった 今時のGUIなデバッガだったらブレーク時にスタックやレジスタの内容を表示できるのは普通じゃね?
個人的にはパイプラインの動作状況を表示してくれるデバッガとか欲しいわ
依存関係に起因するNOP率とか、原因となっている命令の特定とか アセンブラに詳しい人はスゴい人多いから失礼な態度はとらない方がいいと思う >>767
アセンブラだからと言って人間が1から10まで考えなくてもいいんだよ。
間違いやすい処理はできるだけソフトやツールにさせるように考え方を変えればいい。
スタックの状態が間違いやすいと思うなら、スタックを管理するマクロを組めばいいし、
レジスタ退避を忘れるなら、レジスタ退避するマクロを組んでそれを使えばいい。 その昔8051用のソフトをフルアセンブラで開発したことがある。デバッグは8個のLEDのみ
1500程度のコードだけどスタックや汎用レジスタの操作で苦労した記憶はないな
ペリフェラルの使い方等は大苦戦だったが
>>767は何を作っているのだろうか。IA-32ならともかくAMD64ならレジスタ本数も多いし
複雑なスタック操作をする機会は多くないと思うんだが >>784
おれの方がアセンブラ技術も数学も上だから
何の問題もない スタックにデータ積んでサブルーチンに渡す時がずれやすい 今のアセンブラの需要って
・OS等の低レイヤーの処理をする
・高速化。1クロックでも節約したい
・リアルタイム。nクロック後に○○を実行する必要がある
こんなもんか? >>798
この業界では、アセンブラが使える人と使えない人ではやはり使える人の方が尊敬されるよね そういう歪んだ価値観のせいで
アセンブラじゃなくて良い所までアセンブラにするアホがいる 役に立ってる人は忙しいのでわざわざこんな辺鄙なところに描き込みに来る暇がない
自分も役に立ってない >>801
Cが得意だと何でもCで書こうとする。
アセンブラが得意だと何でもアセンブラで書こうとする。
プログラマなら良くあること。
アセンブラがそれほど得意でない人が見たら余計なことと思うんだろうけど。 >>805
そういう人はエンジニアとして三流。賃金も三流で良い PICマイコンみたく用途が限られてると、返ってアセンブラの方が短かったりする。 おいらがマシン語勉強した時(Z80A)ニモニック表見て作ってたね
相対ジャンプなんか手で計算して 今でもコード覚えてるよ LD A = 3E とか LD Bは06とか
アセンブラが手に入った時はなんて便利なんや〜と感動した
当時は子供でまさか仕事でもアセンブラ組むとは思わなかったけどね http://www.yamamo10.jp/yamamoto/comp/Z80/instructions/index.php#LOAD08
A や B にイミディエイト値を入れる場合
00DDD110
DDD はレジスタ番号
B=0, C=1, D=2, E=3, H=4, L=5, A=7
LD B,n は 00000110 (06), n
LD A,n は 00111110 (3E), n
なんで DDD=6 は飛んでるんだっけ (HL) が DDD=110 相当にみえなくもないが
命令デコーダーの都合なんだろうな >>806
他人の評価などどうでもいい。俺もそんな古くさい見方しかできないあんたを三流と言ってあげよう。 >>810
原則的には、DDD=6 は、(HL)に相当している。 >>814
昔の事だったし、資料が手元に無いが、原則論として
DDDとかのレジスタ番号の1つとして、(HL)が書いてあり、
それがDDD=6だったと思う。
ただし、原則論なので、全ての命令でDDD=6にすれば必ず合法で、
(HL)になるという意味ではない。 >>816
リンク先のページでも、
INC r; DEC r; LD r1,r2; LD r2, r1 においても、DDD=6は、(HL)の命令に該当
していることが分かる。 AND, OR, XOR, ADD, ADC, SUB, SBC, CP,
やローテート、シフト命令でも、レジスタ様の命令で、
レジスタ番号を6にすると、(HL)に対する命令と同じ
マシン語になっていることが分かる。 x86_64のアセンブラを始めようと思ってるのですが、レジスタの使い方を教えてください
以前、80286の頃だと、たとえばECXレジスタはカウンタ用に使うものだったと記憶してますが
x86_64だとほぼもう汎用レジスタとして使えるように見えます
gccなどもx86_64用でもそういうコードを出力するようです
昔の用途での使い方について、どれくらい意識した方がよいのでしょう >>820
CPUの世代によっては、loop 命令は、
dec ecx
jnz ラベル名
とするよりも遅いことがあるので、後者の書き方の方が良い。
その意味で、ループカウンタを入れるレジスタとして、ecxにこだわる必要はない。
ただし、rep movsd などでは今でもカウンタが ecx に固定されている。
それ以外の場面では、ecxは、他の汎用レジスタと同じと考えてよい。
なお、ebpは汎用レジスタとしては使わず、スタックフレームの先頭アドレスを保持して、
ローカル変数をアクセスするために使うことが原則。
ただし、ローカル変数をebpの代わりにespを介してアクセスすることによって
ebpを汎用レジスタとして使う流儀も有り得る。
その場合は、push,pop命令によってespが変化してしまうので注意が必要となる。
なお、masmのlocalやarg擬似命令は、ebp方式を前提としている。
edi,esi は、movsd で使うことは意識しておく。
edx,eaxは、div命令で使うことを意識しておく。
edi,esi,ebpは、関数呼び出しで保存されるが、eax,ebx,ecx,edxは保存されないことを意識しておく。
eaxは関数呼び出しの戻り値になることを意識しておく。 >>821
さらに、dec reg 命令より、sub reg,1 の方が速いことがある。
前者は2クロック、後者は1クロック。なので、loop文は、
sub ecx,1
jnz ラベル名
と書くのが最良。 レジスタが増えてるし
SIMDレジスタもあるんで
自由度は高い
MULとDIVは相変わらずRAX, RDX縛りがあるけど 820です
回答ありがとうございました
ABIやライブラリ等での使い方・縛りを考慮して使うようにすると、
やはりそれぞれのレジスタをアキュムレータ、カウンタ等として使う、
というのを指針にした方がよさそうですね >>826
いや、普通の命令文に対する繰り返しのカウンタとしては、ecxを意識する必要はない。
計算のアキュムレータとしても、eaxを意識する必要も余りない。
余りを求める割り算だけは特殊。 ■ このスレッドは過去ログ倉庫に格納されています