[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[pbsd-mg2] change MACHINE_ARCH or not

MACHINE_ARCHの件です。

この手の話題は過去何度も繰り返されているようで、たとえば、tech-toolchain
の以下のmailに始まる議論などもあります。

To: tech-toolchain@NetBSD.ORG
Subject: IMPORTANT: MACHINE_ARCH WRONG ON MIPS PLATFORMS
Message-ID: <Pine.NEB.4.02.9807231234270.20864-100000@duhnet.net>

興味のある方はarchiveを探してみてください。98年の7月23日から始まっていま
す。

結局、この時は、endianでMACHINE_ARCH=mipsを分離して、

MACHINE		MACHINE_ARCH
============================
pmax		mipsel
newsmips	mipseb

とすることになったのだと理解しています。異論を唱える人は結構いたようです
が、少なくとも1.4がリリースされる時点まではこうなっています。

soft-float(SF), hard-float(HF)の問題も、ソース互換の程度の差こそあります
が、バイナリ互換でないという点ではbig-endian(BE)/little-endian(LE)の区別
と変わりはありません。SFとHFはABIが異なるため、SFでコンパイルされたもの
とHFでコンパイルされたものはバイナリ互換にならないからです。

したがって、

    BEとLEはバイナリ互換でないのでmipsel/mipsebに分離された
    BE/LEと同様にSFとHFもバイナリ互換でないので分離すべき

だと考えています。

SF/HFだけ特別扱いするのは間違いで、SF/HFを分離しないのであれば、BE/LEも
分離すべきではありません。

* * * * *

soft-floatを続けるべきか否かという点については以下のように考えています。

そもそも、NetBSD/hpcmipsがターゲットとしているマシンにはFPAがないCPUしか
ありません。しかも、FPAを追加したり、FPAを内蔵したCPUに交換することもで
きません。

つまり、hpcmips的にはSFが当たり前であって、それが一番効率良く実行できる
バイナリです。

従来のMIPS CPUを使ったワークステーションではFPAがあるのが当然で、System
V ABIなどでもFPAはCPUアーキテクチャの一部であると見なされていました。つ
まり、従来のMIPSマシンではHFが当たり前であったわけです。

hpcmipsはその点で従来のMIPSマシンから見ると仲間外れな訳ですが、そういう
作りになっている以上、VR41xxやTX39xxはMIPSの亜種として独立した物と考えた
ほうがいいと思います。

HFのバイナリをemulationによって実行するのは不可能ではありませんが、その
ために必要な労力(c1命令に限らず、ほとんどすべての命令をemulation
するコードを開発する)とそれによるメリット(mipselとバイナリを共有できる)
とを秤にかけると、やる価値のあることだとは私には思えません。

それよりは、すっぱりとバイナリ互換をあきらめれば、(CPUを選びますが)
mips16命令をサポートしてバイナリを小さくするとか、mips2を使ってバイナリ
サイズを小さくするとか、いろいろとhpcmips的に嬉しいことができるので、そ
ちらの方に開発パワーを回したほうがいいと思います。

ということで、私の意見は、

    hpcmipsではSFが基本
    HFのemulationを無理にやるメリットはない

です。つまり、将来に渡って、hpcmipsはSFであると考えます。

* * * * *

BE/LE, SF/HFでソースを共有する方法についての技術的な話ですが、どちらも大
差ないと思います。

BE/LEの場合は、gcc/binutilsのバイナリフォーマットの切り替えでほとんど用
が足りますが、bit-fieldやhtonl()などでは#ifdef等によるソースレベルの切り
替えが必要です。

SF/HFの場合は、コンパイル時の-msoft-float/-mhard-floatの指定でほとんどで
きますが、アセンブラレベルでFPAのコンテキストを参照するものについてはソー
スレベルの切り替えが必要です。

いずれもオプション＋ソースの切り替えですので、本質的な差はないと思います。
量的な違いはあると思いますが。

したがって、技術的な点においても、BE/LEとSF/HFを区別して考える必然性はな
いと思います。

* * * * *

MACHINE_ARCHをmipsel/mipsebのように分けるやり方については、私もこれが絶
対に正しいと思っているわけではありません。ただし、MACHINE_ARCHについては、
pkgsrc的な問題や、GNU的な問題等が複雑に絡み合っているようなので、これら
の問題を深く追及するのは気が進まないというのが正直なところです。

過去の議論を蒸し返すよりは、決着がついたものと考えて、従来の枠組みにならっ
てSF/HFもMACHINE_ARCHで分けるというやり方を取ったほうが面倒がないのでは
ないかと思っているだけです。

篠原