osecpu_0002
の編集
https://k.osask.jp/klog/?osecpu_0002
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
2012_0001
2013_0001
2013_0002
2013_0003
2014_0001
2015_0001
2016_07
2016_08
2016_09
2016_10
2016_11
2017_01
2017_02
2017_03
2017_04
2017_05
2018_01
2019_01
BracketName
FormattingRules
FrontPage
Help
InterWiki
InterWikiName
InterWikiSandBox
K
KH_SARC_00
KH_dha8
MenuBar
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
VC_install
WikiEngines
WikiName
WikiWikiWeb
YukiWiki
fdpl_memo0001
fdpl_memo0002
fdpl_memo0003
fdpl_memo0004
fdpl_memo0005
fdpl_memo0006
fdpl_memo0007
fdpl_memo0008
fdpl_memo0009
fdpl_memo0010
gg02_0004
gg02_0005
gg02_0006
gg02_0007
gg02_0008
gg02_0009
https
impressions
memo0001
memo0002
oisix01
osaskology
osaskology0
osecpu_0001
osecpu_0002
p20200229a
p20200303a
p20200310a
p20200321a
p20200401a
p20200730a
p20201230a
p20220628a
p20220701a
populars
prog_0001
prog_0002
prog_0003
prog_0004
prog_0005
* OSECPUに関するメモ(番外版) #2 -(by K, 2013.05.28) ** 機能密度追及に関するメモ -(0) このメモをOSECPUのサイトに書かない最大の理由は、OSECPU-wikiが機能密度の話題でいっぱいになるのが少々申し訳ないため。 -(1) ver.0.40をリリースしてから思いついたこと。 --まず、charsは現在9バイトだが、実はこれは8.5バイトで書く方法もある。つまりもう少しで8バイト化が可能だ。どうにかならないだろうかと考えること1時間弱。実はcharsの9バイト目は00なのだ。それなら実行ファイルを解釈する際には、00を数個付与してから解釈するようにしたらどうだろうか。実はそのようにしても他の実行ファイルには何の影響もない。というか内部では数バージョン前からそうしている(番兵にしている)。よし採用。 --次にhelloだけど、実はこれも15.5バイトで書ける。そしてOSASK文字列という7bitエンコードと8bitエンコードの中間みたいなものはやめて、純粋な7bitエンコードに切り替えることができれば、これも15.0バイト化が可能なはずだ。よしこれもやってみるか。 -(2) なんか僕の場合、いきなり最高の設計には到達できなくて、まず自分の持っているアイデアを全部入れたものを作ってみて、それをしばらく使っているとやっと改良案が出てくる。・・・ということは、出し惜しみなく作るしかない。 -(3) charsをちょっと考えてみる。現在8バイトだけど、単純に考えれば、0x20という開始値と0x7fという終了値は必要で、まあこれがそれぞれ1バイトだとしよう。そして2バイトのシグネチャがある。そうするとそれだけで4バイトは必要で、制御のために使っているのは4バイトだということになる。なるほど。 -(4) アセンブラ短歌という遊びがある。31バイトでプログラムを書くのだが、さらに制約があってそれは57577のところで命令を区切らなければいけない。またがってはいけないのだ。非常に文化的で有意義な遊びである(笑)。ちなみにシグネチャやヘッダは31バイト内に含めなくてよい。 --http://kozos.jp/documents/ の 第2回APASEC+第2期サイボウズ・ラボユース合同勉強会(2013/03/29) --のところによい資料がある --このアセンブラ短歌にOSECPUで挑戦したらどうなるのかということを少し考えてみた。すると、3+5+3+5+6=22バイトじゃないかなということになった。OSECPU以外のCPUではせいぜい13バイト程度だったことを思えば、これは圧倒的に強い。575であるアセンブラ川柳でさえ3+5+4=12バイトまでいけるので、もはやハンデとして川柳にしてやらなければいけないかなと思うレベルだ。 --また7bitエンコードモードにすればメッセージの難読化も同時に実現できるので「アセンブラかるた」の実現も容易だと思う。 --余談ではあるが、アセンブラ短歌は本当は機械語短歌だよなあ、と思った。 -(5) putConstStringのメモ: --510(len)(UINT8): lenは符号なしhh4 ---(1...6 → +2), (7...63 → +2.5), (64...511 → +3) ---OSASK文字列を使えば、8文字を9.5バイトで出力できる。以降8文字ごとに-1バイト。 --513(UINT8)(00): ---(1... → +2.5) ---末尾: (1... → +1.5) ---OSASK文字列を使えば、8文字を9.5バイトで出力できる。以降8文字ごとに-1バイト。 --515x(UINT7): xはlen-4で、0~F ---(4...7 → +1.5), (8...11 → +1), (12...15 → +0.5) --516(UINT7)(00) ---(1...2 → +2.5), (3...6 → +2), (7...10 → +1.5), (11...14 → +1) ---末尾:
タイムスタンプを変更しない
* OSECPUに関するメモ(番外版) #2 -(by K, 2013.05.28) ** 機能密度追及に関するメモ -(0) このメモをOSECPUのサイトに書かない最大の理由は、OSECPU-wikiが機能密度の話題でいっぱいになるのが少々申し訳ないため。 -(1) ver.0.40をリリースしてから思いついたこと。 --まず、charsは現在9バイトだが、実はこれは8.5バイトで書く方法もある。つまりもう少しで8バイト化が可能だ。どうにかならないだろうかと考えること1時間弱。実はcharsの9バイト目は00なのだ。それなら実行ファイルを解釈する際には、00を数個付与してから解釈するようにしたらどうだろうか。実はそのようにしても他の実行ファイルには何の影響もない。というか内部では数バージョン前からそうしている(番兵にしている)。よし採用。 --次にhelloだけど、実はこれも15.5バイトで書ける。そしてOSASK文字列という7bitエンコードと8bitエンコードの中間みたいなものはやめて、純粋な7bitエンコードに切り替えることができれば、これも15.0バイト化が可能なはずだ。よしこれもやってみるか。 -(2) なんか僕の場合、いきなり最高の設計には到達できなくて、まず自分の持っているアイデアを全部入れたものを作ってみて、それをしばらく使っているとやっと改良案が出てくる。・・・ということは、出し惜しみなく作るしかない。 -(3) charsをちょっと考えてみる。現在8バイトだけど、単純に考えれば、0x20という開始値と0x7fという終了値は必要で、まあこれがそれぞれ1バイトだとしよう。そして2バイトのシグネチャがある。そうするとそれだけで4バイトは必要で、制御のために使っているのは4バイトだということになる。なるほど。 -(4) アセンブラ短歌という遊びがある。31バイトでプログラムを書くのだが、さらに制約があってそれは57577のところで命令を区切らなければいけない。またがってはいけないのだ。非常に文化的で有意義な遊びである(笑)。ちなみにシグネチャやヘッダは31バイト内に含めなくてよい。 --http://kozos.jp/documents/ の 第2回APASEC+第2期サイボウズ・ラボユース合同勉強会(2013/03/29) --のところによい資料がある --このアセンブラ短歌にOSECPUで挑戦したらどうなるのかということを少し考えてみた。すると、3+5+3+5+6=22バイトじゃないかなということになった。OSECPU以外のCPUではせいぜい13バイト程度だったことを思えば、これは圧倒的に強い。575であるアセンブラ川柳でさえ3+5+4=12バイトまでいけるので、もはやハンデとして川柳にしてやらなければいけないかなと思うレベルだ。 --また7bitエンコードモードにすればメッセージの難読化も同時に実現できるので「アセンブラかるた」の実現も容易だと思う。 --余談ではあるが、アセンブラ短歌は本当は機械語短歌だよなあ、と思った。 -(5) putConstStringのメモ: --510(len)(UINT8): lenは符号なしhh4 ---(1...6 → +2), (7...63 → +2.5), (64...511 → +3) ---OSASK文字列を使えば、8文字を9.5バイトで出力できる。以降8文字ごとに-1バイト。 --513(UINT8)(00): ---(1... → +2.5) ---末尾: (1... → +1.5) ---OSASK文字列を使えば、8文字を9.5バイトで出力できる。以降8文字ごとに-1バイト。 --515x(UINT7): xはlen-4で、0~F ---(4...7 → +1.5), (8...11 → +1), (12...15 → +0.5) --516(UINT7)(00) ---(1...2 → +2.5), (3...6 → +2), (7...10 → +1.5), (11...14 → +1) ---末尾:
テキスト整形のルールを表示する