na2co3 [21:02]
そういえば、32bitアラインメントにするなら、これの(13)は失敗でもよくなりますね
https://gist.github.com/na2co3-ftw/39701a576636068ea70ebc5f72f6ace1

jekto_vatimeliju [22:28]
現状の私の実装だと通してますけど、一応仕様上は「4の倍数以外のアドレスは未定義」ですからねぇ
いや仕様書「アクセスした番地が4の倍数でなくともエラーは出ない。」って書いてあるやん（しまった）

na2co3 [22:29]
そう。なのでアラインメントの設定は仕様変更なのです

jekto_vatimeliju [22:31]
2017年9月26日


なるほど、これがきっかけで「アラインメントあり」に傾き始めたというわけか
…2003lkは直交性かなり高いし、

na2co3 [22:33]
まあアラ違反認めるとメモリに全加算機いるよなあ

jekto_vatimeliju [22:33]
許容（遅い）のほうがいいかもなぁ
しかも仕様変更になるというならなおさらである
メモリに全加算器要るんです？

na2co3 [22:35]
preferred alignmentという感じだ
メモリの回路詳しくないので適当ですが

jekto_vatimeliju [22:37]
アラインメント違反したときはロード命令を2回呼んでビット演算したりする、みたいな話は聞いたことがあって、そうすると全部CPUで収まりますね

na2co3 [22:37]
それ、CPUの仕事というよりコンパイラの仕事という感じがする

jekto_vatimeliju [22:38]
たしかx86-64だとCPUの仕事のはずです

na2co3 [22:38]
強い

jekto_vatimeliju [22:38]
x86-64、歴史的経緯のかたまりなので

na2co3 [22:38]
x86-64はマイクロプログラム ゴリゴリ使ってるのでそれでもいいかもですが
回路だけでやるのは死にそう
2003fの最近の流れ、アセンブラがコンパイラの仕事を一部やる感じになってきてるのでアセンブラの仕事かもしれない

jekto_vatimeliju [22:39]
アセンブラの仕事、たしかにそれはありそう

na2co3 [22:40]
2003lk、機械語と1対1に対応しないのであればアセンブリ言語ではなく低級言語では

jekto_vatimeliju [22:40]
んーでも実行時にアドレスが決まる場合はアセンブラで処理できるはずがなく
実際現世Cと現世アセンブラの中間みたいな立ち位置になりつつある
説：「アクセスした番地が4の倍数でなくともエラーは出ない」
「エラー『は』出ない」（想定した値が来るとは限らない）（処理系定義ですﾆｯｺﾘ）（ますますC化が進む） （編集済み）

na2co3 [22:41]
エラー、そもそも仕様がないので出るはずがない

jekto_vatimeliju [22:42]
それはそう
というか、ubpl（直交性の無いRISC）が2003lkからアセンブル（というよりもはやコンパイル）されている時点で、という話はある
アラインメント違反を罰さないとなると「byte読む命令が確実に（現世の）今後入るので、4の倍数の場合は32bitを読んでそれ以外ならbyteを4回読む」とでもする感じになるんですかね
遅そう

na2co3 [22:46]
llvmさんがコンパイル時に勝手にやってくれるやつだ

jekto_vatimeliju [22:47]
つよい（アドレスが実行時にしか決まりえない場合はどうするんだろ）（まあそんなコードは書くほうが悪いか）

na2co3 [22:48]
アラインメントを書くと勝手にやってくれるので、同時にその型のポインタはそれでアラインメントされてるという前提になりますね

jekto_vatimeliju [22:48]
なるほどです
「実行時に下位2bitを見て、非0なら遅い処理に移る」ってやっぱりマイクロプログラム要るんですかね？

na2co3 [22:50]
んーそれでもどうしても決まらない場合は全部byte化かも
intをvoid *にキャストされた時とか

jekto_vatimeliju [22:50]
まあ現実的にはそうするしかないでしょうね

na2co3 [22:51]
回路でできないことはないと思いますが
最大3つもオペランドあるしなあ
あまり使わない機能に専用のめんどくせえ回路作りたくねえ

jekto_vatimeliju [22:53]
たしかに
せっかくなのでこの機会に現状の懸案事項一覧まとめておくか （編集済み）
@Xarzni'ar Fixa アラインメント問題、回路屋さんとしてはどう思われます？ （編集済み）

na2co3 [22:58]
ubpl、今の実装みると32bitアラインンメントされてないとエラー吐く

jekto_vatimeliju [23:02]
ﾌﾑｰ

Nobuyuki Tokuchi [23:04]
ubplは32bit読みしか出来ないので4の倍数以外だとエラー．(今のところめんどいのでException投げてる)
それなりにシンプルにしたつもりだけど2003fと大して処理速度変わらなそうな感じで辛い

na2co3 [23:06]
ubpl、いっそRISCに振り切ってアセンブラが頑張る案

jekto_vatimeliju [23:06]
私もわりとそれを想定している
2003lk/2003fの現状
・少なくともbyteを読む命令は確実に必要
・アラインメント違反、どうしたもんかなぁ（わりと最初から許容しなきゃよかった感しか無い）（2003「lk」は許容、ubplは不許可("アセンブラ"が頑張る)、2003fは…どうなるの？、とかはアリかもな）

Nobuyuki Tokuchi [23:07]
命令数めっちゃ多いんだよなー．(エミュレータなので回路が複雑化することもないし)

Ritchan [23:08]
現世の(RISC系)マイコンだとこういう複合仕様だったりしますね
・メモリアクセスは変数の型の幅のアラインメントに合わせる
・プログラムカウンタには4の倍数のアドレスしかロードできない

Nobuyuki Tokuchi [23:08]
inj→injxx/fnx/krz*2，lat/latsna→lat/latsna+latkrz，

na2co3 [23:09]
ubpl、現状PCが128bitアラインメントみたいな感じで面白い()

jekto_vatimeliju [23:10]
今回の混乱、完全に私のせいなのでなんとか打開策を見出したい感しかない

na2co3 [23:10]
一度書いた仕様ってそんなに変えにくい感じですか

Nobuyuki Tokuchi [23:11]
そもそもubplの32bitマシンは32bit単位(「64bitになったら」は今は考えてない)じゃないといけないのでアライメント問題とかは無い．(メモリは贅沢に使用する前提) （編集済み）

jekto_vatimeliju [23:11]
たしかに今ならまだ変えられるか（変えるなら変えるでスッパリ変えると決め、いろんなところに漏れなく明記すればそれで十分ではある）

na2co3 [23:12]
現状アラインメントの仕様変更で動かなる2003lkコードは、上記のテスト13と、llvm-2003fで16bitや8bit型のロード・ストアを伴うコードをコンパイルしたものだけかと

jekto_vatimeliju [23:14]
…じゃあ変えますかね。同時に8bit/16bitのロード・ストア命令を足す

Ritchan [23:15]
アクセス幅指定の修飾子ではなく命令が増える方向ですか？

Nobuyuki Tokuchi [23:15]
1byteしか使用してなかろうがビッグエンディアンで4byte使用がubpl．
128bitアライメントは作成中にいい感じになることに気付いて意図的にしてます．

na2co3 [23:15]
(ot)悠里世界内のFAFssで同じことがあったらこう簡単に仕様変更とはいかないんだろうなあ

Nobuyuki Tokuchi [23:15]
(ot)それはそう (ubplは既に1度変えてる．) （編集済み）

jekto_vatimeliju [23:16]
「アクセス幅指定の修飾子ではなく命令が増える方向」どう名付けるかの差でしかないので
(ot)それはそう

Ritchan [23:16]
うーん

na2co3 [23:17]
現世のCPU(特にCISC)、アドレッシングモードによって機械語のオペコードも変わったりするので
オペランドで機械語を決めるかニーモニックで決めるかは表記上の差でしかないと

jekto_vatimeliju [23:18]
特に、こっちではレジスタの下位何bitかを表すレジスタ名があるわけでもないので、結局 ｀mov｀ とは書けなくて ｀movl｀ ｀movq｀ ｀movb｀ をそれぞれ名付けるしかないという
qは無いけど

na2co3 [23:18]
(そういうCPUは大抵あまり直交性がなくてア)

Ritchan [23:24]
(アドレッシングモード周りでなんか気持ち引っかかったけど、多分そんなに影響無さそう)

na2co3 [23:25]
アドレッシングモードごとの命令を全部別々に用意するLLVMの実装を見てると「アドレッシングモードなんて無かったや」みたいになってきます （編集済み）
ATArr, ATAri, ATArm, ATAmr, ATAmi, ATAmm みたいに全部用意しとる

Nobuyuki Tokuchi [23:26]
とりあえず，generalに自分が作成した実装のバイナリへのリンク貼っといた．(ソースコードはGithubで見れるので)

jekto_vatimeliju [23:27]
あと、8bit/16bit は ロード（符号拡張）・ストア命令だけあれば十分というのもあり（こうやって汎整数拡張は生まれるのだなぁ）

na2co3 [23:29]
汎整数拡張、LLVMくんが勝手にやってるけどそんな名前あったのかあ

jekto_vatimeliju [23:30]
Cを学習していくと、中盤ぐらいで「式の中では基本的にint未満のは全部intに昇格されます」と習って、「どうしてそうなるんだろう」と不思議に思う仕様の一つ（今回Cコンパイラ書いてやっとモチベが分かった） （編集済み）