アカウント名:
パスワード:
使い方に対して強い執着があったので結局はやらんかったんだよなぁ。
牽引する強靭な開発体制がないのに、オープンソースでもないせいでコミュニティも脆弱、仕様ですら書籍や説明会とセットで普及に及び腰な印象すらある。税金を突っ込んだ割にはガラパゴス化を象徴するような徒花になってしまった。
まー公務員、少なくとも当時の公務員に税金を投入したものをオープンにするなんてのは無理だったろうな逆に各企業に「強力に指導」はできたかもしれんが当時の政治の顔色もあるしでへにょへにょ
TRONそのものは、昔っから「オープン」ですよ。ただし、TRONはあくまで「OSのAPI仕様」だけで、実装は含まれない。
かつての組み込みの世界では、OS無しに全コードをベタに書くのが当たり前で、そこから、リソース管理するOS的なものが欲しい、となった時に、自前でOSもどきの設計から始めるよりは、TRON仕様に従ったほうが「設計の手間が減る」というのが、ITRONが流行った最大の理由だと思う。
だけど、組み込みにもOS乗せるのは当たり前って方向になると、「いちいち実装する手間がかかる」「実装がバラバラなので互換性が微妙で移植性が悪
TRONがオープンってことを主張するなら、少なくともAPIの一覧表がネット上にないとおかしいでしょうが。坂村氏はクローズドソースじゃないことを「オープン」っていってるけど、著作権でガリガリに囲ってたから、ソフトウェアとしては技術的に発展しなかった。
# ひょっとして、と思って今検索してみたら、The TRON Developer HubっていうサイトにAPIの一覧 [developers.tron.network]があるじゃないか！でも、これ暗号通貨 [wikipedia.org]だ！！商標管理はどうなってるのよ……
坂村さんはAPIや各種機器の操作体系の仕様を決めているだけ。その仕様に基づいたソフトやハードを開発するのはメーカーの仕事。で、その仕様は誰が使ってもいいよと言っていたハズ。
「著作権でガリガリに囲ってた」とはlinuxに対するBTRONのことかな？世の中に出たBTRONはパーソナルメディアの作った1Bとか2Bしかないけど、これはパーソナルメディアに著作権があるのは当然だよね。
> 坂村さんはAPIや各種機器の操作体系の仕様を決めているだけ。> その仕様に基づいたソフトやハードを開発するのはメーカーの仕事。
こういうやり方で先進的な技術の成功が得られるとは思えないんだよなあ…仕様を考えて、実装して、そこから得た知見を仕様にフィードバックするというループを高速に回さないと本当にいいものはできないような。仕様と実装を別に進めると、どうしてもこのフィードバックが遅くなったりフィードバックがされなくなったりしてしまう...
だから RISC のトレンドに乗り遅れて、実際には使わない命令満載の TRON chip とか作ってしまったんじゃないかしら。
TRON はトータルアーキテクチャをうたってたけど、実際にそれを実行したのは自分たち自身で CPU を設計し、コンパイラを作り、OS を乗せた RISCベンダーの方だったように思う。
BTRONをフルスクラッチで実装するB-Freeプロジェクト [github.com]なんてのもあったのです。
# 期待してました。。いまならWindowsなりLinux上で互換APIをコツコツ作っていくのが良いのかな。
技術者は良いものを作ってさえいれば、いつの日か世の中が認めてくれるっていう、古き良き日本の風景ですよ。
タネンバウム教授のMINIXはIntelのファームウェアに利用されるという形で実はインストールベースが大きいみたいなネタ話があるけど、それはこういうやり方での先進的な技術の成功でいいんじゃないでしょうか。
今思えばそう思えるところも多いけど、時代が全然違うでしょ。当時は色んな思想っで群雄割拠をしていたし、今ほどOSS的な考え方も受け入れられてなかった。
OSSが普及して、RISCが勝利した世界ではバイアスがかかる
> だから RISC のトレンドに乗り遅れて、実際には使わない命令満載の TRON chip とか> 作ってしまったんじゃないかしら。
基本的には直行性の優れた高級な命令があればコンパイラが楽に高品質なコードを生成できるという考え方で、RISCに否定的なことを当時の本に書いていたように記憶している。
それから、グラフィックス用のチップを外付けするとBOMコストが上がるからCPUが高速にビットマップを操作できる命令を持つべしというように、どちらかというと発想がPC的なものではなく民生機器的。（当時だとキャプテンシステム端末、今だとインターネット家電がターゲットか？）
> 基本的には直行性の優れた高級な命令があればコンパイラが楽に高品質なコードを> 生成できるという考え方で、RISCに否定的なことを当時の本に書いていたように> 記憶している。
同じ記憶がありますが、坂村先生はコンパイラ屋ではなく、またコンパイラ屋と密接に対話して仕事してたわけでもないみたいなので、結果として誤った認識を改められなかったんでしょうね。
RISC陣営の方は、実際にコンパイラの出力したコードを分析して命令セットを決め、コンパイラも CPU設計しているのと同じ会社で作ってました。その差が出たんだと思います。
TRON-CHIPの場合は、割り込み発生時の応答性能の良さが重視されていたと思う。RISCの場合、パイプラインでどかどか命令を実行する分には性能は高いが、割り込みが頻発するような用途では途端に性能が落ちると。
坂村さんがRISCで問題にしていたのはレジスタの多さだね割込みのレジスタ退避と復帰に時間が掛かる、と
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
TRONってよい候補だったと思うだけど (スコア:0)
使い方に対して強い執着があったので結局はやらんかったんだよなぁ。
Re: (スコア:0)
牽引する強靭な開発体制がないのに、オープンソースでもないせいでコミュニティも脆弱、仕様ですら書籍や説明会とセットで普及に及び腰な印象すらある。税金を突っ込んだ割にはガラパゴス化を象徴するような徒花になってしまった。
Re: (スコア:2)
まー公務員、少なくとも当時の公務員に税金を投入したものをオープンにするなんてのは無理だったろうな
逆に各企業に「強力に指導」はできたかもしれんが当時の政治の顔色もあるしでへにょへにょ
Re: (スコア:5, 参考になる)
TRONそのものは、昔っから「オープン」ですよ。ただし、TRONはあくまで「OSのAPI仕様」だけで、実装は含まれない。
かつての組み込みの世界では、OS無しに全コードをベタに書くのが当たり前で、
そこから、リソース管理するOS的なものが欲しい、となった時に、
自前でOSもどきの設計から始めるよりは、TRON仕様に従ったほうが「設計の手間が減る」というのが、ITRONが流行った最大の理由だと思う。
だけど、組み込みにもOS乗せるのは当たり前って方向になると、「いちいち実装する手間がかかる」「実装がバラバラなので互換性が微妙で移植性が悪
Re: (スコア:0)
TRONがオープンってことを主張するなら、少なくともAPIの一覧表がネット上にないとおかしいでしょうが。坂村氏はクローズドソースじゃないことを「オープン」っていってるけど、著作権でガリガリに囲ってたから、ソフトウェアとしては技術的に発展しなかった。
# ひょっとして、と思って今検索してみたら、The TRON Developer HubっていうサイトにAPIの一覧 [developers.tron.network]があるじゃないか！でも、これ暗号通貨 [wikipedia.org]だ！！商標管理はどうなってるのよ……
Re:TRONってよい候補だったと思うだけど (スコア:0)
坂村さんはAPIや各種機器の操作体系の仕様を決めているだけ。
その仕様に基づいたソフトやハードを開発するのはメーカーの仕事。
で、その仕様は誰が使ってもいいよと言っていたハズ。
「著作権でガリガリに囲ってた」とはlinuxに対するBTRONのことかな？
世の中に出たBTRONはパーソナルメディアの作った1Bとか2Bしかないけど、
これはパーソナルメディアに著作権があるのは当然だよね。
Re:TRONってよい候補だったと思うだけど (スコア:2, すばらしい洞察)
> 坂村さんはAPIや各種機器の操作体系の仕様を決めているだけ。
> その仕様に基づいたソフトやハードを開発するのはメーカーの仕事。
こういうやり方で先進的な技術の成功が得られるとは思えないんだよなあ…
仕様を考えて、実装して、そこから得た知見を仕様にフィードバックするという
ループを高速に回さないと本当にいいものはできないような。
仕様と実装を別に進めると、どうしてもこのフィードバックが遅くなったり
フィードバックがされなくなったりしてしまう...
だから RISC のトレンドに乗り遅れて、実際には使わない命令満載の TRON chip とか
作ってしまったんじゃないかしら。
TRON はトータルアーキテクチャをうたってたけど、実際にそれを実行したのは
自分たち自身で CPU を設計し、コンパイラを作り、OS を乗せた RISCベンダーの方だった
ように思う。
Re:TRONってよい候補だったと思うだけど (スコア:2)
BTRONをフルスクラッチで実装するB-Freeプロジェクト [github.com]なんてのもあったのです。
# 期待してました。。いまならWindowsなりLinux上で互換APIをコツコツ作っていくのが良いのかな。
Re: (スコア:0)
技術者は良いものを作ってさえいれば、いつの日か世の中が認めてくれるっていう、
古き良き日本の風景ですよ。
Re: (スコア:0)
タネンバウム教授のMINIXはIntelのファームウェアに利用されるという形で実はインストールベースが大きいみたいなネタ話があるけど、
それはこういうやり方での先進的な技術の成功でいいんじゃないでしょうか。
Re: (スコア:0)
今思えばそう思えるところも多いけど、時代が全然違うでしょ。
当時は色んな思想っで群雄割拠をしていたし、今ほどOSS的な考え方も受け入れられてなかった。
OSSが普及して、RISCが勝利した世界ではバイアスがかかる
Re: (スコア:0)
> だから RISC のトレンドに乗り遅れて、実際には使わない命令満載の TRON chip とか
> 作ってしまったんじゃないかしら。
基本的には直行性の優れた高級な命令があればコンパイラが楽に高品質なコードを
生成できるという考え方で、RISCに否定的なことを当時の本に書いていたように
記憶している。
それから、グラフィックス用のチップを外付けするとBOMコストが
上がるからCPUが高速にビットマップを操作できる命令を持つべしというように、
どちらかというと発想がPC的なものではなく民生機器的。
（当時だとキャプテンシステム端末、今だとインターネット家電がターゲットか？）
Re: (スコア:0)
> 基本的には直行性の優れた高級な命令があればコンパイラが楽に高品質なコードを
> 生成できるという考え方で、RISCに否定的なことを当時の本に書いていたように
> 記憶している。
同じ記憶がありますが、坂村先生はコンパイラ屋ではなく、
またコンパイラ屋と密接に対話して仕事してたわけでもないみたいなので、
結果として誤った認識を改められなかったんでしょうね。
RISC陣営の方は、実際にコンパイラの出力したコードを分析して命令セットを決め、
コンパイラも CPU設計しているのと同じ会社で作ってました。
その差が出たんだと思います。
Re: (スコア:0)
TRON-CHIPの場合は、割り込み発生時の応答性能の良さが重視されていたと思う。
RISCの場合、パイプラインでどかどか命令を実行する分には性能は高いが、
割り込みが頻発するような用途では途端に性能が落ちると。
Re: (スコア:0)
坂村さんがRISCで問題にしていたのはレジスタの多さだね
割込みのレジスタ退避と復帰に時間が掛かる、と