page0103
の編集
http://osecpu.osask.jp/wiki/?page0103
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
BracketName
FormattingRules
FrontPage
Fulyn
Fulyn-v2
Fulyn_Samples
Help
InterWiki
InterWikiName
InterWikiSandBox
K
KOR_PIT8254
KWVM.NET
Liva
MANA
MenuBar
OSECPU_FPGA
PG_MANA
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
WikiEngines
WikiName
WikiWikiWeb
YukiWiki
hikalium
hikarupsp
hikarupsp_ELCHNOS
hikarupsp_ELCHNOS_IDE
hikarupsp_FrontEndCode
hikarupsp_WebCPU-VM
hikarupsp_WebCPU-VM_internal
hikarupsp_study_hh4
impressions
impressions0000
jpag0000
jpag0001
jpag0002
jpag0003
jpag0004
jpag0005
lambdalice
mandel59
members
memo0000
memo0001
memo0002
memo0003
memo0004
memo0005
memo0006
memo0007
memo0008
memo0009
memo0010
osask
osecpu4android
page0000
page0001
page0002
page0003
page0004
page0005
page0006
page0007
page0008
page0009
page0010
page0011
page0012
page0013
page0014
page0015
page0016
page0017
page0018
page0019
page0020
page0021
page0022
page0023
page0024
page0025
page0026
page0027
page0028
page0029
page0030
page0031
page0032
page0033
page0034
page0035
page0036
page0037
page0038
page0039
page0040
page0041
page0042
page0043
page0044
page0045
page0046
page0047
page0048
page0049
page0050
page0051
page0052
page0053
page0054
page0055
page0056
page0057
page0058
page0059
page0060
page0061
page0062
page0063
page0064
page0065
page0066
page0067
page0068
page0069
page0070
page0071
page0072
page0073
page0074
page0075
page0076
page0077
page0078
page0079
page0080
page0081
page0082
page0083
page0084
page0085
page0086
page0087
page0088
page0089
page0090
page0091
page0092
page0093
page0094
page0095
page0096
page0097
page0098
page0099
page0100
page0101
page0102
page0103
page0104
page0105
page0106
page0107
page0108
page0109
pagenames
populars
seccamp2013
seccamp2014
seccamp2017
ttwilb
ttwilb-asmi
yao
* 続サイズ対決 -(by [[K]], 2014.07.29) ** (0) -かつて[[K]]は、サイズ対決と称して、同じ内容のアプリをさまざまなOS向けに書き直した場合の最小サイズの比較をやっていました。 -あれから月日もたったので、もう一度やろうと思います。 ~ -なお、MS-DOSのCOMファイルのようにシグネチャを含まない実行ファイルはペナルティとして2バイトを加算します。 --シグネチャが1バイトの場合は、1バイトのペナルティです。 --このルールは、私たちがシグネチャを削って判定にしくくなった実行ファイルの流行を望んでいないためです。 ~ -おことわり: --そもそもこんな小規模なアプリでは実際のユースケースを反映していないという指摘は十分すぎるほど説得力があります。しかし規模が大きくなればなるほど、作り比べるのが大変になります。ですからまずこの辺りから始めるのは、十分に合理的であると[[K]]は考えます。 -備考: --青字はOSASK計画以外での世界最高記録です。 ** (1) hello, world対決 -画面に「hello, world\n」を出力すること。それだけです。 --末尾に!は入れません。これはK&R(有名なC言語の教科書)のサンプルに由来します。 --GUIで表示するのなら、改行を出力しなくても構いません。 |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''14バイト''};|app0110, osecpu125d以降| |osecpu-rev1|RIGHT:&color(#f00){''14バイト''};|app0091| |第二世代OSASK|RIGHT:16バイト|| |MS-DOS|RIGHT:&color(#00f){''24バイト''};|(シグネチャ補正前は22バイト)| |Linux/x86|RIGHT:57バイト|http://d.hatena.ne.jp/kikx/20061111 から!の分を引いた| |Java|RIGHT:336バイト|| ** (2) chars対決 -画面にキャラクターコード0x20から0x7e(印字可能なASCIIキャラクタのすべて)と改行を出力するという課題です。順序は逆順でも構いません。 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''7バイト''};|app0109, osecpu125d以降| |osecpu-rev1|RIGHT:8バイト|app0036| |CLE on OSZ|RIGHT:&color(#00f){''8バイト''};|http://nerry.hatenablog.com/entry/2014/06/19/005735| |第二世代OSASK|RIGHT:13バイト|| |COM64plus|RIGHT:14バイト|| |MS-DOS|RIGHT:19バイト|(シグネチャ補正前は17バイト)| |Java|RIGHT:352バイト|| ** (3) hexdump対決 -指定されたファイルの16進数ダンプを画面に表示します。 --以下のフォーマットを再現してください。 offset +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F 0123456789ABCDEF --------------------------------------------------------------------------- 00000000 05 E2 AE 3A 0C 46 4B B3 DA 41 D8 10 95 A0 53 51 ...:.FK..A....SQ 00000010 11 72 C0 75 10 77 71 79 C3 5B 75 AC 38 1B FA 4A .r.u.wqy.[u.8..J 00000020 BB B8 BC 46 46 8F 5B 48 81 01 43 02 46 B8 88 6B ...FF.[H..C.F..k 00000030 94 00 B4 88 10 3A 50 09 70 11 A5 08 74 53 40 .....:P.p...tS@ |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''104バイト''};|app0129, osecpu125d以降| |第二世代OSASK|RIGHT:168バイト|hexdump| ** (4) グラデーション対決 -画面の256x256ピクセルの領域に、それぞれ違う色で点を描画します。32Kカラーしかサポートできない場合に配慮して、同じ色の点が2つまでならあってもよいとします。3つ以上あったら課題を満たしていません。 --したがって32K未満のカラーモードしか持たないOSは、この課題に参加できません。 --上記の条件を満たしていれば、グラデーションになっていなくてもOKです。 ~ http://osecpu.osask.jp/download/app0124a.png |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''6バイト''};|app0124, osecpu124d以降| |osecpu-rev1|RIGHT:12バイト|app0092| ** (5) bball対決 -定番の以下の画像を描画します。むやみに拡大縮小してはいけませんが、1ピクセル程度の誤差は許容します。色はこの配色ではなくとも構いませんが、色数を減らしてはいけませんし、線が重なるところはどちらが先に描画しても結果が同じになるように、OR演算でやってください。 --OR演算で描画できない場合は、この課題を満たしていないと判断します。・・・ただし描画順序を工夫して重なり部分の色に一貫性があるなら、例外的に課題を満たしているとします。 ~ http://osecpu.osask.jp/download/bball.png |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''63バイト''};|app0103, osecpu122d以降| |osecpu-rev1|RIGHT:71バイト|app0023| |MS-DOS/PC-9801|RIGHT:&color(#00f){''114バイト''};|(シグネチャ補正をしたかどうか不明)| |第一世代OSASK|RIGHT:186バイト|| ** (6) コルモゴロフ複雑性対決 -Wikipediaには「コルモゴロフ複雑性」というページがあり、そこにマンデルブロ集合の画像があります。 --http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%AB%E3%83%A2%E3%82%B4%E3%83%AD%E3%83%95%E8%A4%87%E9%9B%91%E6%80%A7 -その画像にはキャプションがあり、以下のように書かれています。 --この画像はフラクタル図形であるマンデルブロ集合の一部である。このJPEGファイルのサイズは17KB以上(約140,000ビット)ある。ところが、これと同じファイルは140,000ビットよりも遥かに小さいコンピュータ・プログラムによって作成することが出来る。従って、このJPEGファイルのコルモゴロフ複雑性は140,000よりも遥かに小さい。 -「遥かに小さい」って、なんか逃げた表現ですよね。はっきりと○○バイトで書けるって言い切ってしまえたら、この説明はもっとすっきりすると思いませんか? -それならば、この画像に十分に近い画像を何バイトのプログラムで書けるのかを競おうではないか、というわけです。 ~ -解像度は1024x768です。色数は24ビットカラーかそれ以上です。 ~ http://osecpu.osask.jp/download/app0125a.png |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''88バイト''};|app0125, osecpu124d以降| ~ -画質を十分に上げるために、4x4=16倍サンプル以上のオーバーサンプリングをするべきだと感じます。その方がずっと目標画像に近いです。 ~ http://osecpu.osask.jp/download/app0126a.png |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''111バイト''};|app0126, osecpu124d以降| ** (7) マンデルブロ集合対決 -上記(6)の対決は要求スペックが高すぎるかもしれないので、もっと簡単なマンデルブロ集合画像の表示で競います。これは640x480の二値画像です。 ~ http://osecpu.osask.jp/download/app0127a.png |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''49バイト''};|app0127, osecpu124d以降| ** (8) invader対決 -OSASKでは定番のインベーダゲームでの比較です。 ~ http://osecpu.osask.jp/download/invader.png |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''430バイト''};|app0107, osecpu125d以降| |osecpu-rev1|RIGHT:505バイト|| |MSX-DOS|RIGHT:&color(#00f){''985バイト''};|ASXXXを使用| |第一世代OSASK|RIGHT:1108バイト|| |TownsOS|RIGHT:1241バイト|| |はりぼてOS|RIGHT:1509バイト|| |win32(Win9X限定)|RIGHT:2192バイト|| |win32|RIGHT:2560バイト|| ** (9) 考察みたいなもの -はりぼてOS、第一世代OSASK、第二世代OSASK、OSECPU-VMを簡単にまとめました。 |OS/VM|APIのタイプ|一般命令コードのタイプ|開発年| |はりぼてOS|レジスタAPI|x86|(教材)| |第一世代OSASK|32ビットパケットAPI|x86|2000-2005| |第二世代OSASK|hh4パケットAPI|x86|2008-2009| |OSECPU-VM(rev1)|hh4パケットAPI|osecpu-hh4|2013| |OSECPU-VM(rev2)|hh4パケットAPI|osecpu-hh4|2014-| -傾向としてはhh4化が進めば進むほどサイズは改善するようです。 * こめんと欄 #comment
タイムスタンプを変更しない
* 続サイズ対決 -(by [[K]], 2014.07.29) ** (0) -かつて[[K]]は、サイズ対決と称して、同じ内容のアプリをさまざまなOS向けに書き直した場合の最小サイズの比較をやっていました。 -あれから月日もたったので、もう一度やろうと思います。 ~ -なお、MS-DOSのCOMファイルのようにシグネチャを含まない実行ファイルはペナルティとして2バイトを加算します。 --シグネチャが1バイトの場合は、1バイトのペナルティです。 --このルールは、私たちがシグネチャを削って判定にしくくなった実行ファイルの流行を望んでいないためです。 ~ -おことわり: --そもそもこんな小規模なアプリでは実際のユースケースを反映していないという指摘は十分すぎるほど説得力があります。しかし規模が大きくなればなるほど、作り比べるのが大変になります。ですからまずこの辺りから始めるのは、十分に合理的であると[[K]]は考えます。 -備考: --青字はOSASK計画以外での世界最高記録です。 ** (1) hello, world対決 -画面に「hello, world\n」を出力すること。それだけです。 --末尾に!は入れません。これはK&R(有名なC言語の教科書)のサンプルに由来します。 --GUIで表示するのなら、改行を出力しなくても構いません。 |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''14バイト''};|app0110, osecpu125d以降| |osecpu-rev1|RIGHT:&color(#f00){''14バイト''};|app0091| |第二世代OSASK|RIGHT:16バイト|| |MS-DOS|RIGHT:&color(#00f){''24バイト''};|(シグネチャ補正前は22バイト)| |Linux/x86|RIGHT:57バイト|http://d.hatena.ne.jp/kikx/20061111 から!の分を引いた| |Java|RIGHT:336バイト|| ** (2) chars対決 -画面にキャラクターコード0x20から0x7e(印字可能なASCIIキャラクタのすべて)と改行を出力するという課題です。順序は逆順でも構いません。 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''7バイト''};|app0109, osecpu125d以降| |osecpu-rev1|RIGHT:8バイト|app0036| |CLE on OSZ|RIGHT:&color(#00f){''8バイト''};|http://nerry.hatenablog.com/entry/2014/06/19/005735| |第二世代OSASK|RIGHT:13バイト|| |COM64plus|RIGHT:14バイト|| |MS-DOS|RIGHT:19バイト|(シグネチャ補正前は17バイト)| |Java|RIGHT:352バイト|| ** (3) hexdump対決 -指定されたファイルの16進数ダンプを画面に表示します。 --以下のフォーマットを再現してください。 offset +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F 0123456789ABCDEF --------------------------------------------------------------------------- 00000000 05 E2 AE 3A 0C 46 4B B3 DA 41 D8 10 95 A0 53 51 ...:.FK..A....SQ 00000010 11 72 C0 75 10 77 71 79 C3 5B 75 AC 38 1B FA 4A .r.u.wqy.[u.8..J 00000020 BB B8 BC 46 46 8F 5B 48 81 01 43 02 46 B8 88 6B ...FF.[H..C.F..k 00000030 94 00 B4 88 10 3A 50 09 70 11 A5 08 74 53 40 .....:P.p...tS@ |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''104バイト''};|app0129, osecpu125d以降| |第二世代OSASK|RIGHT:168バイト|hexdump| ** (4) グラデーション対決 -画面の256x256ピクセルの領域に、それぞれ違う色で点を描画します。32Kカラーしかサポートできない場合に配慮して、同じ色の点が2つまでならあってもよいとします。3つ以上あったら課題を満たしていません。 --したがって32K未満のカラーモードしか持たないOSは、この課題に参加できません。 --上記の条件を満たしていれば、グラデーションになっていなくてもOKです。 ~ http://osecpu.osask.jp/download/app0124a.png |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''6バイト''};|app0124, osecpu124d以降| |osecpu-rev1|RIGHT:12バイト|app0092| ** (5) bball対決 -定番の以下の画像を描画します。むやみに拡大縮小してはいけませんが、1ピクセル程度の誤差は許容します。色はこの配色ではなくとも構いませんが、色数を減らしてはいけませんし、線が重なるところはどちらが先に描画しても結果が同じになるように、OR演算でやってください。 --OR演算で描画できない場合は、この課題を満たしていないと判断します。・・・ただし描画順序を工夫して重なり部分の色に一貫性があるなら、例外的に課題を満たしているとします。 ~ http://osecpu.osask.jp/download/bball.png |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''63バイト''};|app0103, osecpu122d以降| |osecpu-rev1|RIGHT:71バイト|app0023| |MS-DOS/PC-9801|RIGHT:&color(#00f){''114バイト''};|(シグネチャ補正をしたかどうか不明)| |第一世代OSASK|RIGHT:186バイト|| ** (6) コルモゴロフ複雑性対決 -Wikipediaには「コルモゴロフ複雑性」というページがあり、そこにマンデルブロ集合の画像があります。 --http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%AB%E3%83%A2%E3%82%B4%E3%83%AD%E3%83%95%E8%A4%87%E9%9B%91%E6%80%A7 -その画像にはキャプションがあり、以下のように書かれています。 --この画像はフラクタル図形であるマンデルブロ集合の一部である。このJPEGファイルのサイズは17KB以上(約140,000ビット)ある。ところが、これと同じファイルは140,000ビットよりも遥かに小さいコンピュータ・プログラムによって作成することが出来る。従って、このJPEGファイルのコルモゴロフ複雑性は140,000よりも遥かに小さい。 -「遥かに小さい」って、なんか逃げた表現ですよね。はっきりと○○バイトで書けるって言い切ってしまえたら、この説明はもっとすっきりすると思いませんか? -それならば、この画像に十分に近い画像を何バイトのプログラムで書けるのかを競おうではないか、というわけです。 ~ -解像度は1024x768です。色数は24ビットカラーかそれ以上です。 ~ http://osecpu.osask.jp/download/app0125a.png |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''88バイト''};|app0125, osecpu124d以降| ~ -画質を十分に上げるために、4x4=16倍サンプル以上のオーバーサンプリングをするべきだと感じます。その方がずっと目標画像に近いです。 ~ http://osecpu.osask.jp/download/app0126a.png |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''111バイト''};|app0126, osecpu124d以降| ** (7) マンデルブロ集合対決 -上記(6)の対決は要求スペックが高すぎるかもしれないので、もっと簡単なマンデルブロ集合画像の表示で競います。これは640x480の二値画像です。 ~ http://osecpu.osask.jp/download/app0127a.png |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''49バイト''};|app0127, osecpu124d以降| ** (8) invader対決 -OSASKでは定番のインベーダゲームでの比較です。 ~ http://osecpu.osask.jp/download/invader.png |OS/VM|サイズ|備考| |''osecpu-rev2''|RIGHT:&color(#f00){''430バイト''};|app0107, osecpu125d以降| |osecpu-rev1|RIGHT:505バイト|| |MSX-DOS|RIGHT:&color(#00f){''985バイト''};|ASXXXを使用| |第一世代OSASK|RIGHT:1108バイト|| |TownsOS|RIGHT:1241バイト|| |はりぼてOS|RIGHT:1509バイト|| |win32(Win9X限定)|RIGHT:2192バイト|| |win32|RIGHT:2560バイト|| ** (9) 考察みたいなもの -はりぼてOS、第一世代OSASK、第二世代OSASK、OSECPU-VMを簡単にまとめました。 |OS/VM|APIのタイプ|一般命令コードのタイプ|開発年| |はりぼてOS|レジスタAPI|x86|(教材)| |第一世代OSASK|32ビットパケットAPI|x86|2000-2005| |第二世代OSASK|hh4パケットAPI|x86|2008-2009| |OSECPU-VM(rev1)|hh4パケットAPI|osecpu-hh4|2013| |OSECPU-VM(rev2)|hh4パケットAPI|osecpu-hh4|2014-| -傾向としてはhh4化が進めば進むほどサイズは改善するようです。 * こめんと欄 #comment
テキスト整形のルールを表示する