もしかしたら開発室附属雑記帳

計算機の明後日を考える「もしかしたら開発室」の雑文(又は下書き)コーナー

電脳文庫プロジェクト

[ リスト | 詳細 ]

記事検索
検索

全1ページ

[1]

長らく開発を続けている割りに今まで殆ど情報を出してこなかったのですが、さすがにモチベーションがアレ気味になってきたので、今回はプロジェクトの現況や概要について、かなり掘り下げて書いてみようと思います。

今着手しているのはOSの方です。名前は「Scrapstick(スクラップスティック)」と言います。Slapstickの書き間違いではありません。

「ソフト・ハードを問わないモジュール実装と高いモジュール可換性を実現する、新しいコンピュータシステムの開発」なんて掲げていますが、これ使って何がやりたいかというと、気軽にハードウェアの世界と戯れることができる環境と、そんな環境用に書いたコードを将来にわたって(何かしらの簡単な方法で)動かすことができる仕組みを両立させたい…というものです。

「あるOSの中でアプリどうしが通信しているのと、バス上で相互接続されたデバイスどうしが通信してるのって、細かい点は抜きにしてもやってること自体は似たようなもんだろ?」という点に着目して、

  • じゃあそれぞれ区別せずにまぜこぜで通信できるよな仕組みを作ってやれば良くね?
  • いっそ通信相手を(作者ではなく)利用者側都合で自由に差し替えられるようになってりゃ便利じゃね?
  • これ使えば、ハードべったりなコードがあったとしても、必要に応じてハード部をエミュレータへ簡単に差し替えられるので、実機無くなっても動かせるっしょ?
  • なんならこの仕組みにシェル(ユーザコンソール)でも付けてしまえばOSの代わりになるじゃねーか?

  • …といった発想の元に実装を進めています。OSだけでなくバスプロトコルの開発も視野に入れているのは、ネタの根本がこういったソフト / ハード界面みたいなところにある為です(まぁ単独のバスとして使えるもの方はいつ着手できるかわかりませんが…)。当然、カーネルレベルでのPOSIX互換なんて一切取る気もありません。


    通信相手がソフト実装かハード実装かを区別しない…ということから察しがつく方もいらっしゃると思いますが、このシステムで扱う通信は「バスアクセス」を抽象化したものです。ユーザモードにおけるコードフェッチやデータエリアのR/W、I/O操作に割り込み等々、大凡全てのバスアクセスがシステム管轄の通信として扱われます(!!)。当然マジメにそんなことしてたら死ぬほど遅くなるので、特定の条件を満たした場合に限ってカーネルを介さず直接ページアクセスできるようにする等の工夫を入れて、実用的な速度で動作するようにしています。また、バスに発行可能なアクセスのサイズは可変長としているので、ブロックI/O的な使い方で通信コスト(発行回数)を減らすことも可能です。この辺は、システムコール的なものを持たせない設計(HLT等、プロセッサ機能に絡む内容以外のカーネルとの対話は、全て通信経由で行う必要がある)などと絡んでいる所でもあるのですが…細かい話はいずれ。

    前掲の話ではハードモジュールをソフトモジュール(エミュレータ)で置き換えることだけ触れましたが、当然逆も可能です。つまり、元々ソフト実装モジュールだったものをハード実装のアクセラレータに、呼出元コードを弄ることなく利用者都合で自由に切り換えることができます。例えば、元々通信を伴うものや演算系等、処理の粒度が大きく、かつ各々一回の呼出で完結できるようなタイプの処理であれば威力を発揮できるはずです。特に、前述した直接アクセスの条件を満たしていればカーネルを介在せずに直接レジスタを叩くことができるので、大幅な高速化が期待できます。あまりにもソフト間通信コストが問題になった場合は、FPGAボードとかと組み合わせてこういう逃げ道もありますよということで…。

    この辺をさらに発展させると、

  • 「デバイスドライバ」の概念は必ずしも必要ではなくなる。同時アクセス時の調停機能と、ハードウェアI/FをAPIが定めるI/Fに見せかける機能を持つエミュレータだったのだ…と解釈できるので、いずれも必要無ければ無くて良い。
  • デバドラが通常階層構造になっているように、エミュレータを多段に繋いでも良い。つまり、各エミュレータ段で直接叩いたつもりのレジスタが、実は他のモジュールでエミュレートされた代物だった…というのを多段に繰り返しても良い。
  • これより、わざわざ抽象化レイヤや共通APIを作らなくても上手くいく可能性が出てくる。例えば、機能Aの実現に使えるハードウェアが5種類位あるとして、作者側は手持ちにあわせてどれか1つのI/Fに合わせたコードを書けば良い。利用者側は、手持ちに合わせて、I/F変換のエミュレータを探すなり(単独では揃わなくとも、多段にすれば揃う可能性が高まる)、作るなり(必ずしもフル機能を作る必要は無く、そのアプリが動く程度のザルいものでOK)すれば良い。恐らく、ユースケースが固まっておらずI/Fが乱立しがちな新規分野だったり、共通APIに集約する動機も無いようなニッチ分野で特に効果的。
  • メモリアクセスが通信である以上、メモリだと思って通信した相手が「本物のメモリ」である必要は無い。即ち、ディスクドライブ等を使ってエミュレートできる(メモリマップドディスク的な)。これより外部ストレージ・メモリ空間上の揮発 / 不揮発メモリ等々を全て等価に扱える。ごくごく自然に仮想記憶が実現できるとでも言うべきか。バス空間上に「ファイルシステム」をマップすることさえ可能。
  • CPUエミュレータを経由して他機種のマシン語で書かれたコードを実行しても、実機向けに書かれたコードと全く同等に扱える。バスアクセスを通信として使うので、通信相手から見ればどっちだろうと差異は無い。極端な話、例えばx64 PC上で、SPARC向けに書かれたアプリケーションが、68000向けに書かれたTCP/IPスタックとARM-v6向けに書かれたモデムドライバと実機モデムを経由して通信を行い、Z80向けに書かれたV9958を使うコンソールに結果を出力…なんてことも、ごくごく自然に行える。CPUエミュレータの多段も可(CPUエミュレータを別のCPUエミュレータ上で動かしたりできる)。
  • これをハードレイヤにも適用すると、ヘテロジニアスなマルチプロセッサ環境を自然に扱える。前述の通り、バスアクセスさえ発行できれば実行コンテキストのアーキテクチャは問わない為。DMAの処遇についても同様。但し、当然ながらカーネル側でも専用の対応が必要。
  • 所用の通信さえ実現できれば良いので、最終的に、Scrapstickの殆どの機能をハードウェア化したアーキテクチャのマシンを作ることも可能かもしれない(ただの浪漫)。

  • といったように、結構面白いプラットフォームになりそうです。「互換性の担保をエミュレータに押しつける」点や、それを利用して「新しく作る部分では互換性を無視して好き放題できるようにする」という思想については、使い方や目的は違えど、とても古のOSASKっぽい所だと思います(当然ですが、コレには多々強い影響を受けて育ちましたので…)。うまくいけば、コンピュータシステムの組み方・あり方を大きく変えることができるシステムに発展できるかもしれません。例えば、枯れた分野のハードウェアはよりインテリジェントなI/Fを持つ方向に進化することが簡単になるし…ストレージがファイルシステムを話すとか…、新たな分野ではI/Fの試行錯誤がより気軽に行えるようになるはずです(I/Fが固まるより前に生まれた徒花たちを、エミュレータさえ書けば後世にも使い続けることができる可能性が高まる。よって、書き捨てることに後ろめたさが無くなる)。


    ここまでは割と美味い話ばっかり書いてきましたが、当然、この方式によるデメリットもあります。

    先程からもちょこちょこ触れているように、まずは性能上の問題です。バスアクセス全てをカーネル管轄の通信として扱う以上、このコストがとんでもないことになるであろう予測が立ちます。前述したように、通常のコードフェッチやメモリの読み書き程度であれば、カーネルを介さず直接アクセスできるような細工を入れ込んではあるのですが、モジュール間通信部分はどう転んでもカーネル経由です。単段であればUnix系で言うところのパイプを介したプロセス間通信レベル + αで済むと考えられますが、エミュレータを多段で組むような状況下では各モジュール境界でそれぞれ通信が起きるので、マイクロカーネルでサーバ間通信が多発しているような状況 + α程度を覚悟しておくべきと思います。また、作成者都合で通信相手を限定できない(利用者側で勝手にエミュレータへ差し替えられる / 多段にできる)ことから、時間制約が厳しかったりリアルタイム性を保証しなければ動かない用途には不向きです。こういった性能上の懸念については、いくつか代替の腹案はあるのですが、当面は利便性の代償としてあきらめる方向で考えています。ただ、このシステムの中であっても、極力依存する外部モジュールを減らせばベアメタルに近い性能を出すことは可能と思われるので、必要であればその辺を駆使して乗り切ってほしいところです。

    次はこの通信方式に関する点です。モジュール間通信の界面は所定のバスアクセスの形で行う必要があるため、既存のシステムで良く見られる関数呼出スタイルのAPI / ライブラリを、そのまま別モジュールとして切り出すことができません。どうしてもやりたければ、呼出元にラッパ関数を噛ませて、その中で通信を発行する形にする必要があります。これはシステムコールをCから呼ぶラッパ等と同種といえば同種ですが、差し替え可能にしたい部分は全てこの形式にしておく必要があるため、他のシステム用に書いたコードをScrapstickへ移植する場合などはこの点をよく意識しておかないと、折角のメリットが全く得られないハメになるかもしれません。


    システムの概要をざっくり書いてしまうとこんな感じです。じゃあ後はどこまで形になってるのか…という話なのですが…、以前の記事にも書いたように、現在はWindows上で動く版(以下Win32版と呼びます)を書いていまして、その上でI/Fの確認などの実験を重ねています。流石に記事当時よりも実験が進み、Win32版内蔵のQuark D1000エミュレータ( + α相当。i386をFlatモデル固定にして命令を減らしたようなヤツ)上でCで書いた実験アプリを走らせて機能や使い勝手を確認できたりする状態です。詳細は後述しますが、ようやく長年の懸念事項があらかた片づき、今後システムの大改造を伴うような手戻りは無いであろう段階まで来たので、あと2〜3機能程、ユースケースとして実現性を確認しておきたい大物が上手くいけば(ハマらなければ)公開に踏み切れると思います。

    前述の記事でも少し触れていますが、実機版が完成した暁には、何らかのシリアル通信I/F経由でそのまま協調動作できるようになる予定です。ようはバスアクセスをシステム間でまたいで伝達することができれば、相手方が持つアドレス空間の一部(公開されている領域)をローカルに(仮想的に)マッピングしてアクセスできることを利用して、実機版で走るアプリからWin32版のウィンドウマネージャを叩き、ウィンドウを生成してボタン操作やら入出力やらを受け付けたり、逆にWin32版で走るアプリから実機版のI/Oエリアを叩いたりすることなどに使えます(当然、実機のシェル代わりや各種デバッグにも使えます)。最初に公開するのはこのWin32版の予定です。こっちだけだと魅力半減ですが、どういうものかは伝わるかなぁ…と。

    (以下、2018/12/29修正)

    流石に時間かかりすぎじゃねーの…という話なんですが、実は2012〜15年にかけて作っていた代物(1回だけ人目に出したことがあります)を一旦放棄したりと、結構大きな手戻りを何度もやらかしてしまっています(実験的要素しかないので仕方ない部分ではあるのですが…もどかしい)。本稿で書いたことのうちの大半は、この放棄したものでも仕組みとしては実現できる構造だったのですが、一言で言ってしまうと「プラットフォーム性」とでも表現できるでしょうか、使い勝手上の難があった為、その仕組みのままI/F類を整備する気になれず、本格的な実験(特に、発展に書いたような部分の確認)にまで至れませんでした。

    この「プラットフォーム性」について具体的に言うと、例えば、自分が書いたコードを他の人にも手軽に使ってもらえるように、或いは他の方が作ってくれたコードを手元で手軽に使えるように…というのは当然ですし、システムを使い込んだ際にスケールしないようでは困りますし(例えばシステムが扱うアドレス空間。フラット・固定長でスケールする訳が無い)、何がどこにあるのかわからずとっちらかったり、システムの扱いが複雑怪奇になりすぎても困ります。この辺り、割とUnix(当初の)やPlan9辺りはバランスが良いんですよねぇ(そしてSmalltalk、テメーはダメだ)。

    これらを本来やりたいことと両立して実現できる仕組みに組み上げるのがなかなか厄介で、さりとてノウハウも無いので何度も作っては壊しして進めているような状態です。現在の実装についても、大枠となるブレイクスルーは2017年前半までに得られたのですが、やはり使ってみるとどうしても気になる点が次々出てきて、最近まで長期スパンで大改造を繰り返し行っていた位ですので…。そしてこの部分こそ、システムの根幹を成す「Scrapstickバス」です。少々毛色は違いますが、UnixやPlan9で言うところのファイルシステムみたいな立ち位置ですかね。これまで「カーネル管轄の通信」と書いていたのは、このバス上で扱う通信のことです。こいつの概要も書いておきたいところですが、ちょっと長くなりすぎたので年明け以降にでも別途改めて書くことにします。

    それでは皆様よいお年を。
    IA-32上で走るOSや486辺りのエミュレータ、或いはパチモンのRTLを書いたりする場合、CPU実機の細かい挙動を知りたくなることがあるかもしれません。通常、詳しい公式資料というと「IA-32 インテル・アーキテクチャ ソフトウェア・デベロッパーズ・マニュアル」を見ることが多いのではと思うのですが、これはあくまでもアーキテクチャ共通の記述しかなく、各プロセッサ固有の事柄についてはあまり触れられていません(例えば、プリフェッチバッファのサイズはいくらか・キャッシュやTLBヒットミス時のペナルティは何クロックなのか…など)。

    実は、古いモデル(特に386)についてはデータシートや関連するドキュメントの記載が充実していまして、命令セット表やバスサイクルの解説などと一緒にこういった細かな情報についても書かれていました(よく非ARM系の組み込み用の石とかでも、データシートに命令セットが書いてあるやつがありますよね。あれと同じノリだと思います)。486DX4の頃になるとデータシートは幾分寂しいものになってしまいますが、エンベデット版固有のドキュメントで同じレベルの記載が残りました。一方、Pentium以降はデータシートやWeb上に上がっている文書からは細かい挙動がわかりにくくなってしまったようです。

    ということで、486DX4までであれば比較的詳しい説明が得られます。

    肝心の入手方法ですが、当然ながら今のIntelのサイトには上がっていません。そこでInternet Archiveの出番です。以下にリンクを張っておきますのでご利用下さい。尚、各文書について、ダウンロード先サーバの選択ではHTTPのみが使えるようですのでご注意を。
    特に有用そうなものを列挙しておきます。

  • 80386DX データシート
    IA-32の元祖。必要なことは大抵書かれています。が、各命令の詳細動作など、ソフトウェア・デベロッパーズ・マニュアルで細かく説明されていることについては詳しく書いていないので、組み合わせて読むと良いです。強いて難点を挙げるとすればしおりが無いこと。
  • 80387DX データシート
    FPUの詳細が知りたい方はこちらをどうぞ。

  • Embedded Intel486プロセッサファミリ デベロッパーズマニュアル
    386のデータシートに書かれていたソフト観点で使いそうな項目を、486用にアップデートしたような文書です。キャッシュの詳解、細かい所要クロック数やペナルティ時の所要クロック数なども記載されています。
  • Embedded Intel486プロセッサ ハードウェアリファレンスマニュアル
    上記のハードウェア版。


  • 何か必要そうな情報がありそうだと思った方はぜひ活用してみて下さい。


    --

    結局今年は親指シフトネタばっかりで全然OS関係のブツを上げられませんでした。Galileoのディスコンにも間に合わなかったし…。かなりフラストレーションが溜まっています。ということで、今年最後の悪あがきでOSネタと関連する記事を書いてみました。

    外には情報を上げてないのでアレですが、開発中のOSは今年一年でかなり良い方向に進化してきました。これに関連して書きたいことも大量に溜まっています。個人的には、ある程度動くブツをリリースした上で書く方がやりやすい気がしているのですが、頭を整理する為にも、少しずつ文章化して公開していった方が良いのかもしれません。この辺は暫く考えたいと思います。

    直近で嵌まって暫く開発が止まったりもしたのですが、まぁアレですね、やりたい事(例えばアプリケーションとか)がかなり明確になっている以上、欲張っちゃいかん…と。最低限必要なネタ以外はある程度割り切って、ちゃっちゃか進めたいと考えているところです。春までに成果物が何か公開できれば良いなぁ…と思います。

    それでは、皆様良いお年を。

    開く トラックバック(0)

    突然ですが、こんなニュースを目撃してしまいました…。


    なんでも、Intel Galileo(含Gen2)、Edison、Jouleの各ボードが、今年一杯で生産終了とのことです。

    ちょっと待って…。オレ、Galileo Gen2向けにOS書いてる最中なんだけど…。

    いや、正確に言うと、モジュール間通信仕様(って言えば良いのか、或いはオブジェクトシステム仕様といえば良いのか、とにかくこのOSの核となるI/F部分)を固める為に、まだWindows上で動くシミュレータをスクラップ&ビルドしているところなので、カーネルやドライバが直接影響を受けた訳ではないのですが、このシステムのテーマとして「ソフト・ハードを問わないモジュール実装と高いモジュール可換性を実現する」と掲げているだけに、手軽にGPIO操作できるターゲットボードが無くなってしまうと、正直ファーストインパクト半減といったところです…。まぁカーネルそのものはGalileoとPC/AT(IA-32)版で共通にするつもりだったので、Galileo固有のドライバをオマケで準備する程度には対応するつもりですけど…なんだかなぁ。

    正直、(チップ単体と違って)民生品っぽいとはいえ組み込み分野の製品ですので、細々と長期生産してくれるものだと勝手に考えていたのですがねぇ…。下手すりゃそこら辺の市販マザボとかよりも短命だったんじゃなかろうかという気がします(特にJoule)。

    尚、今回はチップそのものがディスコンになる訳ではないように見えるので(先行きはあまり明るくない気がしますが)、またQuark X1000を使ったボードとか出てくれればいいなぁ…と、生温かく期待することにしておきます…。


    ええと、ついでにOSネタの進捗状況です(長らく外部に見える成果が出てないので、何かこういう形でも出さないと寂しい気がしてきました…)。

    上の方で少し書いた通り、まだ仕様固めに走っている段階で、カーネルにはほとんど手が入っていません。最初はカーネル上で色々試行錯誤していたのですが、一旦メモリ管理のことを忘れたくなったので、Windows上で動くシミュレータを作り、そっちで実験することで試行錯誤を高速化することにしました。お蔭でI/Fは大分目標地点に近づいてきたと思います(アプリ走らすところまで確認できたら一旦完成にして、カーネル上への移植を始めようかと)。

    このシミュレータですが、いずれ実OSが走っているマシンと通信してなんやかんやするツール(デバッガ兼ウィンドウマネージャ…Xサーバみたいな…)を作るつもりだったので、実験完了後はこっちの雛型にでもして、無駄にしないつもりです(笑)。

    しかしまぁ、このシステムの本丸に定めているアイディアは4〜5年位前に思いついたものなのですが、これをベースに「オペレーティングシステム」として使いものになるよう細部を詰めていくと、なかなか一発で良い形にはなりません。最初の頃は、無駄に使い勝手が複雑だったり実用アプリが書き辛い仕組みになってしまったりと(実は1回だけ人目に触れた機会があるのですが、そのころの話です)、せっかくのネタが生きない代物になってしまったので、実際にテストアプリを作りながらフィードバックしたり、「最終的に同じことが実現できるものの、全く別なI/Fやオブジェクト機構」を考え直して大改造するとか、ここ2〜3年はこんなことばっかりやっております。これもやっと、Windows上で検討サイクルを高速化(ぉ)したことで終わりが見えてきたところですが…。

    ということで、まだまだ時間はかかりそうですが、Galileoのディスコンまでに実機で動く版をリリースできればいいなぁ…とぼんやり考えながら、引き続き開発を続けようと思います。つーか早くこのシステムで動くアプリを書きたい(順番

    # 尚、実際に動くところまで作ってみたら大凡実用的とは言えない何かになる可能性もありますが、それはご愛嬌ということで…。

    近況など

    また暫く間が空いてしまいました。

    この間色々ありまして、正直コード書く気力も無くなってたりしたのですが、ふと見たファミコンの解析資料からファミコンプログラミングを始めまして、おかげさまでみるみる回復しました。これめっちゃ楽しいですよ。なんというか、少ない命令とシンプルなハードの組み合わせで何でもやってやろうというのは、プログラミングの面白さの本質に限りなく近いのではないかと思います(最も、HWを省略し過ぎているが故に、一見不可解な動きをされたりしてハマることも多々ありましたが…。資料としてはこちらも見ると良さげです)。まだ暫くは何か公開できるようなものはできないと思いますが、そのうちゲームか何か作ってこっそり乗せるかもしれません。

    しかし向こう約1年程、クソチップ・クソ環境・クソジジイ達の三連コンボに疲弊しきった身にはこれ以上ない位の回復薬でしたね。もし私のような趣味上がりのソフト屋の方で、タチが悪い方の役所仕事しかできないみみっちい秩序LOVEな連中に囲まれて辟易している方がいらっしゃったら、こういった方向で童心を回復しつつウサ晴らしすると良いのではと思います。そんでもって、千葉の稲毛海岸辺りで夕日に向かって「全部焼け野原になっちまえ! その後立ち上がって次を作り出すことができるのは俺たちだけだ!」とでも叫んでやりましょう(ぇ。

    さて、こんな状況なので、電脳文庫プロジェクトの方もかなり停滞気味です。いや、全く進展が無い訳ではなく、例えばUEFI用のブートローダを書いたとか(このお蔭で、Intel Galileo Gen2ボードから自前のカーネルをブートできるようになりました)成果が無いこともないのですが、アプリケーション環境におけるリソースや各種モジュール・オブジェクトの表現方法というか見せ方というか、そういったところで良いアイディアが出ず足踏みしている状態です。そこのところに限れば、UnixとかPlan9のファイルシステムって絶妙なバランスだったんですねぇ…とつくづく感じます。決して完璧とは思いませんが。

    昔、OSASK計画の川合さんから例の緑本(と、カオちゃんのバンダナ!)を頂いて以来、長らくOSの研究的なことを趣味でこっそり続けてきたのですけど、post Unix世代とでも呼べるものがなかなか世に広まらない理由って結局この辺なのかなと思います。単純に、手持ちの環境で動くOSと呼べるものを作り、その上で走るアプリを用意して見せるだけなら、例の緑本で川合さんが示したようにそこまで難しい話ではないはずです(実際、海外フォーラムとかでも多くのプロジェクトを見かけられますし)。ただ「多くの人に使ってもらえるような良くできたアプリケーションプラットフォームを作る」となると別問題なだけで。なので、結局多くのOSプロジェクトは、例え革新的な設計だったとしても「POSIX準拠のユーザランド載せました☆」とか言い出しちゃって、折角「そのOSを使うことでできる面白いこと」があっても殆どユーザランドから使えず(使えたとしてもベンチ結果がちょっと良くなったとか、メンテ性向上とか)、「別にLinuxで良くね?」 or 「一部機能だけLinuxにマージ」という流れに行き着いてしまうのではないでしょうか(主にマイクロカーネル勢の瓦礫の山を横目に見ながら)。

    尤も、ただアプリケーションを走らせるだけならば、抽象化レイヤを積み重ねていくことで下層レイヤのことなどいくらでも忘れられるので(ぇ)、単純にもっと新しい設計のプラットフォームを求める人たちの多くは、より上層に新世界を積み重ねていくことで理想を実現する方向に移って行った…というだけのことかもしれません。

    しかし、ハードウェアと密に組んで何か面白い物を作ろうとするとそうはいきません。当たり前ですけど、「生まれたてのHW」みたいな抽象化されたこともないようなのが出てきたとき、こいつを上層から扱おうとするには、最下層に降りてデバドラ作るところから、最悪はAPIやらもっと上位のラッパまで用意してやらないといけなかったりします。
    まぁLinuxだったら、デバドラから見せるI/Fを上手くファイルアクセス(read/write)として表現できる場合に限り、上層から触るハードルが随分低くなるのでまだマシなのですが(例えば、Intel Galileoだと、/sys/class/以下のファイルにアクセスすることで諸々のI/O操作が行えるようになっているそうです)、それでもデバドラの開発とI/F上の制約が付きまといますし(割り込みがなぁ…POSIXのシグナル周りはどうもしっくり来ない記憶が…)、そもそも文字列ベースのデータのやりとりは個人的に嫌いなので、この辺何とかしたいところです。

    こういったように、電脳文庫の場合、ソフトウェアプラットフォームとしての既存OS(特にPOSIX環境)に不満を感じた上での新規開発なので、(一番問題と考えている)モジュール間I/F部分の改良が要となる訳です。他にももっと野心的な試みを内に秘めていたりもするのですが、最低限ここだけは妥協ができません。通信の仕組みそのものについてはかなり前から固まっているだけに、あとは上手いモジュール表現の方法が固まればなぁ…というところです。たかがコード書き歴20年弱程度だと、まだまだ思うようなモノを作れないもんだと痛感しますね…。

    このため、しばらく(何かブレイクスルーがあるまで)はこちらを止めて、何か気分転換になるような軽いものを作るのが続くかと思います。

    本当はここまでマクラのつもりだったのですが、長くなったので本文にしようと思った話は改めて書きます(ぇ。

    全1ページ

    [1]


    .


    プライバシー -  利用規約 -  メディアステートメント -  ガイドライン -  順守事項 -  ご意見・ご要望 -  ヘルプ・お問い合わせ

    Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.

    みんなの更新記事