X
FreeBSDを語れ Part49
■ このスレッドは過去ログ倉庫に格納されています
0116名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 04:47:59.22
perl で何でもかんでもやってまーす
0119名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 11:27:02.29
>>96
mallocしたポインタのオフセット[-1]あたりにsizeがある実装が多いから
それをもっと早く規格化すればよかったと思う
0121名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 12:05:51.57
mallocで管理されるsizeはバイト単位やろ
wchar_t が 32bit とか言う話か？
0124名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 12:35:23.45
無駄なチェックを端折れて高速な処理を書けるからC使ってるのに、
遅い堅牢ならライブラリをC、C++に用意しろと言うような低レベルPGなら元からC、C++使うなってことだな。
0126名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 14:06:11.98
堅牢な高級言語しか生き残ってないだろｗ
アドレスを直接扱える危険な言語って
たくさんの言語のなかどの程度あると思う？
0128名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 14:20:06.52
>>126
Cは元々アセンブラの代替として作ったものだからポインタが扱えて当たり前ですよ。
C = 高級アセンブラだから。それが嫌な人はFortranでも使っとけということで。
0130名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 17:39:53.55
>>124
ほんそれ

関数入るたびに境界チェックするコードとか入れてたらCの有難味がないな
0131名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 19:10:51.35
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);
}
0133名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 19:57:49.49
>>130
Cなら
if ( checkfunc( func ) ) ...
と1行で書けるから大したことなさそうに見えるけど、これをアセンブラで書くと、
汎用レジスタ全部退避して、戻りアドレス設定して、新しいスタックポインタ設定して、
チェック処理を実行して、戻る直前に汎用レジスタ全部戻してリターンするので、
毎回こんだけの処理させてわざわざ遅くするのが嫌になるんだよね。
全レジスタの退避と復帰を毎回実行させるのってほんとに無駄に感じる。
本当は、破壊されてもいいレジスタは関数ごとに異なるはずなので、破壊されて困るレジスタだけ退避
するようにすれば最適化されていいんだけど、そうするとどこかを書き換えたとき、元に戻さないといけない
レジスタができて、それの退避を忘れただけで吹っ飛ぶ。
0137名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 21:21:08.17
確かMS-C6.0の頃か？（うろ覚え）破壊しないレジスタは退避しなかった筈だが？ｗ
十数年前からメジャーどこのコンパイラは短い関数なら勝手にインライン展開するのが殆どだし
いつの時代の話をしてるんだかさっぱり
0138名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 21:24:57.47
流し読みで読み飛ばしちまったけんども
アセンブラでプロシージャ書いたとこでコーダーがスタックポインタを設定する事なんて先ずありえんｗｗｗ
0139名無しさん＠お腹いっぱい。
垢版 |
2019/09/13(金) 21:28:15.19
>>137
俺も最初そう思って ？？？ 状態だったけど、よく読んだらアセンブラで書いた時の話みたい
アセンブラで書く時に全レジスタ保存なんてよほど間抜けでないと普通しないけどな
0145名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 00:41:44.98
ちなみにC++では配列の各要素に対してデストラクタを呼ばなくちゃいけない都合上サイズが格納されている
0146名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 05:03:45.80
>>142
おまわりさんこの人
0149名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 10:12:55.40
>>133
レジスタ退避と復帰は専用の命令が有るけど、CPUは実際には見えてる以上にレジスタを持ってるから毎回律儀にメモリに退避とかしてないよ
0150名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 10:53:54.50
https://mao.5ch.net/test/read.cgi/linux/1560665525/
286
俺はもうWindowsでVirtualBoxは諦めてるんだが、
FreeBSDとかSolarisとかどうしてもVirtualBoxでしか動かせなくて
必要なときはMacを使ってる。

FreeBSDとかSolarisがHyperVでも動かせるなら良いんだけど
どうもうまく行かない。
0151名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 11:01:09.06
>>145
delete [] hoge;
のときですね
良く [] 付け忘れるので防止策教えてくだされ
0152名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 13:04:16.01
>>133は、アセンブラでコード書いてると自然にそうなるってこと。
ルーチン内ではできるだけ汎用レジスタを使って処理したほうが早くなるから、最初にメモリから必要なデータを持ってきた後は
極力レジスタだけで処理するように書く。後からその処理の途中に別の処理を入れることになって、別の関数を挟んだとすると
レジスタの値を変えてはいけないから、その関数に入ったところで全レジスタを待避し、関数の終わりで戻さないといけなくなる。

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

しかしこのやり方ではメモリとレジスタ間のセーブ/ロードが頻繁に起こるので、アセンブラのソースで見るといかにも効率が悪くて
遅いとわかる。当たり前だがメモリ - レジスタ間のセーブ/ロードはレジスタ内だけの演算よりずっと遅い。
そうするくらいなら、必要なときだけレジスタを退避・復帰させた方がまし。さらに、これがforなどのループ内で使われた場合、
この遅さがプログラム全体の遅さになる。Cコンパイラのコード生成は、アセンブラから見れば遅くて無駄だらけに見える。
その分、ソースが見やすいから便利なんだけれども。
0153名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 13:06:51.37
>>151
今から作るならnew/deleteなんてやめてvectorとかにしなよ
deleteの[ ]付け忘れるような人は例外時の解放忘れとかもしそうだし
0155名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 13:14:43.19
問題はコンパイラじゃなくて変態的な処理になってしまったx86系CPUのコード処理の方だと思われ
もはやアセンブラ最適化とか狂気の沙汰と聞いた

あー、スモールでコード書いてた頃が懐かしい
0156名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 13:40:31.42
>>151
valgrindを使えば実行時にエラーを検出して実行終了時にエラーを出力してくれる
つうかCやC++でコーディングする場合はvalgrindは必須だな
実行する環境によっては使えないかもしれんけど、他には静的解析ツールを使うという手もある
例えばcppcheckとか使うと実行する前に間違いを指摘してくれる
0157名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 13:48:29.18
FreeBSDを12.0にアップグレードしたらvalgrindがメモリ関係のエラーを検出しなくなった(泣)
その上システムコールに対するサポートも不完全みたいで、エラーが出るし
だれかfreebsd-portsのvalgrindを更新プリーズ…
0159名無しさん＠お腹いっぱい。
垢版 |
2019/09/14(土) 13:57:51.90
to be to be ten made to be
0163名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 08:08:41.06
86系にうんざりして68系に目覚めた遠いあの日の思い出
0165名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 10:21:18.16
些細なことは気にすんな
プロテクトモード遷移でいちいち再起動の方が糞
0167名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 12:35:29.17
前スレ617 621で
タイトルバーの向きをひねって窓の左縁に付けたがってた者ですが
紹介してくれたsawfish, awesome, flwm, wmx, xmonadそれぞれ堪能しました
感謝を込めてlightdmディスプレイマネージャのメニューに仕込んでスクショ奉納
https://imgur.com/vqmxm21.png
0169名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 13:02:16.63
昔のWin3.0（3.1とかじゃないぞ）もきっちりプロテクテッドモードからリアルモードに正常に遷移してDOSに戻れてた
戻った時の事を考えて下位メモリ残しておくかとか、コードの増加とか実行時のメモリの無駄とかに目をつむって
正常終了のシーケンスを考えた設計にするかとか次第だろうて
0171名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 14:18:57.98
つーかプロテクテッドモードからリアルモードへの遷移は有名な話やろ？
Microsoftの凄さに震えるわｗ
https://builder.japan.zdnet.com/os-admin/sp_history-of-windows-2009/20392994/2/

1. まずCPUの制限でプロテクテッドモードからリアルモードへは切り替えられない（Windowsの制限ではない）

> Windows 2.0と80286
>　その後、特定の命令を実行することで仮想記憶が利用可能なモード
>（メモリ保護機能がついているため「プロテクトモード」と呼ばれる）に移行できるのだが、
>プロテクトモードからリアルモードに戻る方法は存在しなかった。


2. それをMicrosoftはとんでもない発想で実現してしまった

> 　もし、リアルモードに戻れなければ、Windows 2.0が起動したあとはMS-DOSコマンドが実行できなくなってしまうだろう。
>
> 　Microsoftは実に巧妙な方法でこの問題を解決した。
>
> 　リアルモードに移行したい場合はCPUをリセットするのである。もちろん単にリセットしたのでは
> Windowsは強制終了され、BIOSの初期化ルーチンが動いてしまう。
>
> 　そこでWindowsはリセット時に実行するプログラムの実行番地をあらかじめ書き換えておく。
> そして必要なデータを退避させた上でリアルモードに移行するようにした。Windowsに戻るときはプロテクトモードに移行すればよい。
>
> 　Windows 2.0の「DOS窓」は1つしか立ち上げることができない。それは、実際にリアルモードに移行しているためである。
0172名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 14:19:35.47
節子それ左ちゃう右や
0173名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 15:02:59.61
最初のプロテクテッドモード（286）はリアルモードへの遷移ってCPUが非対応だったのか知らなかったｗ
てか殆ど使われなかった286プロテクテッドモードの方の話なら286って付けろよと
0174名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 15:08:07.73
64kとか言ってる時点でお察し
0176名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 15:37:04.73
Windows 3.0は 8086/8088 （80286を含む）以上に対応してるからな

https://en.wikipedia.org/wiki/Windows_3.0

The official system requirements for Windows 3.0:

8086/8088 processor or better
384 KB of free conventional memory (real mode), 1 MB (Standard Mode), or 2 MB (Enhanced Mode)[9]
Hard disk with 6-7 MB of free space
CGA, EGA, MCGA, VGA, Hercules, 8514/A or XGA graphics and an appropriate and compatible monitor
MS-DOS version 3.1 or higher[1]


Memory modes
Windows 3.0 was the only version of Windows that could be run in three different memory modes:

Real mode, intended for older computers with a CPU below Intel 80286, and corresponding to its real mode;
Standard mode, intended for computers with an 80286 processor, and corresponding to its protected mode;
386 Enhanced mode, intended for newer computers with an Intel 80386 processor or above, and corresponding to its protected mode and virtual 8086 mod
0178名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 16:58:24.68
Win3.1とかがメジャーになる前は普通に書籍でもプロテクテッドモードって書いてあったでよ
いつの間にかプロテクトモードとか呼ばれる様になっただけ
どっちも間違えじゃないだろうけど、プロテクトモードって聞くとどうしても違和感がある（全プリキュア並感

386プロテクテッドモードのA5の技術書がくすんだ緑のカバー、286の方は藍色、厚さ大体1cm位な記憶
両方持ってたけど386の方は手垢が付きまくってダメになるまで読んだり調べものしたりしたな
0180名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 17:27:36.78
>>173
有名な話だからこの手の話でドヤりたいたらそれぐらいは知っておかないと知ったかの烙印押されてもしょうがないわな
0184名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 17:57:38.52
>>171
CPUリセットでリアルモードへの遷移を実現したのは、
MicrosoftではなくIBMだと思ったけど、記憶違いかな
BMとMSがOS/2を共同開発していた頃なんで、どっちとも言えないのかも知れないけど
0187名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 18:24:52.18
>>183
＞お前らジジ臭いな
＞俺はPentium 133MHzだ

爆速だな。 i386DXは16/20Mhzだ。もちろん20で使ってた。
1990年に買って5年間はDOSで使って、
Windowsはスルーして1995年からFreeBSDだったかな。
0189名無しさん＠お腹いっぱい。
垢版 |
2019/09/15(日) 19:03:21.52
>>184
> MicrosoftではなくIBMだと思ったけど、記憶違いかな
ハード的にリセットする仕組みが必要だからどちらかと言うとIBMだろうね
そもそも>>171の
> そこでWindowsはリセット時に実行するプログラムの実行番地をあらかじめ書き換えておく。
は間違いでPC ATならリセット前にRTCのCMOS RAMにシャットダウンコードを書いておいてリセット時にそのコードがリアルモードへの復帰なら復帰用のコードを実行するようにしてるだけ
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況