アカウント名:
パスワード:
とにかく、トランスメタには「CMSを“開放”して欲しい」と思うのは私だけ? (↑ムリを承知で言ってます…)
命令の互換性の問題は、初期のRISCにもありましたね。高速化のためにハードウェアを変更しても、コンパイラがそれを吸収してソフトを動かす…つまり、 ・RISCの場合は極端な話、Cコンパイラで互換性を確保してCのソースコードを動かす… ・トランスメタの場合は、CMSで互換性を確保してx86のコードを動かす…
しかし現状のRISCは結局、時間の経過とともにソフトウェア資産を捨てられなくなり、例えばパイプラインの構成が変更になっても互換性を確保するような回路を実装したりなど、本来のRISCの精神とは反するように肥大化してきているわけですが…
なので、CMSの公開がトランスメタとしてはもちろん、ユーザーにとってもある意味、危険なことであるのはわかってはいるのですが、それでも私は、トランスメタのCPUを、ネイティブに操ってみたいと思うわけですよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
CMSのユーザサポート (スコア:2, 参考になる)
PCハードベンダーがCMSをファーム書き換えなどでのサポートを
してないように思うのですが、これは...
技術的にできない
ライセンス的に無理
販促的にやらない
CMS書き換えは費用対効果が薄い
どうなんでしょうか?
TM8000
Just a whisper. I hear it in my ghost.
Re:CMSのユーザサポート (スコア:1)
もちろん会社規模がそれほど大きくないときに、他アーキテクチャなんかやってられない…ってのもあるかもしれませんが…
どっか「うちにやらせてくれ!」ってところは無いのかな…
またはCPUエミュレーションじゃなく、CMSをダイレクトに使うOSやらアプリやら…
とにかく、トランスメタには「CMSを“開放”して欲しい」と思うのは私だけ?
(↑ムリを承知で言ってます…)
エミュレーションじゃなく、CMSをダイレクトに使う (スコア:1)
Re:エミュレーションじゃなく、CMSをダイレクトに使う (スコア:1)
>どういうことよ、それ。
すいません。つまり「トランスメタのCPUのネイティブのコードでソフトを書きたい」という意味です。
Re:エミュレーションじゃなく、CMSをダイレクトに使う (スコア:0)
Re:エミュレーションじゃなく、CMSをダイレクトに使う (スコア:0)
Re:CMSのユーザサポート (スコア:1)
…なんで出さないんだろ
JavaVMのCMS (スコア:0)
実のところJavaVMのバイトコード・インタプリタを作ってもそれだけではJavaの実行はできないわけで、最低でも標準ライブラリを実装できないと使い物になりません。
さらにバイトコード+標準ライブラリだけではできないこともあって、それは通常ならJNIで逃げるわ
CMSをダイレクトに使う? (スコア:0)
ここでいうCMSってのはTM5800やらTM8000のオリジナル命令セットの積りですよね。
CMSアーキテクチャはx86をエミュレーションしているから良いのであって、オリジナル命令セットを直に使うと命令セットの互換性がないから大変ですよ。
# 実際TM5800とTM8000では全く別
Re:CMSをダイレクトに使う? (スコア:1)
VLIWの語長が倍になりましたからね。実際のネイティブなコードはまったく別ものでしょう。
命令の互換性の問題は、初期のRISCにもありましたね。高速化のためにハードウェアを変更しても、コンパイラがそれを吸収してソフトを動かす…つまり、
・RISCの場合は極端な話、Cコンパイラで互換性を確保してCのソースコードを動かす…
・トランスメタの場合は、CMSで互換性を確保してx86のコードを動かす…
しかし現状のRISCは結局、時間の経過とともにソフトウェア資産を捨てられなくなり、例えばパイプラインの構成が変更になっても互換性を確保するような回路を実装したりなど、本来のRISCの精神とは反するように肥大化してきているわけですが…
なので、CMSの公開がトランスメタとしてはもちろん、ユーザーにとってもある意味、危険なことであるのはわかってはいるのですが、それでも私は、トランスメタのCPUを、ネイティブに操ってみたいと思うわけですよ。