ノート:Intel 8086

ページのコンテンツが他言語でサポートされていません。

懐かしいですね。

私の記憶では、メモリモデルは tiny, small, compact, medium, large, huge の6種類ありました。
tiny: code・dataともにnear(code+data<=64Kで、link警告"no stack segment"を無視して.COMに変換)
small: code・dataともにnear(code<=64k, data<=64k で、.COMには変換できない)
compact: codeがfar, dataがnear
medium: codeがnear, dataがfar
large: code・dataともにfar
huge: 初期には存在せず、後で新設された。largeに似ているがセグメント優先で増減。

compactとmediumは逆だったかも知れません。
hugeは記憶が曖昧で全く自信がありません。

2007-03-29 by Vegetamin-Z

なんか記事にもの凄い悪意を感じるんですけれども、いわゆる68000信者の人が執筆したんでしょうか…?(68000愛好者がみんなアンチi8086とは思いませんが)
1978年の時点では1MBはおろか64KBさえも「使い切れないほどの広大な空間」だったはずで、そもそもセグメント機構を「16bitで狭い64KBの壁を無理に突破する仕組み」と捉える事自体に無理があります。あくまでセグメント機構は「目的毎にアドレス空間を分離する」ためのものなのは、後に出たi80386が、アドレス空間の拡張には不要にもかかわらずセグメント機構を採用した事からも明らかでしょう(64KB未満のセグメントの、セグメント以降のアドレスもアクセス出来てしまうのは、単にメモリ保護機構が備わってない為)。i8086の「64KBの壁と1MBの壁の悲劇」は、単に「i8086設計当初i8086が廃れるまでにアドレスが枯渇すると予測出来なかった」事と「アドレスが枯渇対策が後手後手に回りi80386登場まで待たされた」事にあるのであり、セグメント機構そのものが諸悪の根源というのは全くの誤解です。
i8086のセグメント機構により、プログラムのリロケータブル性が向上し、MS-DOSはそれによる恩恵を大いに受けています(実際68000のMS-DOS類似OSのHuman68Kではリロケートのオーバーヘッドがちょっとした問題になっていたはずです)。 また、68000登場はi8086登場よりかなり後になってからの話であり、時代が違うものを同じ土俵で語る事自体がおかしい事なのです。(i4004がCore2Duoより低性能・低機能だからといってi4004をゴミだと非難する人はいません) 122.18.151.116 2008年3月23日 (日) 11:37 (UTC)[返信]
時勢を無視した批判や、行きすぎていると思われる箇所を修正しました。

しかしあなたは、コンピュータ科学(コンピュータ・アーキテクチャ)の観点で、すでに定着した概念であった「セグメント」とはこれっぽっちも似ても似つかないものに同じ名前を付けて混乱(優良誤認と言われても文句は言えないでしょう)させたという負の事実からは意図的に目をそむけていますね。パソコンの所持者の多くが初学者であったために本来のセグメントを知らなかったために、さらに混乱させられ恨まれたことまではインテルの責任じゃないにしてもね。--MetaNest会話2016年8月19日 (金) 13:12 (UTC)[返信]

8080のアセンブラソースコードに一切の手を加えることなく再アセンブルするだけで、8086用のバイナリを生成する事も出来た、とありますが、 参照せよとのCP/M-86をみると、「ほとんど手直し無しで再アセンブルするだけでも動作する」と書かれているので、一切の、とは言いすぎでしょう。 InTheCastle会話2020年11月2日 (月) 15:08 (UTC)[返信]