2016_12
の編集
https://khfdpl.osask.jp:443/wiki/?2016_12
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
2016_10
2016_11
2016_12
BracketName
Essen
Essen0
Essen1
Essen2
Essen3
Essen4
EssenMemo0001
EssenMemo0002
EssenMemo0003
EssenMemo0004
EssenMemo0005
EssenMemo0006
EssenMemo0007
EssenMemo0008
EssenMemo0009
EssenMemo0010
EssenMemo0011
EssenR2
EssenR2_ess03f
EssenR2_ess03h
EssenR2_ess03i
EssenR2_ideas
EssenR2_jit00
EssenR2_jit01
FormattingRules
FrontPage
Help
IP
InterWiki
InterWikiName
InterWikiSandBox
K
KHPC
KHPC_v000doc01
KHPC_v001doc01
KHPC_v002doc01
KHPC_v003doc01
MenuBar
OSC
OSC20181027
OSC20190222
OSC20191123
OSC20230401
OSC20230528
OSC20231021
OSC20240310
OSC20241026
PHP
PukiWiki
PukiWiki/1.4
PukiWiki/1.4/Manual
PukiWiki/1.4/Manual/Plugin
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/H-K
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/V-Z
RecentDeleted
SandBox
SltVA
VariableArray
WikiEngines
WikiName
YukiWiki
advcal20161205
advcal20161206
advcal20161209
advcal20161210
advcal20161215
eoml0001
eoml0002
essen_ex01_0001
impressions
kcl_malloc
khfdpl_result1
members
memo0001
memo0002
note0001
note0002
note0003
note0004
note0005
note0006
oldworks
oldworks00
oldworks06
oldworks12
oldworks13
osaskjp_index
persistent_C
populars
pr20161105
pr20161105b
scsc
seccamp2017
spam_test
uxf
uxf_01
uxf_02
uxp
* 2016年12月 -(by [[K]], 2016.12.09) ** 2016年12月09日(金) #00 Essenやりたい -アドベントカレンダじゃなくて、Essenを作りたい。 -しかしそれにしてもOSの自作ってどうしてこんなに人気があるんだろう。ハードウェアをいじるから? -EssenにはOSっぽい要素がいくつかある。 --(1) Essenはタスクスケジューリングをする --(2) Essenはファイルシステムの代わりをする(変数の内容が永続化されるから) --(3) Essenは機種依存を吸収して、異機種間での互換性を提供できる -っていうか、そもそもOSと言語処理系ってよく似ていると思う。特に私にとっては、OSなんて「アプリを実行するためのプログラム」でしかなく、言語は「プログラムを実行するためのプログラム」でしかない。アプリは機械語やバイナリで書かれていて、言語のソースコードはテキストかもしれないけど、でもそれは大した差じゃないと私は思う。 -OSも言語も、何が正しくて何が正しくないかを開発者が自由に決められる。 -(1)に関して: --Essenのタスクスケジューリングは、基本的にはプログラムが「ここで一区切り」って書いたタイミングでしか切り替わらない。また、マルチコアCPUであっても同時に2つ以上が動作することはない(そういうこともできるけど、その場合はアクセス競合をEssenは管理しない)。 --だからマルチスレッドプログラムは非常に書きやすい。まあミスして「一区切り」命令を書き忘れるといつまでもスイッチしないという問題はある。・・・これを検出しやすくするため、あるスレッドが一定時間以上(たとえば3秒間とか)ずっと「一区切り」命令を実行しないでいると、警告が表示される。 --[Q]どうしてもっと普通の(=勝手に切り替わるタイプの)マルチスレッドにしないんですか?・・・っていうか切り替わるタイミングを指示って、つまりイベントドリブンってことですよね?おいおい、いつの時代の話ですか?? --[A]マルチスレッドで競合問題が生じると、解決はかなり難しい。それは結局は意図せぬタイミングで中途半端になっているデータを読み書きしたせいであり、これを何度か経験するとマルチスレッドプログラミングが嫌になる。ロックとかも学ばねばならない。・・・しかしロック・アンロックを繰り返すくらいなら、「ここで一区切り」な命令を実行させてもいいじゃないか。ここで必ず切り替わるという保証はない。もしまだ自分の実行時間が残っていれば、一区切り命令を実行してもそのまま継続する。・・・ロックし忘れは深刻なバグの温床だけど、「一区切り」のやり忘れはマルチスレッドの切り替えがまずいだけで、発見もデバッグもとても簡単である。だからこのパラダイムでやりたい。・・・まあマルチコアCPUを活用したいとかになるとこんな方法ではダメなんだけど、それはEssenを継行した人が別のプロセスでやって、その結果をEssenで受け取らせて処理する、みたいな感じになればいいと思っている。 -(2)に関して: --変数の永続化について、全部の変数を保存じていたら遅くてたまらないのではないかという指摘がときどきあります。・・・まあそう思うのは無理ないのですが、基本的には、処理系が起動したときにメモリに読み込んで、処理系が終了した時にディスクに書き込むような動作を考えています。だからディスクアクセスはたまにしかありません。メモリに収まらないほどの巨大変数はどうするのさ、ってことになるわけですが、そういうのはやっぱり仮想記憶的なことをやるしか・・・ないですよね。そういうことまでやるようになったら、起動時に読むのはやらなくて、最初のアクセスがあった時に読む、みたいな方式になると思います。 --しかし仮想記憶って・・・つまりスワップですよね。うわー、ますますOSっぽくなってきました!! -(3)に関して: --たとえばPythonプログラムはWindowsでもLinuxでもラズベリーパイでも同じように動いてくれるので、互換性を提供できているわけです。同じようなことをEssenでも目指しているだけです。この点に関しては特により優れた機能とかはないです。 -Essenがタスクスケジューリングをして、ファイルシステムの代わりになるものも提供して、互換性レイヤも提供するとなれば、もはやEssenはOSといってもいいかもと思いませんか?というかEssenの下のOSってどんな仕事が残っているのか?・・・シングルタスクで良くて、ファイルシステムもものすごく簡素なものだけで十分で・・・。 * こめんと欄 -それぞれのアーキテクチャ用に最低限の機能を持つOSを作って、あとは全部Essenにお任せ的なことが出来るたらすごそうですね! -- ''sksat'' SIZE(10){2016-12-15 (木) 16:55:10} -sksatさん、ありがとう! そういうのを目指してがんばります!! -- [[K]] SIZE(10){2017-06-05 (月) 14:39:48} #comment
タイムスタンプを変更しない
* 2016年12月 -(by [[K]], 2016.12.09) ** 2016年12月09日(金) #00 Essenやりたい -アドベントカレンダじゃなくて、Essenを作りたい。 -しかしそれにしてもOSの自作ってどうしてこんなに人気があるんだろう。ハードウェアをいじるから? -EssenにはOSっぽい要素がいくつかある。 --(1) Essenはタスクスケジューリングをする --(2) Essenはファイルシステムの代わりをする(変数の内容が永続化されるから) --(3) Essenは機種依存を吸収して、異機種間での互換性を提供できる -っていうか、そもそもOSと言語処理系ってよく似ていると思う。特に私にとっては、OSなんて「アプリを実行するためのプログラム」でしかなく、言語は「プログラムを実行するためのプログラム」でしかない。アプリは機械語やバイナリで書かれていて、言語のソースコードはテキストかもしれないけど、でもそれは大した差じゃないと私は思う。 -OSも言語も、何が正しくて何が正しくないかを開発者が自由に決められる。 -(1)に関して: --Essenのタスクスケジューリングは、基本的にはプログラムが「ここで一区切り」って書いたタイミングでしか切り替わらない。また、マルチコアCPUであっても同時に2つ以上が動作することはない(そういうこともできるけど、その場合はアクセス競合をEssenは管理しない)。 --だからマルチスレッドプログラムは非常に書きやすい。まあミスして「一区切り」命令を書き忘れるといつまでもスイッチしないという問題はある。・・・これを検出しやすくするため、あるスレッドが一定時間以上(たとえば3秒間とか)ずっと「一区切り」命令を実行しないでいると、警告が表示される。 --[Q]どうしてもっと普通の(=勝手に切り替わるタイプの)マルチスレッドにしないんですか?・・・っていうか切り替わるタイミングを指示って、つまりイベントドリブンってことですよね?おいおい、いつの時代の話ですか?? --[A]マルチスレッドで競合問題が生じると、解決はかなり難しい。それは結局は意図せぬタイミングで中途半端になっているデータを読み書きしたせいであり、これを何度か経験するとマルチスレッドプログラミングが嫌になる。ロックとかも学ばねばならない。・・・しかしロック・アンロックを繰り返すくらいなら、「ここで一区切り」な命令を実行させてもいいじゃないか。ここで必ず切り替わるという保証はない。もしまだ自分の実行時間が残っていれば、一区切り命令を実行してもそのまま継続する。・・・ロックし忘れは深刻なバグの温床だけど、「一区切り」のやり忘れはマルチスレッドの切り替えがまずいだけで、発見もデバッグもとても簡単である。だからこのパラダイムでやりたい。・・・まあマルチコアCPUを活用したいとかになるとこんな方法ではダメなんだけど、それはEssenを継行した人が別のプロセスでやって、その結果をEssenで受け取らせて処理する、みたいな感じになればいいと思っている。 -(2)に関して: --変数の永続化について、全部の変数を保存じていたら遅くてたまらないのではないかという指摘がときどきあります。・・・まあそう思うのは無理ないのですが、基本的には、処理系が起動したときにメモリに読み込んで、処理系が終了した時にディスクに書き込むような動作を考えています。だからディスクアクセスはたまにしかありません。メモリに収まらないほどの巨大変数はどうするのさ、ってことになるわけですが、そういうのはやっぱり仮想記憶的なことをやるしか・・・ないですよね。そういうことまでやるようになったら、起動時に読むのはやらなくて、最初のアクセスがあった時に読む、みたいな方式になると思います。 --しかし仮想記憶って・・・つまりスワップですよね。うわー、ますますOSっぽくなってきました!! -(3)に関して: --たとえばPythonプログラムはWindowsでもLinuxでもラズベリーパイでも同じように動いてくれるので、互換性を提供できているわけです。同じようなことをEssenでも目指しているだけです。この点に関しては特により優れた機能とかはないです。 -Essenがタスクスケジューリングをして、ファイルシステムの代わりになるものも提供して、互換性レイヤも提供するとなれば、もはやEssenはOSといってもいいかもと思いませんか?というかEssenの下のOSってどんな仕事が残っているのか?・・・シングルタスクで良くて、ファイルシステムもものすごく簡素なものだけで十分で・・・。 * こめんと欄 -それぞれのアーキテクチャ用に最低限の機能を持つOSを作って、あとは全部Essenにお任せ的なことが出来るたらすごそうですね! -- ''sksat'' SIZE(10){2016-12-15 (木) 16:55:10} -sksatさん、ありがとう! そういうのを目指してがんばります!! -- [[K]] SIZE(10){2017-06-05 (月) 14:39:48} #comment
テキスト整形のルールを表示する