アカウント名:
パスワード:
とにかく、トランスメタには「CMSを“開放”して欲しい」と思うのは私だけ? (↑ムリを承知で言ってます…)
命令の互換性の問題は、初期のRISCにもありましたね。高速化のためにハードウェアを変更しても、コンパイラがそれを吸収してソフトを動かす…つまり、 ・RISCの場合は極端な話、Cコンパイラで互換性を確保してCのソースコードを動かす… ・トランスメタの場合は、CMSで互換性を確保してx86のコードを動かす…
しかし現状のRISCは結局、時間の経過とともにソフトウェア資産を捨てられなくなり、例えばパイプラインの構成が変更になっても互換性を確保するような回路を実装したりなど、本来のRISCの精神とは反するように肥大化してきているわけですが…
なので、CMSの公開がトランスメタとしてはもちろん、ユーザーにとってもある意味、危険なことであるのはわかってはいるのですが、それでも私は、トランスメタのCPUを、ネイティブに操ってみたいと思うわけですよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
CMSのユーザサポート (スコア:2, 参考になる)
PCハードベンダーがCMSをファーム書き換えなどでのサポートを
してないように思うのですが、これは...
技術的にできない
ライセンス的に無理
販促的にやらない
CMS書き換えは費用対効果が薄い
どうなんでしょうか?
TM8000系CMSはどうでしょうね。
「CMSを改良していく」と言われても、既存資産に影響しないのでは
消費者レベルではあまりありがたみがないというか。
もちろん、CPUベンダーからみると、費用効果はあるのでしょうけど。
Just a whisper. I hear it in my ghost.
Re:CMSのユーザサポート (スコア:2, 参考になる)
初代LOOX T5/53W使ってますが、BIOS書き換えでCMSがアップデートされたようです。
手元に本体がないので確認できませんが、1.1 -> 1.2だったと思います。
Re:CMSのユーザサポート (スコア:0)
BIOSアップデートとは別ですけど。
Re:CMSのユーザサポート (スコア:1)
>CMSのアップグレードとしてダウンロードできる。
>以前あなたに話した、CMSのアップグレードをダウンロードすることで、
>PCを買った後も性能を上げるというフィーチャが、今提供され始めたわけだ。
って書いてありましたね。
寡聞にして今まで、こういったことを知らなかったのですが
HP以外もやってくれますかね。
Just a whisper. I hear it in my ghost.
Re:CMSのユーザサポート (スコア:1)
CMSアップデートでパフォーマンスアップ、というのはユーザから
してみると素晴らしいことなのですが、PCメーカとしてはどうなん
でしょうね。
PCの世代交代のサイクルが長くなってしまうので、あまりうまみは
ないのかなぁ、とも思うのです。
Re:CMSのユーザサポート (スコア:1)
ただ、ベンダーがあまりやりたがらないのはCMS部分の書き込みに失敗した場合、x86CPUとしての機能そのものを失ってしまうからです。
Intel/AMD CPUの場合、ROM Chipが壊れてない限りはたいていのMBでリカバリする手順が用意できますが、CMS部分が壊れたらそうはいきません。
今時のMBに搭載されているようなDual BIOS構成か、二段式のCMSを搭載し、二段目が壊れたら一段目からBIOSリカバリだけでも行える構造にならない限り難しいと思います。
取り外してROMライタで書くって訳にもいかないですしね。
# rm -rf ./.
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を、ネイティブに操ってみたいと思うわけですよ。