アセンブラ初心者スレッド 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/

**デフォルトの名無しさん** · 2017/04/13(木) 17:41:03.83

>>1
乙

**デフォルトの名無しさん** · 2017/04/13(木) 18:14:24.24

**あぼーん** · 2017/04/13(木) 18:15:04.12

あぼーん

**デフォルトの名無しさん** · 2017/04/13(木) 18:15:32.34

終了

◆QZaw55cn4c · 2017/04/13(木) 19:36:20.78

きょうびの時代にアセンブラの優位性を主張する，とすれば
どのような分野で有効でしょうか？

**デフォルトの名無しさん** · 2017/04/13(木) 19:43:03.43

asm.js とかさ
LLVM とかさ
このスレで扱っても良いと思うのね

**デフォルトの名無しさん** · 2017/04/13(木) 20:44:33.86

ごもっともですわ

**デフォルトの名無しさん** · 2017/04/13(木) 21:26:38.34

うん需要ある？

**デフォルトの名無しさん** · 2017/04/14(金) 08:40:42.32

組み込みでなら多少は。

**デフォルトの名無しさん** · 2017/04/14(金) 10:04:28.48

あ。。。IoTとか？

**デフォルトの名無しさん** · 2017/04/15(土) 04:12:03.81

アセンブラはじめるならLinuxでやるといいよ
DOSと同じような感覚でアセンブラプログラミングができるから

こんな感じ

Linux でアセンブリプログラミング
http://www.mztn.org/lxasm/asm00.html
Linux で64bitアセンブリプログラミング
http://www.mztn.org/lxasm64/amd00.html

Linuxでのアセンブル方法はこんな感じ
as -a=hogehoge.lst -o hogehoge.o hogehoge.s
ld -o hogehoge hogehoge.s

gccのでアセンブラ出力&アセンブル
gcc -S -o hogehoge.s hogehoge.c
as -a=hogehoge.lst -o hogehoge.o hogehoge.s
gcc -o hogehoge hogehoge.o

**デフォルトの名無しさん** · 2017/04/15(土) 04:12:41.23

ちなみにx86_64上のLinuxで32bitのバイナリを作成したい場合はこう

x86_64のLinuxでのCの32bitのx86バイナリのコンパイル
gcc -m32 -O2 -o hogehoge hogehoge.c

x86_64のLinuxでの32bitのx86アセンブル
as --32 -a=hogehoge.lst -o hogehoge.o hogehoge.s
ld -melf_i386 -o hogehoge hogehoge.o

x86_64のLinuxでのgccので32bitアセンブラ出力&アセンブル
gcc -m32 -S -o hogehoge.s hogehoge.c
as --32 -a=hogehoge.lst -o hogehoge.o hogehoge.s
gcc -m32 -o hogehoge hogehoge.o

**デフォルトの名無しさん** · 2017/04/15(土) 04:13:21.76

nasmでのx86_64のLinuxでの32bitアセンブル

nasm -f elf hogehoge.s
ld -melf_i386 -o hogehoge hogehoge.o

nasmでのx86_64のLinuxでの64bitアセンブル
nasm -f elf64 $1.s
ld -o $1 $1.o

Ubuntuでのnasmのインストール方法

sudo apt-get install nasm

**デフォルトの名無しさん** · 2017/04/15(土) 04:42:00.93

UbuntuだとQEMUを入れるだけでQEMU+binfmtの設定が自動せされるから
ライブラリへのリンクを貼るだけで他のCPUのバイナリをそのまま実行できるようになる
UbuntuだとARM、MIPS、PowerPCができる

64bitARMならこんな感じ
sudo apt-get install qemu
sudo apt-get install g++-aarch64-linux-gnu
sudo ln -s /usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 /lib
sudo ln -s /usr/aarch64-linux-gnu/lib /lib/aarch64-linux-gnu

32bitARMならこんな感じ
sudo apt-get install qemu
sudo apt-get install g++-arm-linux-gnueabihf
sudo ln -s /usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3 /lib
sudo ln -s /usr/arm-linux-gnueabihf/lib /lib/arm-linux-gnueabihf

Cのコンパイル方法はこんな感じ
aarch64-linux-gnu-gcc -O2 -o hogehoge hogehoge.c

arm-linux-gnueabihf-gcc -O2 -o hogehoge hogehoge.c

数学ライブラリを使う場合のCのコンパイル方法はこんな感じ
aarch64-linux-gnu-gcc -O2 -o hogehoge hogehoge.c -lm
(Ubuntuでは依存するライブラリを後ろに書く)

arm-linux-gnueabihf-gcc -O2 -o hogehoge hogehoge.c -lm

**デフォルトの名無しさん** · 2017/04/15(土) 04:43:20.47

アセンブル方法はこんな感じ
aarch64-linux-gnu-as -a=hogehoge.lst -o hogehoge.o hogehoge.s
aarch64-linux-gnu-ld -o hogehoge hogehoge.s

arm-linux-gnueabihf-as -a=hogehoge.lst -o hogehoge.o hogehoge.s
arm-linux-gnueabihf-ld -o hogehoge hogehoge.s

アセンブラソースの出力はこんな感じ
aarch64-linux-gnu-gcc -S -o hogehoge.s hogehoge.c
aarch64-linux-gnu-as -a=hogehoge.lst -o hogehoge.o hogehoge.s
aarch64-linux-gnu-gcc -o hogehoge hogehoge.o

arm-linux-gnueabihf-gcc -S -o hogehoge.s hogehoge.c
arm-linux-gnueabihf-as -a=hogehoge.lst -o hogehoge.o hogehoge.s
arm-linux-gnueabihf-gcc -o hogehoge hogehoge.o

できたバイナリは普通に実行できる
./hogehoge
バイナリがどのアーキテクチャかはfileコマンドで確認できる
file hogehoge

**デフォルトの名無しさん** · 2017/04/15(土) 04:44:00.98

32bitのARMでUbuntuのgnueabihfではデフォルトでThumb-2でコンパイルされる
ARM命令でコンパイルする場合はオプションを追加する

ARM命令の場合の例
-marm -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
-marm -march=armv7-a -mfloat-abi=hard -mfpu=neon -ffast-math

実行例)
arm-linux-gnueabihf-gcc -O2 -marm -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -o hogehoge hogehoge.c

arm-linux-gnueabihf-gcc -O2 -S -marm -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -o hogehoge.s hogehoge.c
arm-linux-gnueabihf-as -a=hogehoge.lst -o hogehoge.o hogehoge.s
arm-linux-gnueabihf-gcc -marm -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -o hogehoge hogehoge.o

参考）
Thumb-2命令の場合の例
-mthumb -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
-mthumb -march=armv7-a -mfloat-abi=hard -mfpu=neon -ffast-math

**デフォルトの名無しさん** · 2017/04/15(土) 04:47:16.32

32bitARMアセンブラの参考URL
http://www.mztn.org/slasm/arm00.html

64bitbitARMアセンブラの参考URL
http://www.mztn.org/dragon/arm6400idx.html

**デフォルトの名無しさん** · 2017/04/15(土) 07:38:04.38

>>18の32bitARMのアセンブラのサイトの

http://www.mztn.org/slasm/arm04.html
1: ldrb r3, [r0, #+1]! @ r3=mem[r0++]
strb r3, [r1, #+1]! @ mem[r1++]=r3
でエラーが出ます

ここは
1: ldrb r3, [r0], #+1 @ r3=mem[r0++]
strb r3, [r1], #+1 @ mem[r1++]=r3
ですね

**デフォルトの名無しさん** · 2017/04/15(土) 08:02:58.82

補足
32bitARMでのシステムコールの呼び出しはEABIの方式で行ってください

.text
.align 2
.global _start
_start:
adr r1, msg @ address
mov r0, #1 @ stdout
mov r2, #13 @ length
mov r7, #4 @ sys_write
swi 0

mov r0, #0
mov r7, #1 @ sys_exit
swi 0

.align 2
msg:
.asciz "hello, world\n"

**デフォルトの名無しさん** · 2017/04/15(土) 08:35:58.99

32bitARMでFPU命令を使う場合の例
arm-linux-gnueabihf-as -mfpu=vfpv2 -a=hogehoge.lst -o hogehoge.o hogehoge.s
arm-linux-gnueabihf-as -mfpu=vfpv3-d16 -a=hogehoge.lst -o hogehoge.o hogehoge.s

**デフォルトの名無しさん** · 2017/05/07(日) 22:56:59.24

Intel AVX512とか３２ビットモードや１６ビットモードでマシン語記述できるの？
１６ビットモード（ＭＳ－ＤＯＳ６．２）で３２ビット命令を実行できることは確認ずみ。

**デフォルトの名無しさん** · 2017/05/08(月) 01:10:33.28

どうやってマシン語生成するつもりか分からんが、マシン語は記述できるだろ。

**デフォルトの名無しさん** · 2017/05/08(月) 01:56:11.92

>>22
REXプリフィックスは別の命令の再定義なので

**デフォルトの名無しさん** · 2017/05/09(火) 04:41:32.11

いまじゃ解析とか簡単になっとるからなぁ
小学生でもできるんじゃない？

**デフォルトの名無しさん** · 2017/05/11(木) 21:51:54.08

ねえねえ、Altivecって知ってる？

**デフォルトの名無しさん** · 2017/05/13(土) 00:24:52.24

それ作ったチームはインテルでAVX512に関わったんだっけ

**デフォルトの名無しさん** · 2017/07/19(水) 15:57:14.47

>>22
理屈の上ではアセンブラがそれらの命令をサポートしてれば可能。
ただ、今はアセンブラの方がMS-DOSサポートして無いだろうからクロス開発になりそう。
(動けば運が良かったって程度)

でもリアルモードでバイト数大きい64bit命令使うメリットは無い希ガス。
せめてプロテクトモードに移行してから64bit命令使った方が。。。
と言うか、Linuxのブートローダーからロングモード移行までの記事最近読んだけど、アセンブラから見たら多分16bit32bitじゃ無くてリアルモードかプロテクトモードかのが重要(使えるメモリの大きさが違う)な希ガス。

http://postd.cc/linux-bootstrap-1/

**デフォルトの名無しさん** · 2017/10/19(木) 07:34:02.07

TLCS-900H2のDL命令の意味を教えてください
ソースを見る限りではCALLと同等のようですが

**デフォルトの名無しさん** · 2017/12/20(水) 04:38:28.77

LibreOfficeのExcel互換アプリ calc では既にPythonでマクロが書ける

**デフォルトの名無しさん** · 2017/12/20(水) 04:39:01.17

誤爆した。スマン

**デフォルトの名無しさん** · 2017/12/22(金) 18:09:17.57

excel最近使ってないわ

**デフォルトの名無しさん** · 2018/02/21(水) 13:16:23.71

初心者質問じゃないのだが、調べてもわからないので知ってる人がいたら教えて欲しい

Zynqを使ってハードウェアエミュレータを作ろうとしているんだが、
そのままだとアドレス0x40000000からしか自由に使えなくて困ってるんだけども、
Cortex-A9のMMUを設定するにはどうしたらいいんだろうか？
やりたいことはアドレス0x40000000から0x4FFFFFFFまでを0x00000000から0x0FFFFFFFにマッピングしたい

**デフォルトの名無しさん** · 2018/02/22(木) 03:37:57.63

>>33
MMUについてどれだけ知っているのか分からないが
とりあえずLinuxのARMv7周りのコードを調べるのがよいと思われ
"linux arm source mmu"辺りをググッてみるとか
あとはARMのリファレンスマニュアル
http://infocenter.arm.com/help/index.jsp
から、「ARM アーキテクチャ」→「Reference Manuals」→「ARM アーキテクチャリファレンスマニュアル ARMv7-A および ARMv7-R エディション」
のPDF、1267ページ以降を参照

大まかな手順としては
・ページテーブルを構築
・変換テーブルベースレジスタ(TTBR0、TTBR1)をセット
・変換テーブルベース制御レジスタ(TTBCR)をセット
・システム制御レジスタ(CP15 c1、SCTLR)レジスタのMMU有効化ビットをON
となると思われ

**デフォルトの名無しさん** · 2018/02/23(金) 00:45:14.45

>>34
ありがとう
linuxカーネルを参考にしてやってみる

**デフォルトの名無しさん** · 2018/02/24(土) 13:07:22.87

>>34
armのドキュメント読みつつzynqでステップ実行しながらメモリの状態見てみたんだが、
以下の認識で合ってるだろうか？
・ページテーブルを構築
　　適当なメモリ領域にページテーブルを構築(要16kiBアラインメント)
　　(レジスタをいじって設定とかではなく例えば0x80000000番地に作っておく等)
・変換テーブルベースレジスタ(TTBR0、TTBR1)をセット
　　TTBR0はユーザー用、TTBR1はOS用
　　さっき用意したページテーブルの先頭アドレス(上位ビット)を渡す
　　下位ビットの方にその他の設定する
・システム制御レジスタ(CP15 c1、SCTLR)レジスタのMMU有効化ビットをON
　　SCTLRのBit0に1をセット

**デフォルトの名無しさん** · 2018/02/24(土) 18:39:17.01

>>36
俺はARMはちゃんと触ってないので確実なことは言えないが
基本的にはそれで合っていると思う

ページテーブルとTTBRは物理アドレス(PA)で管理、ページテーブル内は仮想アドレス(VA)とPAの対応関係にアクセス保護ビット等
ページテーブルが2段以上(ページディレクトリ経由)になる場合はページディレクトリ内のデータの解釈が少し変わる

RISC系CPUはTLBミスヒットした時のテーブルウォークを自前で叩いてやらないといけない場合があったが、ARMv7ではCPUが自動でやる模様
あと微妙にキャッシュの管理とMMU周りの管理が絡み合っているようで、ここを俺は把握し切れていない

とにかく、Cortex-Aではコプロセッサ#15(CP15)がMMUなので、CP15の制御レジスタ周りをよく見ておいたほうがよいと思われ

**デフォルトの名無しさん** · 2018/02/25(日) 15:07:04.60

>>37
0x40000000の内容に0x00000000からアクセスできるようになった！
GBA(ARM7TDMI)のBIOSもちゃんと実行できてるっぽい
VRAM領域にアクセスしに行って止まってるが(；・∀・)
TLBのattributeの設定はとりあえず適当だが動いてるしよくわからんけど放置しよう・・・

**デフォルトの名無しさん** · 2018/02/25(日) 18:36:29.28

>>38
おめでとう！

**デフォルトの名無しさん** · 2018/02/26(月) 06:57:20.16

気楽にx86_64のアセンブラをやりたい人はこれを読むといいかもね
ただ、あまり詳しくは書かれてない
あくまで、初心者がx86_64アセンブラのとっかかりを掴むために読む本
CPUについての詳しい解説はあまり書かれてない(レジスタの解説程度)
x86_64のWindowsアセンブラ特有のスタックの使い方についても簡単に解説されてる
(x86_64のWindowsのアセンブラではスタック操作を自由にやってはいけない)
この本を読むとx86_64のアセンブラを簡単に試せるようになる

64ビットアセンブラ入門―64ビットCPUの基本構造もやさしく解説
https://www.amazon.co.jp/dp/4877833617/

**デフォルトの名無しさん** · 2018/02/26(月) 15:57:09.08

x86_64のWindowsのアセンブラで最初に嵌るのがスタック関係

ttp://herumi.in.coocan.jp/prog/x64.html
Windowsでのスタック
スタックは常に16byteアラインメントされています.
ただし関数呼び出し直後は戻りアドレス(8byte)がpushされているため, 8(mod 16)となっています.
関数内から別の関数を呼び出すときはアライメントを揃える必要があり,
引数4個のスタック分(32byte)を呼び出し元で確保する必要があります.
確保された領域は呼び出された側で自由に使えます.

Windowsでのスタックの扱い方はここのページを参照するといいかも
ttp://www.officedaytime.com/tips/asm64/caution.html
x64アセンブラ関数の書き方の注意【すごく要注意】
スタックが自由に使えない
32ビットまでのインラインアセンブラでは好き勝手にpush/popしたりして使えていたスタックが
x64では厳しい使用制限を受けることになりました。

具体的には以下のような制限です。
スタックポインタが動くような操作をしていいのは関数の最初と最後の部分だけ
（フレームポインタ（後述）を設定しない場合）。
その部分は「prolog」「epilog」と呼ばれ、やっていいことが決まっている。
prologが終わった時点でスタックポインタは16の倍数になっていなければならない
（中から他の関数を呼ばない場合はこの制限はない）。

ただし、push/popやその他の方法でRSPを動かさない、
何も呼び出さない、
壊してはいけないレジスタをセーブ（push/popに限らずいかなる方法でも）しない、
例外処理をしない、
のすべての条件を満たす関数は「leaf」（関数呼び出しツリーの枝の末端の葉っぱ、くらいの意味でしょうか）と呼ばれ、
この制限を受けません。
前ページのコーディング例にprolog/epilogがないのはそのためです。
-------以下、prolog/epilogの方法はページを参照-------

**デフォルトの名無しさん** · 2018/02/28(水) 14:26:24.02

アライメントとアラインメントとか
用語もちゃんと揃えて欲しいな

**デフォルトの名無しさん** · 2018/03/08(木) 20:28:48.99

linuxでのx86_64のコンパイル＆アセンブル

コンパイル
gcc -O2 -o hogehoge hogehoge.c

コンパイルでアセンブル出力＆アセンブル＆リンク
gcc -O2 -S -masm=intel -o hogehoge.s hogehoge.c
as -a=hogehoge.lst -o hogehoge.o hogehoge.s
gcc -o hogehoge hogehoge.o

　　注：gccに-Sオプションを付けた場合に-masm=intelオプションを付けるとInteニーモニックのアセンブルリストが出力される
　　　　　(デフォルトではAT&Tニーモニックで出力される)

アセンブル＆リンク
as -a=hogehoge.lst -o hogehoge.o hogehoge.s
ld -o hogehoge hogehoge.o

　　注：アセンブラソースに.intel_syntax noprefixを記述するとgasでIntelニーモニックを使えるようになる
　　　　　(デフォルトではAT&Tニーモニック)

**デフォルトの名無しさん** · 2018/03/08(木) 20:29:33.06

例) Linuxアセンブラ版hello world

.intel_syntax noprefix
.text
.global _start
.align 4
_start:
mov rax, 1 # sys_write (1)
mov rdi, 1 # stdout (1)
movabs rsi, offset flat: msg # address(offsetを付けることによってアドレスをロードする)
# gasでは64bitイミディエイトや64bit絶対アドレス指定でのメモリからのロードを使う場合はmovabsを使う
mov rdx, offset flat: len # length(offsetを付けることによってアドレスをロードする)
syscall
mov rax, 60 # exit (60)
xor rdi, rdi # return 0
syscall
.data
.align 8
msg:
.asciz "hello, world\n"
.equ len, . - msg
.end

**デフォルトの名無しさん** · 2018/03/08(木) 20:32:10.43

64bitLinuxでの32bit x86のコンパイル＆アセンブル

コンパイル
gcc -O2 -m32 -o hogehoge hogehoge.c

コンパイルでアセンブル出力＆アセンブル＆リンク
gcc -O2 -S -m32 -masm=intel -o hogehoge.s hogehoge.c
as -a=hogehoge.lst --32 -o hogehoge.o hogehoge.s
gcc -m32 -o hogehoge hogehoge.o

アセンブル＆リンク
as -a=hogehoge.lst --32 -o hogehoge.o hogehoge.s
ld -melf_i386 -o hogehoge hogehoge.o

**デフォルトの名無しさん** · 2018/03/08(木) 20:34:16.87

例)　Linuxアセンブラ版hello world（32bit）
.intel_syntax noprefix
.text
.global _start
.align 4
_start:
mov eax, 4 # sys_write (4)
mov ebx, 1 # stdout (1)
mov ecx, offset msg # address(offsetを付けることによってアドレスをロードする)
mov edx, offset len # length(offsetを付けることによってアドレスをロードする)
int 0x80
mov eax, 1 # exit (1)
xor ebx, ebx # return 0
int 0x80
.data
.align 4
msg:
.asciz "hello, world\n"
.equ len, . - msg
.end

**デフォルトの名無しさん** · 2018/03/10(土) 06:44:54.80

あせんぶりゃー
あせんぶり
あせんぶる

**デフォルトの名無しさん** · 2018/03/11(日) 17:22:40.99

x86_64のリファレンスマニュアル

インテルR エクステンデッド・メモリー 64 テクノロジー・ソフトウェア・デベロッパーズ・ガイド、第 1 巻
https://www.intel.co.jp/content/dam/www/public/ijkk/jp/ja/documents/developer/EM64T_VOL1_30083402_i.pdf

インテルR エクステンデッド・メモリー 64 テクノロジー・ソフトウェア・デベロッパーズ・ガイド、第 2 巻
https://www.intel.co.jp/content/dam/www/public/ijkk/jp/ja/documents/developer/EM64T_VOL2_30083502_i.pdf

**デフォルトの名無しさん** · 2018/05/03(木) 11:01:18.80

8086にワード幅の相対ジャンプあるのに今頃気付いた…＼(^O^)／…

orz

**デフォルトの名無しさん** · 2018/05/03(木) 11:36:54.78

86には無くない？
386以降だった気がする

**デフォルトの名無しさん** · 2018/05/03(木) 11:38:07.04

違った

相対ジャンプは、ほぼ全てが相対ジャンプだから、86からあるな
386からは、8bit限定じゃなくなったのは、条件ジャンブだ

**デフォルトの名無しさん** · 2018/05/03(木) 12:21:57.39

うんまあそういう感じで多分勘違いしていた
というかワード幅のは絶対ジャンプといつのまにか思ってたらしい...(*ノノ)

**デフォルトの名無しさん** · 2018/05/03(木) 13:31:52.82

Hugeモデルω

**デフォルトの名無しさん** · 2018/05/23(水) 19:33:19.00

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

Z4DKB

**デフォルトの名無しさん** · 2018/05/23(水) 19:44:16.48

正規化HUGEとタイリングHUGE

**デフォルトの名無しさん** · 2018/05/24(木) 10:55:44.30

**デフォルトの名無しさん** · 2018/06/13(水) 15:38:35.51

その昔条件分岐のオフセットが8ビットを超えると勝手にnear分岐に展開してくれるアセンブラがあってだな

**デフォルトの名無しさん** · 2018/06/13(水) 15:56:44.91

で？

**デフォルトの名無しさん** · 2018/06/13(水) 17:23:26.62

edas86覚えてる人いる？

**デフォルトの名無しさん** · 2018/07/04(水) 22:19:45.76

TDC

**デフォルトの名無しさん** · 2018/07/05(木) 16:39:14.28

TDC

**デフォルトの名無しさん** · 2018/07/21(土) 07:03:04.58

オブジェクト指向のアセンブラアプリのお薦めを教えてください。

**デフォルトの名無しさん** · 2018/07/21(土) 10:03:59.76

Julia

**デフォルトの名無しさん** · 2018/07/31(火) 18:07:47.27

初心者なので意味が解らないんだけど、オブジェクト指向って考え方なんじゃないの？

**デフォルトの名無しさん** · 2018/07/31(火) 23:36:25.25

ところで、2つの32BIT レジスタの値を、64BITレジスタの上位32bit、下位32bit に
分けて入れる場合、shld を使えばいいのかな？

32BIT 時代の場合は、ebx <--- dx:ax としたい場合、

mov bx,dx
shl ebx,16
mov bx,ax

などとしたもんだけど、64BIT モードで、rbx <--- edx:eax としたい場合、
例えば、

shld rdx,rax,32
mov rbx,rbx

とするのかな。

**デフォルトの名無しさん** · 2018/07/31(火) 23:38:20.35

あ、訂正させて。

多分、正しくは：

shl rax,32
shld rdx,rax,32
mov rbx,rbx

**デフォルトの名無しさん** · 2018/07/31(火) 23:39:52.06

もしかして、mmx レジスタや xmm レジスタの、shuffle 命令なども使えたりする
のだろうか？？

**デフォルトの名無しさん** · 2018/07/31(火) 23:44:49.05

すまん。最訂正。

shl rax,32
shld rdx,rax,32
mov rbx,rdx

**デフォルトの名無しさん** · 2018/07/31(火) 23:51:35.80

>>68
もちつけ

**デフォルトの名無しさん** · 2018/07/31(火) 23:53:48.39

shl rdx, 16
mov ebx, eax
or rbx, rdx

**デフォルトの名無しさん** · 2018/07/31(火) 23:55:11.65

16じゃなくて32

**デフォルトの名無しさん** · 2018/07/31(火) 23:58:34.01

なるほど、つまり：

shl rdx, 32
mov ebx, eax
or rbx, rdx

と。OR を使うとは全く思いつかなかった。

**デフォルトの名無しさん** · 2018/08/01(水) 00:00:05.11

考えてみれば、C言語ではいつも、シフトとOR使ってやってた・・・。

**デフォルトの名無しさん** · 2018/08/01(水) 00:02:01.85

もちつけ

**デフォルトの名無しさん** · 2018/08/01(水) 00:17:55.42

【まとめ】

64BIT モードでは、mov 命令などの destination が、32BITレジスタの場合、
原則的に、対応する64BITレジスタの上位32BITがゼロクリアされてしまうの
で注意が必要。蛇足だが、destinationが16BITレジスタや8BITレジスタの
場合は、対応する64BITレジスタの残りの上位ビットは完全に保持される。

この結果、2つの同じビット数のレジスタを2倍のビット数のレジスタの上位、下位
に代入したい場合、

32BIT Legacy Mode で、ebx <--- dx:ax としたい場合、

mov bx,dx
shl ebx,16
mov bx,ax　　　　;ebx(64BITモードだと、rbx) の上位16ビット(上位48BIT)は、
　　　　　　　　　　;直前のまま変化しない。

で良かったが、

64BIT モードで、rbx <--- edx:eax としたい場合、

shl rdx, 32　　　　; 左シフトの結果、rdx の下位32BIT は、0になる。
mov ebx, eax　　; rbx の上位32BIT は（勝手に）0クリアされる。
or rbx, rdx

や、

shl rax,32　　　　　; 左シフトの結果、rax の上位32BITに元の eaxが入る事になる。
shld rdx,rax,32　　; rdx : rax をひとまとめにして 32BIT分、左シフト。
mov rbx,rdx

などとする必要がある。

**デフォルトの名無しさん** · 2018/08/01(水) 00:48:03.95

64bitレジスタの上位が0になるのは無駄な依存関係を無くすため

32bitレジスタの部分書き換えは大きなペナルティが発生するので注意

**デフォルトの名無しさん** · 2018/08/01(水) 00:52:48.93

アセンブラで高速なコードを書くなら
インテルの最適化マニュアルを一通り読むことを勧める
IACAも非常に便利

**デフォルトの名無しさん** · 2018/08/01(水) 20:01:51.01

アセンブラは普通に書いただけでもCに比べてバイナリも非常に小さいし高速に動いてくれるよね

**デフォルトの名無しさん** · 2018/08/01(水) 23:09:30.00

ペナルティを避けるため、普通は同じレジスタでも別のでもいいから、movzx使って上位ビットが0だって明示してから使うべき

**デフォルトの名無しさん** · 2018/08/01(水) 23:17:32.46

今回の64ビットバージョンのrbx <--- edx:eax としたい場合は関係なかったけど、
mov bx,dxをやった後にebxやrbxを参照するとペナルティが発生するのは32ビットでも一緒だけどね

**デフォルトの名無しさん** · 2018/08/02(木) 20:11:37.64

>>77
これですかね
http://herumi.in.coocan.jp/prog/intel-opt.html

**デフォルトの名無しさん** · 2018/08/02(木) 20:19:01.70

それ

**デフォルトの名無しさん** · 2018/08/02(木) 21:46:38.87

IACAってなんかすごい

**デフォルトの名無しさん** · 2018/08/02(木) 23:06:24.79

>>79
確か、64BIT モードだと、そもそも、movzx reg64,reg32 に相当する専用命令が
存在せず、その代わりに、単なる mov reg32,reg32 を使う想定になっているはず。
なぜなら、後者でも上位32BITが0になるから。

一方、movsx reg64,reg32 については、新しい新命令として、movsxd なる
ものが導入されている。なぜなら、movsx の第二オペランドは、32BIT時代
から、8BIT か、16BIT レジスタしか採りえないから。命令自体で
第二オペランドのビット数が固定されていて、第二オペランドが
8BIT と 16BIT で別々の opcode になっていて、0x66 prefix でデータサイズ
を変えた場合は、第一オペランドのサイズが変わるだけ、という仕様だった
から。つまり、64BITモードでも、第二オペランドのBIT数は、
opcode 自体で固定されてしまっているので、REX.W や 0x66 prefix では
第二オペランドのBIT数の変更はされない、というのが素直な解釈だったから。

**デフォルトの名無しさん** · 2018/08/11(土) 19:53:27.03

[test3.asm]
.data
my_mojiretu　　db 'somothing', 0　　　;1
.code
　　　　mov　　　rax,offset my_mojiretu　　　;2
　　　　xor　　　 rbx,rbx
　　　　mov　　　al,my_mojiretu[rbx]　　　　;3
-------------------------------------------------------------------
2 は、大丈夫なのに、3 だと、以下のようなエラーになる。なぜ？
test3.obj に「絶対アドレス」の relocation 情報が入ることにはなるハズなんだけど。

J:\Develop\C\masm64_s\masm64>d:\ml64\bin\ml64.exe /Fl test3.asm /link /libpath:"
C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64" /subsystem:windows /def
aultlib:kernel32.lib /defaultlib:user32.lib /entry:main
Microsoft (R) Macro Assembler (x64) Version 9.00.30729.207
Copyright (C) Microsoft Corporation. All rights reserved.

Assembling: test3.asm
Microsoft (R) Incremental Linker Version 9.00.30729.207
Copyright (C) Microsoft Corporation. All rights reserved.

/OUT:test3.exe
test3.obj
"/libpath:C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64"
/subsystem:windows
/defaultlib:kernel32.lib
/defaultlib:user32.lib
/entry:main
test3.obj : error LNK2017: 'ADDR32' relocation to 'my_title' invalid without /LA
RGEADDRESSAWARE:NO
LINK : fatal error LNK1165: link failed because of fixup errors

**デフォルトの名無しさん** · 2018/08/11(土) 19:55:58.66

エラーでは、my_title になってるけど、5ch に登校する際に、
ソースを my_mojiretu に変えただけなので、同じと思って。

あと、somothing は、something の typo。

**デフォルトの名無しさん** · 2018/08/11(土) 20:05:28.32

あー。例外的に2の部分の、
mov reg,imm
は、imm に 64BIT 即値が入れられるけど、3の部分では、
ModRMの間接参照の
[ebx + disp]
を使ってるけど、この形では、dispに32BIT までしか入れられないからだな。。。
なるほど。つまり、
mov al,my_mojioretu[ebx]
は、
mov al,[ebx + disp64]
としたくても、AMD64 ではそのようなメモリオペランドが使えないので、
mov al,[ebx + disp32]
にしかアセンブルできないと。

だから、絶対アドレスが、32BIT を超えるような値になった場合にはどうしようも
ないと。

**デフォルトの名無しさん** · 2018/08/11(土) 20:08:54.58

ちょっと勉強になった

64bitでasm触ることなくなったもんなー

**デフォルトの名無しさん** · 2018/08/11(土) 22:13:23.67

>>85
実際に試してないから推測だけど、2では64bitレジスタに代入しているのに対して
3では8bitレジスタALに代入しようとしている。EAXかRAXに代入してみれば動くんではないかと。

**デフォルトの名無しさん** · 2018/08/12(日) 06:39:04.85

>>89
関係ないと思うよ。

よく読んでみて。

**デフォルトの名無しさん** · 2018/08/12(日) 06:49:59.09

AMD64 では、ModRM を使った MemoryOperand の [reg64 + disp] のような形式の場合、
disp の BIT 数が、最大でも、
　[reg64 + disp32]
のように 32BIT までが限界で、64BIT の disp64 は存在していない。
imm も「一般的には」、imm32 までで、imm64 は使えない。
ところが、mov reg,imm に関しては、例外的に
　mov reg64, imm64
という命令が存在している。また、似た話として、
ModRM を使わない MemoryOperand では、disp64 のようなものが例外的に
存在していて、
　mov reg,[disp64]
というものが存在している。ただし、意味的には、[disp64] ではなく、[moffset64]
のような意味合いで、
　mov reg,[moffset64] や
　mov reg,moffset64
と書かれることがある。この場合、[] が付いてなくても意味は同じ(混乱注意)。
ちなみに、mem64 は、データサイズが 64BIT という意味なので、
　qword ptr [xxxx]
の意味になるので、また違う。

つまり、レジスタに入れてアクセスできるアドレスは64BITなのに、固定アドレスを入れてアクセス
できるメモリは、32BIT に制限されやすい、ということ。ただし、上記のような例外が用意されている
ので、絶対に32BITを超えた固定アドレスのメモリをアクセスできないというわけではない。

**デフォルトの名無しさん** · 2018/08/12(日) 06:59:38.95

ちなみに、
.data
ラベル名 db 'xxxx',0　　;1
.code
lea ebx,ラベル名　　　;2
のような場合、一見、2の第二オペランドは、ModRM に encode されるので、
lea ebx,[disp32]
になってしまうから、この場合も、32BIT の限界に遭遇してしまうのではないかと
思ってしまうかもしれない。ところが、実際には、
lea ebx,[rip + rel_addr32]
のように命令ポインタの rip 相対のアドレスとして、encode されるので、また、事情が
違ってくる。結論的には、この場合は、ラベル名がリンクに指定した obj の中にある
限りにおいては、32BIT の限界を特に気にすることは無い。

**デフォルトの名無しさん** · 2018/08/12(日) 07:04:02.85

>>92
間違った。 ebx ではなく、rbx だった：

lea rbx,ラベル名　　　;2
lea rbx,[disp32]
lea rbx,[rip + rel_addr32]

**デフォルトの名無しさん** · 2018/08/16(木) 12:39:22.96

>>41
実は、以下のようにしておくだけで、SEH例外のサポートも含めて、
ほぼ、push, pop は自由に出来るようになるらしい。

1. 関数の最初と最後を以下のように書く :
push rbp
mov rbp, rsp
・・・
pop rbp
ret

2. rbp を frame pointer に使っているということを、関数の prolog に書く。

【「ほぼ」の例外】

call 関数名などの関数コールの直前では、rsp を16バイトアラインしてある
必要があること。それさえ気をつけていれば、push, pop は自由に行える。

【16倍とスタックアラインについて】

push rbp のおかげで、return address の 8 バイトと合わせて、直後からは、
上手く勝手に rsp が 16 バイトにアラインされた状態になってくれる。
だから、余り難しい事を考える必要は無い。

**デフォルトの名無しさん** · 2018/08/16(木) 13:12:50.69

frame pointer(rbp) を使わない場合は、関数の通常部分では、rsp を最初から最後まで
固定しなくては、構造化例外を処理出来なくなる。

なので、rsp が変化する事になる push, pop が使えなくなる。

（なお、人間にとっては便利でも、コンパイラにとっては、元々 push, pop は使いにくい
命令であった。）

x86、x64 アーキテクチャでは、mov reg, reg/mem のような事は出来ても、
mov mem, mem は出来ない。ところが、この、push, pop についてはそれが
出来てしまう数少ない例外。

例えば、

push qword ptr [ebp + disp1]　　;1
や
push qword ptr [esp + disp1]　　;2

で、ローカルの auto 変数をスタックに保存する事が出来る。ところが、

mov qwrod ptr [esp + disp1], qword ptr [esp + disp2]　　;3

とは出来ない。だから、push 命令を使うと、実はパフォーマンスが向上する可能性も
秘めてはいるかも知れない。ただし、これも、レジスタの個数が十分沢山ある
近年では、必ずしもそうとも言えないかもしれない。レジスタの個数が不足して
スタックに保存したくなった場合、

mov [esp + disp1], reg　　;4

と書けばいいわけであって、3 のように書く必要性は、近年では下がっているようだから。

**デフォルトの名無しさん** · 2018/08/16(木) 13:27:50.54

>>95
誤：esp, ebp
正：rsp, rbp

【なぜ、3の必要性が少ないかについて】

3のようにしなくても、そもそも、3の第二オペランドの値は、メモリ上において
あるのだから、レジスタが不足しても値が消えてしまう事はない。だから、
保存の必要も無い。

レジスタが不足した場合に保存する必要があるのは、必ずレジスタの値。
だから、mov [rsp + disp], reg の形式で十分保存できてしまう。

**デフォルトの名無しさん** · 2018/08/16(木) 15:37:56.45

>>96
間違えてやんの
だせー！

**デフォルトの名無しさん** · 2018/08/16(木) 21:00:56.95

内部的にロード、ストアは別命令
アセンブラの命令数とかあまり関係ない

**デフォルトの名無しさん** · 2018/08/18(土) 06:32:40.93

>>92
コードセグメントのリテラルならrip相対でエンコードされると思うけど、データセグメントでそれ可能だったっけ？
最近アセンブリ言語いじってないから確認してないけど、それが可能だったら>>85の3はエラーにならないのでは。

>>95
最適化マニュアルのスループットとレイテンシの表見れば書いてあるけど、
push、popはロードユニットやストアユニットだけじゃなくALUも使う。その分無駄。

**デフォルトの名無しさん** · 2018/08/18(土) 06:35:45.68

push、popはコードサイズに制限のある、プロローグ、エピローグ部分で使うことはあるけど、
あまり必要性はなくなったよ。

**デフォルトの名無しさん** · 2018/08/18(土) 07:05:31.99

push、popみたいに複数のμOPになる命令は利用可能なデコーダーも制限されるので
他の命令のデコードも阻害しやすい。
演算命令のメモリオペランドみたいに、フュージョンされて簡単デコーダーで発行できるようになったのもあるけど。

**デフォルトの名無しさん** · 2018/08/18(土) 08:53:46.48

>>99
>コードセグメントのリテラルならrip相対でエンコードされると思うけど、
>データセグメントでそれ可能だったっけ？

可能。

**デフォルトの名無しさん** · 2018/08/18(土) 09:10:13.08

>>99
>最近アセンブリ言語いじってないから確認してないけど、それが可能だったら>>85の3はエラーにならないのでは。

エラーメッセージをよく読むと書いてあるけど、linker に、
/LA RGEADDRESSAWARE:NO
というオプションを渡すと、エラーが消える。

これは、[rbp+disp] の disp には、32BIT までしか入れられないので敢えて
エラーを出しているだけなので、本当は特に問題にはならない。

**デフォルトの名無しさん** · 2018/08/18(土) 14:23:17.32

>>103
それ、可能と言えば可能だけど、64bit化のメリットのかなりの部分が消えてしまうし、
DLLでも制限なく使えるんだっけ？
と思って調べたらやっぱ問題あるよなあ。
https://www.webtech.co.jp/blog/optpix_labs/programing/6387/

**デフォルトの名無しさん** · 2018/08/18(土) 19:54:44.26

>>103
mov cl, hogehoge
これでアセンブルして、dumpbin /relocations test01.obj
これで見ると
hogehogeがREL32になる(PC相対の32bitオフセット)
ラベルの種類としてRIP相対のREL32はあるけど
通常のレジスタに32bit相対のラベルの種類がないのでは？
だからエラーになると

**デフォルトの名無しさん** · 2018/08/18(土) 21:13:26.29

簡単なWindowsのアプリを作ってWinMainのアドレスを表示すると
0x000000003fdf1770
俺の環境ではこんな値が出た
これってアドレスとしては1GBくらいの位置
下位32bitの絶対アドレスで指定すると符号付と解釈した場合に
残り1GBの範囲しかアクセスできない
だから、64bitのWindowsや/3GBスイッチを指定した32bitWindowsでは
下位32bitの絶対アドレスで指定するなとマイクロソフトは決めたのでは？

RIP相対なら開始アドレスに関係なくRIPの相対値なので
プログラムがロードされた位置に関わらず2GBまでアクセスできる

**デフォルトの名無しさん** · 2018/08/18(土) 21:29:59.45

同じようなプログラムを32bitで作ってコンパイルしたらWinMainの開始アドレスは
0x013215a0
アドレスとしては19MBくらいの位置

64bitアプリは32bitアプリよりもずっと高位のアドレスにロードされるんだろうね
だから64bitアプリでは下位32bitでの絶対アドレス指定は禁止してるのかも

**デフォルトの名無しさん** · 2018/08/19(日) 12:41:20.07

論理的に高位か下位かはどうでもよくね？

**デフォルトの名無しさん** · 2018/08/19(日) 16:59:22.46

>>108
通常のプログラムが扱えるのは論理的なアドレスだからな
関係なくないよ

>>85の
　　　　mov　　　al,my_mojiretu[rbx]　　　　;3
のような下位32bitの絶対アドレスで指定する場合、扱えるデータの量が減る
上の例では0から2GBの範囲しかアクセスできないのに
論理アドレスで1GB付近からロードされたら扱えるスタティックに割り当てられたデータの量が極端に減ってしまう

**デフォルトの名無しさん** · 2018/08/19(日) 17:05:58.03

だからこそ
>>85の
　　　　mov　　　al,my_mojiretu[rbx]　　　　;3
のようなコードを書くとリンカがエラーを吐くようになってるんだろうね
下位32bitの絶対アドレスで指定するなと

**デフォルトの名無しさん** · 2018/08/19(日) 17:21:35.92

ほとんどのCPUでは64bitのアドレスを直接指定する方法は限定されてて、実行速度も遅くなる
だからWindowsやLinuxでは64bitでもデフォルトではスタティックに割り当てられたシンボルは
だいたい32bitの値として扱ってる
(Linuxではコンパイラのオプションでメモリモデルを指定できて
スタティックなシンボルを64bitの値として扱うこともできる)

64bit Windowsの場合、かなり高位のアドレスにロードされるようだから
RIP相対の32bitの値として扱ってるのだろう

ちなみにこれはスタティックに割り当てられたデータだけで動的に割り当てられたデータは
64bitのポインタ値で扱われるのでユーザプログラムが扱える全仮想メモリ領域に配置できる

**デフォルトの名無しさん** · 2018/08/19(日) 17:30:58.64

64bitARMの場合、Linuxではスタティックなシンボル値読み込む場合
adrp x0, :pg_hi21:hogehoge
add x0, x0, :lo12:hogehoge
これで読み込む
これで33bitのページ単位でPC相対のアドレスを読み込める
つまり64bitのARMではスタティックなシンボル値は33bitのPC相対アドレスとして扱ってる
(相対なのはページ単位なので下位12bitは動かせない、下位12bitは絶対アドレス値を足してるので)

**デフォルトの名無しさん** · 2018/08/19(日) 17:34:00.29

64bitのARMのadrp命令と同等の命令はRISC-Vや最近発表されたnanoMIPSなどでも採用されてる
RISC-VやnanoMIPSは33bitではなく32bitだが

**デフォルトの名無しさん** · 2018/08/19(日) 17:41:09.62

スタティックなシンボル値の制約はアセンブラではなくあくまでコンパイラの仕様だが
(コンパイラ側でシンボルを扱う場合にあえて下位32bitしか読み込まない仕様にしてる)
最近のアセンブラプログラミングでは高級言語とリンクすることが多いので必須な知識

**デフォルトの名無しさん** · 2018/08/19(日) 19:20:24.59

>>111
> ちなみにこれはスタティックに割り当てられたデータだけで動的に割り当てられたデータは
> 64bitのポインタ値で扱われるのでユーザプログラムが扱える全仮想メモリ領域に配置できる
> ほとんどのCPUでは64bitのアドレスを直接指定する方法は限定されてて、実行速度も遅くなる

　つまりこういうこと？
・動的に割り当てられたデータは64bitでアクセスできるけど実行速度が遅くなる
・静的に割り当てられたデータは32bitでアクセスするように制限されてるけど実行速度は速い。
・ただしLinuxの場合、メモリモデルを指定して再コンパイルすればこの制限はなくなる

**デフォルトの名無しさん** · 2018/08/19(日) 20:02:42.41

>>115
＞・動的に割り当てられたデータは64bitでアクセスできるけど実行速度が遅くなる

そもそも動的なデータは64bitのポインタで管理されるので最初から全アドレスにアクセスできる

＞・静的に割り当てられたデータは32bitでアクセスするように制限されてるけど実行速度は速い。

違う、あくまでシンボルを32bitのアドレスとして読み込んでるだけでデータサイズは関係ない

x86_64でも64bitのアドレスを指定して読み込む命令は限られてるし、
実行速度の面でも効率が悪いのでRIP相対で32bit分だけを使ってる
たとえば、
mov rcx, data01
とした場合、data01の部分はRIP相対の32bitアドレスになる、読み込まれるデータは64bitの値

RISC CPUだとアドレスを読み込んでからデータに読み書きするという2段階になるので
たとえば、64bitのARMだと
adrp x0, :pg_hi21:data01
add x0, x0, :lo12:data01
ldr x0, [x0]
と下位33bitでPC相対アドレスとしてシンボルが読み込まれる

RISC-Vの絶対アドレスだと
lui a0, a0, data01
addi a0, a0, data01
ld a0, (a0)
PC相対だと
1: auipc a0, %pcrel_hi(data01)
addi a0, a0, %pcrel_lo(1b)
ld a0, (a0)
こうなる
(%pcrel_lo()では対応するpcrel_hi()のラベルを指定)

**デフォルトの名無しさん** · 2018/08/19(日) 20:06:20.81

RISC-Vの絶対アドレスのところが間違ってた

不正解
lui a0, a0, data01
addi a0, a0, data01
ld a0, (a0)

正解
lui a0, %hi(data01)
addi a0, a0, %lo(data01)
ld a0, (a0)

**デフォルトの名無しさん** · 2018/08/20(月) 06:10:04.15

>>116
アドレッシングの話をしているだと思ったのではしょったけどこう書けばいいですかね

・動的に割り当てられたデータは64bitアドレッシングでアクセスできるけど実行速度が遅くなる
・静的に割り当てられたデータは32bitアドレッシングでアクセスするように制限されてるけど実行速度は速い
・どちらの場合も読み書きできるデータサイズに制限はない
・ただしLinuxの場合、メモリモデルを指定して再コンパイルすればこの制限はなくなる

**デフォルトの名無しさん** · 2018/08/20(月) 07:34:26.88

何で、動的に割り当てられた変数と静的に割り当てられた変数の
アクセス速度を比較するのか意味不明だが
一番アクセスが速いのはローカル変数だと思うぞ

ローカル変数はdisplacement付きのスタックポインタ間接アドレッシングでアクセスできるので
ほとんどのCPUでdisplacementが届く範囲なら1命令でロード、ストアができるからね

**デフォルトの名無しさん** · 2018/08/21(火) 13:09:22.87

>>119
今までの話の流れで言うと、速度を比較するのが目的ではなくて、
なぜ静的に割り当てられたデータは32bitアドレッシングでアクセスするように制限されているのか？
ですよ。普通に考えたら64bitアドレッシングが制限なくできて当たり前だろ。なんで？ってことです。

**デフォルトの名無しさん** · 2018/08/21(火) 13:14:13.58

x86の64bitモードでのアドレッシングは全て64bit

**デフォルトの名無しさん** · 2018/08/21(火) 16:35:27.52

>>120
命令サイズを節約してるだけ
バラバラにコンパイルされた.oに対して後から命令長は変えられないんでデフォでそうなってる
変えたければラージモデルの類のコンパイルオプションがあるはず

**デフォルトの名無しさん** · 2018/08/21(火) 19:52:55.59

>>120
64bitのデータだろうが32bitデータだろうがデータがキャッシュに入ってれば
キャッシュからデータを読み出す速度は変わらないが、
64bitアドレスを即値で指定すると
CISC CPUの場合、64bitアドレスの分、命令のオペランドの長さが長くなるので
今時の複数の命令を同時発行できるCPUだと一度に発行できる命令の数が減るので遅くなる
64bitのアドレスだけで8バイトにもなるからね
RISC CPUの場合は64bitのアドレスを一度に読み込めないので複数の命令に分けて読み込むが
64bitのアドレスを読み込むと命令数が増える

結局、静的データやジャンプ先のラベルはは32bitアドレスに限定したほうが結果的に速くなる
たいていのプログラムで静的データやジャンプ先のラベルで
32bitの範囲を超えるような応用プログラムは極一部の分野だけだしね
その極一部の応用プログラムのために性能を落とす必要はない

スパコンでも使われるLinuxではメモリモデルとして
静的データやジャンプ先のラベルを64bitで扱うようにコンパイルするオプションがある

このページはPGIのコンパイラのページだがわかりやすく説明してある
https://www.softek.co.jp/SPG/Pgi/TIPS/opt_64.htmlはこのページ

ARMやx86_64、POWERのgccでも-mcmodel=largeや-mcmodel=mediumがあったりする
(ARMでは-mcmodel=largeはあるが-mcmodel=mediumはない)
https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html

**デフォルトの名無しさん** · 2018/08/22(水) 02:39:05.86

>>104
確か、そのリンカオプションは、DLL作成時に指定するとエラーになる。

また、アプリの場合だと、relocation 情報が strip されて、EXE ファイルの中にはなくなっているのに対し、DLLだと relocation 情報が最後まで残されたままになっている。

>>105
あなたが使っている用語が x86 や x64 とは合わずめちゃくちゃなので何を聞いているのか分からないが、
hogehoge　　db 'xxxx', 0
　　　　　　　mov cl, hogehoe １
とすると、
　　　　　　 mov cl,[offset hogehode]
と言う意味になり、encode としては、
　　　　　　　mov cl, [RIP + (offset hogehode - offset label1)]
label1:
のように、RIP 相対の disp
　　　　　　　mov cl, [RIP + disp32]
に encode される。この場合の disp32 は、意味としては、rel32 で、
RIP からの32BIT相対アドレス。

一方、似て非なるものとして、
　　　　　mov cl, hogehode[rbx]
とすると、
　　　　　mov cl, [offset hogehode + rbx]
即ち、
　　　　　mov cl, [rbx + disp32]
と翻訳される。この場合の、disp32 は、32BIT絶対アドレス。同じ、disp32 でも、意味は異なる。しかし、disp は、32BITまでで、 64BIT 値のものは存在していない。一方、64BITアドレスも一応は使えるように、
　　mov REG64, ADDR64 　; REG64 は、RAX, RBX, RCX, EDX, RBP, RSI, EDI など。
や
　　mov ACC, [ADDR64]　 ; ACC は、al, ax, eax, rax
という命令が、専用命令として特別扱いとして存在しているが、特殊中の特殊。

**デフォルトの名無しさん** · 2018/08/22(水) 02:48:04.81

>>124
訂正：

hogehoge　　db 'xxxx', 0
　　　　　　　mov cl, hogehoge
とすると、
　　　　　　 mov cl,[offset hogehoge]
と言う意味になり、encode としては、
　　　　　　　mov cl, [RIP + (offset hogehoge - offset label1)]
label1:
のように、RIP 相対の disp
　　　　　　　mov cl, [RIP + disp32]
に encode される。この場合の disp32 は、意味としては、rel32 で、
RIP からの32BIT相対アドレス。

ちなみに、masm では、
hoge1　　　db 'aaa'　　　　;1
と
hoge2:　　db 'aaa'　　　　　;2
は明確に区別されており、hoge1 は、byte 型の配列変数のような取り扱いになり、
　　　　mov　　al, hoge1　　　　;1
は、masm には通らないが、旧来のアセンブラの感覚で言えば、意味的には、
　　　　mov　　al, qword [offset hoge1]　　　;3
となり、hoge2 の方は、直後の db 命令とは全く関係の無い単なる near アドレスと解釈され、
　　　　mov　　rax, hoge2　　　　　;4
は、意味的には、
　　　　mov　　rax, offset hoge2　　　　;5
となる、ただし、4は、もしかするとそれ自体が文法上、masm の構文に合わないかもしれない。
masm は、「マクロアセンブラ」であって、通常のアセンブラとは結構異なるので。

**デフォルトの名無しさん** · 2018/08/22(水) 02:50:10.88

>>125
誤：　　　　mov　　al, qword [offset hoge1]　　　;3
正：　　　　mov　　al, byte [offset hoge1]　　　;3

これも、masm 流には、
　　　　mov　　al, byte ptr [offset hoge1]　　　;3
nasm 流には、
　　　　mov.b　　al, [offset hoge1]　　　;3
みたいな感覚。みたいなだけで、実際にはそのまま書くと、エラーになる
かも知れない。

**デフォルトの名無しさん** · 2018/08/22(水) 02:55:16.05

>>124
さらに補足すると、

mov cl, [rbx + disp32]

の disp32 は、rbx の中身によって意味が変わってきて、

1. disp = 32BIT 相対アドレス　　(rbx が絶対アドレスの場合)
2. disp = 32BIT 絶対アドレス　　(rbx が相対アドレスの場合)

となる。2. の例としては、
　　rbx = 配列添え字 * (配列の要素のバイト数)
のような場合。1. の例としては、
　　rbx = 構造体の先頭アドレス
のような場合。

**デフォルトの名無しさん** · 2018/08/22(水) 04:37:08.89

>>127
今やってみたが
64bitアプリを通常にコンパイルした場合のWinMainのアドレス
0x000000013f291770

/largeaddressaware:noを付けてコンパイルした場合のWinMainのアドレス
0x0000000001241770

/largeaddressaware:noを付けるとプログラムがロードされるアドレスが変わる
64bitのアプリを通常にコンパイルするとWinMainのアドレスが0x000000013f291770
およそ先頭から5GBの位置
つまり、32bit絶対アドレスでは届かない位置にプログラムがロードされてる

/largeaddressaware:noをつけると先頭から18MBくらいの位置

エラーが出るのは32bit絶対アドレスでは届かない位置にロードされる可能性があるからだろうな

**デフォルトの名無しさん** · 2018/08/22(水) 04:40:24.11

補足：
/largeaddressaware:noを付けると64bitアプリでもメモリは2GBまでしか使えなくなる

**デフォルトの名無しさん** · 2018/08/22(水) 04:46:45.21

つまり、>>128が示してることは

Windowsの64bitアプリでは
mov　　　al,my_mojiretu[rbx]
のような書き方はしてはいけないということ

**デフォルトの名無しさん** · 2018/08/22(水) 08:30:00.67

>>124 XvleiWNbとは別人だよね？
/LARGEADDRESSAWARE:NOの辺りからなんか違和感あって、「そうなん？」って感じだったんだけど。
ARMやコンパイラの仕様だとかまで出てきて訳わからなくなるところだったよ。

＞一方、似て非なるものとして、
＞　　　　　mov cl, hogehode[rbx]
＞とすると、
＞　　　　　mov cl, [offset hogehode + rbx]
＞即ち、
＞　　　　　mov cl, [rbx + disp32]
＞と翻訳される。この場合の、disp32 は、32BIT絶対アドレス。同じ、disp32 でも、意味は異なる。

＞Windowsの64bitアプリでは
＞mov　　　al,my_mojiretu[rbx]
＞のような書き方はしてはいけないということ
今までなんで絶対アドレスが出てくるのか疑問だったけど、コンパイラはこういうコードは吐かない、ってことだよね。

**デフォルトの名無しさん** · 2018/08/22(水) 19:32:17.75

>>131

>>124 XvleiWNbとは別人だよね？

別人。ARMは使ったこと無い。

**デフォルトの名無しさん** · 2018/08/22(水) 19:39:47.75

>>130
でも現実は、複雑。

なぜなら、COFFの仕様的には、obj ではない Image(EXEやDLLの事) のためだけに
ある .reloc section には、64BIT 絶対アドレスの再配置も行えるようになっているから。

現状の MS 製の link.exe がどうなっているかはともかく。

**デフォルトの名無しさん** · 2018/08/22(水) 19:45:45.82

>>133
すまん。間違った。
mov　　　al,my_mojiretu[rbx]
は、意味的には、
mov　　　al, [rbx + offset my_mojiretu]
となって、最後は、
mov　　　al, [rbx + disp32]

となるが、disp32 の部分は、disp64 の命令は存在していないので、
.reloc section が 64BIT 絶対アドレスに対応していても、無理だった。

勘違いした。

**デフォルトの名無しさん** · 2018/08/22(水) 19:57:50.56

>>128
一応、論理的には、WinMain は、code (.text) section に置かれる。
my_mojiretu みたいなものは、.data section (など)に置かれる。

my_mojiretu みたいなものは、初期化(初期値)データなので、
2GB も使えれば十分ではあるはず。もし、2GB を超えるのなら、exe ファイルの
サイズも 2GB を超えるはず。

という事で、初期化データのおかれた section のアドレスが、2GB 未満
に置かれるならなんとかなるはず。

というか、通常、exe ファイルは、relocation 情報が strip されているので、
確か、Optional Header の BaseOfCode に配置したいアドレスを入れておける。

だから、その値を小さめにしておけば、初期化データのアドレスを 2GB 未満
の位置に配置する事はそんなに難しくないはず。

確か、32BIT 時代は、0x40000 位の値だった。

**デフォルトの名無しさん** · 2018/08/22(水) 20:02:29.70

>>135
正しくは、BaseOfCode ではなく、ImageBase の方だった。
正しい値は、0x40000 ではなく、1桁大きい、0x400000 だった。
64BIT COFF では、変わってるかもしれない。確か、PREFERED_BASE
などという名前も記憶にある。

ImageBase Preferred address of first byte of image when loaded into memory;
must be a multiple of 64K. The default for DLLs is 0x10000000.
The default for Windows CE EXEs is 0x00010000.
The default for Windows NT, Windows 95, and Windows 98 is 0x00400000.

**デフォルトの名無しさん** · 2018/08/22(水) 20:11:19.88

>>128
自分の勘だと、そのアドレスは、WinMain よりも、DLL の DllMain が置かれるような
値になってるね。

不思議だ。WinMain をそんな大きなアドレスに置く必要性は余り無いハズなので。
初期化データが 2GB 未満に置かれていても、malloc() や、new で確保されるデータは、
64BIT アドレスにできるはずだし。なお、

1_3f29_1770

↑は、32BIT を超えて、33BIT の値だな・・・。なんちゅう大きな値だろう。

**デフォルトの名無しさん** · 2018/08/22(水) 20:46:10.32

64bitもアドレス空間があるんだから
多少大きくても何の問題も無いだろ

**デフォルトの名無しさん** · 2018/08/22(水) 21:22:24.95

>>134
32bitのフラットメモリモデルだと、静的変数はイメージにはオフセットを入れといて、
実行時にローダで書き換えてたんだと思うんだけど、64bitでは絶対アドレスは制約が大きくなるから変だと思ったんだ。

絶対アドレスはコンパイラでも使えなくはないけど、デバイスドライバでメモリマップトI/O操作するような時しか使わないと思う。
64bitでイメージベースが大きくなったのは、セキュリティ関係でランダマイズしたりとか、
mov　　　al,my_mojiretu[rbx]
みたいなコードが例外吐いて特定困難なバグが発生するのを防止してるのでは？

**デフォルトの名無しさん** · 2018/08/22(水) 21:24:18.64

例外吐くことで

**デフォルトの名無しさん** · 2018/08/23(木) 05:44:12.90

>>135
コマンドライン用の簡単なC言語の64bitのプログラムで試したが
main関数のアドレス＝0x000000013f7f1000
data sectionで定義した変数data01のアドレス＝0x000000013f7fc087
だったぞ
完全に32bit絶対アドレスの範囲を超えてる

**デフォルトの名無しさん** · 2018/08/23(木) 07:08:50.83

64bitのWindowsアプリを作って.data sectionの変数のアドレスも表示してみた
WinMain address = 0x000000013fd419a0

data sectionの変数のアドレス
data01 address = 0x000000013fd4d000

/largeaddressaware:noを付けた場合
WinMain address = 0x00000000013619a0

data sectionの変数のアドレス
data01 address = 0x000000000136d000

**デフォルトの名無しさん** · 2018/08/23(木) 07:09:02.23

>>139
>64bitでイメージベースが大きくなったのは、セキュリティ関係でランダマイズしたりとか、
>mov　　　al,my_mojiretu[rbx]
>みたいなコードが例外吐いて特定困難なバグが発生するのを防止してるのでは？

意味不明だ。別に、
mov　　　al,my_mojiretu[rbx]
というコードが悪いわけではない。

むしろ、最適化のためには使った方が効率が良くなる。

**デフォルトの名無しさん** · 2018/08/23(木) 07:22:22.74

>>141-142
もしそうだとすると、VC++ の吐くコードがx64の命令を上手く使いきれてないという事になる。
本来であれば、アドレスの配置を上手く行うだけで、64BIT モードでも特に問題なく
mov　　　al,my_mojiretu[rbx]
という命令は使えて、かつ、64BIT アドレスの制限を受けるわけでもないのだから。

ちなみに、アプリの EXE は、リンク後は固定アドレスで、ローダーがアドレスを再配置
する事はない。だから、ImageBase を小さい値になるようにリンクしさえすれば、
問題が生じない。

**デフォルトの名無しさん** · 2018/08/23(木) 07:27:31.64

>>139
>64bitでイメージベースが大きくなったのは、セキュリティ関係でランダマイズしたりとか、

通常、コンピュータソフト、特にOSのセキュリティーというのは、そういう人間的なもの
ではなくて、もっと厳密な物だ。

ランダマイズして撹乱して相手の目をくらます、などという方法は通常取られない。

実際、EXE ファイルを解析した経験からしても、ランダマイズなどは全く行われていない。
何回リンクしても、同じアセンブリソースや、同じC++ソースなら、全く同じアドレスになる。
異なるソースであっても、ベースアドレスなどは、ほとんどの場合、固定値。

**デフォルトの名無しさん** · 2018/08/23(木) 07:58:52.05

>>138
実際には問題がある。なぜなら、そんなにアドレスが大きいと、さっきから話題の
mov　　　al, my_mojiretu[rbx]
という命令が使えなくなるからだ。

これは、グローバルな配列変数を、添え字でアクセスするような場合に良いコードに
なる事がある。僅かではあるが。もし、この命令が使えないとなると、

mov　　　rdx,offset my_mojiretu
mov　　　al,[rdx + rbx]

のように、2つの命令を使わなくてはならなくなり、最適化上、不利になる。

**デフォルトの名無しさん** · 2018/08/23(木) 08:10:29.27

そんな事言い出したら
4GBや64KBに限定した方が小さいコードになるから
compactモデルにしよう
とかいう話にもなる

昔に戻りたい？
何のための64bit？

**デフォルトの名無しさん** · 2018/08/23(木) 08:22:23.99

>>147
だから、そういうことじゃなく、EXEファイルの中に、2GBを越える初期化データを
誰が入れたいかって話なんだ。

別に、ImageBase を小さい値にしていても、malloc() や、new するデータは、
6GBでも理論上は確保できるわけで、制限されるのは、EXEファイルの中の
初期化データのサイズが2GBまで、ってだけなんだ。

それで、使えるマシン語の間接オペランドの種類が1つ増やせる。
mov 命令だけでなく、add, sub, mul, div, idiv, lea, addps, addss などにも
全て影響する貴重な間接オペランド。

**デフォルトの名無しさん** · 2018/08/23(木) 08:46:40.08

>>147
8086時代の 64KB では制限が大きすぎて、ほとんどのプログラムで、制限が足かせ
になっていたので、32BIT になって、アドレスが 4GB に拡張されて非常に便利になった。

ところが、64BIT 時代になっても、そのときのようなメリットが無いと思うんだ。
AMD vs Intel の競争の結果出てきた産物かも知れない。そういうの、時々ある。

**デフォルトの名無しさん** · 2018/08/23(木) 08:56:25.66

>>145
WindowsではASLRでランダム化普通にやってるらしいですよ

http://07c00.hatenablog.com/entry/2013/08/07/033443
OSがプロセスをロードするときに、ランダムな場所にモジュールを配置するセキュリティ機能です。
実際はモジュールだけじゃなく、スタックやヒープなどもランダマイズされたりします。

**デフォルトの名無しさん** · 2018/08/23(木) 09:03:22.89

>>150
少なくとも、EXE の .text, .data セクションは再配置される事は無いはず。
なぜなら、.reloc section が存在せず、再配置する事が原理的に出来なくなっているから。

DLL は、.reloc section が残されているので再配置できる。ただし、再配置しなくても、
全てのシステムのDLLは、最初からアドレスが重ならないような ImageBase になっている
ので、再配置されずにそのままおかれるのが、昔は基本であった。

**デフォルトの名無しさん** · 2018/08/23(木) 10:25:25.69

>>148
64bitコードで絶対番地に依存したコードとか
考え方が古いねえ

ていうか、
イヤなら2GB限定のコードにすればいい
コードもデータも2GBの範囲に割り当てられるから

**デフォルトの名無しさん** · 2018/08/23(木) 11:01:43.32

>>152
じゃあなんで、MS純正VSは、いまだに 32BIT コードで動いてるのさ。

x64 は、レジスタが増えた事と、memmove() などが多分、倍の速度で動く事が
最大のメリットじゃないの？

アドレス幅が64BITになって現実的なメリットはどこにあるのかな？

**デフォルトの名無しさん** · 2018/08/23(木) 11:36:32.13

なにが「じゃあ」だか

メリットが無いと思うなら2GB限定のアプリにすれば良い
って書いたのが見えなかった？

**デフォルトの名無しさん** · 2018/08/23(木) 12:51:14.26

>>154
だから、メリットはあるよ。
レジスタが増えること、AVX, AVX2, AVX512 で、YMM, ZMM レジスタでベクトル
の次元が大きくなったSIMD 命令が使えること、3オペランドの以上のSIMD命令が使える
事、メモリ転送の速度が倍近くになること。malloc(), new が、2GB を超えて行える事。

初期化サイズが2GBを越えるメリットは余り無いと思ってるけど。

◆QZaw55cn4c · 2018/08/23(木) 17:09:15.42

>>149
アドレス空間は広いほうがいいに決まっている
ユーザーアドレス空間の断片化は基本防止できない、だったら入れものが広いほういい

◆QZaw55cn4c · 2018/08/23(木) 17:09:45.22

>>153
>>156

**デフォルトの名無しさん** · 2018/08/23(木) 18:36:50.55

>>155
2G限定と関係ないじゃん

**デフォルトの名無しさん** · 2018/08/23(木) 19:03:15.16

>>148
結局、
mov　　　al,my_mojiretu[rbx]
こんなコードを書くと64bitではLINKする時にエラーが出る
/largeaddressaware:noを指定するとLINKでエラーは出なくなるが、
/largeaddressaware:noを指定すると動的メモリも含め2GB以下のメモリしか扱えなくなる

**デフォルトの名無しさん** · 2018/08/23(木) 19:09:33.40

なんかしらあるんじゃね

**デフォルトの名無しさん** · 2018/08/23(木) 19:30:53.52

>>159
それでいいじゃん
何種類作るつもりだよ

**デフォルトの名無しさん** · 2018/08/23(木) 19:47:44.13

32bit Windowsは切り捨てに入ってきてるからね
ゲームでも64bit版のみのも出てきてる

NVIDIA、GPUドライバーの32bit版OSサポートを終了へ～次期版からは64bit版だけに
https://forest.watch.impress.co.jp/docs/news/1098673.html

**デフォルトの名無しさん** · 2018/08/23(木) 19:52:19.27

バーチャルYoutuberなんかでも使われるソフト(エロゲ)だが
64bit Windowsのみ対応
動画配信などで結構使われてる

CUSTOM ORDER MAID 3D2
http://com3d2.jp/main.html
OS Windows® 7／8.1／10 全て64bitのみ対応 ※6
※6:32bitOSには対応しておりません。

**デフォルトの名無しさん** · 2018/08/23(木) 20:04:05.41

>>162
いや、
32bit/64bitアプリの話じゃなくて
64bitの2GB制限/制限なしアプリの話

**デフォルトの名無しさん** · 2018/08/23(木) 20:05:15.44

>>153
10年位前に出来たオンラインゲームでも、今はもう2GBのメモリだともう足りなくて
32bitのゲームでも/LARGEADDRESSAWAREのフラグ立てて延命してるのもあるよ
64bit WindowsならLAAフラグを立てると32bitアプリでも4GBまで使えるようになる
LAAで延命してるゲームで32bit Windowsで遊ぶとメモリ不足で高確率で落ちるゲームとか既にある

**デフォルトの名無しさん** · 2018/08/23(木) 20:12:15.30

こんな記事が出るくらい、2GBではメモリが足りなくなってるアプリがたくさんあるぞ

64bit Windowsを前提とした32bitアプリケーション延命法
～ LAAオプションで32bitアプリケーションのメモリ不足問題を解消
https://www.webtech.co.jp/blog/optpix_labs/programing/6387/

**デフォルトの名無しさん** · 2018/08/23(木) 20:12:19.28

なぜ確率の問題？

**デフォルトの名無しさん** · 2018/08/23(木) 20:16:43.95

ちなみにこのブログ書いてるところはWindows用ソフトもいくつか出してるところだよ

**デフォルトの名無しさん** · 2018/08/23(木) 20:18:49.99

>>167

>>165のこと？

一応、32bitWindowsもサポートしてるがメモリが足りなくなってよく落ちるので
実際は64bit Windowsでしかまともに遊べないってこと
そういうゲームが既にある

**デフォルトの名無しさん** · 2018/08/23(木) 20:23:47.22

質問に全く答えてない件

**デフォルトの名無しさん** · 2018/08/23(木) 20:34:21.09

>>146
実際にどの程度、速度が変わるのか試してみて欲しいもんだな
ただの机上の空論じゃないのか？

大体、配列で何回もデータにアクセスするなら
32bitのDISPを毎回指定するオーバヘッドだってあるんだが

**デフォルトの名無しさん** · 2018/08/23(木) 21:08:22.26

32bitアプリも2G限定アプリも32bit OSも絶滅して良い
Windowsの話

**デフォルトの名無しさん** · 2018/08/23(木) 21:13:40.67

mov rcx, offset HOGEHOGE01
mov rax, qword ptr [rcx + rbx]
mov rax, qword ptr [rcx + rbx]
mov rax, qword ptr [rcx + rbx]
mov rax, qword ptr [rcx + rbx]
これと
mov rax, HOGEHOGE01[rbx]
mov rax, HOGEHOGE01[rbx]
mov rax, HOGEHOGE01[rbx]
mov rax, HOGEHOGE01[rbx]
これを250個並べて1000万回ループさせてみたが、1%くらいしか差はないよ

**デフォルトの名無しさん** · 2018/08/23(木) 21:28:42.56

250個並べてキャッシュに収まる？

**デフォルトの名無しさん** · 2018/08/24(金) 00:12:57.34

なんで訳分からなくなりそうになったのか理解できたｗ
4LRopBJnが変なんだな。

Microsoftが64bitでは絶対アドレスのインデックスは使わないって決めたんだから、その流儀に従うのが高級言語とリンクだよ。

**デフォルトの名無しさん** · 2018/08/24(金) 00:23:58.73

>>167
メモリが厳しいなら、ヒープが断片化すればメモリ確保できなくなっても不思議じゃないよ。
それなら確率的に落ちると思う。

**デフォルトの名無しさん** · 2018/08/24(金) 01:48:40.54

>>158
意味不明。

何の事言ってるの？

**デフォルトの名無しさん** · 2018/08/24(金) 01:50:43.81

>>159
いや、それはあなたの勘違い。

そのオプションを指定しても、EXEの中に入っている「初期化データ」のアドレス
が2GB以下に限定されるだけで、動的メモリは、理論上は、100GB でも一気に
確保できる。それは、再三言ってる。あなたは理解出来てないと思う。

**デフォルトの名無しさん** · 2018/08/24(金) 01:54:49.18

>>164
再三言ってるけど、あの/LARGEADDRESSAWARE:NO オプションを
付けても、「初期化データ」のアドレスが2GBに制限されるだけで、
new や malloc() などの、ヒープから確保される動的メモリは、64GBの
アドレス空間どこにあっても問題ないんだよ。

**デフォルトの名無しさん** · 2018/08/24(金) 02:00:34.30

>>173
そりゃ分かってるよ。

でも逆に、EXEファイルの中に最初から入っている「初期化データ」
の2GB制限とどっちが良いかの話になるんだよ。もちろん、動的メモリ
は何の制限も受けず、64GBアドレスが好きなように使える。

初期化データというのは、何かの埋め込みテーブルのための配列
だとか、文字列データとか、そういうものだよ。

巨大な3Dモデルデータ、テクスチャ、マップデータなどは、外部ファイル
にでも置いておけば、2GBの制限は受けず、仮想アドレスとしては
64BITまるまる使えるから。

実際、EXEの中にある初期化データが2GBを越えるという事は、
EXEファイルが2GBを越えるという事だから、そのアプリの起動
時には、有無を言わさず HDDなどから、2GBの読み込みが
始まってしまうことになる。

**デフォルトの名無しさん** · 2018/08/24(金) 02:02:34.25

>>179 >>180
【誤字訂正】
誤：64GBアドレス
正：64BITアドレス

言葉は間違っているが、中身は間違ってない。数学は100点、国語は赤点
の学生時代だったし。

**デフォルトの名無しさん** · 2018/08/24(金) 02:18:09.88

>>173
それでもやはり、1%の速度低下にはなったんだよね。

「初期化データの2GB制限」は、現実的には何の制限にもなってない
事は理解出来てる？？？？動的メモリは、64BIT 自由に使える
んだよ。

**デフォルトの名無しさん** · 2018/08/24(金) 04:19:33.40

>>178、179
実際にやってみれば？
C言語でmallocでもvirtualallocでも
/largeaddressaware:noを付けると動的メモリも2GB以下しか確保できなくなるから

**デフォルトの名無しさん** · 2018/08/24(金) 04:38:15.52

>>182
実際に試したことないのが丸わかり
/largeaddressaware:noをつけると本当に試してみるといいよ、
動的メモリも2GB以下しか確保できなくなるから

このページの
https://www.webtech.co.jp/blog/optpix_labs/programing/6387/
この図に載ってるプログラムでも試せるよ
https://www.webtech.co.jp/blog/wp-content/uploads/2013/11/laa_test_prg_thumb.png

**デフォルトの名無しさん** · 2018/08/24(金) 04:39:04.29

上のプログラムだと/largeaddressaware:noを付けない時に
無限に確保するので4500MBで終わるように少し改変してみた
これで試してみな

#include <windows.h>
int PASCAL WinMain(HINSTANCE hinst, HINSTANCE hprev, LPSTR cmd, int n)
{
int step = 10; //10MB
int count = 0;
char temp[20];
for (;;)
{
void *p = GlobalAlloc(GPTR, step * 1024 * 1024);
if (p == NULL)
{
break;
}
count++;
if(count > 400 + 50) {
break;
}
}
wsprintf(temp, "Total %d MB\n", count * step);
MessageBox(NULL, temp, "alloc test", MB_OK);
}

**デフォルトの名無しさん** · 2018/08/24(金) 04:45:01.40

上のプログラムは64bitでも、32bitでもコンパイルは通るよ

**デフォルトの名無しさん** · 2018/08/24(金) 05:30:48.46

そもそもWindowsは/largeaddressaware:noを付けなくても静的データは2GBまでしか使えない
動的データだけがOSが対応してるメモリ分だけ制限なく使える
WindowsにはLinuxのgccのような-mcmodel=largeや-mcmodel=mediumのようなオプションは存在しない

/largeaddressaware:noを付けると64bitアプリでも動的メモリも含めてすべてのメモリで2GB以下までしか使えなくなる

PGIのコンパイラのページでわかりやすく解説してあるよ
https://www.softek.co.jp/SPG/Pgi/TIPS/opt_64.html

**デフォルトの名無しさん** · 2018/08/24(金) 07:19:19.64

>>173
これは最適化を知らないコード
250個並べちゃいけない

**デフォルトの名無しさん** · 2018/08/24(金) 07:30:57.16

>>182
そこだけ抜き出して、
しかも最適化してないコードで1%
こんなコードは全体の中では非常にわずかだろうし
タイムクリティカル部分であれば最適化される

実質差が無いメリットの為に絶対アドレスに依存したコードにする
時代に逆行だ

それでも逆行したければ
0～2Gのアドレスしか割り当てられない2G限定アプリにしろ

**デフォルトの名無しさん** · 2018/08/24(金) 07:35:38.16

>>188
250個並べても7KBくらい
1次命令キャッシュに丸ごと収まるぞ

**デフォルトの名無しさん** · 2018/08/24(金) 07:38:24.94

uOPキャッシュ

**デフォルトの名無しさん** · 2018/08/24(金) 07:53:32.13

>>191
25個並べることにしてループ回数を一桁増やしたが早くならないぞ
そういうのを机上の空論というんだ

**デフォルトの名無しさん** · 2018/08/24(金) 07:59:52.52

なんか初心者スレの趣旨とずれまくりなんだけど。
コンパイラのABIが「変わった」のなら、それに合わせたのを紹介しないと。

Visual Cは64bitではインラインアセンブラも使えなくなったし、AVXやSSEは組み込み関数で大概は満足できるはずって判断されたのだろう。
今のご時世わざわざアセンブリ言語でプログラミングしたいって用途は動画のコーデックやフィルタプラグインDLL、将棋とかの思考ルーチンとかでしょ。
こういうのは2GB制限下でしか使えないコードでは困るはず。

**デフォルトの名無しさん** · 2018/08/24(金) 08:09:12.98

>>189
静的配列だとサイズが決まってるから、恐らく最適化されてポインタとオフセット（ディスプレースメント）に変換されるよね。
＞実質差が無いメリットの為に絶対アドレスに依存したコードにする
＞時代に逆行だ
これに同意。

**デフォルトの名無しさん** · 2018/08/24(金) 12:53:22.92

>>192
ヒント HTT

**デフォルトの名無しさん** · 2018/08/24(金) 14:52:13.41

>>185
自分は 64BIT 用C/C++コンパイラをインストールして無いので、試せません。

link.exe に、 /largeaddressaware:no を渡した場合にのみ、
GlobalAlloc() が失敗する理由は何ですか？

ポインタが32BITになる？　それとも、GlobalAlloc の関数が別のものに
入れ替わってしまう？

そのどちらでもないとしたら何が原因ですか？

**デフォルトの名無しさん** · 2018/08/24(金) 14:54:32.88

>>187
>/largeaddressaware:noを付けると64bitアプリでも動的メモリも含めてすべてのメモリで2GB以下までしか使えなくなる
>PGIのコンパイラのページでわかりやすく解説してあるよ
>https://www.softek.co.jp/SPG/Pgi/TIPS/opt_64.html

リンク先のページを見たのですが、自分には、
　「動的メモリの場合にも2GB以下しか使えなくなる」
という文書が見つかりませんでした。

どこに書かれているか、ご指摘いただければ幸いです。

**デフォルトの名無しさん** · 2018/08/24(金) 16:51:48.72

実験したけど2GBまでだったよ
malloc

アドレスは32bitで保持出来る
32bitアプリからの移植用だろうね

**デフォルトの名無しさん** · 2018/08/24(金) 16:55:58.09

>>196
メモリはOS側の管理でしょ？
OSがアプリ種別を判別してアドレスを割り当てる

31bit
32bit
64bit

の3種類かな？

**デフォルトの名無しさん** · 2018/08/24(金) 17:07:40.76

>>199
リンカオプションによって、API の挙動まで変わってしまうんでしょうか。

そして、Win64 API の GlobalAlloc() などが返す値が 31 BIT までに
なるので、malloc() もそれにつられて、勝手に 31BIT までになると？

64BIT COFF だと、COFF Image に、/largeaddressaware:no かどうか
を示す BIT か何かが追加された???