Q&A
回答してくださりどうもありがとうございます。
アセンブリ言語のプルグラムに関する質問です。
ある本でアセンブリを勉強をしているのですがわからない部分があります。
横幅が4の倍数協会にない場合のダミーデータを計算するようなのですが、
なぜダミーデータを計算するのかわかりません。
横幅が4倍でない場合にレジスタと演算回路で計算して4で割り切れない場合の余りを捨てるという意味でしょうか？というかアセンブリプログラムはそのように書いてあるのでしょうか？
個人的に4倍ではなく１バイトが８bitなので８で割ったほうが都合がよいように思えますが。
計算部分とアセンブリ言語のプログラムのある部分に疑問があります。
以上について質問します。疑問のある部分に丸で囲んだ数字を置きます。
wMargineをゼロクリアにして、widthをeaxレジスタに代入します。
４で割った余りを算出するためにeaxレジスタを３で論理積を行う。
（⓵ここで３倍した理由は４で割った際の余りが３以上になるようにするためですか？
だとしたらもともとダミーデータが出ないように計算したほうがいいように思えますが。）
最下位２bitのいずれかが立っているかを検査します。
もし、４で割ったときに余りがあったら、widthを３倍し、それを４で割って得る。そして４から余りを引いてwMargineに設定する。
（⓶「そして４から余りを引いてwMargineに設定する。」の部分の４から余りを引く理由がわかりません）
プログラム通りeaxレジスタにwidthを入れます。そしてebxレジスタに３を代入し乗算します。
（⓷eaxレジスタとebxレジスタを乗算するのはわかるのですがプログラムにはmul ebxとしか書いていないのですが、なぜmul ebxと書いただけでeaxレジスタとebxレジスタを乗算する結果がebxに入る理由がわかりません。演算結果を一旦別のレジスタに入れた後に、mov命令でebxに演算結果をいれるならば理解できます。このアセンブリプログラムを出力したCPUの構造故にmul ebxと書いただけでeaxレジスタとebxレジスタの乗算結果がebxに入るのでしょうか？だとしたら仕方ないです。）
その後4バイトの乗算であるため上位4バイトがedxと下位4バイトがeaxレジスタへ代入されるようです
（⓸この乗算結果を二つのレジスタに乗算の結果を分割して入れている命令部分はプログラムのどこに書いてあるのでしょうか？
どのようにアセンブリ命令を書くことで分割してレジスタに入れられたのでしょうか？）
最後にダミーデータを知るために下位4バイトを入れたeaxレジスタと0x00000003で乗算して余りを取得したと書いてあります。これでダミーデータが得られたそうですが、なぜ得られたのか解説をよんでもいまいちわかりません。（⓹下位4バイトを入れたeaxレジスタと0x00000003で乗算して余りを取得したと書いてあります。これでダミーデータが得られた理由がわかりません。また何で割ったのかわからないのですがアセンブリプログラムには書いてあるでしょうか？）
プログラムは以下の通りです。
mov wMargine, 0 mov eax, width /* 幅 */ and eax, 0x00000003 /* %4 */ jz no_margin xor edx, edx /* クリア */ mov eax, width /* 幅 */ mov ebx, 3 /* 3 */ mul ebx /* 幅x 3 */ and eax, 0x00000003 /* %4 */ mov ebx, 4 /* 4 */ sub ebx, eax mov wMargine, ebx
以上5つの質問でありますが、どうか解説して頂けると大変助かります。
C言語を勉強している上でより技術を磨くためにアセンブリ言語を身に着けたいと思います。
どうかよろしくお願いいたします。
修正
論理積と足し算を勘違いして使っていました。
ようやく回答者様の皆様の回答が理解できてきました。
以後できる限り気を付けて質問します。
どうかよろしくお願いいたします。
本当に申し訳ありませんでした。
3/19 復習している際に疑問が出来たので再度以下の事に関して質問したいのですが、ここでは書きにくいため新しく質問を作ります。回答していただけると大変ありがたいです。
一時的に質問をしないとのことでしたが今回に関してはどうかお許しください。
回答5件
0
ベストアンサー
おそらくビットマップの仕様
水平方向のバイト数が4の倍数ではないときは、0x00で埋めて4の倍数にする。
です。(なんか他にもavi/jpg/png/gif/mpegの仕様で幅に制限あるフォーマットがあった気がするけど思い出せない)
個人的に4倍ではなく１バイトが８bitなので８で割ったほうが都合がよいように思えますが。
1bitには0か1の情報しか詰められませんけど、モノクロ画像でしょうか？
> ⓵ここで３倍した理由は４で割った際の余りが３以上になるようにするためですか？
24bit bmpなのでは？
> ⓶「そして４から余りを引いてwMargineに設定する。」の部分の４から余りを引く理由がわかりません
目的はwidth * 3 + wMargine== 4の倍数にしたいのです。
wMargineが1～4とした場合
n = width * 3 / 4 width * 3 + wMargine= 4 * (n + 1)
この連立方程式を解いてください
編集:計算するとおかしかったので追記
数の性質です。
ある数nの4で割った余りが
- 1の時、n+3は4で割り切れる
- 2の時、n+2は4で割り切れる
- 3の時、n+1は4で割り切れる
- 0の時、nは4で割り切れる
> ⓷eaxレジスタとebxレジスタを乗算するのはわかるのですがプログラムにはmul ebxとしか書いていない
> ⓸この乗算結果を二つのレジスタに乗算の結果を分割して入れている命令部分はプログラムのどこに書いてあるのでしょうか？
以前の回答でx86_64の仕様書を貼り付けましたので割愛
不明な命令くらい自分で調べましょう。
投稿2018/03/02 21:48
編集2018/03/02 22:12
総合スコア15147
0
解決済ですが、diracpaulさんへの質問者のコメントには答えたいことがあります。
載せたアセンブラプログラミング以外のアセンブリ命令の組み合わせでも同じような処理を実現できるのでしょうか
アセンブリコードには決まりきった命令順（イディオムも）もよく出現しますが、そもそも命令の粒度が細かいので、人によって・コンパイラによって、同じ処理でもコードの違いは大きくなります。以下、コメントにC言語風の擬似命令を併記しながら解説します。
xor edx, edx // edx ^= edx; mov edx, 0 // edx = 0; sub edx, edx // edx -= edx;
既にご存知でしょう、これは３つ共にレジスタedxの０クリアが目的ですから、
mov edx, 0 が自然ですが、これだと32bitの0という値を機械語に持つため、機械語命令が長くなる・遅いかもしれない（アセンブルリストで機械語の違いを確認しましょう）、そこで２進数の性質を利用してxor命令がよく使われます。
edxには乗算の結果が格納されることから、おそらく安全のため０クリアした・・・宣言した変数はすべて０に初期化するのと同じ気持ちなのでしょう。でもmul命令の仕様がわかっていれば、edx を０にする必要が無いことは明らか。即ち、xor命令は削除できます。
次に乗算命令の箇所。
mov eax, width // eax = width; mov ebx, 3 // ebx = 3; mul ebx // edx:eax = eax * ebx;
32bit * 32bit の計算結果は 64bit になります。mul命令の結果が EDX:EAX に格納される（EDX, EAX レジスタを固定的に使う）ことから、乗数を EDX に入れて乗算させることが多いのではないでしょうか。レジスタは限りある資源なので、関数の中で使うレジスタを減らした方が何かと有利なのです。
どうせ mul 命令は edx を使うのだから、私ならここは edx を使い回します。ebx を使わずに済む事は大きいのです。こんな風に
mov eax, width // eax = width; mov edx, 3 // edx = 3; mul edx // edx:eax = eax * edx; ... // 途中省略 mov edx, 4 sub edx, eax // edx = 4 - (width * 3) % 4;
それはともかく、３倍は同じ値を３つ足してもよいので、例えばこうできる。
mov eax, width // eax = width; mov edx, eax // edx = eax; add eax, edx // eax += edx; // width * 2 add eax, edx // eax += edx; // width * 3
mulは時間がかかる命令ですから、一命令増えても実行速度は断然速いです。
じゃあ10倍するには10回加算を繰り返すかというと、そうではなくて、2のべき乗（2, 4, 8, 16 ...）倍にシフト命令を使えることをご存知でしょう。10倍は8倍＋2倍だから、10倍するマクロは
#define MultBy10(x) ((x) << 3 + (x) << 1)
のように、シフトと加算の組み合わせで実現できます。もっとも今のコンパイラは何もしなくても大抵こんな風に最適化しますが、アセンブリ言語ならどう書けばよいか、質問者への課題にしましょうか笑。
さて、ここが重要。
提示されたアセンブリコードは何を計算しているのか。全体をC言語風に書けば、こうなります。
C
1 wMargine = 0; 2 if ((width % 4) == 0) goto no_margin; 3 wMargine = 4 - ((width * 3) % 4); // この計算は何か？
width から wMargine を求めていることがわかります（と共に処理を分岐している）が、width % 4 は 0, 1, 2, 3 しかなく、0の場合は明らかなので、0以外を場合分けして考えると、計算結果はこうなります。
| width%4 | width | width*3 | (width*3)%4 | 4-(width*3)%4 |
|---|---|---|---|---|
| 1 | 4n + 1 | 12n + 3 | 3 | 1 |
| 2 | 4n + 2 | 12n + 6 | 2 | 2 |
| 3 | 4n + 3 | 12n + 9 | 1 | 3 |
「width % 4」と「4 - ((width * 3) % 4)」が一致する！・・・実は乗算も減算も不要、即ちあの部分は無駄なコードなのです（あくまで提示されているコードを見る限りですが）。つまり、次の５行だけが残る。
mov wMargine, 0 // wMargine = 0; mov eax, width // eax = width; and eax, 0x00000003 // eax %= 4; jz no_margin // if (eax == 0) goto no_margin; mov wMargine, eax // wMargine = eax;
さらに、x86はmov命令でフラグレジスタが変化しないので、次の４行まで絞り込める・・・
mov eax, width and eax, 0x00000003 // eax = width % 4; mov wMargine, eax // wMargine = width % 4; jz no_margin // if (eax == 0) goto no_margin;
このような「無駄」はアセンブリ言語に限った事ではありません。言い換えれば、漫然とコードを書くなら、どんな言語を使っても無駄な計算をしたり効率が悪かったりするという戒めになるでしょう。
wMargine = 4 - ((width * 3) % 4); // この計算は何か？
念の為、この部分はどういうコードであったか。C言語風コメントをつけておきます。
xor edx, edx // edx = 0; （削除可能な命令） mov eax, width // eax = width; mov ebx, 3 // ebx = 3; mul ebx // edx:eax = eax * ebx; 即ち edx:eax = width * 3; and eax, 3 // eax &= 3; は eax %= 4; と同じ mov ebx, 4 // ebx = 4; sub ebx, eax // ebx -= eax; 即ち ebx = 4 - ((width * 3) % 4); mov wMargine, ebx // wMargine = ebx;
投稿2018/03/04 08:05
編集2018/03/04 16:37
総合スコア1380
rubato6809さんは何者なのですか？
どこかのIT企業でお仕事なされているエンジニアの方なのでしょうか？
仕事とは別に趣味であったとしたらレベルがとても高いプロのようです。
差し支えなければ教えていただけないでしょうか？
今更ながら申し訳ありません。復習をしているのですがwMargine=ダミーデータという扱いでよいのでしょうか？
どうかよろしくお願いいたします。
ダミーデータを求める計算式は4-(width*3)%4でも問題ないとのことですが、1ピクセルが3バイトでありwidth自体がRGB3バイトを含んでいるのだとしたらwidth*３と書いてしますと、RGBを含んでいるwidthと掛けたRGBが重複してしまう気がするのですが、
個人的には本を読む限り、width＝（n個の横のピクセル）*（3バイト/1ピクセル）を表しているように思えます。width/4の4はRGBが3バイト故に４でバイト単位でwidthを割っており、4バイトで高速化を考えているため、widthの余りのとなった1~3バイト数のRGBはダミーデータとして扱われる。
以上のことからアセンブリプログラム内にwidthをどのように扱うか定義されていないところを見ると、
ダミーデータを求める計算式はwidth/4と書くのが正しいものであり、本に書いてある4-(width*3)%4の方はたまたま、3を掛けたらwidth/4と同じダミーデータのバイト数を得られただけだと考えています。
皆様はどのように考えるかを解答していただけると大変ありがたいです。
どうかよろしくお願いいたします。
なので、「実は乗算も減算も不要、即ちあの部分は無駄なコードなのです」に関しては、無駄ではなく、間違ったコードなのではないかと考えています。
もしかしたら作者なりに都合よくなるようにするために書いたコードなのかもしれませんが。
carnage0216さん
別の質問（118057）で議論が続き、03/19 07:30 からちょうど２日間たちました。放っておくのも何なので、お伺いします。
> 無駄ではなく、間違ったコードなのではないか
というお考えは、同じですか、変わりましたか？
変わったなら、どう変わったか、整理できますか？
こちらは急ぎませんので、じっくり考えて、お返事ください。
おはようございます。考えはかわりました。
なので、間違ったコードではないことを証明したいと思います。確認をよろしくお願いいたします。
私なりにまとめたので見て頂きたいと思います。
式が4-(width*3)%4となる理由を説明したいと思います。
例えばwidth=15バイトだとします。
そして3を15バイトかけるのはrgbデータを収納するためのメモリを確保するためです。
(15*3)バイトを4バイトで割るのは(15*3)バイトの中にいくつの4バイトがいくつあるかを調べるためです。
そして(15*3)%4より、4バイトは11個ある事がわかり、1バイト余る計算となります。このおしりの1バイトを4バイトにするには式4-(width*3)%4の4からおしりの1バイトを引けば、1バイトに何バイト足せばよいかわかります。そのため、式に4-を入れました。
よって4バイト-1バイト=3バイトより、おしりの1バイトに3バイトを足せば4バイトとなり、横幅は4の倍数のバイトとなります。
以上より参考した書物に書いてある式が4-(width*3)%4である理由が証明できました。
理由あっての式4-(width*3)%4が正しい式だと理解できました。
4-(width*3)%4=width%4 (width≠4n)に関して証明したいと思います。
変数が一つの式ならば、どんな式も＝できるのですが。
今回はwidth=４ｎ+１、4n+2、4ｎ+３とwidth内に変数があるので二つの変数を使っての計算となるため、width≠4nなどの例外が起きる。
4-(width*3)%4=width%4 (width≠4n)とできるのは剰余の分配法則を使ったためであります。
width%4 のwidthにwidth=４ｎ+１、4n+2、4ｎ+３を代入しても剰余の分配法則より必ず余りが出る
4-(width*3)%4のwidthにwidth=４ｎ+１、4n+2、4ｎ+３を代入しても剰余の分配法則より必ず余りが出る
その余りの数値が＝で結べたため簡略化できたと私は言えるのではないかと思いました。
ただ、証明しておきながらwidth%4 の式に違和感があります。4-(width*3)%4のwidth*3ではRGBの3バイトのメモリを確保するために3をxに掛けていますが、width%4の式ではwidthに3はかけていないのでRGBのメモリを確保できないとは言いませんが、ただ、メモリを確保しているだけなのかなと思ってしまいます。
なので、簡略化も良いと考えますが個人としては本に書いてあった4-(width*3)%4かasmさんに勧めていただいた(width*3 +3) & -4のどちらかが素直で私には理解しやすいです。
個人として考えたのは3*x%4と4-(3*x%4の余り)の二つの式を用いてwidthを埋めるパディングを求めます。もしかしたら式を二つにしたりでデータのサイズが大きくなったりしますが、まずは自分の納得のいくコードがかけてから高速化をはかります。
4-(width*3)%4をwidth%4 に変換できるゆえに、width%4にはwidth*3のrgbのメモリを確保する意味合いが含まれているのかもと。
やはり、わたしにはwidth%4に関しては本当は申し訳ないですが、前の質問で書いた式の方が今の私には理解しやすいです。
ごめんなさい。
あの、私の証明は間違っていたのでしょうか？
返信がないので間違っているのではと不安です。
あれは証明とは言わないでしょう、「説明」ですかね。
それも含めて、今日はコメントを書けないので、気長にお待ちください。
てっきり とうとう呆れられて返信すらしていただけなくなったのかと思い、頭が真っ白になりかけました。
そうだったのですね。よかったです。気が短いものですいません。
では待たせていただきます。
いろいろ言いたいことがあるけど、まずはここから。
> (15*3)%4より、4バイトは11個ある事がわかり、1バイト余る
45 % 4 を計算したら「11個ある事がわか」るでしょうか？
はい。わかります。
C言語のプログラムで % 演算子を使ったこと、無いでしょ？例えば
main() {
int w = 15;
printf("%d\n", (w * 3) % 4);
}
11は、どこかに表示されるかな？
main() {
int w = 15;
printf("%d\n", (w * 3) % 4);
}
printfのカッコ内にある"%d\n"の％dに11が表示されると思います。
思います、ではなく実行してから返事しなさい。
実行してみたところ１と出ました。
何かの間違えかと思いint w=14の時で実行したところ2とでました。これは割った余りを表しているのですね。
main() {
int w = 14;
printf("%d\n", (w * 3) % 4);
}
もう一度聞く。
45 % 4 を計算したら11個ある事がわかりますか？
もちろんわかります。
45バイトを4バイトで割ったら4バイトが11個あり、1バイトと余るのですよね。
ちゃんと実行しました。なのに11とはでず、１とでます。なんで余りのほうが出るのか調べているのですがまだ解決していません。
#include <stdio.h>
main() {
int w = 15;
printf ("%d\n", (w * 3) );
int i = （w * 3）;
printf ("%d\n", (w * 3)/4 );
int a = (w * 3)/4 ;
printf ("%d\n", (w * 3)%4 );
}
を実行したところ
以下のように出ました。もちろん理解できた通り、11バイトあまり1バイトとでました。
45
11
1
なるほど、「％」だとあまりが
「/」 とすると11を得られるのですね。
勉強不足でした。申し訳ありません。
あの、不快な解答をしてしまい申し訳ありません。
私の回答は間違っているのでしょうか。
％を/にしたところちゃんと4バイトが11個あることがわかりました。
0
寝ておきたらほぼ終わってたが、とりあえず書いたので
基礎の基礎
1bitとは
2進数1桁の事であり、0か1のどちらかの状態を保存する記憶領域です
1byteとは
(2008年以降)標準的には8bitです。
論理積とは
まずは1ビットの論理積
左辺 & 右辺 = 解
| 左辺 | 右辺 | 解 |
|---|---|---|
| 0 | 0 | 0 |
| 0 | 1 | 0 |
| 1 | 0 | 0 |
| 1 | 1 | 1 |
という1ビットの演算です
1ビットが入力され1ビットが返される演算の事を論理演算といいます
今現在のコンピューターというのは突き詰めるとこういった論理演算で全てが実装されています。
次にビット毎の論理積
これを拡張して8bitの演算を考えます
例: 101 & 15
101 = 0x65 = 0b01100101 15 = 0x0F = 0b00001111 101 & 15 = 0b00000101
両辺ともにビットが立っているところのみ1になります。
AND EAX, 3について考える
これはEAX &= 0b11;ということです
つまり、EAXを2進数表記にした際の最下位2bitのうち立っているビットのみを取り出すものです。
割り算との関係
10進数である数を100で割ったあまりを考える際、下2桁を取り出しますよね？
2進数でも同じです。
0b10=2で割ったあまりが欲しい場合は最下位ビットが立っているなら1で0なら0なんです。
0b100=4で割ったあまりが欲しいならば最下位2bitが4で割ったあまりになるのです。
以上が、CPU関連で必要な前提知識
%演算子
C言語における%演算子は割り算のあまりを計算する演算子です。
10÷3=3あまり1
なので
10%3=1
になります。
割り算というのはCPUの算術演算(普通の算数の演算)の中でも非常に遅くなるべく回避したいものなので
X%4を計算するときはbit毎の論理演算で代用するのが定石になります。
今回のプログラムについて
ビットマップのフォーマットによるとbmpに保存されている幅情報の単位はピクセルです。
1ピクセル=1ドット=点1個と置き換えてもいいです。
bmpには何色使えるかでいくつかの種類があります。
今回対象にしているフォーマットは推測ですが24bpp
1ピクセルごとに24bit=3byte使うことで16777216色使えるフォーマットだと思います。
1行ごとに最低限必要なバイト数は3*width byteですが
これを4byteの倍数になるように0を付け加えなければいけません。
仮にwidth=31ピクセルの場合を考えます。
31*3=93byte = 93=4*23 + 1byteなので3byte足して1行ごとに96byteになります。
93から余りの1がパディング長なのではなく、96-93の3byteがパディング長なのです。
どうでもいいこと
ピクセル配列に追加されるバイト列なので
ダミーデータというとピクセル単位で追加される事を個人的に想起します。
投稿2018/03/04 17:10
総合スコア15147
0
あの本書のCPUの構造がわからないので同じような結果になるかはわからないのですが。自分なりにコードを書いてみました。結果としては同じような結果になると思いますでしょうか？
mov eax, width // eax = width;
mov edx, 3 // edx = 3;
mul edx // edx:eax = eax * edx;
がもともとのコードです。
以下が私の書いたコードです。
mov eax, width
mov ebx ,3
mul eax ,ebx //←こう書いた場合は掛け算の結果はeaxに入るのでしょうか？//
mov ebx ,eax //eaxの内容をebxに入れます。//
あーめんどくせー 四の五の言わんとやってみろなんだが、
やり方知らんと手が出せんだろからC/C++内にアセンブリ書いて呼んでみたサンプル。
C++
1/* 2 Visual C++ 32bit(x86)コンパイラで試すべし 3 */ 4 5#include <iostream> 6#include <cstdint> 7 8uint32_t your_asm(uint32_t width) { 9 uint32_t result; 10 __asm { 11 mov eax, width 12 mov edx, 3 13 mul edx 14 mov result, eax 15 } 16 return result; 17} 18 19uint32_t my_asm(uint32_t width) { 20 uint32_t result; 21 __asm { 22 mov eax, width 23 mov ebx, 3 24/* mul eax, ebx マチガイ */ 25 mul ebx 26 mov ebx, eax 27 mov result, ebx 28 } 29 return result; 30} 31 32int main() { 33 using namespace std; 34 for ( uint32_t i = 0; i < 10; ++i ) { 35 cout << i << '\t' << your_asm(i) << '\t' << my_asm(i) << endl; 36 } 37} 38 39/* 実行結果 400 0 0 411 3 3 422 6 6 433 9 9 444 12 12 455 15 15 466 18 18 477 21 21 488 24 24 499 27 27 50*/
投稿2018/03/05 02:41
編集2018/03/05 02:46
総合スコア16614
どうもありがとうございます。
早速、32bitの場合と64bitの場合で試させて頂きます。
64では無理よ、__asm 使えないから。
そうなんですか。
意外ですね。
64ビットで実行できるものは32ビットではできないのに。
32ビットで実行できるもので
64ビットで実行できないのは。
アホみたいに思われますが、
gccの方でも実行してみます。
64bitでは intrinsics 使えってことみたい。
https://docs.microsoft.com/ja-jp/cpp/intrinsics/x64-amd64-intrinsics-list
> gccの方でも実行してみます。
「おんなじコードをgccに食わせたらエラーが出ますなぜですか」
なんつーアホな質問せんように。
またしても調べて頂いてすいません。
あ、決して、調べずに待っていたわけではありません。
epistemeさんの方が情報を見つけるのが速すぎるというか、不甲斐ないです。
さすが、そこまでアホなことは、、、多分しないです。
ベーシックc++とgccは扱い方が異なると思うので。
> epistemeさんの方が情報を見つけるのが速すぎるというか
経験は人並み以上にありますからね。
求めるものがどこにあるか、あらかたの見当がつくんです。
見つけるのが速いんじゃなくて、近づくのが速いんだと思う。
そうなんですか。
どこかの企業に勤めているエンジニアの方なのでしょうか？
0
前の方が説明されているので、詳しくはお話しませんが、このコードは、単に4で割った余りを計算してwMarginにセットしているだけと思いますので、単にwidthに対して4で割った余りをセットするだけでも良いと思います。
ちなみに、アセンブラではコーディングでは、mulやdivや条件ジャンプは遅いので、高速処理をする場合には、極力避けるべきです。私はコンパイラーのコード生成部を実装していたことがありますが，2倍や4倍する場合などでは、mulを使う場合には、シフト命令を使っていました。
その意味からいうと、このコーディングでは高速化するには変えたほうが良いと思います。4で割った余りなら、単に0x03でAndすれば、１つの命令で済みます。
投稿2018/03/03 13:28
総合スコア157
回答ありがとうございます。
ッということは載せたアセンブラプログラミング以外のアセンブリ命令の組み合わせでも同じような処理を実現できるのでしょうか？
勉強のため本とは違う形で結果のしょつ力が同じようなアセンブリプログラムを作りたいと考えています。
そらできるわな、モノによるけど。
かけ算はたし算の繰り返しやろ？ mod 4 は and 3 やろ?
あの本書のCPUの構造がわからないので同じような結果になるかはわからないのですが。自分なりにコードを書いてみました。結果としては同じような結果になると思いますでしょうか？
mov eax, width // eax = width;
mov edx, 3 // edx = 3;
mul edx // edx:eax = eax * edx;
がもともとのコードです。
以下が私の書いたコードです。
mov eax, width
mov ebx ,3
mul eax ,ebx //←こう書いた場合は掛け算の結果はeaxに入るのでしょうか？//
mov ebx ,eax //eaxの内容をebxに入れます。//
どうかよろしくお願いいたします。
私自身は、定年過ぎのおっさんなので、インテル系の新しいCPUの詳しい動作はちょっとわかりません。また、マニュアルも捨ててしまっており確実にこれで大丈夫とは言い切れませんが、ご勘弁ください。
掛け算の場合には、例えば、16bit同士の掛け算だった場合には、結果としては32bit必要となります。
インテル系チップの場合は、乗算するレジスタが決まっている為、eaxレジスタとオペランドで指定したレジスタと掛け算をするように決まっている為、mul命令のオペランドにはeaxレジスタを指定しないものと思われます。
インテル系チップの乗算に関するページがありました。下記のURLをご覧ください。
http://wisdom.sakura.ne.jp/programming/asm/assembly11.html
ちなみに、私は、APPLEIIに搭載されていた6502や、PC88のZ80,PC98のインテルの86までです。
アセンブラプログミングの醍醐味というと、それぞれのCPUの特徴を加味して高速処理を実現することにあります。例えば、6502では、レジスタが非常に少ない欠点はあるもの先頭の256バイトのメモリに対するアクセスが早くレジスタの代わりに利用するとか、インテル系のチップではMOVSコマンド(Z80ではLDIR)を使って文字列転送が高速できる事などです。今は、インテル系のチップが主流ですが、昔はたくさんの種類があり大変面白かったです。
なお、今回の元になったアセンブラプログラムで修正すべきと思う点は、
mov ebx,3
の部分です。なぜ3なのか、これはこれが1ピクセルのバイト数と思いますが、コメントでこの事をもっと明確に書いた方がよかったのではと思います。それであれば、意図にが明確になったのではと思います。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/03/02 22:08
2018/03/02 22:24
2018/03/02 22:51
2018/03/02 23:00
2018/03/02 23:22
2018/03/03 23:27
2018/03/04 06:14
2018/03/04 06:26
2018/03/04 06:48
2018/03/04 07:08
2018/03/04 07:41
2018/03/04 07:47
2018/03/04 07:53
2018/03/04 08:08
2018/03/04 08:11
2018/03/04 08:16
2018/03/04 08:28
2018/03/04 08:39
2018/03/04 09:12
2018/03/04 09:23
2018/03/04 09:27
2018/03/04 09:32
2018/03/04 09:41
2018/03/04 09:41
2018/03/04 09:48
2018/03/04 09:53
2018/03/04 09:54
2018/03/04 09:57
2018/03/04 10:00
2018/03/04 10:21
2018/03/04 10:22
2018/03/04 10:22
2018/03/04 10:37
2018/03/04 11:35
2018/03/04 12:38
2018/03/04 13:10
2018/03/04 13:17
2018/03/04 14:10 編集
2018/03/04 13:30
2018/03/04 13:46 編集
2018/03/04 13:43
2018/03/04 13:45
2018/03/04 13:52
2018/03/04 14:01
2018/03/04 14:04
2018/03/04 14:31
2018/03/04 16:52 編集
2018/03/04 17:01
2018/03/04 17:02
2018/03/04 17:08 編集
2018/03/04 17:09
2018/03/04 17:11
2018/03/04 17:13 編集
2018/03/04 17:18
2018/03/04 17:20 編集
2018/03/04 17:54
2018/03/04 17:56
2018/03/04 18:04 編集
2018/03/04 18:10
2018/03/04 18:21
2018/03/04 18:24
2018/03/04 22:51 編集
2018/03/04 20:37
2018/03/04 22:39
2018/03/05 00:05
2018/03/05 00:07
2018/03/05 00:14 編集
2018/03/05 01:02
2018/03/05 01:10 編集
2018/03/05 02:47
2018/03/05 12:06
2018/03/05 12:10
2018/03/05 12:16 編集
2018/03/05 12:28
2018/03/05 12:31
2018/03/05 12:31
2018/03/05 12:33
2018/03/05 12:36
2018/03/05 12:36
2018/03/05 12:38 編集
2018/03/05 12:54
2018/03/05 12:55
2018/03/05 22:59
2018/03/05 23:44
2018/03/05 23:48
2018/03/05 23:52
2018/03/06 06:58
2018/03/06 07:53
2018/03/06 07:54
2018/03/06 08:00
2018/03/06 08:13
2018/03/06 08:57