hikarupsp
の編集
http://osecpu.osask.jp/wiki/?hikarupsp
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
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
*自己紹介 -名前:hikarupsp -OsaskWiki内のページ --http://osask.net/w/520.html -はりぼてOSからKさんの世界に引き込まれた。 -CHNOSProjectという自作OSのプロジェクトを(今のところ一人で)進めている。 --http://chnosproject.sourceforge.jp/wiki147u/index.php?FrontPage -最近は人工知能を研究しようとしていて、OS自作の方は進まなくなってしまった。 --人工知能を研究している理由は、膨大な情報を分かりやすい形に変換することができれば、人類はまだ進化の余地があると考えたから。 --進化に伴って知るべき情報は増えてゆくけれど、それにかかる学習の時間は以前より増えてしまう。 --そうすると、やがては人類は、「すでに分かりきったこと」を学習するだけで寿命がつきてしまうのではないか?と思った。 --その意味では、Kさんの考える「機能密度」という概念は、人類の処理能力という有限のリソースを十分に活用するためにも使えるのかもしれない。 -学校が忙しくて、人工知能すら進まない…。 --我々に最も必要なリソースは時間だ。 *OSECPU関連計画 -WebCPU-VM --OSECPU-VMのJavaScript実装(動作する状態・APIの大部分は未実装) -OSEC --OSECPU-VMのためのC言語風言語(一応動作する) --最初はJavaScriptで作って、その後OSECを使ってOSECPUで動くOSECコンパイラを作ればいいと思う(笑)。 -HeavyOSECPU --OSECPU学習用ソース --http://sourceforge.jp/projects/heavyosecpu/ --[[ttwilb]]さんと共同開発 *OSECPUに欲しい機能 あったらさらにOSECPUの発展性が上がりそうだと個人的に思う機能(そのうち派生版OSECPUを作ると思います) -ポインタタイプにUTF-8が欲しい --テキストの扱いを簡素化できるし、既存のUTF-8データを簡単に利用できる。 --サイズを追求する、という点ではボトルネックになるかも --そのメモリを読み書きすると、ポインタを一つ進めると文字を一つ進めたことになり、取得・設定できる値はUnicodeの値そのもの。 --実は人工知能をOSECPUで実装したい。 ---だけど日本語テキストを扱える環境がまだそこまでなってないから… -UUIDを簡単に使える機能 --UUIDレジスタ、それに関する代入命令、UUIDラベル、UUIDジャンプ、UUID生成命令が欲しい --異なるアプリやライブラリ間で関数呼び出しをするとき、SINT32のラベル番号のみでは衝突が容易に発生しそう ---UUIDを利用したラベルもあれば、確実に飛び先の関数を特定できる --アプリごとにUUIDを割り振って、そのUUIDとSINT32のラベル番号を指定しても飛べるようにする。 ---セグメンテーションみたいなもの? --同じ機能を持つ関数には同じ「機能UUID」を振って、さらに「固有UUID」を振れば、ライブラリ関数のバージョンを取っ替え引っ替えするのが簡単になる? --でも結局はサイズが大きくなる問題が… ---だけどコードサイズに必ずしも比例しない。 --OS側がUUID対応表を持てば、デフォルトではそこに指定されているUUIDを参照するから、ライブラリ関数をコールする場所が無駄に肥大することはないと思う。 ---その対応表にもUUIDをつけて… *OSECPU Tips + Macでamakeの代わりをするには "make appname.ose" *OSECPU Bugs + @064a ++app0023(bball)をコンパイルしたところ、 db2bin: error: LMEMPP(R00, 0x03, P01); となってコンパイルできない。 ++osecpu_ask.hにLMEM0PPのところを真似して #define LMEMPP(reg, typ, preg) LMEM(reg, typ, preg, 0); PADDI(preg, typ, preg, 1) と書いたところコンパイルも通り、正しく実行できた。これはアプリソースとヘッダファイルどちらを直すべきなんだろう… *amake.sh %%amakeはバッチファイルなのでMacintoshでは動かない…。%% こんなことしなくてもmake appname.ose で生成できるじゃん…もっとよく調べるべきだった。 #!/bin/sh # gcc実行コマンドを設定 cc=gcc ${cc} -x c -E -o a_0ask.txt ${1}.ask ./osectols tool:aska in:a_0ask.txt out:a_1oas_${1}.txt ${cc} -x c ${2} ${3} ${4} ${5} ${6} ${7} ${8} ${9} -E -P -o a_2cas.txt a_1oas_${1}.txt ./osectols tool:lbstk in:a_2cas.txt out:a_3cas.txt lst:a_3lbl.txt ./osectols tool:db2bin in:a_3cas.txt out:a_4ose.ose ./osectols tool:appack in:a_4ose.ose out:${1}.ose -ポイント gccはファイル形式を拡張子で判断してしまうので、"-x c"オプションで、言語解釈をCだよと教えてあげないとプリプロセッサすら通してくれない。"linker input file unused because linking not done"とか言われる。 *osecpuをMacOSX Xcodeで! HariboteOSでも同じことをしているので。 -osecpu.cとtek.cを追加。 -BuildSettingsでPreprocessorMacroにシンボル定義"JITC_OSNUM=0x0002"を追加 -FileTypeはCSource -BuildPhase.LinkBinaryWithLibrariesにCocoa.frameworkを追加。 %%現状:Illegal instruction: 4で落ちます…。%% -%%配布されている状態で、説明の通りにコンパイルを行っても、落ちます…。%% Xcodeなんて使わなくても、forMacOSフォルダ内のMakefileをソースと同じディレクトリにコピーして、 make osecpu で、きちんと動作するバイナリが生成されます。 "make"だけじゃだめだった…。 default: make osectols make osecpu をMakefileの一般生成規則の下に追加すると良いかもしれない。 *コメント -時間なんて所詮四つの次元の内の一つでしかない。 -- [[ttwilb]] SIZE(10){2013-07-09 (火) 00:55:55} -MacOS版のosecpu生成で、forMacOSディレクトリからMakefileを取り出して、それをosecpuディレクトリにコピーしてからmakeしたらうまくいきますか? -- ''K'' SIZE(10){2013-07-09 (火) 10:05:21} -あ…できました!Makefileをコピーして、"make osecpu"でosecpuバイナリが生成されるんですね…。&br; 昨日は"make"しか試していなくてosectolsしか生成されておらず、今Makefileを読んで、defaultターゲットがないのに気付きました。ありがとうございます。&br; bball(app0023.ose)もきちんと動作しました。お騒がせしてごめんなさい。 -- [[hikarupsp]] SIZE(10){2013-07-09 (火) 16:08:35} -Xcodeでうまく行かない原因もわかりました。64bitでコンパイルすると、jitfuncのあたりがずれてしまって動かないようです。32bitでコンパイルすれば問題なしでした。 -- ''hikarupsp'' SIZE(10){2013-07-09 (火) 16:23:36} -解決して何よりです。 -- ''K'' SIZE(10){2013-07-09 (火) 17:17:36} -HeavyOSECPUをcloneして少し読ませていただきました。Sourceforgeのフォーラムは無効だったので、おせっかいかもしれませんが2点こちらにコメントいたします。(1)あなたとttwilbさんとではソースコードの改行コードが違うようです。mergeのたびにconflictが発生していて、見ていて危なっかしく感じます。どちらか一方に統一してはいかがでしょうか。あるいは(どちらかがWindows環境ならば)core.autocrlfオプションを導入を検討されてはいかがでしょう? (2)PRegCopyは「*dst = *src」と実装すべきではないかと思われます。もしコメントアウトされている実装に変更してからエラーが発生するようになったとしたらこれが原因かと。もしエラーが発生するがためにコミット4d5d6faの変更をしたのだとしたらこちらの勘違いなのでこの点は無視してください。 -- [[yao]] SIZE(10){2014-03-17 (月) 10:36:48} -yaoさん、ご指摘ありがとうございます。ttwilbさんはWindowsのVisualStudio,私hikarupspはMacOSXのXCodeで開発しており、改行コードはCRLF,文字コードはUTF-8(BOMなし)に統一しているつもりなのですが、どうしても完全には同じにならないようです。何か良い解決策があれば教えていただけたらうれしいです。 -- [[hikarupsp]] SIZE(10){2014-03-17 (月) 17:23:58} -PRegCopyの件ですが、この関数内に書かれているコメントアウトのコードは確かに間違っていました。yaoさんの言われた通りに元の実装ではなっていた(別関数ではなく直接書かれていた)のですが、MacOSX環境下ではこの方法ではMOVDQA命令が発行され、スタックのアライメントが合わず、アライメントエラーで落ちています。コメントについては、コミット7abdd91で修正させていただきました。ありがとうございます。 -- [[hikarupsp]] SIZE(10){2014-03-17 (月) 17:33:14} -[[yao]]さん、重要なご指摘ありがとうございました。我々開発者としても、コミットする環境の違いによってdiffがうまく動かないなど、様々な弊害を抱えておりました(困るのは開発者だけではないのですね)。アドバイス頂いたことを参考に改善に取り組みたいと思います。 -- [[ttwilb]] SIZE(10){2014-03-17 (月) 17:50:24} -yaoさんのご指摘をふまえ、core.autocrlfの再設定を行いました。diffも正常に動作しているようなので、このまま様子を見たいと思います。今後も私の不勉強ゆえの問題があれば、ご指摘いただければ幸いです。よろしくお願いします。 -- [[ttwilb]] SIZE(10){2014-03-19 (水) 00:09:30} -pullして調べてみました。(1)エンコードはファイルを最後に編集・コミットした人の設定に変更され、改行にはhikarupspさんはCR+LFを、ttwilbさんはLFを使っているようです。文字コードはお二人ともBOM付きUTF-8でした。こちらの勘違いで、このようなケースではcore.autocrlfは意図した挙動をしません。私は使ったことがないですが、gitattributesを設定するのがよさそうに思われます。次の2点をおすすめします: (a)一度エンコードの変更だけを含むコミットを行い、その後お二人とも一度ワークツリーを作り直す、(b)コミット前にはエンコードの確認もかねてgit diff --cachedを見ておく。(2)MOVDQAという命令があったんですね。16バイト境界にないと例外になる命令を、それを保証できないメモリ領域に対して吐くというのはコンパイラのバグではないでしょうか。この問題への対応を思いつくままに列挙すると、(a)単純さ優先: MOVDQA命令への最適化を(あれば)コンパイラオプションまたはpragmaで抑制する。(b)速さ優先: 関数OsecpuMain内でstruct Regsを定義している文に、メモリの16バイト境界に配置するよう強制するよう(あれば)pragmaを書く。(c)関数PRegCopy内で構造体のメンバを一つずつ代入する代わりにmemcpyで一気にコピーする(規格に厳密に従う書き方ではなかったはずですが、CでJITコンパイラを書くのにそんなこと言っても仕方ないですし)。(d)struct Regsより15バイト大きい領域をmallocで動的確保し、16バイト境界で始まる領域を指すポインタを作って使う。といったところでしょうか。いずれの方法にしても、こういう対処をしたとコメントに残しておくほうがよいでしょう。 -- [[yao]] SIZE(10){2014-03-19 (水) 22:44:03} -うろおぼえだけどMOVDQAってたしかSSE2のあれで、たしかXMMレジスター用のMOVだったと思うけどこれってコピー元や先のメモリーの位置が16バイト境界に無いとあれなんだけど、これじゃなくてMOVDQUっての使えば16バイトになってなくても動いたような記憶。あとそうじゃなくてosecpuのドライバー側がやってるmallocWRCだかいうマルロックの中を作るときに、適当に16バイトアラインするようなマルロックで作っとけば偶然上手くいくんじゃないかなとおもいました、マルロックのかわりにposix_memalignとかで。ためしても無いのにてきとう言ってます。まちがってたらごめんなさい -- ''けめっぽ'' SIZE(10){2014-03-21 (金) 16:14:27} #comment();
タイムスタンプを変更しない
*自己紹介 -名前:hikarupsp -OsaskWiki内のページ --http://osask.net/w/520.html -はりぼてOSからKさんの世界に引き込まれた。 -CHNOSProjectという自作OSのプロジェクトを(今のところ一人で)進めている。 --http://chnosproject.sourceforge.jp/wiki147u/index.php?FrontPage -最近は人工知能を研究しようとしていて、OS自作の方は進まなくなってしまった。 --人工知能を研究している理由は、膨大な情報を分かりやすい形に変換することができれば、人類はまだ進化の余地があると考えたから。 --進化に伴って知るべき情報は増えてゆくけれど、それにかかる学習の時間は以前より増えてしまう。 --そうすると、やがては人類は、「すでに分かりきったこと」を学習するだけで寿命がつきてしまうのではないか?と思った。 --その意味では、Kさんの考える「機能密度」という概念は、人類の処理能力という有限のリソースを十分に活用するためにも使えるのかもしれない。 -学校が忙しくて、人工知能すら進まない…。 --我々に最も必要なリソースは時間だ。 *OSECPU関連計画 -WebCPU-VM --OSECPU-VMのJavaScript実装(動作する状態・APIの大部分は未実装) -OSEC --OSECPU-VMのためのC言語風言語(一応動作する) --最初はJavaScriptで作って、その後OSECを使ってOSECPUで動くOSECコンパイラを作ればいいと思う(笑)。 -HeavyOSECPU --OSECPU学習用ソース --http://sourceforge.jp/projects/heavyosecpu/ --[[ttwilb]]さんと共同開発 *OSECPUに欲しい機能 あったらさらにOSECPUの発展性が上がりそうだと個人的に思う機能(そのうち派生版OSECPUを作ると思います) -ポインタタイプにUTF-8が欲しい --テキストの扱いを簡素化できるし、既存のUTF-8データを簡単に利用できる。 --サイズを追求する、という点ではボトルネックになるかも --そのメモリを読み書きすると、ポインタを一つ進めると文字を一つ進めたことになり、取得・設定できる値はUnicodeの値そのもの。 --実は人工知能をOSECPUで実装したい。 ---だけど日本語テキストを扱える環境がまだそこまでなってないから… -UUIDを簡単に使える機能 --UUIDレジスタ、それに関する代入命令、UUIDラベル、UUIDジャンプ、UUID生成命令が欲しい --異なるアプリやライブラリ間で関数呼び出しをするとき、SINT32のラベル番号のみでは衝突が容易に発生しそう ---UUIDを利用したラベルもあれば、確実に飛び先の関数を特定できる --アプリごとにUUIDを割り振って、そのUUIDとSINT32のラベル番号を指定しても飛べるようにする。 ---セグメンテーションみたいなもの? --同じ機能を持つ関数には同じ「機能UUID」を振って、さらに「固有UUID」を振れば、ライブラリ関数のバージョンを取っ替え引っ替えするのが簡単になる? --でも結局はサイズが大きくなる問題が… ---だけどコードサイズに必ずしも比例しない。 --OS側がUUID対応表を持てば、デフォルトではそこに指定されているUUIDを参照するから、ライブラリ関数をコールする場所が無駄に肥大することはないと思う。 ---その対応表にもUUIDをつけて… *OSECPU Tips + Macでamakeの代わりをするには "make appname.ose" *OSECPU Bugs + @064a ++app0023(bball)をコンパイルしたところ、 db2bin: error: LMEMPP(R00, 0x03, P01); となってコンパイルできない。 ++osecpu_ask.hにLMEM0PPのところを真似して #define LMEMPP(reg, typ, preg) LMEM(reg, typ, preg, 0); PADDI(preg, typ, preg, 1) と書いたところコンパイルも通り、正しく実行できた。これはアプリソースとヘッダファイルどちらを直すべきなんだろう… *amake.sh %%amakeはバッチファイルなのでMacintoshでは動かない…。%% こんなことしなくてもmake appname.ose で生成できるじゃん…もっとよく調べるべきだった。 #!/bin/sh # gcc実行コマンドを設定 cc=gcc ${cc} -x c -E -o a_0ask.txt ${1}.ask ./osectols tool:aska in:a_0ask.txt out:a_1oas_${1}.txt ${cc} -x c ${2} ${3} ${4} ${5} ${6} ${7} ${8} ${9} -E -P -o a_2cas.txt a_1oas_${1}.txt ./osectols tool:lbstk in:a_2cas.txt out:a_3cas.txt lst:a_3lbl.txt ./osectols tool:db2bin in:a_3cas.txt out:a_4ose.ose ./osectols tool:appack in:a_4ose.ose out:${1}.ose -ポイント gccはファイル形式を拡張子で判断してしまうので、"-x c"オプションで、言語解釈をCだよと教えてあげないとプリプロセッサすら通してくれない。"linker input file unused because linking not done"とか言われる。 *osecpuをMacOSX Xcodeで! HariboteOSでも同じことをしているので。 -osecpu.cとtek.cを追加。 -BuildSettingsでPreprocessorMacroにシンボル定義"JITC_OSNUM=0x0002"を追加 -FileTypeはCSource -BuildPhase.LinkBinaryWithLibrariesにCocoa.frameworkを追加。 %%現状:Illegal instruction: 4で落ちます…。%% -%%配布されている状態で、説明の通りにコンパイルを行っても、落ちます…。%% Xcodeなんて使わなくても、forMacOSフォルダ内のMakefileをソースと同じディレクトリにコピーして、 make osecpu で、きちんと動作するバイナリが生成されます。 "make"だけじゃだめだった…。 default: make osectols make osecpu をMakefileの一般生成規則の下に追加すると良いかもしれない。 *コメント -時間なんて所詮四つの次元の内の一つでしかない。 -- [[ttwilb]] SIZE(10){2013-07-09 (火) 00:55:55} -MacOS版のosecpu生成で、forMacOSディレクトリからMakefileを取り出して、それをosecpuディレクトリにコピーしてからmakeしたらうまくいきますか? -- ''K'' SIZE(10){2013-07-09 (火) 10:05:21} -あ…できました!Makefileをコピーして、"make osecpu"でosecpuバイナリが生成されるんですね…。&br; 昨日は"make"しか試していなくてosectolsしか生成されておらず、今Makefileを読んで、defaultターゲットがないのに気付きました。ありがとうございます。&br; bball(app0023.ose)もきちんと動作しました。お騒がせしてごめんなさい。 -- [[hikarupsp]] SIZE(10){2013-07-09 (火) 16:08:35} -Xcodeでうまく行かない原因もわかりました。64bitでコンパイルすると、jitfuncのあたりがずれてしまって動かないようです。32bitでコンパイルすれば問題なしでした。 -- ''hikarupsp'' SIZE(10){2013-07-09 (火) 16:23:36} -解決して何よりです。 -- ''K'' SIZE(10){2013-07-09 (火) 17:17:36} -HeavyOSECPUをcloneして少し読ませていただきました。Sourceforgeのフォーラムは無効だったので、おせっかいかもしれませんが2点こちらにコメントいたします。(1)あなたとttwilbさんとではソースコードの改行コードが違うようです。mergeのたびにconflictが発生していて、見ていて危なっかしく感じます。どちらか一方に統一してはいかがでしょうか。あるいは(どちらかがWindows環境ならば)core.autocrlfオプションを導入を検討されてはいかがでしょう? (2)PRegCopyは「*dst = *src」と実装すべきではないかと思われます。もしコメントアウトされている実装に変更してからエラーが発生するようになったとしたらこれが原因かと。もしエラーが発生するがためにコミット4d5d6faの変更をしたのだとしたらこちらの勘違いなのでこの点は無視してください。 -- [[yao]] SIZE(10){2014-03-17 (月) 10:36:48} -yaoさん、ご指摘ありがとうございます。ttwilbさんはWindowsのVisualStudio,私hikarupspはMacOSXのXCodeで開発しており、改行コードはCRLF,文字コードはUTF-8(BOMなし)に統一しているつもりなのですが、どうしても完全には同じにならないようです。何か良い解決策があれば教えていただけたらうれしいです。 -- [[hikarupsp]] SIZE(10){2014-03-17 (月) 17:23:58} -PRegCopyの件ですが、この関数内に書かれているコメントアウトのコードは確かに間違っていました。yaoさんの言われた通りに元の実装ではなっていた(別関数ではなく直接書かれていた)のですが、MacOSX環境下ではこの方法ではMOVDQA命令が発行され、スタックのアライメントが合わず、アライメントエラーで落ちています。コメントについては、コミット7abdd91で修正させていただきました。ありがとうございます。 -- [[hikarupsp]] SIZE(10){2014-03-17 (月) 17:33:14} -[[yao]]さん、重要なご指摘ありがとうございました。我々開発者としても、コミットする環境の違いによってdiffがうまく動かないなど、様々な弊害を抱えておりました(困るのは開発者だけではないのですね)。アドバイス頂いたことを参考に改善に取り組みたいと思います。 -- [[ttwilb]] SIZE(10){2014-03-17 (月) 17:50:24} -yaoさんのご指摘をふまえ、core.autocrlfの再設定を行いました。diffも正常に動作しているようなので、このまま様子を見たいと思います。今後も私の不勉強ゆえの問題があれば、ご指摘いただければ幸いです。よろしくお願いします。 -- [[ttwilb]] SIZE(10){2014-03-19 (水) 00:09:30} -pullして調べてみました。(1)エンコードはファイルを最後に編集・コミットした人の設定に変更され、改行にはhikarupspさんはCR+LFを、ttwilbさんはLFを使っているようです。文字コードはお二人ともBOM付きUTF-8でした。こちらの勘違いで、このようなケースではcore.autocrlfは意図した挙動をしません。私は使ったことがないですが、gitattributesを設定するのがよさそうに思われます。次の2点をおすすめします: (a)一度エンコードの変更だけを含むコミットを行い、その後お二人とも一度ワークツリーを作り直す、(b)コミット前にはエンコードの確認もかねてgit diff --cachedを見ておく。(2)MOVDQAという命令があったんですね。16バイト境界にないと例外になる命令を、それを保証できないメモリ領域に対して吐くというのはコンパイラのバグではないでしょうか。この問題への対応を思いつくままに列挙すると、(a)単純さ優先: MOVDQA命令への最適化を(あれば)コンパイラオプションまたはpragmaで抑制する。(b)速さ優先: 関数OsecpuMain内でstruct Regsを定義している文に、メモリの16バイト境界に配置するよう強制するよう(あれば)pragmaを書く。(c)関数PRegCopy内で構造体のメンバを一つずつ代入する代わりにmemcpyで一気にコピーする(規格に厳密に従う書き方ではなかったはずですが、CでJITコンパイラを書くのにそんなこと言っても仕方ないですし)。(d)struct Regsより15バイト大きい領域をmallocで動的確保し、16バイト境界で始まる領域を指すポインタを作って使う。といったところでしょうか。いずれの方法にしても、こういう対処をしたとコメントに残しておくほうがよいでしょう。 -- [[yao]] SIZE(10){2014-03-19 (水) 22:44:03} -うろおぼえだけどMOVDQAってたしかSSE2のあれで、たしかXMMレジスター用のMOVだったと思うけどこれってコピー元や先のメモリーの位置が16バイト境界に無いとあれなんだけど、これじゃなくてMOVDQUっての使えば16バイトになってなくても動いたような記憶。あとそうじゃなくてosecpuのドライバー側がやってるmallocWRCだかいうマルロックの中を作るときに、適当に16バイトアラインするようなマルロックで作っとけば偶然上手くいくんじゃないかなとおもいました、マルロックのかわりにposix_memalignとかで。ためしても無いのにてきとう言ってます。まちがってたらごめんなさい -- ''けめっぽ'' SIZE(10){2014-03-21 (金) 16:14:27} #comment();
テキスト整形のルールを表示する