"The QEMU virtual x86 CPU core library is released under the GNU Lesser General Public License."
とあるので、このライブラリを使って独自のエミュレータや86コードをそのまま載せた"移植アプリ"などを作る場合はソースを開示する必要はないのではないかと。
また、 "The Linux x86 QEMU emulator is released under the GNU General Public License."
とは書いてありますが、いくらエミュレータがGPLでもそこで動かすソフトまでGPLが必要ってことではありますまい。エミュレータを改編する場合はソースを開示する必要があるわけで。
…って、詳しくは分からないのでいまいち確証は持てませんが。
Binary Emulation (スコア:2, 参考になる)
FX!32というAlphaでx86のコードを動かすものの資料です。 [compaq.com]
Web上に資料が見当たらなかったのですが、（これのP.104参照 [ascii.co.jp]）
x86 DarwinでPPC Darwinのバイナリを動かそうという試みもありましたね。
Re:Binary Emulation (スコア:1)
驚異のバイナリエミュレータだったような。
あと、こうやってリアルタイムコード変換後のデータを、
HDDに書きこまずにメモリ上にキャッシュとしてのみ保持するのが
Transmetaのコードモーフィング技術ではなかったかな。
なんだかんだ言ってもx86のコード資産は膨大ですから、
その有効活用を図るソフトのメリットはかなり大きいですね。
エミュレータとしてはVMWAREが定番みたいですが、
フリーのbochs/plex86やosaskなんかにも期待しています。
Re:Binary Emulation (スコア:1)
あと、コードモーフィングはHDDに書き込まない技術じゃなくて現行のCMSが書き込まない実装だっただけです。
# rm -rf ./.
Re:Binary Emulation (スコア:0)
# ASTROの方が気になるけど・・・
Re:Binary Emulation (スコア:1)
| 驚異のバイナリエミュレータだったような。
すごいですよね。
個人的には、FPU の仕様の違いをどうカバーしてるのかが、ずっと気になってます。
こういった実行時 (on demand な) バイナリ変換は、ゲーム機のエミュレータもやってるようです。
MIPS (Playstation) -> x86 とか。
あと、Java の JITコンパイラもやってるわけです。
Java バイトコードはもともと変換を意識して設計してあるので、変換元としては x86 のコードよりはずいぶん易しいのですが。
IEEE CSの会誌 2000年 3月号に Binary Translation の特集があって、IBMワトソンの DAISY の記事に感銘を受けた覚えがあります。
2000年 3月号
http://www.computer.org/computer/co2000/r3toc.htm
DAISY
http://www.research.ibm.com/daisy/
PowerPC などからある種の VLIW プロセッサへの実行時変換器です。
Re:Binary Emulation (スコア:1, 参考になる)
実装だった筈です。＞FX!32
#297730 のリンク先のレポートには、
>Very few applications rely on the full precision
>provided by the x86 floating-point unit's (FPU's) 80-bit
>registers.
とか載ってて…それが問題になる場合は「本物」を使えという事
なんでしょうね。
Re:Binary Emulation (スコア:1, 参考になる)
ココ [asahi-net.or.jp]ですね。
逆に (スコア:2, すばらしい洞察)
PPCやs390アーキテクチャで動いてしまう訳ね。
ちと考え過ぎ？
PCにECC Registeredメモリの利用を推奨します。
Re:逆に (スコア:0)
ちょっと待て。 (スコア:1)
まさか、そんなことはないよなぁ。それでは使えないにも程がある。
# ジョークにマジレス
ライブラリはLGPLみたいですね (スコア:1)
"The QEMU virtual x86 CPU core library is released under the GNU Lesser General Public License."
とあるので、このライブラリを使って独自のエミュレータや86コードをそのまま載せた"移植アプリ"などを作る場合はソースを開示する必要はないのではないかと。
また、
"The Linux x86 QEMU emulator is released under the GNU General Public License."
とは書いてありますが、いくらエミュレータがGPLでもそこで動かすソフトまでGPLが必要ってことではありますまい。エミュレータを改編する場合はソースを開示する必要があるわけで。
…って、詳しくは分からないのでいまいち確証は持てませんが。
Re:逆に (スコア:0)
もしくは、サーバーを勝手に立ててソースを公開するワームとか。
Re:逆に (スコア:0)
Linux も GPL なソース付きワームだったりして。
身の回りでも知らない間に 21/23 番ポートが開いているマシンが増えているし。
x86 emulators (スコア:1)
クロスプラットフォームフェチ (スコア:1)
$ /usr/local/qemu-i386/bin/qemu-i386 -L / /usr/local/java/bin/java -jar /usr/local/java/demo/jfc/SwingSet2/SwingSet2.jar
qemu: Unsupported syscall: 191
qemu: Unsupported syscall: 149
Unsupported syscall: 191 と 149 (スコア:1)
(arch/i386/kernel/entry.S より)
すぐに追加実装できそう。
Linux / x86 エミュ for Linux / 他のプロセッサ ってことは、
x86 エミュレータ + システムコールの中継器
だけで済みそうだから、エミュレータとしてはかなり単純な部類かと。なるほど。
x86 プロセッサのエミュレータが主眼で、実証のために Linux のシステムコールをホストOSに中継する仕掛けを作った?
やはり、 (スコア:1)
(エンドユーザーにとって)x86の最大のコード資産を形成してるのはWindows上のソフトウェア群でしょうし、例えばMacOS XのようなほかのUNIXyなOSに移植されればもっと活用の幅が広がるでしょうな。
# またLZEXEの人か…
Wineがどれだけ動くか (スコア:1)
やっぱりWineが動いてくれると有りがたいでしょうね。
あとはコーデックとか。でもライセンス関係でやばかったりするのかもしれないですけど。
#試しもせずろくに調べもせずに書き散らして無責任の極みである、が。
gy0
ISA/PCIボードを非x86アーキテクチャで使う場合に (スコア:1)
いや、そのハードの全仕様を公開してもらえれば話は早いんですが、NDAだなんだといろいろあって結局仕様を入手できず、「もうこうなったらx86エミュレータを作って拡張BIOS実行するしか！」とか言って、ホントに作る寸前まで行ったことがあったっけな（汗）
ただ、PC/AT用の拡張ボードの場合は、それらの拡張BIOS内で、PC/ATのBIOSやらワークエリアやら、他のI/Oとかも少なからずアクセスするでしょうから、“x86エミュレータ”だけでは足りず、“PC/AT互換機エミュレータ”が必要になるでしょうが…
Re:ISA/PCIボードを非x86アーキテクチャで使う場合に (スコア:1)
"Alpha Linux x86 BIOS エミュレーション" あたりで google したら、何やら見つかりました。
Re:ISA/PCIボードを非x86アーキテクチャで使う場合に (スコア:1)
ビデオカードに載ってるx86コードな初期化処理を走らせたりするのが目的だったんじゃないかな。
# 拡張BIOSのコードってx86コードって呼んでいいのかな。
# 「x = 0」限定とかな気がするなぁ。
libqmeu (スコア:0)
なるほど、Big EndianとLittle Endianが混在している。
Re:libqmeu (スコア:1)
“libqemu”が正しいです。タイプミス＆チェック不充分でした。すみません。
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.