[過去ﾛｸﾞ] FreeBSDを語れ Part49 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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コンパイラのコード生成は、アセンブラから見れば遅くて無駄だらけに見える。
その分、ソースが見やすいから便利なんだけれども。
153: 2019/09/14(土)13:06 AAS
>>151
今から作るならnew/deleteなんてやめてvectorとかにしなよ
deleteの[ ]付け忘れるような人は例外時の解放忘れとかもしそうだし
154(1): 2019/09/14(土)13:08 AAS
>>152
頼むから今時のまともなコンパイラ使ってから語ってくれ…
155: 2019/09/14(土)13:14 AAS
問題はコンパイラじゃなくて変態的な処理になってしまったx86系CPUのコード処理の方だと思われ
もはやアセンブラ最適化とか狂気の沙汰と聞いた
あー、スモールでコード書いてた頃が懐かしい
156: 2019/09/14(土)13:40 AAS
>>151
valgrindを使えば実行時にエラーを検出して実行終了時にエラーを出力してくれる
つうかCやC++でコーディングする場合はvalgrindは必須だな
実行する環境によっては使えないかもしれんけど、他には静的解析ツールを使うという手もある
例えばcppcheckとか使うと実行する前に間違いを指摘してくれる
157: 2019/09/14(土)13:48 AAS
FreeBSDを12.0にアップグレードしたらvalgrindがメモリ関係のエラーを検出しなくなった(泣)
その上システムコールに対するサポートも不完全みたいで、エラーが出るし
だれかfreebsd-portsのvalgrindを更新プリーズ…
158(2): 2019/09/14(土)13:51 AAS
和訳せよ
Send FreeBSD to the great bitbucket in the sky.
159(1): 2019/09/14(土)13:57 AAS
to be to be ten made to be
160: 2019/09/14(土)13:59 AAS
>>158
FreeBSDを空の素晴らしいbitbucketに送ってください。
>>159
十歳になる
161: 2019/09/14(土)18:38 AAS
>>152
今北産業
162: 2019/09/14(土)19:30 AAS
これでも読んだほうがいいんじゃね？
外部ﾘﾝｸ:gihyo.jp
163(1): 2019/09/15(日)08:08 AAS
86系にうんざりして68系に目覚めた遠いあの日の思い出
164: 2019/09/15(日)08:39 AAS
>>163
セグメント内64kB、相対ジャンプが8bit…
うんざりって言うより殺意を覚えたあの頃
165(5): 2019/09/15(日)10:21 AAS
些細なことは気にすんな
プロテクトモード遷移でいちいち再起動の方が糞
166(5): 2019/09/15(日)12:29 AAS
OS/2はプロテクトモード→リアルモード遷移を再起動することなく実現したけどな
167(2): 2019/09/15(日)12:35 AAS
前スレ617 621で
タイトルバーの向きをひねって窓の左縁に付けたがってた者ですが
紹介してくれたsawfish, awesome, flwm, wmx, xmonadそれぞれ堪能しました
感謝を込めてlightdmディスプレイマネージャのメニューに仕込んでスクショ奉納
画像ﾘﾝｸ
168: 2019/09/15(日)12:56 AAS
>>166
再起動してるだろ
169(3): 2019/09/15(日)13:02 AAS
昔のWin3.0（3.1とかじゃないぞ）もきっちりプロテクテッドモードからリアルモードに正常に遷移してDOSに戻れてた
戻った時の事を考えて下位メモリ残しておくかとか、コードの増加とか実行時のメモリの無駄とかに目をつむって
正常終了のシーケンスを考えた設計にするかとか次第だろうて
170: 2019/09/15(日)13:27 AAS
>>167
必要ないかも知れませんがlightdmの背景変えられますよ
171(4): 2019/09/15(日)14:18 AAS
つーかプロテクテッドモードからリアルモードへの遷移は有名な話やろ？
Microsoftの凄さに震えるわｗ
外部ﾘﾝｸ:builder.japan.zdnet.com
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つしか立ち上げることができない。それは、実際にリアルモードに移行しているためである。
172: 2019/09/15(日)14:19 AAS
節子それ左ちゃう右や
173(5): 2019/09/15(日)15:02 AAS
最初のプロテクテッドモード（286）はリアルモードへの遷移ってCPUが非対応だったのか知らなかったｗ
てか殆ど使われなかった286プロテクテッドモードの方の話なら286って付けろよと
174: 2019/09/15(日)15:08 AAS
64kとか言ってる時点でお察し
上下前次1-新書関写板覧索設栞歴
あと 828 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.021s