gg02_0009
の編集
https://k.osask.jp/klog/?gg02_0009
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
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と第三世代OSASKの差異のメモ -(by K, 2013.04.10) --(osask.netに書こうと思ったんだけどパスワードを忘れて新規ページが作れない。メモを見つけるまでこっちに書いておく) ** メモ -gg02でも簡易レジスタsave・restoreはある。そしてこの命令にも精度指定がある。したがって、上位のビットは復元されないことになる。 --そしてその精度は、その関数の復元精度ということになり、それ以上のビット幅で使っているレジスタについては、呼び出し側で保存、復元する必要がある。これを支援するためにuse(Rxx, 128); みたいな疑似命令を用意してもいいかもしれない。 --でもちょっと待て。そもそも上位のビットを破壊しないのであれば、復元しなくてもいいのではないか?・・・その通りだ。 --しかし上位ビットを破壊しないという保証が難しい。16bitアーキテクチャで実行して、タスクセーブして64bit環境で復元した場合、上位を壊さないような命令で実行するのか?・・・それは違うだろう。 --これはビット数に依存しないでそこそこの性能を出すという目的のための代償だと思って割り切るべきだ。 -gg02では、バックエンドもhh4にする。そうすればtinyモードとか、レギュラーモードとか、そういうことに頭を悩ませなくても済む。hh4でも固定長はできる。 -色数指定で15bitカラーをやりたい。これは0x7fffまでしか使わないので、符号付きの16bit環境と相性がいい。 -Pxxを指定するときはtypよりも前にする。OSECPUではtypを先行させて失敗だったと思う。 -enter/leave命令のフロントエンドコードは再考の余地がある。 --しかし関数展開を考えるとこれはこれでよかったのかもしれない。 -オペコードの直後は精度フィールド。余計なことで悩まないためにも、単純な数字を入れる(符号なし整数)。 -src,destの順序のほうがいいかもしれない。検討する価値はある。 - -16からがレジスタでいいのかどうかは検証の余地がある。まあでもR0Fまで入ればいいのだから、やっぱりこれでいいのかな? -グラフィックス系のAPIでmode=4で3bitカラーは失敗だった。頻度を考えればこれはmode=1でいいはず。 * こめんと欄 #comment
タイムスタンプを変更しない
* OSECPUと第三世代OSASKの差異のメモ -(by K, 2013.04.10) --(osask.netに書こうと思ったんだけどパスワードを忘れて新規ページが作れない。メモを見つけるまでこっちに書いておく) ** メモ -gg02でも簡易レジスタsave・restoreはある。そしてこの命令にも精度指定がある。したがって、上位のビットは復元されないことになる。 --そしてその精度は、その関数の復元精度ということになり、それ以上のビット幅で使っているレジスタについては、呼び出し側で保存、復元する必要がある。これを支援するためにuse(Rxx, 128); みたいな疑似命令を用意してもいいかもしれない。 --でもちょっと待て。そもそも上位のビットを破壊しないのであれば、復元しなくてもいいのではないか?・・・その通りだ。 --しかし上位ビットを破壊しないという保証が難しい。16bitアーキテクチャで実行して、タスクセーブして64bit環境で復元した場合、上位を壊さないような命令で実行するのか?・・・それは違うだろう。 --これはビット数に依存しないでそこそこの性能を出すという目的のための代償だと思って割り切るべきだ。 -gg02では、バックエンドもhh4にする。そうすればtinyモードとか、レギュラーモードとか、そういうことに頭を悩ませなくても済む。hh4でも固定長はできる。 -色数指定で15bitカラーをやりたい。これは0x7fffまでしか使わないので、符号付きの16bit環境と相性がいい。 -Pxxを指定するときはtypよりも前にする。OSECPUではtypを先行させて失敗だったと思う。 -enter/leave命令のフロントエンドコードは再考の余地がある。 --しかし関数展開を考えるとこれはこれでよかったのかもしれない。 -オペコードの直後は精度フィールド。余計なことで悩まないためにも、単純な数字を入れる(符号なし整数)。 -src,destの順序のほうがいいかもしれない。検討する価値はある。 - -16からがレジスタでいいのかどうかは検証の余地がある。まあでもR0Fまで入ればいいのだから、やっぱりこれでいいのかな? -グラフィックス系のAPIでmode=4で3bitカラーは失敗だった。頻度を考えればこれはmode=1でいいはず。 * こめんと欄 #comment
テキスト整形のルールを表示する