パスワードを忘れた？ アカウント作成
Close
12146 story

Sun、SPARCプロセッサをオープンソース化 35

ストーリー by GetSet
なぜか「拙速」という単語が脳裏をよぎった 部門より

astro曰く、"PC Watchの記事によると, Sun Microsystemsが、同社のWS/Server用SPARCプロセッサ「Sun SPARC T1」の設計情報を無償公開すると発表した。
公開されたのは、VerilogHDLで記述された設計ソース、検証スィート(検証環境か？)と、シミュレーションモデルなどの情報。オープンソース化されたSPARC T1を「OpenSPARC T1」と呼称するそうだ。
タレこみ人は半導体設計の人間なのだが、通常こういった設計ソースはIPとして流通させることはあるが、無償で公開するのはあまり聞いたことがない。もちろん皆無ではないが、研究用などがほとんどだったと思われ、実際に製品化可能なレベルのソース公開は珍しいと感じる。 まさにハードウェアのオープンソース化ともいえる。 ただ、ライセンスがGPLらしく、実際に組み込んで製品化されることは少ないと思われる。
とはいえ、ソフトウェアと違って、個人では簡単に実使用できるわけではないが、ハードウェア設計者や、ハードに密着したソフトウェア(ドライバやOS下層など)を書く人には参考になることも多いのではないかと思われる。
サードパーティなどから、無償のVerilogシミュレータなどが公開される予定もあるそうなので、それらを使って実際のプロセッサの内部の動きなどをシミュレートしてみても面白いのではないだろうか？"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Sun、SPARCプロセッサをオープンソース化 More

  • UltraSPARC T1 そのものより、同時に公開された UltraSPARC Architecture 2005 Specification の方が重要ではないかと考えています。Linux 等の OS を移植できるほど詳細な仕様なんでしょうか。教えて、偉い人。

    ドキュメントで仕様が公開されている CPU は、スーパバイザモードが実装依存であることが決まっている場合が結構あります。これまでの SPARC とか、組み込みを含めた PowerPC とか、MIPS III, IV と MIPS32, MIPS64 が違うこととか。他に実装を見ると MC680x0 も SH もそうでした。そういう CPU ではユーザモードは互換性があってもスーパバイザモードは局所最適を選んでいました。

    すると、石はリリースされても OS は後から作らなきゃいけないことも多かったです。

    Intel と AMD が x86 で採った互換性最重視の姿勢がいかに大事だったかと、今なら言える話なんですが。

    今回公開されたドキュメントで SPARC のスーパバイザモード(細かい人なら SPARC の用語を使うでしょうが、そこはご容赦を)が固定されたなら、UltraSPARC T1 の回路が公開されるよりはるかに、有益な貢献となると考えます。

  • 特許はどうなってるんでしょ (スコア:4, 興味深い)

    by Anonymous Coward on 2006年03月28日 1時25分 (#910066)
    こういう製品レベルのものになると SUN のインプリ特許が沢山使われてそうな気がするけど、どうなんでしょ、実際のところ。通常 LSI の中身に使われている特許の実施確認はほぼ不可能ですけど、この場合、件のソースを使ってる時点で自動的に特許を使ってることになるわけで。

  • 参考 (スコア:3, 興味深い)

    by pastel_you_me (21769) on 2006年03月27日 22時20分 (#909918) 日記
    Sun、OpenSPARC Projectを立ち上げへ [srad.jp]

    SPARC V8のVHDL実装であるLEON2 [gaisler.com]

  • 回路図の使い途 (スコア:3, 興味深い)

    by ikuuya (14857) on 2006年03月27日 23時25分 (#909987) 日記
    すごく単純な意見ですけど、どこぞの誰かが回路図(HDLソース)を解析して、とてつもなく最適化された機械語を吐いてくれるコンパイラとか書いてくれそうですよね、
    それこそ秘孔を突くような、パイプラインの段数とかも考慮に入れたようなのを吐き出してくれるやつ。
    あとは、アセンブラ直書きのライブラリとか。

    ＃某国産RISCチップの機械語を読んで、Cのコードを書きかえて速度アップをさせた経験あり。
    ＃そんなに大きなコードではありませんでしたが。

    • Re:回路図の使い途 (スコア:2, すばらしい洞察)

      by lunatic_sparc (15416) on 2006年03月28日 9時46分 (#910203)
      >すごく単純な意見ですけど、どこぞの誰かが回路図(HDLソース)を解析して、とてつもなく最適化された機械語を吐いてくれるコンパイラとか書いてくれそうですよね、
      >それこそ秘孔を突くような、パイプラインの段数とかも考慮に入れたようなのを吐き出してくれるやつ。
      >あとは、アセンブラ直書きのライブラリとか。

      どの辺か、までって話はあるでしょうが、"OpenSPARC" に特化してしまうと "Scalable Processor ARChitecture" という意義が失われてしまうような希ガス。
      シェア
      親コメント

    • Re:回路図の使い途 (スコア:2, 参考になる)

      by astro (17245) on 2006年03月28日 10時46分 (#910250) 日記
      Pentium(P5)全盛だった頃、友人がPentiumGCCで再コンパイルすると
      速くなると言って、片っ端から再コンパイルしてた記憶があります。

      昔では386と486でも高速に動かすにはコードの最適化が必要でだったはずです。
      たとえば386ではJumpはDword境界で行ったほうが効率がいいので、
      境界整合のためNOPを入れたりしたようですが、486では意識せずによくなったとか、
      命令ごとのクロックサイクルを意識することもなくなったとかいうのも
      プロセッサの設計からくる最適化ネタですかね。
      シェア
      親コメント

      • Re:回路図の使い途 (スコア:1, 参考になる)

        by Anonymous Coward on 2006年03月28日 12時25分 (#910321)
        最適化ネタといえばそうかもしれませんが方向が逆ですね。

        コードの最適化をシリコン上でon the flyでやってしまうことがプロセッサの大きな進化です。CISC命令をRISCライク命令に変換、レジスタリネーミング、アウトオブオーダー、データプリフェッチなどなど、最適化の塊です。デコードステージがやたら長く、実行ステージがわずかなのはその証明ですね。

        そうして、コンパイラはあまり最適化など考えないでよい方向になってしまいました。それはそれでインストラクションアーキテクチャの意味がより大きくなって良いことではあります。

        こってこてのコンパイルをやるというのなら回路図から最適な最適化方法を推定するというのもありかもしれませんが。

        シェア
        親コメント
        • > コードの最適化をシリコン上でon the flyでやってしま
          > うことがプロセッサの大きな進化です。CISC命令をRISC
          > ライク命令に変換、レジスタリネーミング、アウトオブ
          > オーダー、データプリフェッチなどなど、最適化の塊で
          > す。デコードステージがやたら長く、実行ステージがわ
          > ずかなのはその証明ですね。

          　そのはずなんですけどね～。コンパイラが最適化を考え
          なくていいどころか、プログラマーがCのソースコード上
          で、ループアンロールまでやらないといけないのが現実
          だったりして。
          　Pentium4 + IntelC++コンパイラですけど、本当のレジ
          スタなんか見えないはずなのに、Cのソース上でループ
          アンロールをはじめとする、姑息な最適化が結構効果が
          あったりしました。
          シェア
          親コメント

    • Re:回路図の使い途 (スコア:1)

      by fujihara (4983) on 2006年03月27日 23時34分 (#909995)
      そのあたりくらいの最適化だと、今時のコンパイラは
      普通にやってますよね。回路図解析してまで出すのはさすがにないのかな?
      シェア
      親コメント

      • Re:回路図の使い途 (スコア:3, 興味深い)

        by Anonymous Coward on 2006年03月27日 23時56分 (#910010)
        その手の論文も見たことはあります。CPUのバージョンによって乗算機の数とか、パイプラインの制約とかが変わるので、すべてのCPUに最適にするのは難しいね。コンパイラのオプションとかに凝るっていう手もあるけど。 どうせパフォーマンスに関係するのは全体の1%ぐらいなので、そこだけ、最適化したコードを書く方良いと思う。コンパイラに頼る風潮は、「何を最適化したいのか」っていう視点に欠けてる。
        シェア
        親コメント

        • 率直に言うと (スコア:5, すばらしい洞察)

          by ko-ji.t (21285) on 2006年03月28日 0時18分 (#910025)
          >「何を最適化したいのか」
          人件費です。ハイ
          シェア
          親コメント

          • Re:率直に言うと (スコア:3, おもしろおかしい)

            by Henrich (121) on 2006年03月28日 9時16分 (#910173)
            >>「何を最適化したいのか」
            >人件費です。ハイ

            人件費は最適化ではなく最小化したいものではないでしょうか？０ならサイコー :-p

            ＃ホントに適切に払われると困る、という企業多数と見た。

            シェア
            親コメント

        • Re:回路図の使い途 (スコア:1)

          by bero (5057) on 2006年03月28日 13時33分 (#910392) 日記
          ていうかそのための仮想マシン化(VM化)じゃなかろうか。
          最適化フェイズは実行時またはロード時、インストール時に行う。
          javaは（もとは別の目的だったらしいから）瓢箪から駒っぽいけど、CLRは絶対狙ってると思う(64bitへの移行も兼ねて）
          シェア
          親コメント

    • Re:回路図の使い途 (スコア:1, 興味深い)

      by Anonymous Coward on 2006年03月28日 0時50分 (#910046)
      大学で実践的な回路設計の演習だとか、研究の評価データに使うとか。

      新しいCADシステムを作ってみて、このソースを評価に使うことで
      XX%の性能向上が見込めただとか、どういうトラブルが発生した
      だとか。そういう実践的な評価を行おうと思うと評価用データの
      作成がネックになったりするんですよね。

      それなりに良いデータがあるのかもしれないけど、やはり本物に
      勝るもの無し。
      シェア
      親コメント

    • Re:回路図の使い途 (スコア:0)

      by Anonymous Coward
      パイプラインの段数を考慮するような最適化を考える上で、プロセッサのロジックまで考慮する必要があるのですか？
      必要な情報は仕様として提供されていると思いますが。

      • Re:回路図の使い途 (スコア:0)

        by Anonymous Coward
        ロジックの状態によってリーク値が結構変わるので、
        プロセッサのロジックの状態が最小のリーク値となるように
        ソフトでしむけられないかと言った覚えはある。
        #無駄と即答されたおぼえもある。

  • どこまでGPLが影響するのだろうか… (スコア:3, 興味深い)

    by macaro (27147) on 2006年03月28日 0時22分 (#910028)
    今回みたいな公開の仕方をするといったい何処までGPLが影響するのだろうか？ 例えば、中国あたりの企業が独立系のファブに製造を委託したり、もしくは小規模な半導体製造設備を有する企業が生産したりって事は起こりうるのか？ （今回の場合はロジカルな面のみの公開だから直ぐに物理設計が出来るわけではないだろうケド） その場合は、OpenSPARCの技術を使ったchipのみがGPLの対象なのかボードまでがGPLの対象なのか…

    • Re:どこまでGPLが影響するのだろうか… (スコア:2, おもしろおかしい)

      by shadowin (23191) on 2006年03月28日 0時54分 (#910049)
      ボードに直付けの場合、ボードもGPLの対象
      ソケットつけて取り外し可能な場合、ボードは対象外
      ということになりそう。
      シェア
      親コメント

    • Re:どこまでGPLが影響するのだろうか… (スコア:1, おもしろおかしい)

      by Anonymous Coward on 2006年03月28日 1時13分 (#910058)
      ハードウェアがなければ OS は動きません。
      つまり、ハードウェアは OS の本質的な構成要素のひとつです。
      ゆえに、GPL 第3項により、ハードウェアのソースを渡す必要はありません。
      シェア
      親コメント

    • Re:どこまでGPLが影響するのだろうか… (スコア:1, 興味深い)

      by Anonymous Coward on 2006年03月28日 14時40分 (#910429)
      ボードまでにGPLが及ぶなんて発想をするとはスゴイねぇ・・

      最小限に解釈すれば、FPGA内の他の部分はGPLに汚染されない。
      最大限に拡大解釈したとして、１つのFPGAの中に入っているソースまでの汚染。
      それに、特許でガチガチだし、まっとうな企業はみんなGPLなんて危ないもの使いたがらない。
      よって、これを製品化なんてする会社は出てこないでしょう。

      しかし、OpenSPARCの内部を公開して、研究機関やサードパーティに興味を持ってもらったり、第三者がSPARCを使ったシステムの動作検証をしやすくなったり、という効果はあるでしょう。

      回路は巨大だそうなので、FPGAに実装しようものならきっとSUNから純正のチップを買った方が安い。
      大きなFPGAって高いんだよ。
      これを実装できるようなFPGAにはすでにPowerPCが入っていたりするので
      わざわざSPARCを入れるような無駄なことはしない。

      それよか、GPL以外のライセンスでSUNから同じ(か、もしくはより良いバージョンの)ものを提供してもらってSPARCをハードマクロ化して組み込んでしまったFPGAがそのうち出てくるかもね。
      シェア
      親コメント

      • ん～。普通に考えればボードは含まれまいがCPUってチップの設計を『GPL』で公開したわけだからチト、状況が『特殊』かな？って（苦笑）。VHDLとかVerilogで出してそれがGPLなら、ボードのガーバーデータやネットリストも同じ扱いにされてしまうんじゃ

        自分が想定したのは論理設計をパクったchipで、『not FPGA』です、安価なNICの代表格のカニさんのように大量にSPARCを作って安く売るビジネスモデル、自分で物理設計をこなして量産効果で激安販売って感じだとchipのみが汚染される『ダケ』では実現できないわけではないと感じたんで…

        SUNはそういうケースを想定してるのかなぁ

        シェア
        親コメント
        • >VHDLとかVerilogで出してそれがGPLなら、ボードのガーバーデータやネットリストも同じ扱いにされてしまうんじゃ

          ならない。そもそも、リンクとか同一メモリで動作するプロセスとか、そういうGPL汚染の条件があてはまりません。最悪のケースで考えても、論理合成の段階で一緒にコンパイルされるFPGA内のネットリストまででしょう。
          それ以外の部分、つまり基板の設計はFPGAとは全く別に行われるので、リンクとか同一メモリのプロセスと解釈するのは無理があります。

          >自分が想定したのは論理設計をパクったchipで、『not FPGA』です
          動作するだろうとは思われますが
          • なるほど、勉強になりました。 確かに、FPGA内で使うのが無難だと思います。 可能性として、ASICなりを製造するメーカがあればと思いましたが難しいようですね。安価にSPARCコアが使えて組込みにあったコンパニオンチップ的なものを含めたASICがあれば是非使いたいとか思ったもので（笑） 自分もハードウェア（それなりに大規模）を過去行ってきたのである程度の演算性能が必要≒PowerPC系みたいな現状に新たな選択肢が出れば面白いと思ったのですが。 ためになる投稿ありがとうござました。
            シェア
            親コメント

  • このマイコンは (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2006年03月28日 0時15分 (#910017)
    いつ雑誌のオマケに付くんですか？
    トラ技ですか？DWMですか？
  • 　プロセッサをオープンソースされてもねぇ...
    　プロセッサ由来のバグが見つかったとしても、修正ということで、プロセッサ自体にハードウエアパッチ（！）を当てたり、ピンセットでパターンにジャンパ線付けたり、カッターナイフでパターンを切ったりできないしねぇ。
    　Sunは、設計のミスのfeedbackを期待しているのかしら
    　3rd party（ハード、ソフト）のための、仕様の公開というほうが現実的かな?
    • >プロセッサ由来のバグが見つかったとしても、修正ということで、プロセッサ自体にハードウエアパッチ（！）を当てたり、ピンセットでパターンにジャンパ線付けたり、カッターナイフでパターンを切ったりできないしねぇ。

      何で? できるんじゃない?
    • FPGAに実装されてればハードウエアパッチできますね。

      あと、チップ自体もイオンビームで配線を切ったり張ったりってのも試作評価段階ならやったりします。。。
      ＃昔千個単位でやっちゃったのでAC(汗

  • 拙速 (スコア:0, おもしろおかしい)

    by Anonymous Coward on 2006年03月27日 22時17分 (#909914)
    これならいけますよ！

    ご連絡先

    • Re:拙速 (スコア:0)

      by Anonymous Coward
      オープンハードつながりのネタが分からなくてオフトピモデなのか
      わかった上でオフトピとしているのか……
typodupeerror

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell