アセンブラ初心者スレッド 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/30(土) 15:59:39.71

1000ワードの多倍長加算を100個

データはキャュシュにあるとして
どんなコードにする？

糞遅いコードしか書けないだろうね

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

>>611
多倍長の1ビットシフト
って意味わからない？

そこから説明しないとダメ？

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

レベルが低すぎて会話にならない

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

どうして依存性が切れないのか理解できてないのがレベルが低いって言ってんだよ
WAW依存とか理解してるか？

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

>>612 の擬似コード

for (int i = 0 ; i < 100 ; i++){
. . CLC
. . for (int j = 0 ; j < 1000 ; j++){
. . . . ADC dest[i][j], src[i][j]
. . }
}

メモリアクセスや制御時間がゼロとしても
100 x 1000クロックかかる
ADCが前のADCの結果に依存するから
順番に処理をするしかない

RCL/RCRを使ったシフトも同じ

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

これはコンパイラの最適化やCPUのアウトオブオーダーでは解決出来ない

アセンブラで書こうがCで書こうが
頭が悪い人にとってはこれが限界

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

ただの荒らしにマジレスしても疲れるだけだよ

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

そういうキャリーが必要な、前の計算結果が必要で依存する計算は、
キャリーがないCPUだとさらに効率は悪化するから例として意味がない。

128bitを1bit左シフト
SHL
RCL

mips64だとどういうコードですか？
andi
srl
sll
sll
or
みたいな？　大変でつね。他に便利な命令でもあるんですかね？RISCに対して失礼な質問でしたね^^

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

> 頭が悪い人にとってはこれが限界

ほんとそのまんまでわらた
依存性を減らす、隠蔽するのが最適化の肝
ちょっとは考えてね

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

当然>>616のままじゃダメ
MIPSだろうがARMだろうがx86だろうが

工夫するんだよ
その工夫がキャリーフラグを使うとちょっと難しい

いや、
そもそも>>616のままでも制御をフラグ無しでやらないといけないから大変だね
遅い命令を使って保存しておく？？？？

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

それって1bit以外のシフトならどうなるの？

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

キャリーフラグの人は多倍長1ビットシフトを繰り返す
普通の人はバレルシフタをうまく使う

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

一度に1000回もADCするとかよほど暇なアプリケーションなのだろうな
マイコンのADCと仮定すると速い物でも計0.5～1msecくらいかかるだろう
単に移動平均が欲しいだけなら必要なコストはADC変換1回に付き加減算各1回＋メモリアクセスですむんだし

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

何で移動平均が突然？
多倍長の話だろ？

そもそも多倍長なんか普通は使わない
普通は64bitで収まる
だからキャリーフラグを使った足し算なんて普通はしない

キャリーフラグを使った演算は
8bit、16bit時代の、遅いCPU時代のなごりだ

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

>>625
ARMは最初から32bitだし、AVRに至っては32bit時代に新規に開発された8bitCPUだし、
共に市場で成功したRISC CPUである。キミがキャリー使わないのは単にコード書かないからに過ぎない。
Cでif文でも書けばコンパイラが必然的に使ってしまう。

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

>>623
さて、キミの任意bitシフトのバレルシフタのコードみせてもらおう。verilogでいいよ。

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

>>626
ARMはともかくAVRって
1個ずつ順番にやるしかないCPUは>>616で良いんだよ
このコードが糞なのはスーパースカラーの話
つまり、現代の高速CPU全て

スーパースカラーでどうやって速くするか
SIMDでどうやって速くするか
ベクトルコンピューターでどうやって速くするか

頭が悪いと>>616が限界

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

>>627
書いてることがトンチンカン
>>623をもう一回読みなおしてみようか

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

＞そもそも多倍長なんか普通は使わない
とか書いておきながら100個の多倍長とか、ずいぶんと極端な例を持ち出すことｗ

ローテート命令が依存性を抱えてる理由に即答することもできずに、別の話題で誤魔化そうとしてるから
あんたがアウトオブオーダーをまともに理解してないのは確定的だな
これで究極の最適化だのほざいてたのかよｗ

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

煽れば答えがもらえると思うのは間違い
レベルが違い過ぎて話にならんから無視するぞ

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

>>607
「話にならん」が口癖の人には悪いけど、可読性は非常に大事。
MASMならマクロが使えるから、定型的な処理はマクロで書いておけばその処理が必要な部分は1行で書けるし、
if-elseマクロを使うだけでもだいぶわかりやすくなる。
http://shaw.la.coocan.jp/masm/control.php

特に他人が書いたソースをいじらないといけないときは可読性大事。修正や変更の手間が大幅に省ける。

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

>>629
頓珍漢なレスにマジレスしてやったらそれを理解せず頓珍漢なこと言われてもだな。
それともMIPSは1bitシフトとバレルシフタと命令が別なのかい？　RISCなのにw

> キャリーフラグの人は多倍長1ビットシフトを繰り返す
> 普通の人はバレルシフタをうまく使う

とにかく煽りではなくコード見せてよ。
バレルシフタを上手くつかった任意bitのシフトを。キミは普通の人なんだろ？

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

>>631
俺が答えを知らないんじゃなくて、お前が知らないんだろｗ
煽られても答えることが出来ないからって、レベルが違うとかｗ
恥も上塗りしまくれば目立たなくなるともお思いで？
ｗｗｗｗ

**デフォルトの名無しさん** · 2019/12/01(日) 01:20:15.72

100個の多倍長の配列なんて極端な例を持ち出さなきゃ、普通にアウトオブオーダー実行されるってことだよな
でなきゃそんな欠陥CPUなんてスパコンで使うはずないだろうに

mov edx, 1
…
xor eax, eax
キャリーを変化させたい命令
cmovc eax, edx
ってやりゃ、キャリーフラグの結果をGPRに反映できるはずだから、以降は機械語の制限による
依存は切り離せるはずだよな

**デフォルトの名無しさん** · 2019/12/01(日) 01:44:07.93

cmovcじゃなく、
adc eax, 0
でもいいか
こっちの方が余計なレジスタ使わなくていいし

**デフォルトの名無しさん** · 2019/12/01(日) 02:42:43.59

コンパイラに出力させると
例えば、15bitの左シフトはこんな感じ
　　$3:$2←$5:$4 << 15
　　dsrl　　$2,$4,49
　　dsll　　$3,$5,15
　　or　　 $3,$2,$3
　　dsll　　$2,$4,15

risc-vのRV64GCだとこう
　　a1:a0←a1:a0 << 15
　　srl　　 a5,a0,49
　　sll　　 a1,a1,15
　　sll　　 a0,a0,15
　　or　　 a1,a5,a1

arm64だとこう
　　x1:x0←x1:x0 << 15
　　mov　　 x2, x0
　　lsl　　 x0, x0, 15
　　extr　　x1, x1, x2, 49

**デフォルトの名無しさん** · 2019/12/01(日) 02:43:56.72

任意のシフトはこんな感じ
　　$3:$2←$5:$4 << $6

　　sll　　$2,$6,0
　　dsrl $3,$4,1
　　nor　　$7,$0,$6
　　dsrl $7,$3,$7
　　dsll $3,$5,$2
　　andi $6,$6,0x40
　　dsll $2,$4,$2
　　or　　 $3,$7,$3
　　movn $3,$2,$6
　　movn $2,$0,$6

risc-vのRV64GCだとこう
　　a1:a0←a1:a0 << a2
　　　　and　　 a5,a2,64
　　　　beqz　　a5,.L1
　　　　sll　　 a1,a0,a2
　　　　li　　 a0,0
　　　　jal zero, .L2
.L1:
　　　　srl　　 a5,a0,1
　　　　not　　 a4,a2
　　　　srl　　 a5,a5,a4
　　　　sll　　 a1,a1,a2
　　　　or　　 a1,a5,a1
　　　　sll　　 a0,a0,a2
.L2:

**デフォルトの名無しさん** · 2019/12/01(日) 02:44:18.13

arm64だとこう
　　x1:x0←x1:x0 << w2
　　mov　　 w4, 63
　　sub　　 w5, w4, w2
　　lsr　　 x4, x0, 1
　　sub　　 w3, w2, #64
　　cmp　　 w3, 0
　　lsl　　 x1, x1, x2
　　lsr　　 x4, x4, x5
　　orr　　 x1, x4, x1
　　lsl　　 x4, x0, x3
　　csel　　x1, x4, x1, ge
　　lsl　　 x0, x0, x2
　　csel　　x0, x0, xzr, lt

**デフォルトの名無しさん** · 2019/12/01(日) 11:18:31.61

そういえば最近のx86は
典型的な条件ジャンプは
内部的に比較やテストとあわせて1個のuOP命令になる

内部的にはMIPSの条件ジャンプをリッチにした感じ
比較とブランチで2命令も費やしてたら
パフォーマンス的に問題だからね

分岐でも演算でも、
キャリーフラグの出番はもうほとんどない

**デフォルトの名無しさん** · 2019/12/01(日) 12:25:49.37

Intel® 64 and IA-32 ArchitecturesOptimization Reference Manual
64-ia-32-architectures-optimization-manual.pdf
248966-033June 2016
109ページ目3-12の3.4.2.2 Optimizing for Macro-fusionに書かれてるね
リンクはNGワードで貼れなかったのでググッてね

**デフォルトの名無しさん** · 2019/12/01(日) 12:29:50.17

最新のやつだと貼れるかな？
https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf
130ページ目3-12の3.4.2.2 Optimizing for Macro-fusionに書かれてるね

**デフォルトの名無しさん** · 2019/12/01(日) 13:38:02.71

>>640
キミが有名なMIPS君かw

**デフォルトの名無しさん** · 2019/12/01(日) 13:45:41.30

>>640
jcc命令の説明
77 cb JA rel8 D Valid Valid Jump short if above (CF=0 and ZF=0).
73 cb JAE rel8 D Valid Valid Jump short if above or equal (CF=0).
キャリーフラグは使われてるぞ

**デフォルトの名無しさん** · 2019/12/01(日) 13:47:09.12

ちょっと見難いね
JA Jump short if above (CF=0 and ZF=0).
JAE Jump short if above or equal (CF=0).

**デフォルトの名無しさん** · 2019/12/01(日) 14:13:26.95

>>644
>>642にマクロフィユージョンで内部的に1命令になるって書いてあるじゃん
JA、JAEはTEST、AND、CMP、ADD、SUBがマクロフュージョン可能なようだね

**デフォルトの名無しさん** · 2019/12/01(日) 14:21:48.12

>>646
間にフラグをいじらない他の命令挟むとフュージョン出来ないはずだし、
フュージョンした場合でも、フラグレジスタも一緒に更新するので、フラグを使うと考えていい
演算回路のキャリー信号を使わないということは、まず考えられないよ

**デフォルトの名無しさん** · 2019/12/01(日) 14:22:09.47

>>643
MIPS君が何者かしらんが
おれはx86/ARM/MIPS全てを愛する男
SH/RL78/C6000/C2000/PIC/AVR/RX
などなどいろいろと経験あり

**デフォルトの名無しさん** · 2019/12/01(日) 14:23:53.09

RISC-Vは開発経験ないです

**デフォルトの名無しさん** · 2019/12/01(日) 14:24:03.34

>>647
内部的に1命令のμOPsになるのに何言ってるの？

**デフォルトの名無しさん** · 2019/12/01(日) 14:31:19.10

CFとZFのみを使うやつはCMPでマクロフィユージョン可能のようだね

**デフォルトの名無しさん** · 2019/12/01(日) 14:33:05.42

>>650
なんで噛みついて来るんだ？
間にmovが入ったりしてもフュージョンすると思ってる？
こういう時は普通にフラグレジスタを参照するぞ

**デフォルトの名無しさん** · 2019/12/01(日) 14:40:26.09

確かマクロフュージョンって、実行キューに入るときには別々のμOPsに分解されたはず
整数パイプと分岐ユニット用にね

**デフォルトの名無しさん** · 2019/12/01(日) 15:01:21.03

>>653
また分割しちゃったらマクロフィユージョンで統合した意味なくないか？

>>646のExampleのところにこう書かれてるね
Sandy Bridge microarchitecture enables more arithmetic and logic instructions
to macro-fuse with conditional branches.
In loops where the ALU ports are already congested,
performing one of these macrofusions can relieve the pressure,
as the macro-fused instruction consumes only port 5, instead of an ALU
port plus port 5.

**デフォルトの名無しさん** · 2019/12/01(日) 15:30:27.00

>>654
そういや、分解されるのはマイクロフュージョンの方だったか？
ポート5でALUと分岐ユニットが一緒になってるから間違ってたかも、ゴメン
でも、フュージョン出来ない書き方も可能なはずなので、フラグ参照するパターンもあるはずだよ

**デフォルトの名無しさん** · 2019/12/01(日) 22:01:05.21

>>648
MIPSマシン、RISC-Vマシンなんて手に入らないからMIPSの話はMIPSスレでよくね？　ここ初心者板だよ？　

ほんとこんなところでスレチのMIPS、RISC-Vニュースコピペしないでくれるかな。
ここム板だよ。荒らしと変わらないよ。興味あるならMIPSスレのほう除くでしょ。

**デフォルトの名無しさん** · 2019/12/01(日) 22:35:59.05

MIPSならPIC32がMIPS
RISC-Vのマイコンもすぐに手に入るようなった

https://www.switch-science.com/catalog/5707/
https://www.switch-science.com/catalog/5946/
https://www.switch-science.com/catalog/5700/

**デフォルトの名無しさん** · 2019/12/01(日) 22:42:54.44

MIPS君って人の話聞かない人なんだな。

**デフォルトの名無しさん** · 2019/12/01(日) 22:47:20.58

RISC-VのSBC

HiFive1
http://select.marutsu.co.jp/list/detail.php?id=351

MIPSのSBCもあることはあるぞ

Imagination Technologies Creator Ci40 IoT 開発ボード
https://jp.rs-online.com/web/p/processor-microcontroller-development-kits/1253306/

Imagination Technologies Creator Ci20 Linux/Android 開発ボード
https://jp.rs-online.com/web/p/processor-microcontroller-development-kits/1253305/

**デフォルトの名無しさん** · 2019/12/01(日) 22:54:42.00

RISC-Vが手に入るようになったからトランジスタ技術2019年11月号や
インターフェースの2019年12月号で特集やってるわけだが

**デフォルトの名無しさん** · 2019/12/01(日) 23:20:53.64

RISC-VはMaix Bit、MaixdunoならArduinoで使えるのでかなり敷居は低くなったぞ
価格も3000円から4000円程度
これらがダメというならAVRの話もダメということになるね
そもそもこんなに荒れたのは
>>529->>539の話があって、>>540を貼ったらAVR信者が食いついて荒らしただけ

**デフォルトの名無しさん** · 2019/12/01(日) 23:26:12.86

MIPS君？って、
＞フラグはアウトオブオーダーの妨げになるし
＞並列化も出来ないから
って主張が完全崩壊して、当分は現れないんじゃないかな…
アウトオブオーダーの知識も色々とおかしくて、あれで最適化の講釈する度胸はないだろ

**デフォルトの名無しさん** · 2019/12/01(日) 23:36:04.53

複数の人間の書き込みを同一人物視する人は頭おかしい

**デフォルトの名無しさん** · 2019/12/01(日) 23:38:09.37

Cortex-M7やRXｖ3と競合するRISC-Vコア搭載のASICはよこい

**デフォルトの名無しさん** · 2019/12/02(月) 00:11:51.31

>>657
とりあえず買ってみる

**デフォルトの名無しさん** · 2019/12/02(月) 19:22:50.55

AVX512に慣れると、
他のコアがチープに見える
特に32bit～64bitの中途半端なヤツが

京の次のヤツのARMってSIMD何ビットだっけ？
ちょっと遊んでみたい

**デフォルトの名無しさん** · 2019/12/02(月) 19:24:16.67

PICみたいな超チープなやつは
それはそれで楽しいんだけど

**デフォルトの名無しさん** · 2019/12/03(火) 10:01:22.58

チープというか変態すぎる。

**デフォルトの名無しさん** · 2019/12/03(火) 11:32:29.72

チープなやつは大体どれも変態だよ

C言語で記述不可能なのもあるから
PICは変態な中でもまだマシな方

**デフォルトの名無しさん** · 2019/12/13(金) 00:51:18.32

PICは命令数が少ないから大好き
アセンブラは慣れれば問題ない

**デフォルトの名無しさん** · 2019/12/13(金) 18:29:36.28

GOTOで発作が起きます

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

gotoアレルギー多いよな

**デフォルトの名無しさん** · 2019/12/13(金) 20:44:16.76

JP　じゃないの

**デフォルトの名無しさん** · 2019/12/14(土) 02:42:04.15

日本では特に間違って伝わってるからなぁ
想像するのがC言語やスクリーンエディタ機能組み込まれてた頃のBASICのGOTOっていう

**デフォルトの名無しさん** · 2019/12/14(土) 07:46:40.45

古臭くて役にも立たない話をするのが大好きで、LARGEADDRESSAWAREやキャリーフラグで
大爆死した誰かさんがしれっと戻って来てるのか？

**デフォルトの名無しさん** · 2019/12/14(土) 12:04:43.11

GOTOがというより抽象化に関する教育の不足が問題なんじゃ
昨今のプログラミング教育も本質が見えているようには見えない

**デフォルトの名無しさん** · 2019/12/14(土) 12:07:38.82

歪んだ教育のせいで
ループ内で意地でも
continue, break, goto
を使わない人がいる

その為、
無駄な変数を使ったり
ループ条件が複雑になったり
本末転倒

**デフォルトの名無しさん** · 2019/12/14(土) 13:25:49.98

breakにラベル指定出来なかったのはCの設計ミスやろ

**デフォルトの名無しさん** · 2019/12/14(土) 13:34:05.64

多重ループはgotoで抜ける
って事だろうけどね
gotoはラベル名を考えるのが面倒

break 2;
で2段階breakが出来ると良い

**デフォルトの名無しさん** · 2019/12/14(土) 13:39:05.39

>>679
N88-BASICのような時代は、行番号があったからラベル名を考える必要が
なく楽だった。MASMの場合は、プロシージャローカルのラベル名が
使えたので、lab1:, lab2: のようにしておくと楽だった。
Cの場合、見た目的に「ラベルが浮く」現象が起きるのも問題。

**デフォルトの名無しさん** · 2019/12/14(土) 13:44:49.72

BASICの場合、
1000 xxx
1010 if xxx > xxx then 1200
1020 xxx
1030 goto 1300
1200 xxx
のように書けて至って楽だったし、見た目も綺麗に書けた。

アセンブラの場合も
xxx　proc near
　　　mov yyy,zzz
lab1:
　　　call aaa
lab2:
　　　dec ecx
　　　jnz bbb
xxx　endp
のように命令の前には tab(0x09) 付けされ、ラベルと区別が付き易いのでとても
綺麗に書けた。ところがCの場合は、ラベルと命令の見た目のバランスが悪いので
問題となった。構造上の汚さよりもその問題の方が大きい。

**デフォルトの名無しさん** · 2019/12/14(土) 13:48:16.80

>>680
@@:
jmp @b
jmp @f
も便利

Cで｢ラベルが浮く｣？
ラベルに慣れてないだけでは？

**デフォルトの名無しさん** · 2019/12/14(土) 13:50:15.98

ラベルはインデントを1個左にずらす
case文と同じように

**デフォルトの名無しさん** · 2019/12/14(土) 16:23:54.51

>>683
こんな感じですか？
{
　　{
　　ラベル名1:
　　　　if ( xxx < yyy ) {
　　　　　　普通の文1;
　　　　ラベル名2:
　　　　　　普通の文2;
　　　　}
　　}
}

**デフォルトの名無しさん** · 2019/12/14(土) 16:57:20.57

caseって用途は限定されてるけど、飛び先ラベルそのものよな？

**デフォルトの名無しさん** · 2019/12/14(土) 17:00:28.16

>>684
そうそう

**デフォルトの名無しさん** · 2019/12/14(土) 17:27:51.24

実装が楽なのだろうが条件スキップ命令が嫌い。

**デフォルトの名無しさん** · 2019/12/14(土) 22:37:51.56

好きとか嫌いとかどうでも良い

**デフォルトの名無しさん** · 2019/12/14(土) 22:59:07.71

最初に言い出したのは誰なのかしら

**デフォルトの名無しさん** · 2019/12/15(日) 01:17:17.22

PICのアセンブラは非人間的で嫌われている

**デフォルトの名無しさん** · 2019/12/15(日) 11:22:32.97

アセンブラは元々CPUに寄せてるのが普通で、人間に合わせるなんてこと考えてません。
人間がわかりやすいようにしたければマクロで補うなり、プリプロセッサ作るなどして工夫すればいいんですよ。

**デフォルトの名無しさん** · 2019/12/15(日) 11:26:35.35

PICくらいで非人道的とか
もっと変態CPUはいくらでもあるってのに

**デフォルトの名無しさん** · 2019/12/15(日) 13:07:08.62

ハーバードだろ

**デフォルトの名無しさん** · 2019/12/15(日) 13:31:23.47

>>692
でもね、プロセッサ変わる度に覚え直すのは面倒だしつらいだろ。
面倒なものや難しいものをそのまま力業で押し通そうとするのはやっぱり頭悪いやり方。
賢い人なら、もっと頭使って少しでも使いやすく、わかりやすく変えていくもんだと思うんだよね。

**デフォルトの名無しさん** · 2019/12/15(日) 17:23:58.99

RXのアセンブラは判りやすいと思う

**デフォルトの名無しさん** · 2019/12/15(日) 17:38:53.02

>>694
C言語

**デフォルトの名無しさん** · 2019/12/15(日) 19:26:43.84

>>696
Cが対応しているプロセッサならそれ使えばいいけど、同じ処理をアセンブラで書くのとCで書いたのでは実行ファイルのサイズが大きく違う。
Cは余計なランタイムルーチンがリンクされて無駄に太る。Cで書いてもアセンブラで書くのとほとんど同じサイズになる処理系があればその方が良い。
そして、なければ作るしかない。覚えにくいニーモニックを頑張って覚えるくらいなら、そういう処理系を作ることに労力を使ったほうがいいんじゃないかな。

**デフォルトの名無しさん** · 2019/12/15(日) 19:42:57.22

今時マイコンですら結構な容量のフラッシュROMを積んでいるし
高級言語に由来するフットプリント増が問題になるケースは少ないと思うが
高いリアルタイム性が要求されたり重い処理をするケースはアセンブラで書く場合がある

**デフォルトの名無しさん** · 2019/12/15(日) 20:20:04.05

>>697
需要がないプロセッサは作らない
それだけ

変態アーキテクチャは理由があってそうなってる訳だし
普通のCPUならC/C++で使いやすいように整備されてる

Cランタイムサイズが問題になるCPUだと
ランタイムも小さく出来るのが普通
(printf、malloc を使わないなど)

**デフォルトの名無しさん** · 2019/12/15(日) 20:21:43.99

8bitCPUにFlashROM 32KBにRAMが1KB、広すぎて天国のようだ

**デフォルトの名無しさん** · 2019/12/15(日) 20:22:30.32

>>700
だよね

**デフォルトの名無しさん** · 2019/12/15(日) 20:28:26.55

小規模DSPは比較的アセンブラを良く使う

**デフォルトの名無しさん** · 2019/12/18(水) 03:42:06.43

ラーメンには豚のセアブラをよく使う

**デフォルトの名無しさん** · 2020/01/14(火) 15:59:36.64

68000君は居ないようだな。残念だ
C言語も神が作ったのではない、breakやcontinueがどこに飛ぶのか分からん時はある。
入門書を信じ込んだ狂信者、原理主義者のような、痛い目に会ってない素人は結構いる。

**デフォルトの名無しさん** · 2020/01/14(火) 19:13:53.43

>>704
> breakやcontinueがどこに飛ぶのか分からん時はある。
そんな経験はないなあ。普通はCの仕様通りに動く。
Cの仕様通りに動かないとしたらそのCコンパイラのバグだと思いますよ。
もし本当にわけがわからない動作をしたときはテストプログラムを書いてどう動くか調べたり
アセンブラソース出力して見てみればいい。

**デフォルトの名無しさん** · 2020/01/15(水) 10:28:18.25

ソースを追う気がなくなるからわからなくなるって意味だろ

**デフォルトの名無しさん** · 2020/01/15(水) 12:54:18.67

素朴な疑問なんだが逆アセンブラのラベルってどうやって生成されるの？
レジスタ間接ジャンプのジャンプ先アドレスなんて実行してみないと判らないような・・・

**デフォルトの名無しさん** · 2020/01/15(水) 22:23:13.85

PEヘッダ内にあるImage baseとかじゃね　win32の場合だけど

**デフォルトの名無しさん** · 2020/01/16(木) 05:34:03.43

>>705
>そんな経験はないなあ。普通はCの仕様通りに動く。
多重ループ脱出やifやなんやらのネストでどこに行くか分からなくなる事は無かったんか
Cの経験浅い人は、そういうことが分からないんだろうな。

**デフォルトの名無しさん** · 2020/01/16(木) 07:53:03.25

インデントがぐちゃぐちゃなパターンは昔はよく見た。viのせいだろうな。

**デフォルトの名無しさん** · 2020/01/16(木) 08:04:26.22

今も見る