１２８ＢIＴのウインドウズはいつでますか？
1 ：パソコン初心者に毛が生えた程度の者でぷ ：
教えて
|
|
|
2 ：パソコン初心者に毛が生えた程度の者でぷ ：2000/08/27(日) 07:30
でま千
3 ：名無しさん＠そうだ選挙にいこう ：2000/08/27(日) 07:31
ぷう
4 ：名無しさん＠そうだ選挙にいこう ：2000/08/27(日) 11:02
来年か、再来年だろう。
5 ：名無しさん＠そうだ選挙にいこう ：2000/08/28(月) 02:26
＞1
今のペースなら10年後ぐらい。
今のペースなら10年後ぐらい。
6 ：名無しさん＠そうだ選挙にいこう ：2000/08/28(月) 03:56
んなネタスレにマジレスするのはアホすぎるのだが・・・
永久に出ないだろ。単純にレジスタ幅増やす時代ではなく
クルーソーのような手法が主流になるだろうから内部が１２８や
２５６ビット幅になっても３２か６４ビットＡＰＩで動くはず。
Win64自体使われないんちゃうか。
永久に出ないだろ。単純にレジスタ幅増やす時代ではなく
クルーソーのような手法が主流になるだろうから内部が１２８や
２５６ビット幅になっても３２か６４ビットＡＰＩで動くはず。
Win64自体使われないんちゃうか。
7 ：名無しさん＠そうだ選挙にいこう ：2000/08/28(月) 09:37
＞６
つーか、世に出るのか？
つーか、世に出るのか？
8 ：＞7 ：2000/08/28(月) 11:42
クルーソーのこと？
次期VAIOが搭載するはずだけど
次期VAIOが搭載するはずだけど
9 ：7 ：2000/08/28(月) 15:43
んにゃWin64のほう。
10 ：僕チン ：2000/08/28(月) 18:40
64Bit化以降は、機器の小型化に伴ってバス幅は減る一方だと思いまする。
11 ：4 ：2000/08/29(火) 01:38
間違った。64bitのWinかと思った。
Win64なら、来年くらいに出ると思うけど。
128bitっていうのは・・・出ないのでは？
OSとしてサポートする意義があまりないよ。
CPUとしては、SIMD命令なんかで128bit幅に対応すれば
いいっていうくらいで。
Win64なら、来年くらいに出ると思うけど。
128bitっていうのは・・・出ないのでは？
OSとしてサポートする意義があまりないよ。
CPUとしては、SIMD命令なんかで128bit幅に対応すれば
いいっていうくらいで。
12 ：名無しさん＠そうだ選挙にいこう ：2000/08/29(火) 01:58
今後ビット幅が必要なところは専用命令扱い。
intに64ビットもいらんわ。
実行バイナリがでかくなるだけでメリットなし。
intに64ビットもいらんわ。
実行バイナリがでかくなるだけでメリットなし。
13 ：Be名無しさん ：2000/10/10(火) 12:59
＞１
それって、EmotionEngine(=PS2)用Windowsの事？
それって、EmotionEngine(=PS2)用Windowsの事？
14 ：名無しさん＠１周年 ：2000/10/11(水) 13:30
aged
15 ：尾丼：2000/11/05(日) 01:27
＞１３
？？？？
？？？？
16 ：Be名無しさん：2000/11/08(水) 11:15
なぜ上がってるのかよーわからんが、
気になったのでンヶ月前のネタに突っ込み。
> intに64ビットもいらんわ。
単なる整数値としてしか使わんのなら64bitが
必要なケースなんてそうそうないだろーけど、
80GBのハードディスクが30k円以下で買えるわ
その気になれば個人でもGBオーダのメモリは積めるわ
とゆー時代だと、ポインタとかファイル位置の
オフセット値には64bitくらいないと困るっす。
# ま、Cのint型が64bitである必然性はなくて、
# 実際、Single UNIX SpecificationはLP64
# (longとpointerが64bit)というモデルで、
# Win64はLLP64(long longとpointerが64bit)
# というモデルなんだそーだ。
気になったのでンヶ月前のネタに突っ込み。
> intに64ビットもいらんわ。
単なる整数値としてしか使わんのなら64bitが
必要なケースなんてそうそうないだろーけど、
80GBのハードディスクが30k円以下で買えるわ
その気になれば個人でもGBオーダのメモリは積めるわ
とゆー時代だと、ポインタとかファイル位置の
オフセット値には64bitくらいないと困るっす。
# ま、Cのint型が64bitである必然性はなくて、
# 実際、Single UNIX SpecificationはLP64
# (longとpointerが64bit)というモデルで、
# Win64はLLP64(long longとpointerが64bit)
# というモデルなんだそーだ。
17 ：Be名無しさん：2000/11/08(水) 13:39
>>16
データ幅とアドレス幅と(あまつさえFileSystemと)をごっちゃにしないように。
最近のOSなら仮想メモリは64bitであることが多い。
FileSystemはNTFSは64bitだったと思う。UFSやらHFS+なんかも恐らく64bitだろう。
データ幅とアドレス幅と(あまつさえFileSystemと)をごっちゃにしないように。
最近のOSなら仮想メモリは64bitであることが多い。
FileSystemはNTFSは64bitだったと思う。UFSやらHFS+なんかも恐らく64bitだろう。
18 ：Be名無しさん：2000/11/08(水) 16:02
>>17
違うものであることはわかってるつもりだけど、
それぞれが全く独立してるわけでもないでしょ?
メモリをアクセスする際のポインタ演算やファイル
システム上のデータをランダムアクセスする際の
オフセット計算なんかは結局整数演算なわけだし、
最近のOSなら大抵mmap()相当のAPI持っていて
メモリとファイルシステムを透過的に扱えるし。
違うものであることはわかってるつもりだけど、
それぞれが全く独立してるわけでもないでしょ?
メモリをアクセスする際のポインタ演算やファイル
システム上のデータをランダムアクセスする際の
オフセット計算なんかは結局整数演算なわけだし、
最近のOSなら大抵mmap()相当のAPI持っていて
メモリとファイルシステムを透過的に扱えるし。
64bitあると、パフォーマンスが上がる処理は色々あるよね。
2038年問題もあるし。。。
2038年問題もあるし。。。
20 ：Be名無しさん：2000/11/08(水) 17:21
>>18
メモリマップはちと特殊な気がするんだけどどうなんでしょ。
ファイルのシークなんかは今のFileSystemでも64bitだし。
それは、CPUのデータ幅(端的に言ってintのbit幅)とアドレス幅に対する誤解かと思った。
intは32bitだけど64bit演算だって行えるわけだし。
そもそも、ポインタとかファイルポインタを整数型として扱う(or認識する)のは危ないから個人的には好かない。
Cとかでプログラム書くと仕方が無いんだけど。
intの幅が変わったりしたらそれこそ大変だからね(変わらないと思うけど)。
メモリマップはちと特殊な気がするんだけどどうなんでしょ。
ファイルのシークなんかは今のFileSystemでも64bitだし。
それは、CPUのデータ幅(端的に言ってintのbit幅)とアドレス幅に対する誤解かと思った。
intは32bitだけど64bit演算だって行えるわけだし。
そもそも、ポインタとかファイルポインタを整数型として扱う(or認識する)のは危ないから個人的には好かない。
Cとかでプログラム書くと仕方が無いんだけど。
intの幅が変わったりしたらそれこそ大変だからね(変わらないと思うけど)。
21 ：18：2000/11/08(水) 17:24
>intは32bitだけど64bit演算だって行えるわけだし。
っつってもintで64bit演算が出来るわけじゃないね。
誤解を生む発言失礼。
っつってもintで64bit演算が出来るわけじゃないね。
誤解を生む発言失礼。
128bitはいらない？
23 ：名無しさん＠１周年：2000/11/08(水) 18:44
オレの脳みそ一億ビット。
24 ：16=18：2000/11/08(水) 19:29
>>20
> メモリマップはちと特殊な気がするんだけどどうなんでしょ。
configureでmmap()の存在チェックしてるfreewareもけっこー
あるよーだから、特殊とまでは言い切れないよーな気がする、
と思うのは甘いかしらん。使えるとむっちゃ便利なんだけど。
thread程度には一般性があると思いたい。
> そもそも、ポインタとかファイルポインタを整数型として扱う(or認識する)のは危
> ないから個人的には好かない。
あ、「結局は整数演算」つーのは、言語レベルで直接整数型で
扱うとゆー意味ではなくて、CPUレベルでは整数演算ユニットで
処理することになる、という程度の意味っす。
struct_pointer[index].memberってなコードをアセンブラに落として
みるといっしょーけんめーシフトと加算を繰り返してるのがわかる。
(かもしれない。CISC系プロセッサだと1インストラクションで済んでたりして^^;)
>>22
SISDだったらいらない。SIMDで32bit*4とかだったら用途に
よっては非常に意味あるけどそーゆーのサポートしてるからって
「128bit OS」とは呼ばんよーな気がする。
> メモリマップはちと特殊な気がするんだけどどうなんでしょ。
configureでmmap()の存在チェックしてるfreewareもけっこー
あるよーだから、特殊とまでは言い切れないよーな気がする、
と思うのは甘いかしらん。使えるとむっちゃ便利なんだけど。
thread程度には一般性があると思いたい。
> そもそも、ポインタとかファイルポインタを整数型として扱う(or認識する)のは危
> ないから個人的には好かない。
あ、「結局は整数演算」つーのは、言語レベルで直接整数型で
扱うとゆー意味ではなくて、CPUレベルでは整数演算ユニットで
処理することになる、という程度の意味っす。
struct_pointer[index].memberってなコードをアセンブラに落として
みるといっしょーけんめーシフトと加算を繰り返してるのがわかる。
(かもしれない。CISC系プロセッサだと1インストラクションで済んでたりして^^;)
>>22
SISDだったらいらない。SIMDで32bit*4とかだったら用途に
よっては非常に意味あるけどそーゆーのサポートしてるからって
「128bit OS」とは呼ばんよーな気がする。
なんなんだこのスレは・・・
26 ：＞1：2000/11/09(木) 10:16
Ａｐｐｌｅが先に128bit版のＯＳを開発してからでないと
お手本がないのでまだ出ません。
お手本がないのでまだ出ません。
27 ：名無しさん＠そうだ選挙にいこう：2000/11/09(木) 12:10
28 ：Be名無しさん：2000/11/09(木) 13:14
29 ：Be名無しさん：2000/11/09(木) 15:56
31 ：Be名無しさん：2000/11/09(木) 17:27
腐れメーカ開発チームじゃむりだけど
Nextチームが作るならOKってことですか。
Nextチームが作るならOKってことですか。
32 ：Be名無しさん：2000/11/09(木) 17:37
OKかどうかは、まだ発売されてない段階じゃ。
33 ：Be名無しさん：2000/11/09(木) 17:59
大丈夫、どうせすぐ開発のメインは86版のOS Xに切り替わるから。
34 ：Be名無しさん：2000/11/09(木) 19:33
86版はガセだったらしいです。残念。
MacOSXってほんと落ちないですね。何回もＯｍｎｉWeb使ってたとき
でかい爆弾が上から落ちてきたんですが、システムは落ちたことないです。
いやぁ、爆弾出てきたときはびっくりしたです。
MacOSXってほんと落ちないですね。何回もＯｍｎｉWeb使ってたとき
でかい爆弾が上から落ちてきたんですが、システムは落ちたことないです。
いやぁ、爆弾出てきたときはびっくりしたです。
35 ：名無しさん＠１周年：2000/11/09(木) 20:05
>>34
意外とガセでもないかも。
ProjectBuilderのデバッグのメニューにx86というオプションがあった。
マニュアルで確認しただけだけど、これは将来対応しそうな勢い。
まあ、時間はかかるだろうけど。
意外とガセでもないかも。
ProjectBuilderのデバッグのメニューにx86というオプションがあった。
マニュアルで確認しただけだけど、これは将来対応しそうな勢い。
まあ、時間はかかるだろうけど。
36 ：名無しさん＠そうだ選挙にいこう：2000/11/10(金) 02:35
37 ：Be名無しさん：2000/11/10(金) 09:56
てゆうかMacのハード自体がＡＴ互換機になるってハナシだぞ。
38 ：Be名無しさん：2000/11/10(金) 09:58
>>35
x86版MacOS Xが出るか否かは純粋にマーケティングの問題れす。
技術的な障壁はほとんどないと考えていい。(デバイスドライバの問題はあるけど)
# しかしそれにしてもスレッドのテーマ無視無視なPOST続けてるなぁ、わし(^^;
話を強引に戻すと、「汎用的な」128bitOSってのは「現状」存在意義が見当たらないので今後30年くらいは出ないに一票。
# 40億の40億倍(64bit)で足りないデータ(値|サイズ)なんて当面「日常的に」使うとは思えん。
x86版MacOS Xが出るか否かは純粋にマーケティングの問題れす。
技術的な障壁はほとんどないと考えていい。(デバイスドライバの問題はあるけど)
# しかしそれにしてもスレッドのテーマ無視無視なPOST続けてるなぁ、わし(^^;
話を強引に戻すと、「汎用的な」128bitOSってのは「現状」存在意義が見当たらないので今後30年くらいは出ないに一票。
# 40億の40億倍(64bit)で足りないデータ(値|サイズ)なんて当面「日常的に」使うとは思えん。
39 ：Be名無しさん：2000/11/10(金) 11:21
40 ：Bee名無し：2000/11/10(金) 15:11
41 ：名無しさん＠いたづらはいやづら：2000/11/12(日) 01:06
42 ：名無しさん＠そうだ選挙にいこう：2000/11/15(水) 05:02
do do
43 ：Be名無しさん：2000/11/15(水) 10:10
>>39
先のことなんてわからんから、「汎用的」とか「現状」とか
「当面」とか「日常的」とか付けて逃げ道作ってるんです:-)
ま、ディスク容量が年に2倍ずつ増加していったとすると、25〜30年
くらいしたら64bitでおさまらなくなるかなぁ、とは思いますが。
# 30年間線型に増大するとも思えんけどさ。
先のことなんてわからんから、「汎用的」とか「現状」とか
「当面」とか「日常的」とか付けて逃げ道作ってるんです:-)
ま、ディスク容量が年に2倍ずつ増加していったとすると、25〜30年
くらいしたら64bitでおさまらなくなるかなぁ、とは思いますが。
# 30年間線型に増大するとも思えんけどさ。
44 ：ハルマゲドン：2000/11/26(日) 13:29
45 ：Name_Not_Found：2000/12/17(日) 22:20
46 ：Be名無しさん：2001/05/16(水) 18:39
2038年問題って何が起きるの？
8bitのアドレス空間は256Bytes
16bitのアドレス空間は64KBytes
32bitのアドレス空間は4GBytes
64bitのアドレス空間は171億GB
128bitのアドレス空間は3169126500570573503741億GB
4GBはもうすく超えそうだから64bitの必要性を感じるけど、
171億GBはまだ超えそうにないから128bitの必要性は感じないな。
16bitのアドレス空間は64KBytes
32bitのアドレス空間は4GBytes
64bitのアドレス空間は171億GB
128bitのアドレス空間は3169126500570573503741億GB
4GBはもうすく超えそうだから64bitの必要性を感じるけど、
171億GBはまだ超えそうにないから128bitの必要性は感じないな。