観察日記 2010-10-15 - なるせにっき

ちょっとタイミングを逃してしまいましたが。

MinGW64

http://suke.cocolog-nifty.com/blog/2010/09/soft-cygwin-m-2.html
{util_mput} [Soft] Cygwin に mingw64 の 32bit用コンパイラをインストールし.. http://tinyurl.com/2a76xuq
なにをつくっているのかよくわからない
なにをいってるのかよくわからない...
ああ、わかった。
mingw-w64プロジェクトが作った32bit版がi686-w64-mingw32-gcc
つまり、いわゆるmingwと別物なのだな
なんてこった。
cygwinではmingw64パッケージと呼んでるが実際のコマンド名にはmingw64は出てこない
現状はオフィシャルな確認とか一切無しでなし崩し的にコードが入れられてると理解している。
最初に入れたの誰だ。
{unak} Thu Sep 23 18:54:39 2010 wanabe
{unak} * tool/config.sub: add mingw64.
これ?
今回の流れはそれじゃないかな
で、mingw版メンテナのなかださんがいろいろ(俺の不平不満を聞きつつ)軌道修正して、
そんで昨日だか一昨日だかに一気に全部巻戻されたという理解。

64bit Windows を判定するには

r28476
{util_mput} [ruby] Revision 28476 http://tinyurl.com/2dg6anb
しかしこれで64と判断できないなんて、なんてばか？
それは俺が「将来mingwの64bit portが入ったらmingw64とかいう名前になる気がするから /mswin64|mingw64/にしとけばいいんじゃない?」と言ったような気がする。
現状ではほにゃらら64で判定することは拒否されてしまってる状況なんだよな。
ということは /\Ax(?:86_)?64-/ となるのか?
(Windows版であることは前提として)
いやまあ、理には適っているか。

RUBY_PLATFORM の構造

まあ、mingwという名前をRUBY_PLATFORMに使ったのが今となっては誤りなんかね。
RUBY_PLATFORMはCPU-OSだったので
まあ、OSはランタイム環境と考えるべきなんだろうけど。
だからmswin32は正しいがmingw32はあんまり正しくない、と。
mingw32はgccに倣ってたので、今回もgcc本家と揃えるべき？
では本家に尋ねてみよう
いちおう俺の見解を述べると、他プロジェクトの情報はあくまで参考で、rubyにとって都合のよいものに決めればよい、なのだが
もちろんその「参考」の度合いは「あっそ」から「strongly recommended」までいろいろ幅はあるけど...
http://gcc.gnu.org/install/specific.html#windows
{util_mput} Host/Target specific installation notes for GCC - GNU Project - Free Software ... http://tinyurl.com/67edkj
{unak} GCC contains support for x86-64 using the mingw-w64 runtime library, available from http://mingw-w64.sourceforge.net/. This library should be used with the target triple x86_64-pc-mingw32.
嫌なものを見た
とりあえず準オフィシャルなんだなmingw-w64
x86_64-pc-mingw32
pcはあってもなくてもいいような存在
rubyだとpcは省くので、x86_64-mingw32がgccから導かれる結論となる。
とりあえず「あっそ」と言っておこう。
いやgccの要請は割と強めなんだけど。
なんでこいつら末尾に32残したんだろ。
/mingw32/にマッチするように?
逆に迷惑だろ
マッチしちゃっていいのか非常に疑問なんだが
間違えて一致しちゃうのを啓蒙してまわるのと、一致すべきなのを啓蒙してまわるのと、どっちがよいか。
感性の問題になっちゃうかなあ。
どっちも動かない気がするからなぁ
でも、こっちにはWin64環境なので32という数字が現れるのはおかしい、という論理的に否定の仕様がない論拠があるしな。
これってMSVCRT DLL的には何が対象になるのかな？
msvcrt.dll
変わんないのか
そこに数字がなくて幸い
(mswin64だとサポートしてるのはmsvcr(8|9|10)0.dllだけど、まあ意味は同じ)
mswinはx64-mswin64になるんだっけ？
俺の独善的判断でそうなった。
じゃあ、x64-mingw64でいいよ
configure時はgccのも受け付けて、RUBY_PLATFORM的にはシンプルでってのがいいような
configureは既知のは片っ端から受け付けるようにした上で。
で、まあ、x64-mingwになるようにしてたんですが
それがwanabeさんrevert前の状況。
そうするならmswinもx64-mswinにしないと
2.0になったらね。
(なかださんとは口頭でそういう話をした)

一方 Perl は

perlもともとわけわからんしなあ
perlの32bit版はMSWin32-x86で統一されてるようだ
64bit版はどうなるんだろうね
http://win32.perl.org/wiki/index.php?title=PPM_Repositories
{util_mput} PPM Repositories - Win32 Perl Wiki http://tinyurl.com/233sz2
MSWin32-x64
ううむ
俺もActivePerlの64bit版の$^OがMSWin32であるというのを見つけたところだった。
http://strawberryperl.com/ だれか試して
{util_mput} Strawberry Perl for Windows http://tinyurl.com/3237h9
{unak} MSWin32-x64-multi-thread
がフルネームでございました。
というわけでperl界ではMSWin32で確定してるようだな。

nobu 曰く

つか、現mingw版メンテナであるはずのなかださんは
何か言うことないのか。
x64-mswinに統一
config.subはautomakeの追従の手間があるので戻したほうがいいけど

usa による RUBY_PLATFORM 論

実はさっき考えてたんだけど
mswinはmswin64のままで行くべきだと思いなおしまして。
つまり
Win32 APIセットなOSではmswin32
Win64 APIセットなOSではmswin64
筋が通っている。
WinCE APIセットなOSではmswince
だし。
そのAPIセットってのがわからん
Microsoftが定義しているAPIの集合ですが
Win32とかWin64とかいうのは、ここでは何かの略語ではなくて
そのAPIの集合の公式な名前ですよ。
64bitでも32なん?
いやだから64bitなWindowsではWin64というAPIセットだと言ってるじゃないですか。
例えばWindows9xはWin32 APIセットしか搭載していないが
Windows NT4.0だとWin32 APIセットとOS/2 APIセットとposix APIセットを搭載している。
64bit版アプリが使うのは?
Win64 APIセット
へえ
64bit Windowsは、Win64 APIセットとWin32 APIセットの両方を搭載している。
あぁ、64を取っちゃいかんという話か
そう。
なお、NT系列のOSでは、それぞれのAPIセットの実装というか実行体としてSubsystemというものをOSに乗っけている。
それがWin32 Subsystemとかposix Subsytemとかいうやつ。
i386-mswin64とかあるの？
そうなりうるものはない。
32bit Windows上で動作するWin64 Subsystemが存在しないため。
逆は？
逆は標準搭載。
でないと32bitアプリを64bit Windows上で実行できない
で。
仮にそれをx64-mswin32と呼ぶとして、
i386-mswin32と一切違いがないのだから分ける意味はない。
まとめ
* mswin64という名称には筋の通った説明が付けられる
* i386-mswin64は現状ありえないし、あってもx64-mswin64と区別する意味がおそらくない
* x64-mswin32はi386-mswin32と区別する意味がない
以上。
x64-mswin32のx64だと64bitレジスタ使う?
LLP64なのかどうか
いいえ。
Windowsではユーザーランドバイナリ中に32bitコードと64bitコードを混在させることを認めていません。(動的リンクの場合も含む)
Win32を使う限りは必ずILP32?
ゆえに、Win32 APIセットを利用するバイナリは64bitコードを一切含むことができません。
というわけで、Win32 APIセットを使う限りは必ずILP32です。
i386-mswin32とx64-mswin64以外のものは意味を成さないので結果として一対一になりますよ、
ok
ISA-API の組という理解? mswinの所についてがmingwになったりするのは歴史的経緯か
i686-mswin32とかはあり得るとおもってるんだけど
省略したけどありえないこともないよ
ubuntuのは{i586,amd64}-mingw32msvcだったかな
ただ、rubyのWindowsポートにおいては、「i386」という言葉でその辺を全部包含しているつもり。
実際問題としてi386-mswin32は80386なCPU上では動作しない。
(断言したけどほんとかな。たぶん既にそう)
386用にコンパイルしても?
だって80386上で動作するWin32互換なOSは既に存在しないもの。
そっちかい
Win95でRuby多分動かないしなぁ
Win95は486SX以降
実行コードに486以降の命令が使われてるかチェックだ(しない
退役済みのフラグシップみたいなもんだな
VCのコンパイラがどこターゲットにしてるか
何も考えずにビルドすると
自分の環境に対応したものを作るようになってるよ。
現代人だとi686用になると思う
PROCESSOR_LEVEL=6だった /たしかに
amd64てついてたらx64?
はい。
その辺りだけ正規化しようか

x64 の歴史

amd64は開発時はx86_64という名前だった
で、製品化時にAMDが各種OS関係者にx86_64をamd64にリネームするよう要請して
BSD系がOKして、Linuxがはねたとか、そんなん
x64にリネームするような要請はないんだろうか
Microsoftがx64だと言ってるんだからx64でいいよ。
(Intel |AMD)64->x64でそ
RUBY_PLATFORMはi386-mswin32とx64-mswin64だけにしちゃうか
mingwはRUBY_DESCRIPTIONだけ
書いてないだけだろうけれどmsvcrt番号は必要