- CPUアーキテクチャについて語れ 7
25 ：MACオタ[sage]：2007/03/04(日) 15:17:11 ID:4D+WkUI7 - レトリックさんが、しつこくMacOSに32KBの制限があると言い張ってるみたいすけど間違いす。
32KBってのわ、リソースサイズの制限であってmallocとかでヒープに確保するメモリの話じゃ
ないす。
(ただしコード用のメモリも"コードリソース"として実装するのが推奨だったことわ事実)
当時のMacOSわ128KBのメモリでやりくりするために、半自動ガベージコレクション機能がついて
いて、ガベージコレクション時にメモリ上のオブジェクトの取捨選択をするために、コードやデータ
をリソースという単位で管理していたす。ファイルシステム自体がリソース化したオブジェクトの
扱いが便利なようにファイルを「データフォーク」と「リソースフォーク」に分けていたのわ、良く
知られているかと思うす。
|
- CPUアーキテクチャについて語れ 7
27 ：MACオタ＞26 さん[sage]：2007/03/04(日) 15:35:55 ID:4D+WkUI7 - >>26
フラットなメモリ空間をOSを含む複数のプログラムで共有するやり方なんで、問題ないす。
|
- CPUアーキテクチャについて語れ 7
29 ：MACオタ＞28 さん[sage]：2007/03/04(日) 15:42:04 ID:4D+WkUI7 - >>28
MacOS APIでのメモリ確保わポインタじゃなくてハンドルで行うので、あまり問題わ出ないす。
もちろんこれゆえにヒープメモリわ使い難いし、時々再起動しないとメモリの断片化で色々
不具合もあったす。
|
- CPUアーキテクチャについて語れ 7
31 ：MACオタ[sage]：2007/03/04(日) 15:48:31 ID:4D+WkUI7 - 余談すけど、旧MacOS的なフラットなメモリ管理ってアプリケーションごとにコードのアドレスが
異なるすから、仮にバッファオーバーフロー等が発生した場合でも"jump xxx"的なやり方
で危険なコードを実行させることわ不可能す。
昨今の深刻なセキュリティ問題を考えると、良かったじゃないすかね。。。
|
- CPUアーキテクチャについて語れ 7
34 ：MACオタ＞32 さん[sage]：2007/03/04(日) 15:56:02 ID:4D+WkUI7 - >>32
co-operativeマルチタスクも、立派なマルチタスクだと思うすけど。。。
殊に昨今のようにコアが増えてくれば、タスクスイッチのオーバーヘッドが無いというのわ悪くない
と思うす。。。
ちなみにフラットなメモリ管理のマルチタスクOSってOS/400とか色々あるかと思うす。
|
- CPUアーキテクチャについて語れ 7
36 ：MACオタ＞分託 さん[sage]：2007/03/04(日) 16:00:32 ID:4D+WkUI7 - >>33
---------------------
segment manager/loaderに32Kの制約
---------------------
コードリソースを扱うAPIだったかと。
|
- CPUアーキテクチャについて語れ 7
38 ：MACオタ＞分託 さん[sage]：2007/03/04(日) 16:10:21 ID:4D+WkUI7 - >>37
>>25を読み直して欲しいす。。。
|
- CPUアーキテクチャについて語れ 7
41 ：MACオタ＞分託 さん[sage]：2007/03/04(日) 16:18:19 ID:4D+WkUI7 - >>40
プライドが高いのわ結構な話すけど。。。
-------------------
当初Pascalしか無かったんでmallocはどうか覚えてないけど
-------------------
NewHandleと言えば、思い出すすか？
http://developer.apple.com/documentation/mac/Memory/Memory-67.html
|
- CPUアーキテクチャについて語れ 7
45 ：MACオタ＞分託 さん[sage]：2007/03/04(日) 16:21:56 ID:4D+WkUI7 - >>42
英語読めるすか？あなたの引用先に書いてあるす。
---------------------
There is nothing in the Mac or 68000 that REQUIRES a 32K limit,
---------------------
|
- CPUアーキテクチャについて語れ 7
47 ：MACオタ＞分託 さん[sage]：2007/03/04(日) 16:26:49 ID:4D+WkUI7 - >>46
その"Straight Story on 32K Limits"の２行目が>>45に引用した文章すけど(笑)
|
- CPUアーキテクチャについて語れ 7
51 ：MACオタ[sage]：2007/03/04(日) 16:33:48 ID:4D+WkUI7 - 分託さんがリンクした文書に書いてあることわ、
1. Plus以前のMacOS ROMのバグによるリソースサイズの制限
2. >>44さんの書いたISA中の16-bit相対アドレスの制限によるサブルーチンコールの問題
3. 一部開発環境でのグローバル変数のサイズ制限
4. 一部開発環境での配列サイズの制限
4についてわ、ヒープメモリ自体ににそういう制限わ無いすから、ここで言及されている通りの事態になるす。
---------------------------
[Note: neither Lightspeed Pascal nor Lightspeed C will allow arrays over 32K.
---------------------------
|
- CPUアーキテクチャについて語れ 7
53 ：MACオタ＞分託 さん[sage]：2007/03/04(日) 16:34:36 ID:4D+WkUI7 - >>49
リソースとヒープの区別も無しにMacintoshの開発してたすか(笑)
|
- CPUアーキテクチャについて語れ 7
57 ：MACオタ＞56 さん[sage]：2007/03/04(日) 16:37:41 ID:4D+WkUI7 - >>56
話の頭わ>>25すけど。。。
-----------------------
32KBってのわ、リソースサイズの制限であってmallocとかでヒープに確保するメモリの
話じゃないす。
-----------------------
|
- CPUアーキテクチャについて語れ 7
61 ：MACオタ＞58 さん[sage]：2007/03/04(日) 16:41:11 ID:4D+WkUI7 - >>58
でわ、前スレの馬鹿発言を引用させていただくす。
http://pc9.2ch.net/test/read.cgi/jisaku/1169393906/977
---------------------------
977 名前：レトリック君 投稿日：2007/03/03(土) 14:43:50 ID:e5/EMclF
当初のMacの壁って、
128K MacのToolboxが動的に割り当ててくれる連続memoryの最大長だったかな、
---------------------------
|
- CPUアーキテクチャについて語れ 7
69 ：MACオタ＞68 さん[sage]：2007/03/04(日) 19:45:07 ID:4D+WkUI7 - >>68
--------------------
当時現場にいなかったやつはすっこんでろ。
--------------------
匿名掲示板で披露された経歴を素直に信じるすか。。。
|