【真っ黒といわれ】VMware総合スレ Part35【発狂】

本家　http://www.vmware.com/
日本　http://www.vmware.com/jp/
動画　http://www.google.com/search?q=VMware&;tbm=vid&tbs=sbd:1

Player のダウンロード
http://www.vmware.com/go/get-player-jp
http://www.vmware.com/go/downloadplayer

Windows および VMware の EULA の議論は
答えが出ないので避けてください。話題が出されてもスルーしてください。
もし議論したい場合は、法律板かWindows板にでも専用スレをたてて下さい
重複乱立スレを立てる荒らしがいますが、削除依頼などして通報をしましょう

【前スレ】
【真っ黒というと】VMware総合スレ Part34【発狂】
http://anago.2ch.net/test/read.cgi/software/1355202243/

バイトと言えば、そろそろASCIIの呪縛から逃れて１バイト=16ビットな設計のマシンって出んかね
長いこと固定なお陰で補助単位みたいに勘違いしてる人もいるよね
欧米主導のうちは無理か。あっち用ソフトだと文字データ分が丸々倍だもんなぁ

OSレベルでの表示やプログラミング言語の仕様で対応できそうだけど
キビバイトやメビバイトみたいに新しい呼び方を用意して

アジア圏の人間がその気になってOS開発とかしたら、登場しそう

むしろ名称変えない方が単位について考えるいい機会じゃなかろうか
言語仕様云々言うなら、intだってコロコロ変わってるじゃん。同じ様に互換性はオプションで用意すればおｋ

>>444
指摘内容を理解できなかったのか？

>>445
ワードマシンはあんまりメリットないんだけど

「１バイト=16ビットな設計のマシン」ってのがもし出たとして、
既存のワードマシンには関係ないと思うけど

>>448
8バイト互換データ以外に限って言えば、同じアドレシングモードで倍の容量が扱えるというメリットが
まあ実際にはそれ以前に命令体系からゴッソリ見直す事になるんでしょうけど
データの無駄を度外視するなら、いっそ64ビット＝１バイトなんてのも多バイト命令がゴッソリ減って…度外すぎっすね

unicode 2.0の時点で16bitじゃ不足してるから今更16bitにしても同じ問題が残る。
思いきって32bitにしたら既存のascii資産のデータ量が4倍に膨れ上がる。
つまりストレージやメモリ、帯域が4倍にならないと同じ性能確保できなくなるから
デメリットが大きすぎるんだよね。

逆に考えて、ワンボードからマイコンへと同じレベルでの世代交代って事で。
…いや、やっぱりデメリットのが大きいっすね。実現性のないスレチで引っ張るのもアレだし、この辺でどもでした。

汎用機は24bitや36bitとか中途半端なワード単位だった気がする。

>>453
１ビットを互換ビットに使った３１ビット機なら現役でした。とは言っても確か命令だけですけどね。