アセンブラ初心者スレッド 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/01(金) 08:51:34.31

こんな感じ

Enable4G　proc
　call　Relocation
　add　ds:[D_GDTR].@BASE32, eax
　pushr　<ds, es>
　pushf
　cli
　lgdt　D_GDTR
　mov　eax, cr0
　;and　eax, not _PG
　or　al, _PE
　mov　cr0, eax
　jmp　short $+2　　　;flush queue
　movseg　<ds, es>, GD_D4G, ax
　mov　eax, cr0
　and　al, not _PE
　mov　cr0, eax
　jmp　short $+2　　　;flush queue
　mov　al, 2
　out　0F6h, al　　　; A20マスク解除
　sti
　popf
　popr
　ret
　endp

**デフォルトの名無しさん** · 2019/11/01(金) 08:53:59.78

で、仮想86モードに移行する時は、far jmpが必須
なぜなら、仮想86モードに移行するためには
仮想86モード用にセットアップされたTSSを使った特殊なタスクに移行する必要があり
そのためにはプロテクトモード内でのcsの書き換え、つまり、farjmpが必要となるから

これは呼び出し部分

GotoV86　　proc
　pushad
　pushr　<fs, gs>
　pushf
　
　call　ModeSwitch
　
　popf
　mov　al, 3
　out　0F6h, al　　　; force A20 OFF
　popr
　popad
　ret
　endp

**デフォルトの名無しさん** · 2019/11/01(金) 08:54:59.94

ModeSwitch　proc
;　call　Enable4G
　call　SetAddress
　call　SetupIDT
　call　SetupTSS
　
　xor　eax, eax
　mov　es, ax
　call　CleanEMB　　　; これ以降、es=0
　call　SetupPageTable
　call　MoveCode
　call　Setup8259A
　
　prefixd32　　;32bit gdtr (not 24bit gdtr)
　lgdt　GDTR
　prefixd32　　;32bit idtr (not 24bit idtr)
　lidt　IDTR
　
　mov　eax, cr0
　or　eax, _PG + _PE　　; 直接ページングをON
　mov　cr0, eax
　jmp　short $+2　　; flush queue
　mov　ax, GD_D_TSS　　; タスクレジスタにダミーの設定
　ltr　ax
　
　call　VGtest
　FLUSH　GD_V_TSS　; jmp far seg, $next
　ret
　endp

最後に far jmpしてる

**デフォルトの名無しさん** · 2019/11/01(金) 08:56:48.06

Super ASCIIに載ってたサンプルコード
https://pastebin.com/0Tk0U9Y1
(TASMで動作確認済み)

PC9801用のテストプログラム(VRAMを80808080で埋めてるだけです)
.386p
assume cs:prog,ds:prog
prog segment use16
org 100h
mov ah,40h
int 18h
mov ah,42h
mov ch,0c0h
int 18h

mov eax,0
mov es,ax
mov edi,0a8000h
mov ecx, 32768*3/4
mov eax, 80808080h
cld
db 67h
; use ecx for loop counter
rep stosd

mov ax,4c00h
int 21h
prog ends
end

**デフォルトの名無しさん** · 2019/11/01(金) 08:58:53.01

サンプルコード、テストプログラムともにCOM形式なので
LINKした後にexe2bin protect.exe protect.comとcom形式に変換する必要があります

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

知らない人が多いようなので書いておくと、
実測してみると pusha より、ばらばらの push 命令を書いたほうが速度が速い。
一つの理由は、push espという無駄なpushが1つ減らせるから。
これはQEMUなどを使っているだけでは分からない事実。

なお、こっちは良く知られたことだけど、enter, leave 命令より、
push ebp, mov ebp,esp, sub esp, nn などと書くほうが速い。

もっと言えば、486だとなぜかinc, dec が2クロック掛かってしまうのに、
add esp,1 や sub esp,1 は1クロックで済むという事実を知る人は少ないらしい。

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

>>483
補足。QEMU だと、pusha が1命令分の時間で済むのに対し、バラバラの
push命令に直してしまうと、その個数倍の時間が掛かるので、8倍程度後者
の方が遅い。実機だと、後者の方が16%程度速い。実機とQEMUでは全然
速度バランスが違うので、QEMUでの速度測定は全く参考にならないので注意。

**デフォルトの名無しさん** · 2019/11/01(金) 12:10:32.63

>>477
正確には short jmp だったか、far jump だったかは資料を見てみないと
思い出せないけど、少なくとも Wikibooksには、
6. Set the PE bit (and the PG bit if paging is going to be enabled) of the
　MSW or CR0 register
7. Execute a far jump (in case of switching to long mode, even if the destination
　code segment is a 64-bit code segment, the offset must not exceed 32-bit
　since the far jump instruction is executed in compatibility mode)

また、https://stackoverflow.com/questions/26679682/how-does-setting-the-pe-flag-in-cr0-enable-protected-mode
にも、
1. Set up a global descriptor table (gdt) and load it using the lgdt instruction
2. Set the PE flag/bit in the control register CR0 to enabled (ie. to the value 1)
3. Execute a long jump with ljmp

Technically the CPU internally stores the selector information of all selectors used.
Whenever a selector register changes then the limit, base and so on are loaded.
This means that loading the CS register is required for updating the base, limit
and so of the CS register. This means: A far jump must be done (because this
will load the CS register). Maybe a RETF would also work...

I'm not sure if loading the other segment registers (for example DS) would
already work before the far jump so if you load the DS register before the
far jump the base address and limit will be taken from the GDT. Would be
nice to try this out...

と書かれている。

**デフォルトの名無しさん** · 2019/11/01(金) 12:19:54.06

>>485
だんだん思い出してきたので書いておくと、GDTRにGDTのアドレスをセットした
だけでは、CPU内部のセグメントレジスタの情報が更新されない。
例えば、dsには、リミット、ベースアドレスなどの情報がCPU内部に入っているが、
GDTRを更新した段階では、CPU内部のそれらの情報は更新されない。
更新されるのは、mov ds,ax や、pop ds, lds などを実行した場合のみ。
つまり、mov ds,ax などを実行して始めて、CPU内部のdsレジスタに関する隠れ
情報格納場所の情報までが更新され、dsにプロテクトモードらしいセグメントが
対応するようになる。

一方、csレジスタについては、mov cs,ax などの命令が無いので、その代わりになる
のが、far jmp ということになる。far ret や iret などでもいけるかもしれないが、
仕様上は far jmp ということになっているのだと思う。だから、プロテクトモードに
初めて突入したい場合に、far jmp 以外の命令でcs を更新した場合にどうなるかは
保証されていないかもしれない。

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

低レベルな相談です

ADDL・ADDA・SUBL・SUBA・AND・OR・XOR・CPL・CPA命令において
オペランドの第2引数に、=を付けるのをつい忘れてしまうんですが、
何か対処法はありますか？

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

>>487
CASL II は始めて見たんだけど、
http://masudahp.web.fc2.com/casl2/casl2110.html
http://masudahp.web.fc2.com/casl2/casl2120.html

ADDA GR0, =#0045
のように書くと、自動的にラベルを生成して、
ADDA GR0, DATA1
・・・
DATA1 DC #0045
と書いたの等価になるらしいから、忘れるとか言う問題ではなく、
CASL II言語の基礎なので自然に覚えるしかないですね。
アセンブリプログラミングには、このくらいの記憶力は必要です。
ただ、丸覚えするのではなく、ちゃんと理解すれば自然に覚えられると思います。

**デフォルトの名無しさん** · 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

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