アセンブラ初心者スレッド 2©2ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2017/04/13(木) 17:35:55.70

初心者OK！質問大歓迎！のアセンブラのスレッドです。
基本情報の勉強中の人、PICやH8を勉強中の学生などなど…

前スレ
アセンブラ初心者スレッド
http://echo.2ch.net/test/read.cgi/tech/1314502612/

関連スレ
アセンブラ 13
http://echo.2ch.net/test/read.cgi/tech/1314512680/

**デフォルトの名無しさん** · 2019/11/02(土) 22:41:38.43

>>488
実際のCASL IIがそう書けるかどうかはともかくとして、
数学記号と同様の感覚で記号の対応関係や「類推（推論）」で考えれば、
ADDA GR0,#0045
と書くと、アドレス #0045 番地のメモリーに入っている内容を読み出した値を
GR0に足す、という意味になります。# は以後の数値が16進数である事を表す
記号です。初めに言ったようにこの書き方がCASL II 言語で実際に出来るか
どうかは分かりませんが、意味で考えるとそういう意味になるでしょう。一方、
ADDA GR0,=#0045
は、>>488 に書いたように、0045 という16進数の値を入れた領域を
自動的に確保して、そのアドレスを xxx とすると、自動的にその場所を
ADDA GR0,xxx
という命令に置き換えるという意味です。
かなり違う意味です。ですから、覚える覚えないの話では無い事が分かります。

**デフォルトの名無しさん** · 2019/11/02(土) 22:47:11.43

>>489
x86アセンブラを知っている人ならば、
ADDA GR0,GR1　　　　--->　　mov GR0,dword ptr [GR1]
ADDA GR0,#0045　　　--->　　mov GR0,dword ptr [0045h]
ADDA GR0,=#0045　　--->　　mov GR0,0045h
また、C言語を知っている人ならば、
ADDA GR0,GR1　　　--->　　GR0 += *(DWORD *)GR1;
ADDA GR0,#0045　　--->　　GR0 += *(DWORD *)0x0045;
ADDA GR0,=#0045　--->　　 GR0 += 0x0045;
となります。

対応関係は、第二オペランドに X を書くと、[X] や、*X の意味になり、
=X と書くと、X の意味になります。

**デフォルトの名無しさん** · 2019/11/02(土) 22:48:31.37

>>490
すみません、movとaddを書き間違えました。正しくはこうです。：
x86アセンブラを知っている人ならば、
ADDA GR0,GR1　　　　--->　　add GR0,dword ptr [GR1]
ADDA GR0,#0045　　　--->　　add GR0,dword ptr [0045h]
ADDA GR0,=#0045　　--->　　add GR0,0045h

**487** · 2019/11/03(日) 00:10:58.78

>>488-491
ありがとうございます
学習していきたいと思います

**デフォルトの名無しさん** · 2019/11/12(火) 18:31:03.25

マイコン用のアセンブラコードジェネレータを作りたいんだけどどんな感じにするのが良いんだろうか
if文で条件分岐させていくとコード生成部が条件分岐だらけになって訳が判らなくなる
組み込み用なのでパイプラインのストールを引き起こすようなコードはなるべく生成したくない

**デフォルトの名無しさん** · 2019/11/12(火) 18:53:07.41

bison+flex+LLVM

**デフォルトの名無しさん** · 2019/11/12(火) 23:09:55.20

>>493
テーブル参照して引っ張ってくるのが一番楽かと

**デフォルトの名無しさん** · 2019/11/13(水) 01:29:11.05

やる気だけでは進まない

**493** · 2019/11/13(水) 08:08:30.10

ありがとう

>>494
判りにくくてスマン。ガチの処理系を作りたいわけではないんだ
チップメーカーが出しているGUIでパラメータをポチポチ設定してGeneratボタンをクリックすると
設定に従ったライブラリコードを自動生成してくれるみたいな奴を作りたい
というかLLVMとかは自分の手におえそうにない

>>495
ハッシュテーブルみたいな感じ？パターンは結構ある
今考えているパラメータだけでも
書き込み先アドレスが～30種程度と～10種類程度×2
処理の選択にbool値が5個くらい、サイクル数指定が3種
サイクル数を指定できる区間は重なっているし結構ややこしい
ちょっと前から作り始めているけどすでにぐちゃぐちゃ・・・

**デフォルトの名無しさん** · 2019/11/21(木) 00:03:41.36

初歩的な質問です
8086とZ80だったらどっちを勉強した方が良いですか？

**デフォルトの名無しさん** · 2019/11/21(木) 01:21:24.28

8086

**デフォルトの名無しさん** · 2019/11/21(木) 01:21:54.93

x64じゃいかんの？

**デフォルトの名無しさん** · 2019/11/21(木) 02:11:07.86

z80だろ

**デフォルトの名無しさん** · 2019/11/21(木) 02:13:40.22

>>498
やっぱ両方いらん

**デフォルトの名無しさん** · 2019/11/21(木) 05:15:38.34

すでに何かのアセンブラ理解してるなら両方勉強しても数日で理解できるだろう。
はじめてアセンブラ勉強するならそりゃシンプルな8bitCPUで圧倒的に情報が多いZ80だろうな。

**498** · 2019/11/22(金) 00:24:30.25

返信が遅くなってすいません
答えて頂いた方、ありがとうございました

**デフォルトの名無しさん** · 2019/11/22(金) 13:34:09.59

マジレスするとアセンブラを使う目的次第

PICやRL78みたいな小規模でCPUや電子回路を学ぶ
x64で高速化やSIMDを試す
ラズベリーパイやスマホのARMで遊んでみる
DSPで信号処理やフィードバック制御を学ぶ

など

**デフォルトの名無しさん** · 2019/11/22(金) 15:29:17.71

>>498
6809

**デフォルトの名無しさん** · 2019/11/22(金) 16:26:18.45

>>498
ニモニックの美しさと分かり易さではZ80。
実用的には8086。

**デフォルトの名無しさん** · 2019/11/22(金) 16:34:56.93

>>507
ちなみに、CPUとしては両者は親戚みたいなもので、Z80を学んだ後から、
8086へ進んでも文化に共通点が多いので理解し易い。
たとえば、条件分岐は、cmpなどの比較命令を実行して
zero flag や carry flag などに影響を与えた後に、Jcc 命令を使う点や、
cmp以外にsubやaddでも全く同様に zero flag, carry flag などに影響を
与えると言う点が両者で共通している。
他のCPUでは全く違うやり方をとるものも多い。

ところが、Z80は8BIT CPU としてはとても上手くできていた方だが、
8086は、16BIT CPU としては残念な方であった。一つの理由は、
当時は低価格で理想的な16BIT CPUを作るためには、ICにおけるトランジスタの
集積度が不足していたが、8BIT CPUを作るには十分であったためらしい。
なので、8BIT CPUは使い易いものが作れたが、16BIT CPU は使いにくいもの
しか作れなかった、と考えることが出来る。

**デフォルトの名無しさん** · 2019/11/22(金) 16:45:49.82

80186 で恥の上塗りですね判ります

**デフォルトの名無しさん** · 2019/11/22(金) 16:56:01.19

>>508
他にも、

1. 両者とも、アラインの揃ってないアドレスからでも16BIT以上のデータを
　読み出せると言う特徴がある。これが出来ないCPUも多く、Apple系は昔そういう
　CPUを使っていたと聞いている。今でもC言語の構造体などで align が細々と
　決まっているのは、後者の文化圏の人達が主導しているのかも知れない。

2. carry flag（8086 では「borrow flag」という名前になっている）を使うと、
　多倍長の加減算が容易に出来るのも両社に共通している。この特徴は、
　他のCPUには無いことが多いらしい。だから、LLVMなどには adc や sbc(sbb)
　相当の命令が無いし、carry flag を捕捉する命令も定義されていない。

3. LLVM では、単純な引き算の延長線上にある cmp 命令でフラグを作った後、
　条件の種類によっていろいろな種類のJcc で条件分岐するという流儀をとっておらず、
　条件の種類によって比較命令自体を変えてしまって、結果は常に 1BIT の
　BOOL値とし。逆に Jcc 命令は原則一種類となっている。これは、LLVMが
　Z80や8086とは異なる文化圏の人が作ったものであるのではないかと推定される。

4.アカデミカルな世界では、CPUとして、業界事実標準の Z80 や 8086 系統ではなく、
　どうも違う文化のものを想定していることが多い気がする。
　色々な言葉が、Z80 や 8086 ではかなり多く共通しているが、LLVMとは全く
　違う。

**デフォルトの名無しさん** · 2019/11/22(金) 17:05:38.22

まあ普通にx64かARMかMIPS

ARMやMIPSはもともとRISCなので非常にきれいでシンプル

x64はAVXなどのリッチな命令を楽しめるし
環境もPCにVisual Studioを入れるだけ

**デフォルトの名無しさん** · 2019/11/22(金) 17:09:00.41

80186(改)は実はわりと最近まで製品で使ってましたよ
大きなLSIの中に、制御用にコアだけ入ってるやつ
セグメントレジスタが4シフトではなく8シフト

**デフォルトの名無しさん** · 2019/11/22(金) 17:10:09.89

>>510
シッタカで出鱈目書くなよ糞が

**デフォルトの名無しさん** · 2019/11/22(金) 17:11:44.26

すいません

**デフォルトの名無しさん** · 2019/11/22(金) 17:11:56.78

おれじゃなかった

**デフォルトの名無しさん** · 2019/11/22(金) 17:54:18.76

>>513
知ってる人は自分が正しいと思うことを具体的に書けばいい。
書けないなら黙っとけと思う。

**デフォルトの名無しさん** · 2019/11/22(金) 18:28:01.42

>>510じゃないけど

1.性能上(もしくはアトミック性)の理由でアラインメントを揃える

2.8086でもキャリーフラグという名前
もちろんボローの意味でも使う

フラグはOut Of Orderの妨げになりやすく
シンプルな設計を目指したRISC系では使わないし
当然SIMDでも使わない
ただし、命令を組み合わせて同じことが出来る

多倍長の加減算は(乗算他に比べて)速いので
それが性能に影響することは少ないし
64bit CPUではそもそも64bitを越えた演算をすることも非常に少ない

**デフォルトの名無しさん** · 2019/11/22(金) 18:29:07.76

間違った

>>513じゃないけど

でした

**デフォルトの名無しさん** · 2019/11/22(金) 18:33:09.28

4.z80はまったく業界標準ではないですね
数量から言えばARMとx86系が圧倒的

MIPSは教育現場では使われるけど
数量はARMやx86系に比べたら少ない

x86も16bit命令で組む事はほぼない
32bitか64bitがほとんど

**デフォルトの名無しさん** · 2019/11/22(金) 18:35:52.35

あとは教育だとRISC-Vとか

**デフォルトの名無しさん** · 2019/11/22(金) 18:35:58.82

ARM系の条件分岐ってフラグベースじゃね？

**デフォルトの名無しさん** · 2019/11/22(金) 18:43:24.01

いまどき初心者がZ80に興味持つはずないだろ
こいつが御高説を垂れたいがために質問を自演してるんだろ
情けない奴

**デフォルトの名無しさん** · 2019/11/22(金) 19:07:15.94

Z80そのものが使われる機会は減っていてもZ80の流れを汲むアーキテクチャはまだまだある
IA32/AMD64はもちろん、ちょっと上であがっているRL78もだ

**デフォルトの名無しさん** · 2019/11/22(金) 19:10:46.49

>>521
そうでした
頭がMIPSと混ざってしまった

**デフォルトの名無しさん** · 2019/11/22(金) 19:26:38.06

組み込み系でも8bitだと桁上がり演算でキャリーをよく使うけど32bitだと出番は激減する
32bitあれば12bitADCの変換値を10回足し込むくらいじゃ余裕
一部のアーキテクチャは特殊演算用に64bitを超えるレジスタを持っていたりするし
なおさら桁あふれしにくい

**デフォルトの名無しさん** · 2019/11/22(金) 20:20:02.18

>>523
ID変えて否定に回ったのが自演の証拠ｗ

**デフォルトの名無しさん** · 2019/11/22(金) 21:52:14.02

Intel系のCPUは元々4bitの4004から来ている。4004は主に電卓で使われた。4bitレジスタで演算するとき
桁あふれが頻繁に起こるのがわかっていたのでキャリーフラグがあると便利だろうということで入れたんだと思う。
それが8bitの8008以降も継承されて現在に至る。だから64bitでキャリーフラグが使われないのも当然。

**デフォルトの名無しさん** · 2019/11/22(金) 22:00:58.35

最後の｢だから｣がなぜ｢だから｣なのかわからない

**デフォルトの名無しさん** · 2019/11/22(金) 22:22:56.50

>>517
>ただし、命令を組み合わせて同じことが出来る
一年ほど前に調べていたら、x+y に対するキャリーフラグをC言語を使って
作り出すようなことを書いているコードを見つけた。
普通に考えればx,yの最上位ビットに着目すればいいんだけど、
最初に思いつくコードよりかなり短いコードだった。
x,yが8BITの場合、x+yに対するキャリーフラグをcfとすると、
意味的には、
cf = 0;
if ( (x & 0x80) != 0 && (y & 0x80) != 0 ) {
　cf = 1;
}
でいいはずだけど、
cf = (x & y) >> 7;
かな。でも、もっとエレガントなコードだったような気がする。
何か知っていれば教えて欲しい。

**デフォルトの名無しさん** · 2019/11/22(金) 22:28:55.69

さらに、x, y が符号なし8BIT整数の場合の x - y に対する carry flag については、
cf = 0;
if ( x < y ) cf = 1;
で一応求まるんだと思う。
また、sf(sign flag) に関しては、
sf = 演算結果 >> 7;
でいいと思われる。

**デフォルトの名無しさん** · 2019/11/22(金) 22:33:04.48

>>530
短く書きたいのであれば、
cf = (x < y);
sf = (x - y) >> 7;

**デフォルトの名無しさん** · 2019/11/22(金) 22:40:25.25

>>529
cf = (x < (-y));
でも求まるかもしれない。
>>530 を書いてみて気付いた。

>>531 は逆に、
cf = (x & (-y)) >> 7;
でも行ける気がする。

**デフォルトの名無しさん** · 2019/11/22(金) 22:46:49.23

>>532
すまん。後半部は間違いらしい。

**デフォルトの名無しさん** · 2019/11/22(金) 23:19:09.49

>>533
>>532の前半部も多分、間違い。

**デフォルトの名無しさん** · 2019/11/23(土) 00:09:22.51

>>528
64bitレジスタでは4bitレジスタに比べて桁あふれが起きにくいから使用頻度が少なくなる。

**デフォルトの名無しさん** · 2019/11/23(土) 02:42:52.78

足し算
z0 = x0+y0;
z1 = x1+y1+(z0<x0);

引き算
z0 = x0-y0;
z1 = x1-y1-(z0>x0);

**デフォルトの名無しさん** · 2019/11/23(土) 03:01:11.70

carry = 0;
for (i=0 ; i < n ; i++){
. . if (carry){
. . . . z[i] = x[i] + y[i];
. . . . carry = z[i] < x[i];
. . }
. . else {
. . . . z[i] = x[i] + y[i] + 1;
. . . . carry = z[i] <= x[i];
. . }
}

**デフォルトの名無しさん** · 2019/11/23(土) 03:03:32.41

borrow = 0;
for (i=0 ; i < n ; i++){
. . if (carry){
. . . . z[i] = x[i] - y[i];
. . . . borrow = z[i] > x[i];
. . }
. . else {
. . . . z[i] = x[i] - y[i] - 1;
. . . . borrow = z[i] >= x[i];
. . }
}

**529** · 2019/11/23(土) 11:50:40.96

自己訂正です。
実は、色々と間違いがあり、次のようになっています：
>>529 : 間違い。
530 : 正しい。
531 : 正しい。
>>532 の前半 : 正しい。
>>532 の後半 : 間違い。

改めて、>>529 の根本的な間違いとして、carry flag は、演算前の最上位ビットだけでは決まる、
というのが大間違いでした。下位ビットからの桁上がりがあるためです。

まとめると、x, y が符号なし整数の場合、

1. a = x - y に対する carry flag :
　 cf = (x < y);
　または。
　 cf = (a > x);

2. a = x + y に対する carry flag :
　 cf = (x < (-y));
　または。
　 cf = (a < x);

です。上記の「または」以後のやり方は、>>536 537 538 で思い出させていただきました。
一年ほど前に見たやり方がそれだったと思います。とてもエレガントですね。

**デフォルトの名無しさん** · 2019/11/25(月) 14:32:25.64

MIPS64やRISC-VのRV64Iで128bit加算減算のアセンブラ出力してみると
おなじようなことやってるね

mips64 128bit加算 $4:$2 ← $5:$4 + $7:$6
　　　　daddu　　　　$2,$4,$6
　　　　sltu　　　　 $8,$2,$4
　　　　dext　　　　 $8,$8,0,32
　　　　daddu　　　　$3,$5,$7
　　　　daddu　　　　$4,$8,$3

mips64 128bit減算 $4:$2 ← $5:$4 - $7:$6
　　　　dsubu　　　　$2,$4,$6
　　　　sltu　　　　 $8,$4,$2
　　　　dext　　　　 $8,$8,0,32
　　　　dsubu　　　　$3,$5,$7
　　　　dsubu　　　　$4,$3,$8

risc-v RV64I 128bit加算 a6:a7 ← a1:a0 + a3:a2
　　　　add　　　　 a7,a0,a2
　　　　sltu　　　　a6,a7,a0
　　　　add　　　　 t1,a1,a3
　　　　add　　　　 a6,a6,t1

risc-v RV64I 128bit減算 a1:a2 ← a1:a0 - a3:a2
　　　　sub　　　　 a2,a0,a2
　　　　sgtu　　　　a0,a2,a0
　　　　sub　　　　 a1,a1,a3
　　　　sub　　　　 a1,a1,a0

**デフォルトの名無しさん** · 2019/11/25(月) 18:08:28.75

だろうね

**デフォルトの名無しさん** · 2019/11/28(木) 08:12:36.09

>>525
何かいろいろ勘違いしてるようだが、キャリーフラグは条件ジャンプのときにも参照するんだぞ。
MIPSが欠陥品だと言われる理由がこれで分かるだろう。

**デフォルトの名無しさん** · 2019/11/28(木) 08:14:06.75

MIPS以降の多くのRISCベースのCPUはすべてキャリーフラグがある。
とても効率的で不可欠だからだ。

**デフォルトの名無しさん** · 2019/11/28(木) 19:38:36.20

>>543
Zeroフラグは良く使うがCarryフラグはほぼ使ったことがない。
どういうときに使う？

**デフォルトの名無しさん** · 2019/11/28(木) 19:56:47.34

フラグはアウトオブオーダーの妨げになるし
並列化も出来ないから
高速化に対してはイマイチ

**デフォルトの名無しさん** · 2019/11/28(木) 20:01:39.23

>>544
比較や減算で上か下か
どうやって判断してると思ってるんだよ・・・

**デフォルトの名無しさん** · 2019/11/28(木) 20:15:33.90

>>546
それって一々フラグを意識しないだろ。

**デフォルトの名無しさん** · 2019/11/28(木) 20:34:30.59

話にならねえな

**デフォルトの名無しさん** · 2019/11/28(木) 21:08:35.99

じゃあ止めよう

**デフォルトの名無しさん** · 2019/11/28(木) 21:56:14.84

jbという条件ジャンプ命令は使っているけど
jcという条件ジャンプ命令は使っていないので、キャリーフラグを使うことはない

アホくさ

**デフォルトの名無しさん** · 2019/11/28(木) 23:10:51.33

>>545
そういう嘘を真に受けてはいけない。
実際のCPU見れば並列実行能力の高い処理系はすべてキャリーフラグ持ってるし、
むしろ並列実行能力がとくに低いMIPSはキャリーフラグ持ってない。

**デフォルトの名無しさん** · 2019/11/29(金) 01:09:48.76

条件分岐でキャリーフラグの使い方が分からない、使ったことがない、使われることを知らなかった、という人はなんだろう。
6502、Z80、6809、AVR、8086、68K、ARMとメジャーなCPUどれから始めてもマニュアル、入門書には書いてると思う。

**デフォルトの名無しさん** · 2019/11/29(金) 14:38:26.36

JA、JB命令などは普通に使ってもJCを使うことはあまりない

**デフォルトの名無しさん** · 2019/11/29(金) 15:12:01.44

>>551

x86なんかキャリーフラグじゃない別のフラグを使った加算とか
歪んだ方向に行ってる

SIMDによる並列化プログラムも
フラグは単なるループ条件くらいにしか使わん
maskレジスタがその役目を継ぐ

**デフォルトの名無しさん** · 2019/11/29(金) 16:58:01.66

555

**デフォルトの名無しさん** · 2019/11/29(金) 18:54:08.05

キャリーフラグを持たないアーキテクチャ・・・
MIPS？PPC？IA-64？死屍累々じゃねーかｗ

**デフォルトの名無しさん** · 2019/11/29(金) 19:13:07.84

>>545
＞フラグはアウトオブオーダーの妨げになるし
＞並列化も出来ないから
また嘘書いてやがる
Core iプロセッサはフラグがあってもアウトオブオーダーしまくりですが？
アウトオブオーダーを正しく理解してたら絶対にこんなことは書かない
分岐も、投機実行で大凡はカバーされるということになっている

フラグの問題は、元の機械語の並べ方に制約が生じるだけで、アウトオブオーダー実行には関係ない
アウトオブオーダーを妨げるケースでも、元のCISCの挙動に合わせるためで、アウトオブオーダーが
関係しているのではない

＞SIMDによる並列化プログラムも
＞フラグは単なるループ条件くらいにしか使わん
＞maskレジスタがその役目を継ぐ
これもまともに理解してないからこそ書ける内容だな
Pen Proになってアウトオブオーダーが使えるようになった時にcmovが導入されたし、
「単なるループ条件」でも投機実行が必要なんだが？

ここまで酷いとお前に語る資格はないよ

**デフォルトの名無しさん** · 2019/11/29(金) 19:39:22.16

アウトオブオーダーの妨げの意味がわからんのだね
なんでx86に変な命令があるのか考えてみ

**デフォルトの名無しさん** · 2019/11/29(金) 19:42:57.97

フラグは本来依存性の無い処理まで依存性が出てくる
フラグが共通だから

レジスタのようにフラグが複数セットあって指定出来ないとダメ
そらがmaskレジスタであったりx86の変な命令であったり

**デフォルトの名無しさん** · 2019/11/29(金) 20:21:52.83

>>548,549
ID:YkvT9y9mがID変えたのか、別人なのかどっちだ？

アウトオブオーダーってのは、真の依存関係にない部分を抽出して同時に実行するっていう
アーキテクチャーだ
ループの2周目以降は前の分岐に依存しているから、本来は順番にしか実行できない
しかし、分岐は数値演算と違って結果のパターンが極めて限定されているので、
決め打ちで一時的に依存関係を無視して処理を進めるのが投機実行だ
アウトオブオーダー実行にはフラグレジスタの存在など関係なく、結果に依存関係が
あるかどうかが問題なんだよ
そんなことも理解せずに語ってたのかって言ってんだよ

**デフォルトの名無しさん** · 2019/11/29(金) 20:34:10.69

フラグを使う演算だと依存関係が出るって言ってんの

関係ない演算でもフラグのせいで依存関係が出る
同じフラグを使うから

**デフォルトの名無しさん** · 2019/11/29(金) 20:35:56.20

これで3回目だが...

x86の変なフラグを使う歪んだ命令は何のため？

**デフォルトの名無しさん** · 2019/11/29(金) 20:58:00.49

jaもjbもキャリーやゼロや符号の論理演算で表現されるのに、どうしてキャリーフラグが
どうのって話になってんの？

>>561
お前がアウトオブオーダーを理解できてないのはわかった

＞フラグを使う演算だと依存関係が出るって言ってんの
＞関係ない演算でもフラグのせいで依存関係が出る
＞同じフラグを使うから
やはり論理レジスタと物理レジスタの理解も出来てないな
フラグを格納できるレジスタが複数あろうがなかろうが、それは命令アーキテクチャの問題であって
アウトオブオーダーの問題ではない
これでどうしてアウトオブオーダーの妨げになるんだよ？

＞x86の変なフラグを使う歪んだ命令は何のため？
その変な命令って何だよ？

**デフォルトの名無しさん** · 2019/11/29(金) 21:18:44.73

命令を調べて出直しておいで

**デフォルトの名無しさん** · 2019/11/29(金) 21:30:22.27

>>552
なんか勘違いしてる。CYの使い方がわからないのではなく、使う場面が少ないからあまり意識しないんじゃないかということ。

**デフォルトの名無しさん** · 2019/11/29(金) 21:44:01.72

>>564
mips64
daddu　　　　$2,$4,$6　1clock目
sltu　　　　 $8,$2,$4　1clock目
dext　　　　 $8,$8,0,32 2clock目
daddu　　　　$3,$5,$7 1clock目
daddu　　　　$4,$8,$3 3clock目
3clock 演算回数計5回 (加算3回、減算1回、シフト1回)

risc-v
add　　　　 a7,a0,a2 1clock目
sltu　　　　a6,a7,a0 1clock目
add　　　　 t1,a1,a3 1clock目
add　　　　 a6,a6,t1 2clock目
2clock　演算回数 4回 (加算3回、減算1回)

amd64
add　1clock目
adc 2clock目
2clock 演算回数 2回(加算2回)

mips、risc-vは必死に並列化してるのに速くならない。
むしろキャリーがあったほうが無駄な演算回数が減り消費電力も減り、
演算器に空きができ、他の計算の余力を得ることになり、並列処理能力は上がることが分かる。

キミのいう依存関係が出てmipsのほうが速い例を挙げてほしい。

**デフォルトの名無しさん** · 2019/11/29(金) 21:59:54.67

>>562

**デフォルトの名無しさん** · 2019/11/30(土) 07:32:32.63

>>556
最近巷をさわがせてるRISC-Vもキャリーフラグはないぞ
今あるCPUの中で最も新しいアーキテクチャなんだが

**デフォルトの名無しさん** · 2019/11/30(土) 07:35:49.37

MIPSの話が出るとすぐにキャリーフラグを連呼する例の人かな
彼は8bitCPUの話が好きみたいだが
もう、既に死んでる6502、Z80、6809、68Kあたりを挙げてるからすぐにわかる

**デフォルトの名無しさん** · 2019/11/30(土) 07:38:44.36

8bitCPUなら多倍長演算はよく使うだろうが64bitCPUではほぼ出番がない

**デフォルトの名無しさん** · 2019/11/30(土) 07:45:40.61

>>568
> 関係ない演算でもフラグのせいで依存関係が出る

RISC-V信者さんって大学の人でしょ？　例を出してよ。どんな演算？

**デフォルトの名無しさん** · 2019/11/30(土) 07:55:34.04

RISC-VならARMのCortex-A72より早いコアができたってさ
このクラスの性能のCPUはx86、POWER、ARM以外にないだろうに

SiFive readies U8-Series RISC-V core designs to compete with ARM's Cortex-A72 models
https://www.notebookcheck.net/SiFive-readies-U8-Series-RISC-V-core-designs-to-compete-with-ARM-s-Cortex-A72-models.440633.0.html

**デフォルトの名無しさん** · 2019/11/30(土) 08:04:40.62

>>571
別人の発言なのに敵視した人は誰でも同一人物だと思っちゃう人？

**デフォルトの名無しさん** · 2019/11/30(土) 08:05:52.96

>>573
> フラグはアウトオブオーダーの妨げになるし並列化も出来ないから

> 変なフラグを使う歪んだ命令は何のため？

逃げてばかりいないでどういうことか説明してくれよ。コード例がひとつも出ないってどういうことだよ。
128bit加算ではMIPSのほうが遅くなってるし。これ依存関係のない128bit加算が複数あったら
パイプラインが先に詰まるのは演算回数の多い、MIPS、RISC-Vじゃん。>>566

**デフォルトの名無しさん** · 2019/11/30(土) 08:10:23.93

RISC-Vの中国製チップを使ったマイコンボード手に入れたが、
普通にCortex-A7クラスのIPCがあってびっくりした

ARMと違ってRISC-Vなのでおそらく中国の半導体メーカーがコアの設計までしたんだろうな
RISC-Vならオープンソースのコアがあるから
中国の半導体メーカーでもそれを参考にして設計できるんだろうね

RISC-Vは中国やインドで推進してるから今後普及していくだろうね

**デフォルトの名無しさん** · 2019/11/30(土) 08:12:36.49

SIMD命令にキャリーフラグやADC/SBB/RCR/RCL命令が無いのが
演算としては使わないっていう証拠
こういった命令は昔のチープな環境のなごり

**デフォルトの名無しさん** · 2019/11/30(土) 08:14:24.92

>>574
たとえば、

CMP EAX,10
JB hogehoge

こんなコードだと比較命令でフラグレジスタが変わるが
次の命令ですぐにフラグレジスタを参照してるってことじゃないの？
俺が発言したわけじゃないから知らんけど

**デフォルトの名無しさん** · 2019/11/30(土) 08:25:28.29

>>577
mips、risc-vも依存して並列実行できない例を出されてもだな。
しかも投機実行されるintelx64のほうがさらに速くて、mips、risc-vはストールする例だし。

**デフォルトの名無しさん** · 2019/11/30(土) 08:30:24.01

>>578
x86だと演算命令で必ずフラグの値が変わるので
比較命令とジャンプ命令の間にフラグの値が変わるようなほかの命令を挟めないからね

**デフォルトの名無しさん** · 2019/11/30(土) 08:33:19.07

そもそもキャリーフラグが有用なのは2進バイナリの多倍長演算の時だけ
64bitCPUではほぼ出番がない

**デフォルトの名無しさん** · 2019/11/30(土) 08:45:13.32

挟むめないって挟む理由あるアルゴリズムなんて存在するか？
そんなコード書ける高級言語はないし。キミは一体RISCで何を計算したいんだ？

**デフォルトの名無しさん** · 2019/11/30(土) 09:00:24.68

アセンブラの話してるのになんで高級言語の話になるのかな？
MIPSならslt $2, $3, 11とジャンプ命令の間にほかの命令を挟めるってこと

**デフォルトの名無しさん** · 2019/11/30(土) 09:22:02.63

>>582
そうではない。挟まなきゃならない理由を聞いている。
それで並列化できなかったものが並列化可能なら例になるがそうではない。判定の前に命令書いても依存関係がなければ並列化される。
キミの例は可読性が悪くなる書き方ができるというだけで並列化できる例ではない。むしろMPSの欠点だ。

> フラグはアウトオブオーダーの妨げになるし並列化も出来ないから

の例を聞いてるんだよ。ひとつも例が出せてないじゃないか。

**デフォルトの名無しさん** · 2019/11/30(土) 09:40:23.31

演算のたびにフラグレジスタが変化するのは無駄だとは思うけどね
特にアドレス計算のたびにフラグレジスタが変化するのはうっとうしい
ARMだと加算減算命令はフラグレジスタが変化するものと変化しないのと2種類用意されてるね

**デフォルトの名無しさん** · 2019/11/30(土) 09:43:31.34

しかし、キャリーフラグの話題でここまでスレ伸ばすのはすごいね
8bitのAVR信者っぽいんだけど
8bitだとキャリーフラグがないと何もできないからね

**デフォルトの名無しさん** · 2019/11/30(土) 09:53:10.63

結局、自分から言い出しといて挟まなきゃならない理由も説明してくれないのか。

まだほとんどコード書いたことない初心者なんだね^^

**デフォルトの名無しさん** · 2019/11/30(土) 11:02:33.57

間に挟みたい場面なんていくらでもあるだろうに
少しは考えたら？

**デフォルトの名無しさん** · 2019/11/30(土) 11:06:05.90

>>587
自分で言い出しといて、答え、コード例は絶対に言わないのね。

そりゃコード書かないもんね、大学の人は。初心者だもん。