FreeBSDを語れ Part49

[過去ﾛｸﾞ] FreeBSDを語れ Part49 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

123(1): 2019/09/13(金)12:29 AAS
>>101
碌にテストなんてやったことないというのがバレバレだなw

124(2): 2019/09/13(金)12:35 AAS
無駄なチェックを端折れて高速な処理を書けるからC使ってるのに、
遅い堅牢ならライブラリをC、C++に用意しろと言うような低レベルPGなら元からC、C++使うなってことだな。

125: 2019/09/13(金)13:48 AAS
今現在堅牢な高級言語は生き残ってるか?

126(1): 2019/09/13(金)14:06 AAS
堅牢な高級言語しか生き残ってないだろｗ
アドレスを直接扱える危険な言語って
たくさんの言語のなかどの程度あると思う？

127: 2019/09/13(金)14:10 AAS
>>123
へー、すごいねー
で、お前ん所のテスト密度っていくらぐらいなんだ？w

128: 2019/09/13(金)14:20 AAS
>>126
Cは元々アセンブラの代替として作ったものだからポインタが扱えて当たり前ですよ。
C = 高級アセンブラだから。それが嫌な人はFortranでも使っとけということで。

129: 2019/09/13(金)14:28 AAS
>>124
ならCじゃなくてアセンブラ使ってろよ

130(1): 2019/09/13(金)17:39 AAS
>>124
ほんそれ

関数入るたびに境界チェックするコードとか入れてたらCの有難味がないな

131(1): 2019/09/13(金)19:10 AAS
OpenBSDのportsに入ってたパッチw

--- texk/dvipsk/writet1.c.orig
+++ texk/dvipsk/writet1.c
@@ -1449,7 +1449,9 @@ static void t1_check_unusual_charstring(void)
*(strend(t1_buf_array) - 1) = ' ';

t1_getline();
+ alloc_array(t1_buf, strlen(t1_line_array) + strlen(t1_buf_array) + 1, T1_BUF_SIZE);
strcat(t1_buf_array, t1_line_array);
+ alloc_array(t1_line, strlen(t1_buf_array) + 1, T1_BUF_SIZE);
strcpy(t1_line_array, t1_buf_array);
t1_line_ptr = eol(t1_line_array);
}

132: 2019/09/13(金)19:11 AAS
>>131
ごめんなさい。

全然違うサイトに誤爆です。

133(3): 2019/09/13(金)19:57 AAS
>>130
Cなら
if ( checkfunc( func ) ) ...
と1行で書けるから大したことなさそうに見えるけど、これをアセンブラで書くと、
汎用レジスタ全部退避して、戻りアドレス設定して、新しいスタックポインタ設定して、
チェック処理を実行して、戻る直前に汎用レジスタ全部戻してリターンするので、
毎回こんだけの処理させてわざわざ遅くするのが嫌になるんだよね。
全レジスタの退避と復帰を毎回実行させるのってほんとに無駄に感じる。
本当は、破壊されてもいいレジスタは関数ごとに異なるはずなので、破壊されて困るレジスタだけ退避
するようにすれば最適化されていいんだけど、そうするとどこかを書き換えたとき、元に戻さないといけない
レジスタができて、それの退避を忘れただけで吹っ飛ぶ。

134(1): 2019/09/13(金)20:16 AAS
>>133
三行にまとめてくんないと、1ミリも理解できないんだけど

135: 2019/09/13(金)20:29 AAS
素敵なコンパイラなら4行くらいにまとめてくれないかな....

136(1): 2019/09/13(金)21:01 AAS
>>134
理解しなくていいよ。
x86系の知識だけで、とりあえず知ってるワードでマウント取ろうとしてるだけだから。

137(1): 2019/09/13(金)21:21 AAS
確かMS-C6.0の頃か？（うろ覚え）破壊しないレジスタは退避しなかった筈だが？ｗ
十数年前からメジャーどこのコンパイラは短い関数なら勝手にインライン展開するのが殆どだし
いつの時代の話をしてるんだかさっぱり

138: 2019/09/13(金)21:24 AAS
流し読みで読み飛ばしちまったけんども
アセンブラでプロシージャ書いたとこでコーダーがスタックポインタを設定する事なんて先ずありえんｗｗｗ

139: 2019/09/13(金)21:28 AAS
>>137
俺も最初そう思って？？？状態だったけど、よく読んだらアセンブラで書いた時の話みたい
アセンブラで書く時に全レジスタ保存なんてよほど間抜けでないと普通しないけどな

140: 2019/09/13(金)22:25 AAS
知的障害者きてんね

141: 2019/09/13(金)22:35 AAS
支離滅裂さからは糖質の臭いがする

142(1): 2019/09/13(金)22:52 AAS
>>136
俺は一桁ロリに mount -f したい

143: 2019/09/13(金)22:57 AAS
さすがに一桁はないわ

144: 2019/09/14(土)00:36 AAS
>>119
それはC++の場合だな
Cではそんなことする処理系が無い

145(1): 2019/09/14(土)00:41 AAS
ちなみにC++では配列の各要素に対してデストラクタを呼ばなくちゃいけない都合上サイズが格納されている

146: 2019/09/14(土)05:03 AAS
>>142
おまわりさんこの人

147: 2019/09/14(土)05:13 AAS
童貞です

148: 2019/09/14(土)06:22 AAS
ｗｗｗ

149: 2019/09/14(土)10:12 AAS
>>133
レジスタ退避と復帰は専用の命令が有るけど、CPUは実際には見えてる以上にレジスタを持ってるから毎回律儀にメモリに退避とかしてないよ

150: 2019/09/14(土)10:53 AAS
2chｽﾚ:linux
286
俺はもうWindowsでVirtualBoxは諦めてるんだが、
FreeBSDとかSolarisとかどうしてもVirtualBoxでしか動かせなくて
必要なときはMacを使ってる。

FreeBSDとかSolarisがHyperVでも動かせるなら良いんだけど
どうもうまく行かない。

151(2): 2019/09/14(土)11:01 AAS
>>145
delete [] hoge;
のときですね
良く [] 付け忘れるので防止策教えてくだされ

152(2): 2019/09/14(土)13:04 AAS
>>133は、アセンブラでコード書いてると自然にそうなるってこと。
ルーチン内ではできるだけ汎用レジスタを使って処理したほうが早くなるから、最初にメモリから必要なデータを持ってきた後は
極力レジスタだけで処理するように書く。後からその処理の途中に別の処理を入れることになって、別の関数を挟んだとすると
レジスタの値を変えてはいけないから、その関数に入ったところで全レジスタを待避し、関数の終わりで戻さないといけなくなる。

Cで同じことをしてアセンブラに展開したコードを見ると、変数の値はメモリに置いておき、必要になったらレジスタにロードして
計算したら結果をまたメモリに戻すという処理をしている。後から途中に関数が追加されても、その関数はメモリから値を
持ってきて処理するからレジスタを退避する必要はない。関数に渡すパラメータなどもスタックに入れて渡すから
同じくレジスタを退避しなくて良い。

しかしこのやり方ではメモリとレジスタ間のセーブ/ロードが頻繁に起こるので、アセンブラのソースで見るといかにも効率が悪くて
遅いとわかる。当たり前だがメモリ - レジスタ間のセーブ/ロードはレジスタ内だけの演算よりずっと遅い。
そうするくらいなら、必要なときだけレジスタを退避・復帰させた方がまし。さらに、これがforなどのループ内で使われた場合、
この遅さがプログラム全体の遅さになる。Cコンパイラのコード生成は、アセンブラから見れば遅くて無駄だらけに見える。
その分、ソースが見やすいから便利なんだけれども。

上下前次 1-新書関写板覧索設栞歴

あと 850 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.027s