TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
「 国産PCゲームは下に見てた 」 by 洋ゲーマニア
究極の8ビット機を妄想するスレ Part 10
そんなふうに考えていた時期が俺にもありました
富士通9450がまだ現役です
自分の機種を自慢するスレ
[←F-BASIC386] BASICの進化 [VisualBasic→]
「プログラムポシェット」まだ持ってるヤツいるか
MSXの使い道
1983年末に実現可能なPC part 2
[HC/VTOWNS] 富士通 FM-TOWNS 頂上決戦 [MX/UR]

68K v.s. x86


1 ：2008/09/07 〜 最終レス ：2016/02/10
独立させてみた。
Z8Kや658xx、16Bit〜でもOK

2 ：
68000が良いことは十分知っているが
使いにくい6502や8086で仕事をしてきた人達のほうを
今では尊敬したい

3 ：
色つきのレジスタの方が書きやすいわ

4 ：
結局パソコン界ではx86の勝ちだね。
その原因は何？

5 ：
性能と言うよりソフト資産のおかげ
あと、周辺回路の流用も大きい(8080からの流れ)。

6 ：
過去からの流れを断ち切らなかったからだというのは分かる。
理想を追い求めるより(68000)、その時点で可能な範囲での
適度なもの(8086)を作り上げた方が良い結果が得られるということも学んだ。
マーケティングや運の違いもあっただろう。
で、ここからはこの板やスレにはそぐわないかもしれないけど、
最終的に性能（主にスピード）面でも680x0って80x86に負けてるよね？
この要因はどこにあったのだろうか、と。

7 ：
最終段階だけで比較すれば、それは資本主義のなせる技。開発における投資規模が全然違う。

8 ：
x86 CPUの股間品との競争

9 ：
MicroSoft、巨人IBM
それと国内では両者にすがるNECｗ
これらが独占してんだから他CPUに余地は無いだろうな

10 ：
ビッグエンディアンが馴染めなった

11 ：
>>7
アーキテクチャの問題で高速化が難しいわけじゃなくてお金の問題？
十分に金をかければ68も行ける所まで行けるのかな。
>>10
ビッグエンディアン、リトルエンディアンも好みが分かれそうだね。喧嘩するには面白そうな話題だね。
8bit時代からモトローラ好きだけど、普通に考えればリトルエンディアンが自然だよな。

12 ：
ビッグエイリアンだのリトルエイリアンだの
クイーンエイリアンとリトルエイリアンなら

13 ：
68000はゲーム用途に大活躍したけどな

14 ：
>>11
68020 以降はメモリ間接系のアドレッシングモードなんかが増えたから
その点ではちょっと不利かもしれない。
マルチコアとかは 68K だから難しいとかはないと思うので、それなり
にはいけてたんじゃないかな。
リトルとビッグは好みの問題。
普通に考えれば、ダンプリストが見易いビッグが自然



と考える俺みたいな奴がいても不思議じゃない。

15 ：
俺も初めはビッグが自然だと思ったんだが、
ハードを組むときD15〜D08が偶数番地になってしまうことに気付いて
愕然とした。それは違うだろと。
今は下位バイトが下位アドレスになるのが自然だと思っているリトル信者。

16 ：
>>11
いけるっしょ。それに加えてZ80系もそれなりに発展していたことだろうし。
考えてみ？　今から１０年前にクロックアップに向かずにマルチコアに向いていたら。
いまより高度な実装技術とか光ファイバーバスとか高速RAMとかSSDが先に実現していたら...
OSも腐ったマルチタスクじゃなく最初からマルチコア対応の独立＆同期の仕組みになっていただろうし、
1CPU数コア＋シングルバスで何かやるより16CPU128コア＋マルチ光バスでやった方が楽しかったかもしれない。
128コアが干渉せずサウンドデバイス駆動出来ればオーケストラの各パートを各コアにやらせたってなんて事無い。
（分散コンピューティングの兄貴が出来上がっていると思いねぇ)
CPUは技術計算以外は16bitでも十分だしょ。CPUやデバイスが特化すればもっと楽しかったと思う。
経営的にはあり得ない選択肢だろうけどさ。

17 ：
技術的にもありえない選択 (=妄想) は、自分の日記にでも書いてろよ。

18 ：
あり得ないから楽しいんだろ。
ってわかんねぇだろうなw

19 ：
テメェのオナニー妄想なんてくだらんだけだ、ボケ。

20 ：
68Kの倍クロックは技術的に無理なのかな?

21 ：
妄想なんてくだらん

22 ：
>>20
無理ってことはないだろう。技術があればどうにでもなる。
そうやって無理と言われるようなことx86は乗り越えてきたろ？

23 ：
妄想なんてくだらん

24 ：
↑それはタモリを否定してるってことか?

25 ：
8085→8086って新設計だっけ?
それとも得意のレジスタ拡張だったっけ?

26 ：
8080→8086はそうだが、8080→8085の流れとは別じゃね？
8086に8085の互換性を持たせたモノが8088だし。

27 ：
まあ今更どうでもいい話だけど
> 8086に8085の互換性を持たせたモノが8088だし。
つりかバカとしか思えない。

28 ：
8080の16Bit化後継機が8086、8bit後継が8085と思ってたけど違うの？
8086の後に8085が作られたとか思ってたけど違うの？

29 ：
いやどう思ってようとそれは君の自由だよ。

30 ：
横からだがぐぐった情報を書いとくか。
8080　1974年4月に発表
8085　1976年3月に発表
8086　1978年6月に発表
8088　1979年6月に発表

31 ：
8080 … 80系の8bitCPU
8085 … 8080に周辺プロセッサを統合
8086 … 80系の16bitCPU(86系)
8088 … 8086のデータバス8bit版
おまけ
80186 … 8086の周辺プロセッサ統合+小改良版

32 ：
さらにおまけ
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E5%88%86%E9%87%8E%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E5%AF%BE%E7%AB%8B#i80x86_.E5.AF.BE_MC680x0

33 ：
おれ、CPUの「発表」より日本でいつ「発売」になったかが重要だと思うんだが。
当時リアルに買い求めたユーザでないと判らない点が多すぎる

34 ：
秋葉原価格の動向やホビーユーザの動きもわかればベストだな
そこまで把握してたら、本が出せそうだが

35 ：
>>27
確かに違和感あるな。
ただ周辺ICとの互換性って意味ならある程度わかるかな?

36 ：
まだその話引っぱるの？

37 ：
ネタがないんだからしょうがない

38 ：
「8086に8085の互換性を持たせたものが8088」なんて何処も共通性のないものを
「周辺ICとの互換性って意味ならある程度わかる」のは、>>27当人だけだろ。
一週間前の恥を丁寧に上塗りか。

39 ：
おっと、エスパーレスはそこまでだ

40 ：
確か63Kって有ったよな?

41 ：
8085か。懐かしいな。俺はIntel謹製のSDK-85を自腹で買って組み立てたことがある。
8085の売りは5V単一電源で動くことだよ。マルチ電圧なスイチング電源が高価だった頃だし、
5V単一は電源を簡略化できるということで意味があった。8080は三電源。
8086はあまり売れた石じゃない。国内の大口ユーザといえば、ファナックかな。8085だとTEC。
IntelHex形式のバイナリをL/HでスプリットしないとROMに焼けないのがネックだったのかも。
だから8088が…。アセンブラのソースコンバーター(8080→8086)なんかもIntelは配布してた。
安田寿明のマイコン三部作の３巻目に8085の紹介が載ってて、Intel-Japanに電話かけて
普通に手に入るか確認したことがあったなあ。今は無理ですとか。一般的に入手可能になった
のはけっこう後かもしれない。IBM-PCが正式採用するまで、8080のユーザはむしろZ80へ
流れて、8085には来なかった。8086だって5MHzなら6MHzの選別Z80の方がマシ。という企業
ユーザも多かったね。

42 ：
IBM-PCが8085???

43 ：
じゃなくて、IBM-PC(5150)が8088を採用して出荷する頃まで。という意。ちょうど82〜83年。
CP/M86が動くようになったのは81年頃。70年代末から80年頃までの間の8086のソフト開発
はintelのtool使うしか道がなかった。ああ、CP/Mにクロスがあったかな。CP/M86のASM86
もDOSのMASMにしてもHexコードを出力するためには役不足。制御機器開発向きではなかった。
まともな開発toolが無かったが故に流産したたのがZ8000。YamahaのYIS位か。ソフトが無くて
実機がほとんど出てこなかった。
68000は16bitCPUでは一番前人気が高かったが、初期はtool不足だった。だいたいサンプルが
一番遅れてでてきたし。それでも、83年以降、Mac/Amiga/AtariSTと68K採用マシンが輩出して
から、小規模な言語処理系が86系なみに色々出てきていたようだね。実機があればソフトも
たくさん出てくる例かも。
8/16マイコンの初期は、DECのPDPとかVAXとかがクロス開発に使われることもあったが、
大企業や研究所レベル。8bitCPUはICEなどハードウェアのデバッガが作りやすかったから
選べるほどに色々あった。16bitCPUが16MHzを越えた頃からか、そうしたデバッガが難しく
なって数が少なくなったのは。

44 ：
>>41, >>43
コンシューマ系しか知らんのでしょ？
ICE も 68020/80286 ぐらいまでは普通に使ってたよ。
まあ、数百万レベルだから個人がそうそう買えるもんじゃないけど、ハードから
開発している現場だとあるとないじゃデバッグ効率が全然違うから、普通のまと
もな企業なら設備投資するのが当たり前だった。
ちなみに Z8000 と言えば、'82 に開発された Pole Position が有名。
まあ、8086/68K に比べれば陰が薄いのは否めないけど、流産と言うほどでもない。
あと、俺はバイトで ASM86 使って普通に制御機器開発もしたことあるけど、
> CP/M86のASM86もDOSのMASMにしてもHexコードを出力するためには役不足。
って、どこが役不足だったの？




45 ：
コンシューマ系って何を意味しているかよくわからんけど、産業区分でコンシューマ
というと民生(機器・製品)業界で、早い話、家電メーカーみたいな街の店頭販売される
ような一般製品の業界。対語はインダストリか。プラントから自動工作機械など。他に
ラボ系というか研究開発向けっていうのもあるな。どれといわれても困るけど。
Z8000は、確かMSのXenixにZ8000対応があって、それを搭載したUnix系の開発機器
をZilog自身が売っていたはず。だけれど、終にZ8000用のICEは出る出るといっては
みたものの、作られなかったはず。この点が命取り。Motorola のExormacsではたぶん
68000のICEがあったかも。よく知らない。国内でよく使われていたのはHPの64000。
あとIntelのMDS。MDSのICEは85/88/86を使ったことがある。
ASM86というと俺的にはIntelのASM86。DRIのASM86は確かにHex出力すると記憶し
てるが、リロケータブルじゃない（リンカもロケータもない）絶対番地記述なコードしか書けない。
アセンブラ制御ディレクティブもCP/Mのasm.comの8086焼き直しな印象。
MSのｅｘｅはロードタイムリロケータブルなコードでROM焼き向きではない。comファイルは
CP/Mのcomファイルに似た100Hオフセットなバイナリだが、smallモデルだけ。コード中に
セグメントレジスタに直値すればDataエリアをRAMマッピングできるかも。という位。
MASMはインテルのASM86に近似したアセンブラ記述ルール(segmentディレクティブなど)
だけど、セグメントの扱いがヤワなサブセット。インテルASM86だとストリング命令には
セグメント指定のオペランドが必須だけれど、MS/DRIはいずれも省略OKだったような。
いずれにせよ、OSオンマシン上で走るコードのためのアセンブラだから用途方向が違う
のは仕方ないことだけどね。



46 ：
ネットをうろうろしてたら、アルゴリズム同一な倍精度計算のベンチマークが
あったんで面白そうなので参考までに。アルゴリズムは同じでも、実装言語
が異なる。あたりまえだがバイナリは完全に違う。
CP/MのCBASICが糞遅くて、MSのBASICでもPC版はApple版の2.4倍位速い。
LISA-BASICはAppleIIとほぼ同速度。ｗ 68000は素でも8087+8086と同じくらい
の速度が出せたらしい。それでも当時のIBMの中型・大型は10倍速い。今時
のC2DなCPUなら、たぶん0.07秒くらいか。ｗ
Language　Version　　Rel　　　　　RMS　Err　Time　Bits　Mant　Grd
CBASIC2/Eagle　II　　　　　　　　　　　4.56E-6　　　2740.0s　25.9　24　NO
Applesoft　II+　　　　　　　　　　　　　　　2.38E-7　　　488.1s　33.1　32　NO
IBM　PC/BASICA　(S.P.)　1.10　　　　6.83E-5　　　　205.0s　25.0　24　NO
Applesoft　w/DTACK　　　　　　　　　　1.29E-9　　　　34.6s　40.7　32　YES
Tasc　w/DTACK　　　　　　　　　　　　1.29E-9　　　　　24.5s　40.7　32　YES
IBM　PC/BASICA　(D.P.)　2.00　　　　1.41E-14　　　　962.7s　57.2　48　YES
LISA　68000　BASIC　　　　　　　　　　9.30E-14　　　　500.0s　　54.4　53　NO
DEVELOPMENTAL　68000　PASCAL　4.60E-17　　　250.0s　65.4　53　YES
IBM　PC,　COMPILED　(SEE　TEXT)　2.21E-14　　　173.0s　56.5　48　YES
DTACK　68000　#2,　HALGOL/48　　　4.10E-12　　　23.0s　49.0　48　NO
IBM　PC　w/MICROWARE　8087　　　　9.31E-14　　　21.0s　54.4　53　NO
DTACK　68000　#1,　HALGOL/48　　　4.10E-12　　　19.2s　49.0　48　NO
DTACK　68K/16081　(predicted)　　　1.30E-13　　　　4.0s　54.0　53　NO
IBM　3031　FORTRAN　SAS　(SAME)　　　　　　　　　2.76s　52.7　48　YES
IBM　4341　gp2　FORTRAN　SAS　　　　3.09E-13　　1.86s　52.7　48　YES
IBM　VS　FORTRAN　(S.P.)　V.3　　　1.13E-3　　　　1.41s　20.9　24　NO


47 ：
出典はこれ。インターネット・アーカイブとかgoogleのキャッシュにしか残っていない。
http://web.archive.org/web/20080116151803/http://www.amigau.com/68K/dg/dg24.htm

48 ：
68のICEといえば岩崎の(壊れてて)BreakPointで止まらないICEで開発してたのを思い出す
BackTraceとか殆ど意味無くて、単にLoaderだったｗ

49 ：
>>45
> ASM86というと俺的にはIntelのASM86
だからそれのどこが役不足なの？
.exe ファイルとか .com ファイルの事をグダグタ書いてるのもすごく
素人臭いんですけど。
>>48
まあ、当時の ICE は結構壊れやすかったし、未完成な所もあって、
まともに動かないコマンドとかコマンドの投入順序を変えると動作が
おかしくなるとかが結構あったから、回避するための Tips を書いた
ノートが ICE と一緒に置いてあったな。(w

50 ：
>>49
CP/M86のASM86とかMASMは開発現場では使ったことがない。
intelのASM86が主。PL/M86との併用。遊びでは色々弄ったが。
開発現場で俺はCP/Mは一度も使ったことがない。DOSのクロス
開発は86年以降は少しは関わったかな。いずれにせよ、当時の
現場感覚を説明するのは難しい。だいたい、76-78-80-82-84-
86-88-90と15年間を2年単位で刻めば、現場感覚もそれぞれ随分と違う。
一様な話はできないね。
85年前後は、iRMX86やMTOSがライセンシーの重たさのゆえに、
独自なそれらのサブセットなリアルタイム・カーネルやデバッグ・
モジュールを同僚と共同でスクラッチから書いてた。線形な動作を
しないから、デバッグも、止めてメモリとかI/Oを見て、なんてことが
あまり役に立たない。「ICEはローダー」に一票だが、ハード担当の
同僚にブレークポイントの致命なトリガーピンを数本立ててもらって
落ちない検証とかね。色々大変だったが、面白さ満点だったな。


51 ：
>>当時の ICE は結構壊れやすかったし　…　まともに動かないコマンド
とかコマンドの投入順序を変えると動作が おかしくなるとかが結構あったから
って、いつ頃のどの会社のICEなんだろ？　オリエンタルとかのレンタル
品を使ってたな奴らが、故障品を送りつけてきた。とかありそうだね。
4bitから16bitのデバッグtoolやICE類は色々と弄ったことがあるが、
あれは壊れるんじゃなくて壊すものだね。一番多いのはCPUソケット
に差し込むアタッチメントの足を折るとか逆さしとか。そういう初歩的な
事故で壊すのはたいてい外注のソフト屋。始末書書かせたこともあるなｗ　
ターゲットがまともで扱いを心得ていればそうは壊れたりしないものだ。
俺の近くで「壊れた」ことはないな。
岩崎のZ80のICEなら手元にある。不要廃棄になるんで随分前に持ち
帰ってきたもの。よく知られたことだが、C-BUSのインタフェースに難があって、
ICEが9801を選ぶ。ｗ　386機な9801とかでないとうまく動作しない。PEN-IIな
9821ではダメダメなんで、今は押し入れのゴミと化してるなあ。

52 ：
×レンタル品を使ってたな奴らが、
○レンタル品を使ってたなら、奴らが、

53 ：
役不足だという点。Intel的フルセット記述なソースコードを
DRI/asm86, DOS/MASMに持ち込んでアセンブルするとエラー多発。
それだけの理由だな。可搬性が無いので仕事では使わなかった。

54 ：
今だとエミュなんかでデバッグ機能もそれっぽい機能付いてたりするけど、バックトレース出来る奴は見たことが無い。
z80のiceウラヤマシスｗ　でもうちも先日98FAが死んだな…

55 ：
プローブなんて如何にも破損し易いところはソケット挿して保護するとかデフォだろ

56 ：
>>54
オク見てたら、出物があったよ。PC-9801DA込み。
DAと言うのがミソ。DAがZ80用の岩崎ProIceを走らせるための最速な9801
かもしれない。その昔、486機が出始めの頃、BXだったか、機種名忘れたが
速かろう良かろうで用意した486な９８がダメで、結局DAをわざわざレンタルして
その場をしのいだ。ということが実際にあった。岩崎通信（ガンツウ）じゃないよな。
岩崎技研。今はもう逝ってしまってて無い。
これにProASMと組み合わせて使うのが、98的Z80クロス開発のベストマッチだと思うなあ。
MSXに差し込んで弄りたい人向けｗ
http://page13.auctions.yahoo.co.jp/jp/auction/r41158194

57 ：
>>55
そんなことは開発者の常識だから言うまでもないこと。
ところが、人間には「うっかり」があって、考え事とか上の空で
作業してると、なぜかターゲットのCPUソケットが2段のお重に
なってたりすることがある。ｗ　だもんで、ソケット外しの時に
注意喚起のために、わざわざソケットを2段重ねとかして使って
た奴を見たことがある。
某修理会社から聞いた話では、基板型のエミュレータ
（日電のEVAKITみたいな奴）の電源の±を逆接続して全焼させちまった
基板を修理受け取りしたことがあるとか。ｗ
プロでも間違うときは間違うのが、人間。
マーフィーの法則が流行った頃のオヤジネタでこんなのがあった。
　　『納期が近づくとデバッガが必ず壊れる。』


58 ：
>56 ヤベ、ちょっと欲しいわｗ　２万かー

59 ：
>>51
> いつ頃のどの会社のICEなんだろ？
8086 時代のやつはメーカー忘れたけど、その後の 80186/80286 時代はソフィアシステム
のやつ使ってた。型名は流石に覚えてないけど、PC 連動じゃなくて、PC 機能を組み込ん
だ一体型だったから結構重くて移動が大変だった。
>>53
> 可搬性が無いので仕事では使わなかった。
そんな結論ですか...、アセンブラに可搬性を要求すること自体に無理があると思うが...。
>>58
ノスタルジーにひたるなら値段はその人の思い入れ次第だからなんとも言えないけど、
冷静に考えたら今時２万の価値はとてもないと思うよ。

60 ：
>59 うん。２万はちょっと考えちゃうよね…
丁度今PC88の小物開発とかしたい気分だったから、バックトレースとか使えるんなら、と一瞬揺れたｗ

61 ：
>>59
ソフィアは新宿NSビルに移る前、三鷹だったか、あの辺に本社があったころ一度行ったことがある。
80年代はじめ。in-II,in-IIIなんていう8bit系開発機器を出し続けていた地道な会社だね。。in-IIは黄土色
のでかい筐体だったな。当初からCRT一体型+KB、OSも独自とかにこだわりがあったようだね。
186/286の頃だと86年か87年位か。その頃だとSA-700だったかな。5’位の小さなCRTと8’FDD内蔵の
小型オシロサイズのポータブルデバッガで頑張っていたように思う。一度だけランニングテスト用に使った
ことがあるよ。ソフィアには筋違いの上司が転職してNo.3位のポストになっているという噂を風の便りで
聞いたことがある。今どうしているのかは知らない。
86のコードをガリガリ書いていたのは80年代はじめ。おっしゃる通り、アセンブラに可搬性を
求めるのは面倒至極。せっかくMDSがあるんだからとそこから動かなかった。動けなかっただけｗ
>>60
揺れてるくせにｗ Z80が青春の記念碑なら2万は安いだろ？ さすがにDA用のブラウン管はいらないが。　

62 ：
> その頃だとSA-700だったかな。
ああ、確かにそんな名前だったような気がする。

63 ：
>61
あれさ、今気づいたけど「更新済み: 11月 30日 11時 54分」って、約一年 回転寿司状態だったと解釈していいのかね？
もっと待てば安くなるかな…　DA付きで１万なら買うｗ

64 ：
> あれさ、今気づいたけど「更新済み: 11月 30日 11時 54分」って、
> 約一年 回転寿司状態だったと解釈していいのかね？
そんなわけないと思う。
入札履歴 - 全ての入札履歴 を見ると
[10月 7日 23時 54分] オークション開始。数量： 1 で 20,000
ってなってるから。
あと、この出品者 76件も出品してるけど、全部開始価格高すぎ。
Gateway のマウスパッド 2,000円とかソニーの古いカタログ 5,000円
とか、とてもあり得ない。

65 ：
ですよねー。流石に一年はないか・・・
欲しいといえば欲しいけど、無くても全然構わない物だし必要でもないから、待とうｗ

66 ：
68060積んだパソコンを富士通(PFU)が出してたね。
パソコンと言えないほど高かった(オフコンを名前変えただけだけどね)

67 ：
今ってまだ68K系のCPUって作ってるの?

68 ：
直系子孫であるColdFireは現役でしょう？
快適なアセンブリ言語でのコーディングライフを満喫できるよ！

69 ：
>>40
HD6309だろ
もしくは
HD68HC000はあった

70 ：
680000(64Bit)を妄想してみる、とか(~_~;)

71 ：
>>70
面白味はないな。
多分レジスタを増やすだけだろうし。
命令もブランチ命令とか増やしたりしても、しょせん、だし。
まあ、その方がすっきりしてて扱いやすいだろうけど。

72 ：
32bitのまんまでいいからSIMDとGTE追加のが

73 ：
88000ってモトローラだっけ?

74 ：
そうだよ

75 ：
68K系の魅力はコードの上位互換性を無視して新しいコード体系を
割り当てる所にあるよな
SIMDなんかすっきりとすると思う
これにARMのThumb命令なんかを組み合わせると最高
x86はもはやコードの汚さはとうに我慢の限界を超えている
特にx86-64なんかはひどすぎる

76 ：
x86-64はIA32命令にプリフィックスを置くだけとか、確かにコード効率なにそれな感じではあるなあ
レガシー故の不幸というか、それでも真性RISCよりはコード効率マシな命令が大半だしとでも痩せ我慢するしか
恨むならAMDを恨むしかないねぇ…
x86命令自体は当時汚いとかさんざん言われたけど、μopに分解して実行するようになってからは
むしろコーディング段階で符号化済みのコンパクトな命令セットとして逆に高評価とか、
まあ評価なんざ世相でどうにでもなるみたいな笑い話で

77 ：
初歩的な質問で恐縮だが、
ゲーム機とかに、68Kが多かったのはなぜ？

78 ：
互換性を気にする必要がなかったからでないの

79 ：
MPU自体が優れていただけでなく、回路設計もしやすく、部品数も少なくて済むから。
最初は高価ではあったけど。

80 ：
86系はPC向け需要で高止まりしていたから
メガドラ以降値下がりした68kより割高だった
開発環境の充実って意味では86系が優れていたけど
コピー対策の意味でも非主流系が望まれるという要素も

81 ：
ハンドアセンブルするなら6809だべさ

82 ：
>>78
それでSONYは四苦八苦してるけどな。

83 ：
んぁ

84 ：
今でもだけど、インテルはライセンスしないからな。
AMDはどうなんだろ?
苦しくなってきたらやるかな。

85 ：
65816も忘れないでやってﾁｮ

86 ：
単純に6809からの流れとアドレス空間とグラフィックの親和性でしょ
MDで値下がりしたってMDが意識したアーケードは既に68000なんだし
MDで下がったから使われ始めたわけじゃない

87 ：
6809 と68K 使いました。
どちらもレジスタ・命令ともにわかりやすかった。
そのかわり、裏技は少なかった。
アーケードでは、やはり68Kの、32bitデータの扱いやすさが良かったのでは？
内部16bitでも、アセンブラレベルで16bitの制限気にしなくて良かったし。
特にメモリアクセスとか。
ゼビウスの頃は、Z80とか、とにかく裏技使ってでも速く走る事が大事だったけど。

88 ：
そこで70に戻る(~_~;)

89 ：
ふむ。
世代・時代的に違うけどね。
ゼビウスなんか、Z80　基盤5枚組みなんだったっけ。
そういえば、Z80 二基以上搭載PCなんてなかったなぁ。

90 ：
PC-8801は2つ乗せてなかったっけ
まあ1個はFDD用だったけど、使おうと思えば使えたはず

91 ：
ああ、たしかに。
シーナがそれであの高速出したって記事みたなぁ。
その点、FM-7 のサブCPUは、直接的には、まったく
2個目として使えなかった。
クロックアップバージョンもなかったし。
スプライト使えるVDP載せてたらなぁ。
って、すでにチップの話から外れてるww

92 ：
>>59
＞PC 連動じゃなくて、PC 機能を組み込んだ一体型
PC-AXが入ってるやつだな。
キーボードがCRTのフタになるやつ。

93 ：
>>89
MZ3500とかFP5700とか、有ることは有るぞ。
もっともサブをI/O制御やメモリ管理に使ってたけれど。

94 ：
あ、そうだっけ？
MZ-2500って、Z80B 　6MHz 一個だとおもってた。
Z80って、制御用にも使いやすいのかな。88のFD制御にも使われてたしね。

95 ：
使いやすいというか、値段が安かったからというのが一番大きいな。
業務用ゲーム機・パチスロ機向けに各セカンドソースが大量生産してたこともあり、
カスタムチップは言うまでもなく周辺LSIに比べてもZ80ははるかに安かった。
当時パチスロ機で6809使ってたのは一社だけだったな。

96 ：
>>94
1000足りないぞ。

97 ：
Z80x2って一個メインにしてもう一個はメインのZ80のアドレス管理してるようなもんばっかりだったし。

98 ：
>>97
6809でも似たようなもんだし。
6809でちゃんとマルチプロセッサしてんなーと思ったのは
ナムコのアーケードゲーム基盤くらいだったか・・・・

99 ：
まっ、8bitCPUの最初の限界はアドレスだからねえ。
このせいで16bitCPUへの移行が早まった、と思ってる。

100 ：
実際、初期の16bitCPUなんて
処理能力では8bitと大差なかったしな

101 ：
アドレスについては、メモリーが安くなるのが早かったのもあるな
あれば当然使いたくなる、でもバスが狭いと

102 ：
なんか、最近8bitの話ばっかだな。
16bitのスレなのに。

103 ：
昔68000のワンボードマイコン作って、CPM/M68を移植する記事にあこがれたもんだ
で、最近x68kコンパクトのを2台オークションで買ったんだよね
でもこいつ、コンデンサーがそのうち壊れる事で、有名らしーんだよ
先の雑誌まだ持ってるから、ばらして部品とってワンボード作ろうかな
いまさら不便なもの作っても、とも思うけど
憧れを実現して男になるか、大人として合理的に生きるか
あなたなら、どうする

104 ：
x68kばらすのもったいねー
メガドラかピコの初期型でも68000は取れるし、未使用CPU単体でも500円ぐらいだと思うよ。

105 ：
x68のはソケットでついてるから壊さなければ戻せるんじゃね？

106 ：
コンデンサぐらい自分で付け替えろよ。

107 ：
その前にx68kのは400milパッケージだから自作はしにくそう。

108 ：
400milてのは変か。ふつーのDIPよりもちっさいやつね。

109 ：
030系は?

110 ：
ペンティアム辺りって互換機含めもう作ってないの?

111 ：
なんで自分で調べないの？馬鹿なの？死ぬの？
http://www.intel.com/products/embedded/processors.htm?iid=embed_portal+hdprod_processors

112 ：
↑なんか変なの涌いてるね。

113 ：
68Kの最後って68060だっけ?

114 ：
ちがうよぜんぜんちがうよ

115 ：
じゃあなに?

116 ：
一応 Coldfire というのがあってな

117 ：
Coldfire未だに車の電子制御用に使われているね
ARMほどではないが結構資産がある

118 ：
なんだ、サブセットか。

119 ：
じゃあなに?

120 ：
見捨てられつつある過去の異物。

121 ：
ジャアニーさん

122 ：
東芝に12bit CPU有ったよね。
まあ、8bitに毛が生えたような奴だったが。

123 ：
LKIT-12

124 ：
LKITは富士通

125 ：
富士通というかPanafacomだな。
今でこそ富士通下のPFUだけど、当時のLKIT-16とか松下系の石多く使われてた。

126 ：
そりゅあ、当時は半々だったからな。
同じ半々のユーザックと一緒になってPFU。
名前は1/3づつだが出資はそのまま足して2:1:1。
もっとも、パナは数年前に手を引いて今は3:1になったが。
…Pいらんじゃないか(~_~;)

127 ：
今、PFUってなにやってんの?

128 ：
HHK作ってんじゃねーの？

129 ：
i-フィルターの再販してるよ。

130 ：
8800って16bit?

131 ：
8bitの方は変なのが涌いてるなあ。
ひょっとしてふたりぐらいかな?それとも一人で自演?

132 ：
最強君は一人だよ
もう長いことわざとずれたこと書いて反論を待つという
釣りをやってるよ

133 ：
ま〜ったり(~_~;)

134 ：
はっはっは。
さすがにZ80厨はこっちには来れないな。

135 ：
Z80最狂！！

136 ：
>>132
わざとじゃなくて本当に無知なんだと思う

137 ：
井の中の蛙って可哀想だよな
妄想から一生抜け出せないわけだから

138 ：
いつもZ80連呼してるやつって一体どういうやつなんだよ
1年ぐらい放っておけば消えるのか？

139 ：
>>138
あまり長く続くようなら規制議論板に通報しようぜ

140 ：
>>139
ってか、昔からいるよな。

141 ：
結局68Kは020辺りで止めといて680000?64bitCPUを作るべきだった。

142 ：
030って87年だっけか
当時64ビットプロセッサの需要なんて影も形もないだろ

143 ：
8086が嫌われた原因はセグメントモデル
8086が普及した原因もセグメントモデル

144 ：
いくら16MBフラットメモリ空間とか言っても、
実際に載せるメモリが数百KBとか
せいぜい1〜2MB止まりの時代だしねえ
通信どころか広帯域のファイルI/Oですら
一度に64KB以上もバッファを取ることなどまず無い時代、
GVRAMさえ1プレーン64KB越えなどまず無い時代に
セグメントの制約で実現を断念するようなものとなると
実際何があったかってお話
68kは010ですらベクタの扱いに互換性が無くてOS側で対処が必要だったし、
020もさらに専用にコード書かないとOSうら動かなかったし
CPU1基でいいシステムでもバスコントローラを外付けしなければならない高コストCPU
030でやっとそのあたり改善されたけど、386と比べるともうな…って感じだし
040に至っては最後まで量産品が出てこなかった欠陥石
そりゃ負けるべくして負けた、としか言いようが無い罠
まあ68kは夢だけは見せてくれたよ

145 ：
CISCだろうが、RISCだろうが、あまり関係なくなった現在でも、
680x0の本来の設計思想は良かったと思う。
しかし、互換性に関しては680x0は屑としか言いようがないな。
夢だけ見させてくれたという意見は>>144と同じだな。

146 ：
セグメントによるメモリ制限は頭痛の種だけど、リロケータブルなプログラムが簡単に作れるのは素敵だと思う

147 ：
組み込み系だとそもそもコードと固定データはROMに載ってたり、
ただ読み込みが遅いだけでなく8bitバスで繋がってたりし兼ねない勢いで、
そこへ68系を使うに至っては悪夢に近いものがあったりした罠
基本設計の美しさだけならMIPSやPowerの方が遥かに美しいし
だけどそんなものは実際の製品に納まってしまえば外からはどうでもいいお話で


148 ：
セグメントも結局テーブルやバッファ参照のときに
意識してパタンと切り替えてやれば済む話で、
ROMとRAMが混在してたりバンクメモリ切り替えまくったりするような用途では
ポインタの有効範囲を明示できるって意味でも意識上むしろ楽だったくらいで

149 ：
>>142
需要なんて関係ない。
むしろ無いうちから始めるのが吉。
68000だって32bitなんて必要無い時に作られた。
もちろん作ったとしても68000のときと同じで欠陥だらけだと思うけどさ。

150 ：
>>144
何勝手に個人用のコンピュータで使用する事だけを前提にしてくるわけ？
ﾏｼﾞでかなぐり捨てンぞ？

151 ：
６８ｋキチこええｗｗ

152 ：
>>151
アホはよくほえる。

153 ：
68000使ってたときはセグメントみたいな簡単に使えるアドレス変換機構がほしかった。
V50使ってたときは64K超えてるセグメントが欲しかった。
今はもうアセンブラ使わないしメモリ管理はOSの仕事になっちゃったから、どうでも良い。

154 ：
68000はPC相対関係充実してるからセグメントみたいな方法で
アドレス管理する必要は感じなかったな当時。

155 ：
マルチスレッドな処理をアセンブラで手書きすると、欲しくなると思うよ

156 ：
>>154
そもそも、相対アドレスとか絶対アドレスとかを意識しなくてもプログラムできるのがセグメントの利点だと思うのですが...

157 ：
セグメント自体がセグメントベース相対だからぬぇ…
ベースがPCみたいに変化し続けるレジスタじゃない分、使いやすかった。

158 ：
相対アドレスなんてアセンブラが勝手に計算してくれる

159 ：
16bit幅で4bitオフセットだったから
使いもしない馬鹿がブリブリ文句だけは垂れたけど、
68kで24bitや32bit幅のセグメントが存在してたら
神とか言ってたろうにな

160 ：
俺は単純にＣ言語との親和性からセグメントが嫌いだった
確かにサイズがデカく取れれば便利な機構だとは思うが実際アレだったから

161 ：
『PC相対』な位置にデータが有る、という考えを持つこと自体がアレだよ、間が抜けてるよ。
ROMに置いておくべき固定データならともかく、RAMに置くデータやデバイスのレジスタはPC相対という考え方で位置を決めてはイカンよ。


162 ：
タダでさえリロケータブルがやりにくい68kでPC相対って何の冗談？

163 ：
システムコールやI/O叩きROM参照以外を全部PC相対にすればリロケータブルになる、
シンプルで合理的な実装だと思うが。

164 ：
マゾいだけだな

165 ：
PC相対でもデータの位置がコードの位置に縛られる事には変わりないけどね。
レジスタの本数的にPC相対に拘らなくてもなんとかなるっちゃなるけど、やっぱり作る物によっちゃセグメントライクな機構があれば便利。

166 ：
そういえば８６といえば
最近、トレノ・レビンが話題になっているね。

167 ：
なってないよ。
終わり。

168 ：
データと機能に関連性が有る以上、近くに置いて一つのモジュールとしておくのが自然。

169 ：
つまり、セグメントは一番自然な形である

170 ：
コードセグメントとデータセグメント・スタックセグメントは独立指定だが…

171 ：
マルチスレッドはどうなるの？
機能と関連あるデータをコードとまとめておくってことはスレッド分コードも展開するの？

172 ：
>>167
【企業】ハチロク復活！ トヨタ、小型FRスポーツ「FT-86 Concept」　水平対向4気筒　6速MT　中高年の車好きに向け★１２
http://tsushima.2ch.sc/test/read.cgi/newsplus/1255107659/

173 ：
>>172
本気にしてるとは驚いた。
かわいそうな奴だな。

174 ：
68000って信者が言うほどすごい石じゃないね。
自己書き換えしないとマルチスレッドに対応できないなんてｗｗ


175 ：
自己書き換えなんかいらんだろ、どんな実装だよ。
タイマー割り込みの時レジスタやり繰りして切り替えればいいんじゃね。

176 ：
同時期の8086よりは明らかに上

177 ：
その後のクロックアップ競争ではx86の一人勝ちであるが

178 ：
>>176
「仕様書の上では」が抜けてね?

179 ：
>>176
「仕様書の上では」が抜けてね?

180 ：
68000 VS 8086/186 処理速度でも機能面でも上回り
68020 VS 286 処理速度で負けて機能面で並ばれて
68030 VS 386 処理速度は勝てたけど機能面で追い抜かれ
68040 VS 486 処理速度も機能面も突き放された、おまけに最期まで試作だけ
030のMMUなしエディションが存在する時点でメモリ廻りの作込みが弱いとさらけ出してるような物だし。

181 ：
86はセグメントもどきがある時点で汚い設計
その後も汚いリホームの積み重ね
ただそれが人間にとって使いやすかったりする

182 ：
>メモリ廻りの作込みが弱いとさらけ出してるような物だし
中身見たような言い草だな。何が弱いのか問いたい。

183 ：
>>181
インテルの社訓は「互換性か死か」だから仕方なかろう
互換性を無視していいならItaniumみたいな例があるが
さっぱり売れないだろう

184 ：
しかしなんでこんな素人が混ざってんだ？>>178
思いつきで語ってるのかな

185 ：
>>183
Itanium以前にi432という黒れｋ

186 ：
>>182
仮想メモリとそれに上乗せする形で実装される仮想マシンが、MMUが外付けであることによる技術的にどのようなメリットとデメリットが存在しようが、システムを使う立場から見れば弱い。
モトローラのプロセッサはエンジニアに本来なら払わなくてもよい本質的でない余分なこと、MMUの有無を意識すること、を強いている。
ライバルであるインテルのプロセッサは386以降ならエンジニアは同じ手法で利用できる仮想メモリ、仮想マシンの機能があるのが当然としてシステムを設計できる。
68030が、メモリ管理というOSが必要とする根本的な機能において、すべてのエディションで機能的に全くの同一でないというのは弱点以外の何者でもない。

187 ：
ああ、付けるなら全部付けとけって事ね。組み込み用の廉価版なら要らないとか
考えもあったんだろうさ。なんか欠陥でもあるのかと思ったよ。
作り込みが弱いってのは脳内の妄想から出たって事ね。叩きたいからって適当
な事書いちゃ駄目よね。

188 ：
>>185
i860を忘れ(ry

189 ：
組込用廉価版68030載せてたパーソナルワークステーションｗ

190 ：
それじゃHP1も奪えないよ(失笑)

191 ：
低レベルが住みついてることはわかった　189

192 ：
680x0はもともとアドレッシングモード多いしアドレスレジスタの本数も多いからMMU要らないでしょ。

193 ：
MMUが無いプロセッサはゴミだってさ。
286はMMUが無いからゴミだって68信者が言ってた。

194 ：
ワード’信者’を使う人、コテつけて

195 ：
荒らしって奴は基本スルーなんだが、スルーしすぎて住人がいなくなっちゃう事がよく
有る。過疎スレなんかでは特に顕著。そうなるとスレの進行が止まってしまい機能
不全に陥ってしまう。大事なのは住人が散ることなく荒らしをスルーするという事が
求められるわけですよ。MSXスレなんてひどいもんでしょ。
対話でいなくなった荒らしはいないと言うけどスルーでいなくなった荒らしもあまりい
ないけどね。NGにぶっこんで放置するしか無い。機能不全よりはマシだから。

196 ：
どこの話かわからんことを突然提示して、つらつらと無差別相手にに恨み言をたれるのが
この68粘着叩きの特徴みたいだな
どうやったらこういう陰気落武者が生まれるのやら

197 ：
彼が叩く事でスレが延びてた側面もあるのかもな、別に伸びなくてもいいし
キチガイがデンパ撒き散らすスレなら落ちてもかまわんがな

198 ：
>>180
68040はおろか68060だってちゃんと製品出てるんだが?

199 ：
MC68060って出荷されてたの？
初耳。

200 ：
適当にググってみたが
http://bboah.claunia.com/mc68060.html
MC68060は1999年に出たとあるな

201 ：
MC68060RC60なら1万個単位でフリースケールが今も普通?に売っている
MMU/FPUありの75MHz版のMC68060RC75が見つからず
XC68060RC75も入手困難だったという話に尾鰭が付いたんだと思われる

202 ：
うちにもあるが、MC型番の68060は昔から普通に流通してるよ。

203 ：
どっかで小売してるの？

204 ：
Digi-Keyで約7万だな
注文は10個単位のようだが

205 ：
060って結局搭載パソコンは出てないよね
アクセラレータで060搭載したのはあったように記憶してるけど

206 ：
個人レベルのパソコンではないと思うけれど、
富士通のKシリーズ等には68060を載せてる機種もあったよ。
MPUアクセラレータはAmiga、Macintosh、X680x0とかに出てたね。

207 ：
FM-Gでなかった?

208 ：
時代的に060のせるならPowerPCで、しかしMacと競合して勝ち目がないからPC互換機に、というシナリオだろうか？
それとも非PC互換機路線では商売にならないという判断から?

209 ：
って言うより、060が出る以前にモトが68系開発止めてたから次がないのが判ってたからじゃないの。
AT互換機は簡単に作れるし、無理して引き伸ばす必要も無いってことじゃないのかな。

210 ：
新たに、ならAT互換機だろうし、68K系使ってたとこはどうせ変えるならAT互換機にってことか。

211 ：
『腐ってやがる。（市場に出るのが）遅すぎたんだ』
『68kには夢があったぜ』
『ああ。短けぇ夢だったがな』


212 ：
PowerPCの開発を発表してからというか発表するちょい前あたりからモトローラは680x0をないがしろにしてたよな。

213 ：
68(CISC)じゃ勝負できないからPowerPC(RISC)に乗り換えるぞ！
…悔しいがIntelの技術だか企業体力だかは凄かった…orz

214 ：
モトは元々売る気が無かったんですよ

215 ：
バグをそのまま放ってたりと、本当に見放されてたもんな68kは。

216 ：
>>213
んなもんはないよ。
IBMが採用したから脚光を浴びたラッキーボーイだよ。
昔も今も根性は悪いしね。

217 ：
68kが時代が下がるとともにゴミと化したのはモトローラの方針の為。

218 ：
まっ、初めからいわれてるが、68Kは32bitで袋小路。
だからこそのPPCだったのかも知れんが、発想まで違うとユーザーは愚かディーラーまで戸惑っちゃったからね。
6809から16Bit、32Bit(そして64Bit)と地道にアップしていった方がよかったんじゃないのかな。
そしたら(細々でも)生き延びてたかもね。

219 ：
それもあるけどもともとの素性がよくなかったんだろうな

220 ：
えーっ、素性はいいでしょ！？

221 ：
という幻想だったのさ

222 ：
Intel派の人はアセンブラレベルのソフトを書かないのかな…

223 ：
アセンブラでセグメントと格闘したくないですぅ

224 ：
プロテクトモードとか勉強するきのもならないですぅ

225 ：
アセンブラで書く必要がないところまでアセンブラでしこしこと手間かけて書くのはアマチュア、プロはやらない愚行。
どんなプロセッサによらずね。

226 ：
必要なところだから困ってるのさＪＫ

227 ：
x86でオールアセンブラ！
悪魔の所行だ!
インラインアセンブラで済ませられるレベルまでが許容範囲。
MS-DOS環境なら何度かやったことあるけど、今はもうノーセンキュー。

228 ：
アセンブラで問題があるのは移植性くらい
意図がはっきりしやすくむしろ保守性は高い

229 ：
つか、アセンブラこそセグメントが本領を発揮する場じゃないのか?
Cでプログラム組んだら、nearとかfarとかhugeとかで悩まされるけど
セグメントモデルではないプロセッサでリロケータブルなプログラムを作るには、リロケータブルなコードを書く必要があるだろ?

230 ：
まあ当時だったら確かにアセンブラ使うのが一番だったんだろうけど、ねえ。
今だとOSとか、ハードに近いとこでもほぼCかC++辺りじゃね?

231 ：
アセンブラの方が保守性が高いとはこれまた昭和脳ですな

232 ：
ブーとローダーとかコンテクストスイッチとか
割り込みハンドラ（中身じゃなくて受け渡しする部分ね）なんだよ〜
68kの世界に引きこもってるからいいけどさ…

233 ：
x86のプロテクト周りの初期化と、セグメントを超えるCALLとRETやINT、IRETの処理はもう面倒の一言に尽きる。
その辺の処理を書き始めたらOS作るのと大差ないから。

234 ：
アセンブラの方が保守性高いって、ほかのどんな言語使ってんの?
ひょっとして16進数べた打ち？

235 ：
>>233
ビンゴ…68Kだと楽なんだけどね…

236 ：
>>233
納得しかけて気が付いた
それ、OSの仕事なんだからしょうがないだろ?

237 ：
ふと考えたんだけど、なんで8Bit→12Bitにならなかったのかな。
アドレス8Bitのときと同じで倍にしておけば24Bitまで使える。
VRAMマッピングしても充分なエリア。
漢字だって1WORDで扱えるし。
やっぱり舶来文化じゃあ漢字?面倒だから字二つ使えよってことなのかな。

238 ：
>>237
１２bitCPUは昔のレスで秀逸なのを読んだことがある。
漫画だか小説だかは忘れたが、その人の作品に使うためのもので
日本でコンピュータが発展した架空の世界。

239 ：
究極の8ビット機を妄想するスレ
http://bubble4.2ch.sc/test/read.cgi/i4004/1009359454/
>615 名前： ナイコンさん 投稿日： 03/04/29 08:47
>
>コンピュータなるものが、日本原産だとしたら
>http://pc.2ch.sc/test/read.cgi/os/994589053/
>
>>80 名前：Be名無しさん[sage] 投稿日：03/03/11 15:33
>>5年くらい前に、異世界もののゲームに使う設定として作ったコンピュータの規格がある。
>>
>>12ビットワードCISCで、アドレス空間16メガワード、メモリバス・データバスとも24ビット幅で
>>4キロワードセグメントのMMU搭載CPU、動作クロックは2MHz、メモリは旧型が500kHz、
>>新型は1MHz駆動で、いずれも不揮発性。
>>
>>外部記憶は不揮発性電磁気メモリ（バブルメモリのようなもの）のカセットモジュール
>>（高価で容量は少ないが、高速）と磁気テープ（シーケンシャルアクセスのみだが安価）。
>>
>>プリエンプティブマルチタスクOSが稼動するも、UIはCUIのみ、
>>社会環境としては都市部では4096wps(word per second)のパケット回線が敷設済み。

240 ：
>616 名前： ナイコンさん 投稿日： 03/04/29 08:47
>>基本的にこの構成のまま(小幅な改良は続いているが)実に半世紀近くもこのままで
>>安定してしまった世界…というのを想定した。
>>
>>感覚的には、パソコンが8bitから16bitに移行する端境期の雰囲気のままと思って良いかと。
>>
>>
>>この世界の言語は日本語のアナグラムで、コンピュータへの入力は母音5音＋子音10音
>>＋記号等の＋αのキーボードから音節−文節変換で記述、
>>表記は縦書きで右から左に流れ、表示は初期にベクタースキャンCRTが使われたものの
>>すぐに廃れ、主流はレーザースクリーン。
>>
>>技術世代がアンバランスなのは、技術の更新が遅いのんびりした世界という設定から。
>>社会環境から風俗、技術背景、果てはこのネタのコンピュータの命令表まで作ったけど、
>>企画そのものがポシャってしまい、日の目を見ることはなかった…
>
>12bitと変則的だが、なかなか面白そうな発想。
多分これだな
引用元のスレはさすがに行方不明だった

241 ：
4096文字、足りないね

242 ：
東芝の12Bitってどうだったんだい?

243 ：
最初DECのミニコンは6bitだったそうな

244 ：
DECのPDP-8は12bitワード/アドレスらしいが ALUは6bitだったのかな

245 ：
>>212-213
>PPC
88000の事も思い出してあげて >_<
親に捨てられた不憫な子

246 ：
全盛期はｽﾊﾟｺﾝやNeXTに採用されてた68k

247 ：
そう言えばeZ80がアドレス24Bitだったんだよね。

248 ：
Z80000ってのも有ったとか。

249 ：
>248
Z80000って32bitの奴だろう。

250 ：
なんか、68k出た頃の32ビットのプロセッサはアドレス幅とレジスタサイズだけ大きくしただけであとはお茶濁し的な拡張だな。
今の感覚で見ると。

251 ：
ん?
お茶濁し程度だから使いつづけられたんだろ?x86


252 ：
大は小をかねる時代だったからだろう 68ｋ

253 ：
継続は力こぶ。

254 ：
せめて、倍クロック技術を使った68Kが出てたら多少寿命が延びたのになあ。

255 ：
インテルや互換品メーカーが倍クロックとか投入したのは競争してたから。
競争が成立するぐらいニーズがあった。
68kの倍クロックを開発したとしてもどれだけ売れたかな

256 ：
キリ番ゲット。
むかし、nifの壁でキリ番競争やったっけ。

257 ：
PowerPC参入前のモトローラーって倍クロックモデルにするぐらいなら命令当たりのクロック数を半分にするという方向ですすんでなかったっけ?
プロセッサが早くなってもプログラマはたいして楽にならない、機能が増えににゃゴミ屑だと同僚に愚痴った覚えがあるんだが。


258 ：
確か、68Kって力任せワンクロックじゃなかった?

259 ：
１クロックになったのって０２０からじゃなかったっけ?
６８kとか０１０だと結構クロック消費してような気がする。
x８６に比べればぜんぜん少ないけど。
６８０x０のデータシートが行方不明だ。
３８６／４８６のはあるのに。

260 ：
MC68000はどんな速い命令でも最低4クロックでしょ。

261 ：
>>257
x86 でクロックダブラーが入ったのは 486DX2 から。
その前の 486DX/SX で既に基本命令１CPI を実現していた。
そもそも命令あたりのクロック数は減らしようがない。
>>259
68020/68030 は最低でも２クロックかかる。
１CPI になったのは 68040 から。
68000 は最低４クロックで 8086 も同じ。
8086より68000のほうがクロック数が少ないということはない。


262 ：
２５９だす。
さんくす。
３８６のクロック浪費（！）の印象がでかかったから勘違いしてたよ。
この休みに６８０x０のデータシート発掘できれば嬉しいな。
ISBNコードの有無は忘れたけど、値段が入ってなかった非売品。

263 ：
レジスタ数とレジスタ幅以外は総てにおいてx６８に劣るのが６８０x０。

264 ：
しかし、680x0の互換性のなさってどうしようもないな。
初期の設計が美しかっただけに残念だ。
一方のx86は当初は設計が醜い石の代表だったけど、
そのころから互換性はしっかりしてたもんな。

265 ：
CQの20のユーザーズ・マニュアルなら持ってる。
3.5千円って、なんでこんなの買ったんだろう?

266 ：
68kは潔癖すぎるがゆえに醜い進化を拒んだのだろう

267 ：
まともな互換性も維持できないクソ設計が綺麗だぁ?
味噌汁で顔洗ってきやがれ。

268 ：
ところで68Kってデュアル化とか、マルチ化って出来たのか?

269 ：
020以降はSMP対応
まあ実装するとなるとアホかって程高くつく事になる訳だが
x86でSMPに標準対応したのはP6系以降
チップセットの方で対策して486やP5でSMP機の実装もあったけど

270 ：
じゃあOS的には?
って、68KのOS自体よく知らないけど。

271 ：
UNIX系以外は記憶に無いなあ
それも020以降しか
86系も結局UNIX互換系かNTになっちゃうのか
486やPentiumを1000個とか積んだ
今でいうクラスタ系のHPCもあったけど、OSに何を使っていたかまでは知らん
ひょっとしたら386でもやってたかも

272 ：
オッカムとかってそうじゃなかったっかな?

273 ：
そう言えばX86も68Kも当初の周辺チップって単機能ばっかりだったよね。
チップセットっていわれる物はいつ頃から出てきたの?

274 ：
x86系の最初のチップセットは486向け(420xxシリーズ）
68系は標準機的な存在が無かったから恐らく無いのでは
020系のバスコントローラはバスコントローラであってチップセットではないし

275 ：
ここは重複スレです
本スレ
http://gimpo.2ch.sc/test/read.cgi/i4004/1154007686/

276 ：
>>275
自演野郎しかいないスレなんかいらねーよ。
スレ数が物語ってるな。
あんまり嫉妬すんなよ。

277 ：
スレ数?

278 ：
んな馬鹿にかまうなよ。

279 ：
63109なんて有ればなあ。

280 ：
16bitアキュムレータx4(各々2個くっつけて32bitとして使える)
インデックスレジスタ、スタックポインタは32bit(実アドレスは24bit程度かな)で各々4本。
(スタックポインタは2つで充分?)
ダイレクトページレジスタはどうなるのかな???
コンデションコードはそれなりに追加。
こんなもんでも68Kと比べたら半分ぐらいかな。

281 ：
80186って鬼っ子なの?

282 ：
V30という強力なモノマネ師が居るせいで不遇なのだよ。

283 ：
80186は余計なPICやDMACを混載しているせいで扱いづらい

284 ：
68kのアセンブラはCよりも簡単だったなぁ。

285 ：
ASM++というか、C--というか。

286 ：
>>284
取っ付き易さはそうかもしれんな

287 ：
レジスタいっぱいあって汎用性が高かったから最適化がラクチンだったな
大概のループ処理なら16本のレジスタだけで回せた
初代8086より圧倒的に早かったのは恐らくこれが原因

288 ：
loop: move.l (a0)+,(a1)+
bne loop
だけでブロック転送が簡単にできちゃうもんね。
・・・bneだったかな？
もう忘れちゃった。
最近だったら、バッファオーバーフローの可能性を考えて
もう2行付けくわえないといけないけど。

289 ：
8086
mov cx, siz ;word単位
mov si, offset src
mov di, offset dst
rep movs word ptr es:[di], word ptr ds:[si]
68000
move.l #siz-1, d0 ;long word単位
lea src, a0
lea dst, a1
loop: movem.l (a0)+, (a1)+
dbra d0, loop
ループ用にラベル設定しなくて済む分、x86の方がスッキリしてません？

290 ：
プロセッサ自体が最適化できなかったって落ち

291 ：
>>289
8086は専用のストリング処理命令があったのでそれは当然といえば当然。
ただちょっと複雑な処理になるとレジスタの役割も処理内容も固定の
ストリング命令は使い道なかった。
まあZ80のLDIRよりははるかに応用効いたけど。

292 ：
極めたプログラマーが書いたコードのサイズや性能比較はわからないけど
俺みたいなヘボグラマーにとって68はｽｯｷﾘわかりやすくて扱いやすいから好き
86は（俺主観では）変に多機能かつお約束が多くて自分のコードを書く前の段階で頓挫しちゃう

293 ：
俺も一時期そう思ってたけど、x86でもわりと問題無く組める事ができた。
慣れりゃどうってこたぁない。

294 ：
俺は先にx86系に馴れてたんで68kはニーモニックはともかく、
データの構造化がやりにくいって印象が強かった。
mcc68kってコンパイラについてたアセンブラ。
しかしアセンブラはどのプロセッサのどこのメーカーのをどう使おうがちょっとでも高度な制御構造やデータ構造の構築、管理でもやろうとするとプログラマーへの負担が大きくなる。
といってもZ80、80x86、680x0、PowerPC（G4)、ARMv4、H8、SH3/4ぐらいしかアセンブラは使ってないから俺の意見が絶対とは言わないよ。

295 ：
68kでユーザーモード／スーパーバイザーモードを行き来するプログラムは書いたけど
x86のプロテクトモードプログラムは裸足で逃げ出した出ござる
PC-ATも悪いんだろうけどね(A20ラインだっけ？とか）

296 ：
何つくったの?

297 ：
OS

298 ：
仮想記憶によるメモリ管理システムとか楽しいとでも思えなければ
やってられんだろうなあ。
そういやインテルが骨格になるメモリ管理部分のコードを提供してたような
気がするけどそういうのいじくって会社用とか自分用にするのはアウトなのかな。

299 ：
リファレンスコードとして提供してるなら問題ないんじゃないかな?

300 ：
なんかさ、86の命令系統って、MSのアプリと良く似てるんだ

301 ：
まあMSの要望を取り入れながら出来上がった物だからそうなっていまうのかもな


302 ：
今の状況だと淫よりM$の方が強いみたいだな。

303 ：
ん?
規制解けたのか?

304 ：
16bitの話をするならこっち来いよ。

305 ：
>>398
どういう形態で公開してたかだな。
フリーって事はないと思うが。
もちろんあくまで個人として使うと言うなら別だが。

306 ：
>>398
頑張れよ

307 ：
ここに309争奪戦の開始を宣言する！

308 ：
じゃあ>>309は俺がもらいますね

309 ：
どうぞどうぞ

310 ：
>>305
未来人乙
このスレのペースなら1年後くらいか

311 ：
もっと早いだろう、と言ってみる。

312 ：
すげーな。
時代はすでに12コアかよ。

313 ：
Opteron6176SE vs Xeon7560

314 ：
インディアンうそつかない。

315 ：
既に使うだけの身。
コプロありの386DXがアセンブラでコード書いたのが最後だなぁ。

316 ：
半島人うそ付く!

317 ：
68kはVAXだかPDP-11だかを参考にしたけど
x86は、BPの使い方とかPL/M向けの実装だったのかな

318 ：
なんでもスプレッドシートを作りやすくするためだとか小耳に挟んだ記憶が

319 ：
>>317
ん？
68000は、IBMのSYSTEM 360を参考にしたんじゃなかったっけ？

320 ：
8086のBPはなんちゃらの高級言語向けに設計されたって読んだ覚えがある。
186のentry/leave命令のセットがその延長でスタックフレームの転写を明示的に行うんだとか。

321 ：
設計された時期が時期だけに高級言語は意識しただろうな。
どれだけの価値があるか不明だったmicro processorとやらの用途が
当初の予想以上に広がりつつあった頃だから。

322 ：
ふーん、そうなの。
8086なんて単に8080を16bit化(もちろん多少の命令も加えて)した物かと思ってた。

323 ：
8080とアセンブラソースレベルでの互換性も考慮したんだけど
結果8080の基本構造をおおむね引きずることになった。
16bitCPUを新たに設計したというより8080を16bit拡張したと見るほうが
しっくりくるのはそのせい。

324 ：
なにしろフラグ変化なんてほとんど8080と互換だしｗ

325 ：
>>320
「なんちゃら」とかでなくて、局所変数をもつ近代的な言語すべてに必要。
スタック上に局所変数域（スタックフレーム）を形成するため。
ただし 386 以降のように SP 相対アドレッシングモードがあれば、そちら
で代用することも可能。gcc では --omit-frame-printer オプションで
切り替えられる。SP で代用しちゃうと動鎖を手繰れないので、デバック時
にバックトレースできなくなるけどね。
enter/leave 命令はスタックフレームの形成・開放を１命令でやってくれて
便利なんだけど、オンスタックディスプレイを転写する第２引数なんて正気
の人間は誰も使わない。


326 ：
高級言語をアセンブラでデバッグしたことがないから、興味なくて読んだときに「へー、そうなんだ」でながしちゃったよ。
富士テクノロジーとかなんとかいう会社の出してた386/486の解説本だったはず。
技評の286アセンブラ入門だったかも、
よくわかる486でないことはかなり自信あるけど
紙ベースで読んでるからIA32マニュアルではないことだけは確かだ。
実際entry命令の２つめの引数はコンパイラだけが知ってればいいんだよね。
実際いつでも、386のコード書いたときだってずっと0だったし。

327 ：
entry/leaveはたぶんPascal系の（C言語ではない）
引数の数が不定じゃない言語用だな。
あれ？むかしのMS-DOSのC言語で、pascal宣言入れておくと速く（小さく？）なったのは
それのせいだっけ？

328 ：
>>326
> 実際entry命令の２つめの引数はコンパイラだけが知ってればいいんだよね。
いや、コンパイラ作成者でも絶対に使わない。
もう少し詳しく言うと、Pascal や ADA のように関数・手続きの中に
局所的な関数・手続きを定義できる言語で、中間変数（内側の関数など
からみて大域的な、外側の局所変数）を正しくアクセスするために使う。
伝統的には、この目的には静鎖（スタティックリンク）が使われる。
あるいは高速化を狙ってディスプレイ（陳列棚）方式が使われることもある。
通常のディスプレイは静的な配列を１つもっていて、サブルーチンコールの
たびに、その中の１エントリだけ更新する。コピーが必要なのは手続き引数
を使うときだけ。
で、インテルは何を思ったのか、ディスプレイをスタック上にとって、サブ
ルーチンコールのたびにコピーして回るという方法を想定した機能を enter
命令につけてしまったので、みんなの笑いものになったというお話。


329 ：
>>327
それは leave 命令のオペランドの話ね。
呼び出された側がスタックに詰まれた引数をとりのぞく。
今でも PASCAL または WINAPI 呼び出し規約を指定するとそういうコードがでるよ。
なにしろ伝統的な Windows API はほとんどこっちだから。
ただ、昔でも 186 以降を指定しないと enter/leave 命令は使ってくれなかったけどね。
486 以降は単純命令の組み合わせのほうが速かったりするから、今のコンパイラでも使って
くれないかもしれない。

330 ：
あまり聞かない言い回し、この板の住人の素性が気になる

331 ：
かつてそこら辺に大勢居たマイコン・パソコンの虫じゃなかろうか。
現役プログラマーなんかもそこそこ居る感じ。
というか>>330がどこから来て何を独特の言い回しだと思ったのか気になる。

332 ：
まあ、どっかのスレは結局は罵り合いだけだからなあ。

333 ：
68000
二段階マイクロコード採用。
それでもトランジスタの約半分はマイクロコードだっけ？

334 ：
>>333
どうだろう？
写真見る限り面積では半分よりずっと小さいけど、
ROM はトランジスタ密度高いからそんなもんかな？
http://www.infonet.co.jp/ueyama/ip/history/1979-m68000.jpg
＃ 6309 はマジでチップの半分をμROMが占めていたが...

335 ：
ソース不明だけど、
マイクロコード：　17bit長×544
ナノコード：　68bit長×336
合計32096bit

336 ：
>>335
http://www.cs.umass.edu/~weems/CmpSci535/Discussion15.html
一次情報は見つからなかった。

337 ：
最近のCPUってオンキャッシュのコードや、キャッシュ汚染を引き出さないよう
な小容量一次元配列に対する操作じゃないと、CPU本来の速度で高速に走らないでしょ。
そういうところを経験してから、x86のセグメントモデル思い出しちゃてさ。
80年代当時の68系のx86系に対する最大のアドバンテージであった、広大なメモリ
空間をシームレスにアクセスできるっていう奴を、IA-32が手に入れたのもつかの間、
性能を出すために結局64KByteや32Kbyte内でちまちま動くような管理されたバイナリ
コードを用意する昨今。
なんか先祖返りっぽい。


338 ：
windowsなんてのは壮大な無駄だったのかも。あれのおかげで相当進歩したけど。
そういったアーキテクチャレベルのキャッシュ管理ってどうだか。タスク切り替え時に
明示的にキャッシュをクリアするほうがいい気が。(既にやってるのかな、知らないけど)
そんなチマチマしている最適化はプログラマを疲れさせるだけよね。

339 ：
最近の石にはキャッシュ汚染防止の為のロジックが実装されてるのかと勘違いしてた
そんなもん実装できんわな。2行目は無かったことにしてくだちい

340 ：
完全ハードウェアロジック

341 ：
今度は真空管かよ(･･;)

342 ：
ここに東芝の12bitCPUを知ってる人は居ますか?

343 ：
次は128bitだな。

344 ：
というか64ビットが定着するまでにまだ相当時間がかかりそうな予感。

345 ：
あんまり増えすぎても逆に効率悪くなるんじゃ

346 ：
今までも性能とかって言うよりアドレス(容量)が不足してたからって言うのがホントのとこのようだ。
っとすると64bitのアドレスが足りなくなるって事は…

347 ：
あああ

348 ：
スピードも問題だな、CPUに追いついてない。
DDR4も未だ行く先真っ暗。

349 ：
ストアドプログラムマシン化がより顕著になるかと。
組込み用の内蔵RAMがメモリ空間に見えてる様にキャッシュしなくても十分速い内蔵RAMがプログラマーに解放される。

350 ：
ワンチップCPU?ってどの程度の物が出来てるんだろうね。
64bitとかあるのかな。

351 ：
いきなり64bitはムリだから、取り敢えず34bitくらいで

352 ：
>>351
アドレスの下２ビットはどうせ０だし、GC用のマーク入れてちょうどいいかもね

353 ：
>>348
2012年ぐらいから登場らしい。
でもポイントTOポイントで一枚しか付かないらしい。
By WinPC

354 ：
AMIGA,ATARI,Macintosh,X68Kといった個性的なパソコンは
どうして68Kを採用したのだろうか？


355 ：
64KBの限界：セグメントの呪いは存在せず、
16本の32BITレジスタで8BIT時代に泣かされたレジスタの不足とももさようなら。
68000は大容量を必要とするホビーストを魅了して止まないCPUだったのだ。
実はX68000には80386採用案もあったんだけど、ホビーストたちは
あの8086を引きずったなんともじれったい命令セットを好まなかった。
レジスタも少なかったし。

356 ：
あとビッグエンディアンCPUとビットマップV-RAMの親和性。

357 ：
初代x68が386だったら価格どうなっただろうな

358 ：
386はAT互換機や98での採用で大量に作られてたから高くなかったんじゃ？
多分大して変わらなかったかと。

359 ：
NECや富士通は自社CPUと言うくくり(足かせ)有ったからね。
シャープはどうだったんだろう?
もっとも、日立のように自社製品使えない哀れなとこも有ったけど。

360 ：
X68kでプランが存在したのは、386ではなくV30だヴォケが
普通にMS-DOSマシンだった方が面白かったと思うよ

361 ：
ん？鳥居総帥がはっきり386とおっしゃられていたOH!Xの記事は知らんのかな？
ヴォケはそのままそっくり返す。

362 ：
>>360
V30＋豪華グラフィック＆サウンドのPC-88VAは鳴かず飛ばずだったよ。

363 ：
PC-88VA、嫌いじゃなかったけどやっぱX68Kと天秤にかけたら・・・

364 ：
実際にHUDSONへV30版の試作機がですね

365 ：
へえ、でもその後でMSDOSのまがい物を作るって言うのは大変だっただろうなあ。

366 ：
85年頃に68ｋでなくx86系として妄想すると・・・
OSはMS-DOSとなるとNEC、富士通といった先行してる競合他社に勝てると判断したとは思えないから、やっぱりx86系はないな。

367 ：
似たような値段で386なら面白かった気もする

368 ：
…2010年の現在が一番いいかもな。
機種争いはないし、C信者も駆除。
BASICも速いし、3Dも手軽にできる。


369 ：
Ｃ信者ってのが判らんが、基本的には何時の時代も無いものねだりですよ
でも、まぁ同意。安く一通りのことが何でも出来る。いい時代ですわ。

370 ：
>>369
＞Ｃ信者ってのが判らんが
bell研究所の工作活動の一環で、市場からBASICを消し去ろうとした。
＞基本的には何時の時代も無いものねだりですよ
オレにとってはこれから飛躍と復権を目指せる時代に戻れる。
もちろん、オレだけじゃあなくて、外野に多くいる日曜プログラマーたちにとってもな。

371 ：
ここにもキチガイがいたか

372 ：
キチガイとはそういうものです

373 ：
…ってなワケで、オレはこちらにいる。
MAIN STREET
http://www.geocities.jp/courant_de_console/main_street/

374 ：
だからそこから出てくるなw

375 ：
いいから回線切れよ（ゲラゲラ

376 ：
似たような値段で386をあえて妄想してみる。
妄想だからつっこみ歓迎。
80386/16MHz、コプロセッサはオプションで387。
しかし当時のシャープだから287も視野に入れておいた方がいいだろうか？
RAMは標準2M、4Mにすると価格的に厳しかったはずなので。
16M以上は実装できるようになってたけど最大64M程度だろう。
ピン数の関係でデータ32本／アドレス24本(A25〜A2の)で最大64Mバイト、というのがその根拠。
でもコネクタは4〜5本程度だろうから1Mとか2Mのメモリモジュールになったろうからコネクタ数の関係で10Ｍ程度が事実上の限界。
3〜4年経って容量の大きなメモリモジュールが発表されるようになってから16Mオーバーが(コスト度外視で)実現するぐらいか。
画面、サウンド周りは史実のX68000と同等程度。
ただOSがMS-DOSとすると1M以下に収める為に画面が640×480×4・・・いや640×480×8は実現しているだろう、きっと、たぶん、おそらく。
PCMも8BitADPCMにダウングレードするかも。
FD/HDは史実のX68000と同じ。
HDDは、最初はオプション。
で、SASI/SCSI/SCSI-2と史実と同じような経緯をたどると思う。

なんか面白みが減ったマシンだなぁ。
妄想力が足りない。

377 ：
セルフつっこみ！
640×480×4ってなんだよ、×4って！
640×480×6とか、そういう中途半端に思えるスペックを実現しちゃうのが当時のシャープだろ！←偏見だけど

378 ：
そういや、SONYのNEWSって、どこの板扱いなの？

379 ：
ここでいいんでね？

380 ：
>>371
ここに居たんじゃなくて他スレで涌いて移ってきたんだよ。
ほんと、蛆虫みたいだ。

381 ：
ボウフラとかのレベルだよな〜

382 ：
おまえのコテ名、CONSOLE DE BASICにしろよ

383 ：
不潔そうなツラしたジジイが発狂してやんの（ゲラゲラ

384 ：
自己紹介おつ

385 ：
　

386 ：
大事なことだからもう一回言うよ、自己紹介おつw

387 ：
感情的（笑）なことだからもう一回言うよ、自己紹介おつw

388 ：
馬鹿がいないとまったりするな。

389 ：
>>368
少なくともBASICやってる奴の数百倍以上は確実にCやってる奴がいるだろうにな。

390 ：
Oh!Xを読み返すとx86のこと糞味噌に書いてあるんだけどセグメントがあると
そんなにプログラムしにくかったの？

391 ：
扱うデータが64KB超えなければセグメント管理は簡単
超えるとちょっとめんどくさい

392 ：
8086/286でもセグメントは便利使えるし
386なら64KBの制限もない
64KB制限で苦労するのはC/C++を使った時ぐらい

393 ：
64kを超えると面倒ってんじゃなく
シングルタスク環境で複数のメモリ空間を平行で考える手間とメリットに
当時のクズプログラマでは想像が及ばなかったってだけの話だよ
当時64KBセグメントで困る用途なんて
パックドピクセルで広大なVRAMをリニアアクセスさせろ、くらいのもんだろ
そんで殆どのPCのGVRAMはプレーン式だった

394 ：
…ってなワケで、オレはこちらにいる。
MAIN STREET
http://www.geocities.jp/courant_de_console/main_street/
新しいコト、次々と。

395 ：
>>393
バカ?

396 ：
ニフティサーブFGALなど関連各フォーラムで、TOWNS発売直後の
386信者vs.懐疑派の大論争を彷彿とさせる流れだな
富士通側は「サードパーティの希望を充分に考慮して採用CPUを選んだ」という立場だが
実際のところ、X68K市場がかなり立ち上がってたと思うので、当時のソフトハウスとかは
どういう意見だったんだろう？
ただのマイコン少年あがりだった自分としては、その辺の事情に興味がある
アーケードとかは別にして、一般家庭向けパソコン市場のソフトを企画する際
開発環境の充実度/工程とか、クリエイター/プログラマの‘モチベーション’とかw
386と68Kでかなり異なる要素があったんだろうか?

397 ：
68、86両方を使った人はどう判断してるわけ？

398 ：
68kじゃなくて68系なら議論の余地はあると思うが
68kと386なら全てにおいて話にならないだろｗ
386ベースならCPUパワーもメモリも十分コンパイラ頼みでいけたと思うし
68系は製品サイクルも86系に１世代近く遅れ気味で市場に出てたし
386は正解だったと思う。同等品の68系を同価格で装備できたのなら議論の余地は(ry
タウンズはCPUの問題より、他のハードの部分が競争力に欠けた気がする

399 ：
TOWNSは486が載るあたりまでメモリが遅すぎたのと
DSPをユーザーに開放しなかったのが汚点かね

400 ：
DOSエクステンダは、高かった気がする。
よくよく考えると、PC/AT互換じゃないのに、よくやったなと＞TOWNS
まあそれを言ったらHuman68K作ったHudsonはもっと偉いけど。

401 ：
Human68kは当時からバカにされるくらい稚拙なDOSだったけどね

402 ：
正直、68K用に新規に作ったOSがこれかよと思った

403 ：
X68k関係は信者の自画自賛が酷くて
現実と伝説が乖離し過ぎ

404 ：
同梱品としては別にあれで良かったと思うけどな。
IOCSとか使って徹底して将来の仮想化に備えるとかは、あの頃のCPUパワーと
X68に求められてた事を考えれば現実的じゃなかったし。
そうなるとOSというよりDOSでいいんだよね。それ以上されると資源喰われるだけで困る
発売当初からWSレベルのものを本気で求めてた人は違うんだろうけど。

405 ：
MC68000はUNIXワークステーションでの使用を想定し、1979年にモトローラ社が開発したMPUです。
プログラムアドレス空間とデータアドレス空間を分離するハーバード・アーキテクチャを採用することにより、
高度なメモリ保護機能を実現していた。さらに当時としては画期的なマルチタスク動作も可能だった。
MC68000はサン・マイクロシステムズの初代UNIXワークステーションであるSun-1や、
初期のMacintoshや伝説のマシン「Amiga」などに採用された高級かつ高性能で高価なCPUであり、
小売単価で１個２万円している頃・・・。
MC68000を搭載したセガのメガドライブは、れっきとした完成品のくせに・・・。
５００００円？違うぜ！！
１０００００円？いやいや、違うぜ！！
５０００００円？そんな馬鹿なことがあるか！！

なんと、たったの「２１０００円」だぁぁぁぁぁぁぁぁぁぁぁぁぁぁぁあああああああああ！！！

これはもう今すぐ買わないとダメなレベルですね！！

406 ：
>>405
今更メガドライブの宣伝をしてどうするww

407 ：
>>398
386を引き合いに出すなら68030や68040を比較の対象にすべきではないかね？

408 ：
386 なら 68020+68841(MMU) が比較対象だと思うよ。
製品サイクルは別に遅れているとも思わないけど、
仮想記憶サポートするには２チップ構成となるので、
コスト的にちょっと厳しいものがあったね。

409 ：
プログラマー的には286で仮想メモリは使えるレベルだった

410 ：
一般には8086と68000がライバルとして比較される事が多いが、OSサポート機能、
メモリ空間などのプログラミングモデル、実装されている機能から、80286になって
やっと 68000と比肩する機能を得たといえる。（但し演算速度については80286が
68000のほぼ倍程度の性能を有している。）
ttp://ja.wikipedia.org/wiki/Intel_80286

411 ：
当時から386との比較なら030だと思ってたから対抗品としてサイクルちょっと遅いと思ってた。
mmu付きでいいなら020なのかな？
でも386->486の進化と030->040はやっぱ同じような印象を持ってるので、386の対抗はどうしても030って印象なんだよね。

412 ：
>>405
メガドラのこと何も知らなかったので、wikipedia で読んでみたよ
1988年10月29日発売ってことは、22年前か〜
　　MC68000　+　Z80A　+　YM2612
おお〜、なかなか面白そうっと思ったけど
　　RAM　64KB　　VRAM　64KB　　←ここでコケたw
まぁ当時の家庭用ゲーム機としては、これでも破格性能&価格だったのかなと推測

413 ：
ROM媒体のゲーム機に必要なRAMなんてスタックとワークくらいだし、
64KBでも大盤振る舞いもいいところだ。
VRAMも少なく見えるかもしれないけど、
ビットマップVRAMは持っていない（スプライトとBGしかない）ので、これで十分。
逆に、全部RAMで持つしか無いメガCDは512KBも積んでいた。
そりゃあ安く作れる訳がないわ…

414 ：
>>413　解説のレスに感謝
ROMカセット主体ってことをうっかり忘れてました、なるほど納得。
全発売ソフトの一覧表を見たら、ずいぶん色々(移植作とかも)出たそうなので
スプライトとBGだけであれだけできるのは凄いと感心。
ちょうどTOWNS発表(1989年2月)の直前ってことに後から気付いた

415 ：
初代ファミコンなんて、RAMはたったの2KBだしな
メモリをバカスカ積むようになるのは、CD-ROM媒体になってからの話
現在の携帯ゲーム機(DSとか)のソフト供給媒体がROMであるにもかかわらず
本体にメガバイト単位でRAMを搭載している理由は、
プロセッサが高速になることで相対的に半導体メモリ(ROM)といえど読み出し速度が遅くなってしまい、
それに輪をかけてROMへ繋がるバス幅が狭いという事情から

416 ：
ファミコンはビデオRAMも2KBだったな
最大16KB積めるのだけれど、それはゲームカセットの中にROMとして搭載
同時期の他機種は本体内蔵で、価格を押し上げ、敗北する一因となった訳だ。

417 ：
SNESはカセット内にDSPまで積んでカセットの価格が１万円超とか普通だった
今から考えると本当のボッタクリ

418 ：
>>412
1986年ごろ、68000の総出荷数は70万個程度。
当時のセガからメーカーへの発注量は100万個と
明らかにネタとしか思えないほど大量発注だった。
総出荷数よりも多い数を一度に注文した、というので当時としては話題になった。
結局このゲーム機は2200万台を売り上げ、量産効果で68000は一挙に安い石になった。
この影響で組み込み用途にも68000がガンガン使えるようになった。

419 ：
あの100万個という数字にはそんな意味があったのか。
つうか68000てそんなマイナーなCPUだったとは当時思ってなかった。
放っておけばホイホイ売れそうな筋のいいCPUだったけど
モトローラは営業努力怠ってたのかね。

420 ：
Intelの勝因は営業努力

421 ：
営業は何をしていたか知らんけど互換戦略は見事に当たったようだ。
8086がIBM-PCに採用されたのも8080(CP/M)との互換性が大きな要因だったらしいし。
んでボーっとしてればはここまでで終わりそうなんだけど後に286→386→486→Pentiumと
互換性を維持し32ビット化を果たしながら怒涛の勢いで処理能力をアップさせて行った。
開発力も大したもんだったと思う。

422 ：
性能そのものも、型番変わってもインテルほどには進化しなかった。
元が元だけに伸びしろなかったのはわかるが性能頭打ちすぎ

423 ：
68000って仮想メモリ用の命令なかったっけ？
なんで30移行でないとfreeBSDがどうさしないんだっけか・・・。

424 ：
MMUがあっても十分なページング機能と例外機構がないと実用的な仮想メモリシステムは無理
仮想メモリ自体は命令が無くてもMMUが無くてもMZのクイックディスクでも不可能ではない

425 ：
仮想メモリ使うぐらいにソフトウェアが肥大化したころに68000は非力すぎね？
68030以降だよな、仮想メモリ使える68k系は。

426 ：
>>423
FreeBSDは動かない。NetBSDは68030以降で動く。

427 ：
68000のマイクロコード/ナノコード構造や、68020のメモリ間接アドレッシング
みたいなものを極力廃して、新し目なプロセスで作ればそこそこイケるんじゃ？
と思わせたColdFireも、結局 0.18μm 266MHz止まりみたいだし・・・
まぁ、上にはさらに高効率のPowerPCがあるんだから、当然と言えば当然なんだが・・・
なんと言うか、好きだっただけに寂しい結末だな

428 ：
>>419
MC68000の最後の超大型商機はセガのメガドライブだったわけだが、当時のモトローラは既に倒産しかかっていた。
モトローラは当時まだ無名のゲーム機メーカーによる100万個単位の大量発注を受け付けることは
あまりにもリスクが高すぎると判断したモトローラ側が警戒し、セカンドソースを生産していた
シグネティックス社を介して供給することで受け容れたという事情があった。
ちなみに、このシグネティックス製68000はＭＩＬ規格対応だったらしく、
そのためかオリジナルよりもやや大きいパッケージである。
後期のロットには日立製、メガドライブ2にはモトローラ製も採用されている。
そして、セガが使わなかった68000以外の68kファミリーは、結局高価なまま成功しなかった…
セガが開発するハードウェアは伝統的に汎用のプロセッサをそっくりそのまま搭載するため、
確かに任天堂と比べれば弱小の万年負け組ハードだったけれど、
組み込み系では有り得ない数百万個ものオーダーでプロセッサを大量発注・大量消費することから、
セガ一社からの発注分で開発・製造コストを償却可能で、以後価格をガンガン下げられるようになる。
開発するプログラマーにとってもメリットがあり、挙動が不明な専用パーツを使っていないから
コストや開発スケジュールを大幅に圧縮できるという事情もある。


429 ：
>>427
freescaleってモトローラミュージアム的な所あんだよ
いまだに6800系チップや68000の末裔作ってんだから
Intelは8080系や8048なんてもう作ってないでしょ

430 ：
68系プロセッサのデータシートって、一時期ONセミコンダクタのページに
移動してなかった？
モトローラ→ONセミ→FreeScale
と、2回もスピンアウトしたのかと思っていたら、会社概要見る限り
モトローラ→FreeScale
としか書かれてないのだが・・・俺の気のせいかな？

431 ：
ふたつともモトローラから独立した会社か
オンセミは台湾かどこかの会社だと思ってた（恥

432 ：
>>423
68000 単体では仮想記憶サポートできない。
68010 から仮想記憶をサポート、ただし外付け MMU が必要。
ワークステーションなら 68010 や 68020 で仮想記憶をサポートした
マシンはいくつかある。
不十分な例外機能しかない 68000 × 2 で、仮想記憶をサポートしたマシン
もあるから >>424 が何を言いたいのかはよくわからんが。
68030 から MMU を内蔵したので、68030 以降の MPU が乗ってるマシンなら
基本的に仮想記憶がサポートされた。
>>427
> 68000のマイクロコード/ナノコード構造や、68020のメモリ間接アドレッ
> シングみたいなものを極力廃して
その役目は 88000 が担うはずだったんだがちょっと遅すぎたな。

433 ：
>>429
現在のフリースケール・セミコンダクタは通信や車載といった組み込みシステム向けのチップが主力商品。
いまだに6800系チップや68000の末裔を作るという選択肢は当然といえる。
理由は「枯れた技術」だから。
バグみたいな不安定な要素が消えた
安定した技術というわけで堅実で信頼性が高いというわけだ。
自動車の部品は一歩間違えば人命が失われるから、
「枯れた技術」を優先して使うのは悪いことじゃない。

434 ：
車の電子制御がM$のOSだったら…

435 ：
大衆車にはWindowsXP
高級車にはOS/2
TOYOTAの重役専用車にはMS-DOS

436 ：
枯れすぎとるわ

437 ：
>>434
・車が勝手にエンストしたりエンジンブロー
・アクセルペダル戻しても車が加速
・ブレーキが効くのにタイムラグがおきて人を弾く
・メーター文字化けか表示が意味不明
・

…プリウスどころの騒ぎじゃない規模の集団訴訟がおこるなｗｗｗ


438 ：
人命に直接関わる製品にM$のOSなんぞ怖くて使えんわ！

439 ：
どこぞの原発でM$のOSが使われてるって話があったようななかったような・・・
いくらなんでも制御用じゃないだろうけど。

440 ：
ま、Windowsの不安定も大部分はヨソが作ったドライバが原因だけどね。

441 ：
自動車用MVSなら絶対安心

442 ：
>>437
仕様です(+_+)

443 ：
Ｑ：ソフトウェアはPL法（製造物責任法）の対象になりますか？
Ａ：PL法はあくまでも製造物（有体物）に対する法律なので、純粋にソフトウエアに関してのみにはPL法は適用できないそうです。
製造物とは製造または加工された動産のことをいいます。不動産、未加工の農産物や水産物、
有体物でないサービスやソフトウエア、電機エネルギーなどは対象から外れます。
ソフトウェアについては受託開発したシステムの不具合でユーザー企業が被害を被ってもPL法の対象外ということになる。
コンピュータにプリインストールされたOSやアプリケーション・ソフトも，PL法の対象とはならないとする解釈が一般的。
なぜなら、こうしたソフトは利用者に選択の余地が残されているため，製造物であるコンピュータの一部とはみなせないからだ。
だからこそ、どれだけとんでもない異常な欠陥があろうとWindowsにはＰＬ法が適用されることはないんです。
ただし、不動産でも備え付けの建具や厨房、照明器具などの住宅部品は動産の対象になります。
ソフトウエアもそれ自身はＰＬの対象外ですが、ソフトウェアが産業機器などに組み込まれた製品は
「機器に組み込まれた“部品”の一部」とみなされるためＰＬ法の対象品となります。
だからこそ、自動車や鉄道車両に航空機やエレベーターには長年の実績があり、
バグがほとんどなく、堅実で信頼性が高い「枯れた技術」が使われるのです。

444 ：
即応性より確実性。

445 ：
もしあなたが急病に罹り、I担ぎこまれたICUのモニタに「田ミ」マークがあったら…
直ちに近くの救急隊員に転院を申し出るか、来世も人間であることを祈りましょう。

446 ：
キリスト教文化に輪廻転生はないので
諦めて永遠に地獄で苦しむ覚悟します
今と大差ないか…

447 ：
>>432
>不十分な例外機能しかない 68000 × 2 で、仮想記憶をサポートしたマシン
NCRのTOWERだっけ？
1命令分先行したMPUを走らせて、先行している側のMPUが例外を出したら
後ろ側のPCにある命令を解析してメモリマップを変更するんだっけ
インテルもx86を止めたくて仕方がなかったのが、こうなると意地なのかな。

448 ：
確かにBSD256本（256倍悪魔本）に、初代SUNについてそんなことが書いてあるんだけど、
どうも間違ってるらしい。
ttp://www.st.rim.or.jp/~nkomatsu/mc68k/MC68000.html
これによると、コンテキストの保存はせずに、メモリを踏み外したプロセッサを一旦切り離して、
もう一個のプロセッサでページインとかの処理をやればいいんだと書いてある。

449 ：
>>434
＞車の電子制御がM$のOSだったら…
>>438
＞人命に直接関わる製品にM$のOSなんぞ怖くて使えんわ！
>>439
＞どこぞの原発でM$のOSが使われてるって話があったようななかったような・・・

今でもWindowsシリーズ(含むNT系)のライセンス事項には
「核施設や救命施設での使用時にのトラブルは保証しない」とか書いてあります。
使ってはいけないというか、俺たちは何があっても知らね〜よと（ｗ
某一度倒産した悪徳ＰＣショップに勤めてた時、原発から注文受けたことありますよ（ｗ

450 ：
一般とは別のライセンスがあるんだよ

451 ：
ライセンスの問題でなく性能的に使えないんだ。

452 ：
そうだよ、原子炉用ならＭＡＣだろ。

453 ：
>某一度倒産した悪徳ＰＣショップに勤めてた時、原発から注文受けたことありますよ（ｗ
まさかプラントの制御に使うわけじゃないだろう
事務仕事でエクセル、ワードを使う程度じゃないの


454 ：
>>450
ＭＳの使用許諾は、対集団民事訴訟用でしょう。何書いても刑法上の義務は免れないわけで。でも、うまいんだなこれが。
ほら、ＮＴ乗っけた原潜が事故りそうになった事件があったじゃないですか。
ＰＬ法に限った話（なんせ制御屋は一番コレが怖い）で行くと、事故が起こった場合の責任は「システム設計」に課せられます。
ＯＳを含むソフトはここに入りません。唯一例外と言われるのが ROM に焼いたファームウェアで、これはＰＬ法の対象になります。
だから、ＭＳが BIOS プログラミングにも手を出してたら原潜事件の時ヤバかったかも。

455 ：
特にアメリカは何でも訴訟のタネになりうるから企業側の防衛もすごくて通路だって滑って転ぶと危険なんて
注意書きが至る所にある

456 ：
>>455
・日本の某電気カミソリ・メーカー(中小企業で、大手メーカーにOEM供給)が、ドイツの大手の電気カミソリ・メーカーに、米国で知的所有権侵害の民事訴訟を起こされて裁判に負け、巨額の賠償金を支払わされた。
・インドのボパールでガス流出事故が発生して、2000人以上の住民が死亡した大事故で、米国の弁護士が現地に大挙して乗り込んで、被害者から委任状を取りまくって、損害賠償額の高い米国で民事訴訟をおこされて、元経営陣はお尋ね者になった。
・業者に依頼して自宅にプールを作らせた。逆さ飛び込みをしたところ、頭を打って大けが。プールには「飛び込み禁止と、その理由を書いたマニュアルがなかった。」と裁判に。結果は勝訴。プール会社は倒産。
・マクドナルドのフライドポテトで菜食主義者から訴訟を起こされ「フライドポテトに牛脂を使用している表示がなかった」という理由だけで１２億円支払い命令。
・フロリダで化学工場が大爆発する事故があった。事故の様子をテレビで見た地元の人が「精神的なショックを受けた」と化学工場を訴え、その訴訟は成立した。
・職業別電話帳(イエロー・ページ)を見ると、顔写真入りの一面広告を出し、２４時間３６５日、フリー・ダイヤルで受け付けている法律事務所がある
・アフガニスタンで大規模なアルカイダ壊滅作戦を展開、７５０人にのぼる捕虜を捕捉していたら、「収容所での扱いが不当だ！！」で米国政府が米国の裁判所で訴えられた。
・外国で談合していたら大丈夫だろうと思ったら米国子会社が起訴された。
・密室で談合していたらバレないと思ったら、メンバーの１人がおとり捜査官にすり替わっていた。
・事故があると病院に駆けつけたり、救急車の後を追跡して病院に駆けつけたり、病院で待機していたりして、被害者や家族から委任状を取る。
・訴訟費用の全てを法律事務所(弁護士)が負担する代わりに、勝訴した場合には、勝ち取った賠償金の４０パーセントから５０パーセントを 成功報酬として得る成功報酬制弁護士もいる。
・日本の弁護士の人数が日本全体で約１万８０００人であるのに対して、米国の弁護士の人数は米国全体で約８０〜１００万人。

これらは全てガチですｗｗ真実ですｗｗ

457 ：
2ちゃんねるではな、「ガチですｗｗ真実ですｗｗ」なんて言っても相手にされないの、坊や。
信頼性が欲しければしっかりしたソース。それが2ちゃんねる。

458 ：
ケチャップじゃだめか？

459 ：
ソースじゃなきゃダメ。
しかしブルドックは不可

460 ：
>>457
最近のトヨタ車の集団訴訟騒ぎを忘れた？
http://www.news24.jp/articles/2010/02/03/10152843.html
http://plaza.rakuten.co.jp/mimolove18/diary/201002030000/
http://www.bloomberg.co.jp/apps/news?pid=90920000&sid=aaqxO801w0B4
http://www.afpbb.com/article/economy/2708528/5475665

461 ：
で、>>456の訴訟相手は全部トヨタなん？
トヨタって多角経営なのは有名だけど、電気カミソリやガスやプールや食用油や化学工場や
法律事務所や捕虜収容所までやってるとはシラナンダ。

462 ：
「猫チン事件」はただの都市伝説だったが、
ボパールでガス流出事故に関する集団訴訟は紛れも無く実在する。
実際にインドの事件について米国で集団訴訟がおこされている・・・・。

SAJIDA BANO v. UNION CARBIDE CORPORATION and WARREN ANDERSON
http://www.elaw.org/node/2560
http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=2nd&navby=case&no=009250&exact=1
http://openjurist.org/273/f3d/120/sajida-bano-v-union-carbide-corporation-
Jagarnath Sahu et al v. Union Carbide Corporation et al
http://dockets.justia.com/docket/court-nysdce/case_no-1:2007cv02156/case_id-302312/
http://www.websupp.org/data/SDNY/1:04-cv-08825-23-SDNY.pdf
http://amlawdaily.typepad.com/keenanbhopal.pdf
Sahu v. Union Carbide Corporation
http://www.bhopal.net/pdfs/Sahu%20Opinion%2011.3.08.pdf
http://vlex.com/vid/sahu-v-union-carbide-corporation-43930484

463 ：
中国製ペットフード禍米連邦大陪審が中国企業などを起訴
2008.2.7 11:12
【ワシントン＝渡辺浩生】中国産の原料を使ったペットフードを食べたイヌやネコが相次ぎ中毒死した問題で、
米ミズーリ州の連邦大陪審は６日、原料を製造した江蘇省のメーカーなど中国企業２社と
ネバタ州の輸入業者を起訴した。日本では農薬が混入した中国製ギョーザを食べた人が重体に陥るなど、
中国製品の信用が揺らいでいるが、米国で食の安全問題に関係して中国側の関係者に刑事責任が問われるのは異例のことだ。
食品医薬品局（ＦＤＡ）が同日発表したもので、３社の経営者らも同時に起訴された。３社は共謀して、
米国で使用が禁止されている化学物質メラミンを混入した原料を「小麦グルテン」と称して８００トン
（８５万ドル＝約９０００万円相当）を米国に輸入した疑い。中国当局の検査を逃れるため偽の申告もしていた。
メラミンを混ぜると原料のタンパク質含有量を高く見せることができ、製品には「最低含有率７５％」と偽表示されていた。
この原料を使いカナダのメーカーが製造したペットフードで昨年３月以降、イヌやネコが大量に中毒死していたことが発覚した。
中国政府はこれら中国企業２社を営業停止処分にするとともに責任者を逮捕。
このペットフード禍は中国製品への消費者不信が広がる契機となり、その後も、有毒練り歯磨き粉のほか、
抗菌剤が検出された魚介類の輸入禁止、さらには鉛が混入した玩具の大量回収と波及していった。
http://sankei.jp.msn.com/world/america/080207/amr0802071112012-n1.htm

464 ：
“free” is fair for everyone;
FREE TIBET,
CHINA FREE.

465 ：
少なくともいえるのは68000は命を乗せられるCPUだということだ

466 ：
68k向けのMSのマルチタスクOSに命は預けたくない。
486が出るか出ないかの窓3.xの頃に売り込んできたけど門前払いされてた。
後になってWindowsCEの原型らしいと聞いた。

467 ：
スペースシャトルのロケットエンジン
これを制御しているＣＰＵは・・・・。
68000
http://www.hq.nasa.gov/office/pao/History/computers/Ch4-7.html
http://www.hq.nasa.gov/office/pao/History/computers/Ch4-8.html

468 ：
そうか、そんな時代の機械なんだなスペースシャトルは・・・。

469 ：
というか案外新しいとオモタ。
8080あたりのような気がしてた。

470 ：
The revised computer と書いてあるだろう。
当初設計の機材が古くなり過ぎたんで作った新型で使ったのが68000。

471 ：
シャトルも退役が近くてもうあまり延命する予定もないみたいだから
このまま最期まで68000のままかな。

472 ：
シャトルってもともと100回飛んで引退、で作ってなかったけ？

473 ：
1機あたり100回だよ。
今のところディスカバリーの38回が一番回数多いのかな？

474 ：
>>422
出てきたときから完成してたから

475 ：
インテルの石も、型番変わっても、蓄積されたソフト財産のため、”早い8086”
としてしか使われないことがあったという話を聞いたことがある。

476 ：
80386の登場は1985年。
Windowsが普及して使われ始めるまで、それから結構かかっているね。

477 ：
>>476
Windows3.1が発売されたのが１９９３年か。
職場に導入されたPCはMSｰDOSをまずインストールしてそれからWindowsを
インストールしなければならなかった。全部FDだったな。シリアル番号とか何も無し。
LANにつなぐのにLAN Workplaceというソフトを別にインストールしなければ
ならなかった。
それまで使用していたOA用WSはモトローラの68030を積んでいた。WSと違ってPCは
よくハングするし、HDDもよく飛ぶので評判は悪かったが、時代の流れには逆らえなかった。

478 ：
PCもDOSなら安定してたんだけどな。
安定してバグやセキュリティーホールのないOSに果たしてこの先お目にかかれるか？

479 ：
組み込み用のちっちゃいOSなら

480 ：
DOSは保護とか何もないんで、デバドラとかアプリのバグや相性で簡単にOSごと吹っ飛んでただろ。
意味わかんないこと言うなよ。

481 ：
まともな保護機能ついたPC用のOSは初めて使ったのがOS/2 Ver2.11かな？
その後はWin2KかFreeBSDか

482 ：
>>478
９８DOSはそれでもハングしたりリセットがかったりした。
主に、ATOKのせいで。

483 ：
>>482
「ATOKなんか使っているからでしょ」　by　ヘミ猫（void）

484 ：
>>480
Windows でも Unix でもデバドラにバグあったら簡単に OS ごと吹っ飛ぶだろ。
お前のほうが意味わからんよ。

485 ：
ドライバがカーネルと別の空間で動作しているなら、
実装次第では暴走したドライバを終了させ、ドライバをリロードした上で
デバイスを再起動・正常化させる事も（実装次第では）可能。
ドライバが別空間で動作しているからと言って、
それだけではデバイスのみを再起動できる保障は無いし、
デバイスの再起動に成功したとしても、それを利用していたアプリケーションがどうなるかは
さらに保障の限りではないわけだが。

486 ：
たとえばUNIX系の環境では、XやDEが落ちても
システム自体は何事も無く稼動を続け、デスクトップ環境を再起動することは当たり前にできる。
しかしXやDEの再起動に成功したとしても、そこで使っていたアプリケーションは（親プロセスのXと共に）落とされた後の話。
またLinuxやBSD系のようなモノリシックなシステムでは、
GPUのドライバが暴走すれば、カーネルごと巻き込んでシステム全体が落ちる可能性が出てくる。
Windowsでも、XPまでは同様だった。
BSODはWindowsのせいだと思われがちだが、そんな汚名も実態はグラフィックカードのドライバに起因していた
という事をMicrosoftは突き止め、Vista以降では再びドライバをユーザー空間に切り離し、再起動とその後のフォローまで組み込んだ。
Windows 7やVistaでは、グラフィックカードのドライバやシェルのExplorerが暴走・ダウンしたとしても
BSODに直結することはなく、ドライバやシェルプロセスを自動的に再起動させ、デスクトップが復帰する。

487 ：
> Windows でも Unix でもデバドラにバグあったら簡単に OS ごと吹っ飛ぶだろ。
>
> お前のほうが意味わからんよ。
DOSに、アプリが保護されるようなモードがあったかよ。
屁理屈はいらんですよ。

488 ：
>アプリが保護されるようなモード
kwsk
ReactOSでring1でドライバが動作する機構を用意してくれないかなぁ・・・

489 ：
ATS-P
◎エンコーダECとレピータRPのCPUは8085
◎車上演算CPUは68000
http://www.geocities.jp/jtqsw192/FIG/320p/atspcd1.htm
http://www.geocities.jp/jtqsw192/geobooks/geobook10.htm
部品も「最新」を追うのではなく、採用後、なるべく長期に安定して入手できるものを選ぶわけで、
要求仕様をきちんと満たせば、それ以上の高性能は無用ということ。
例えば NECのPC-9801の生産打ち切りはJR各社に衝撃を与えています。
あんなに脆く撤退するとは思いませんでしたからね。目先の高性能を追って、
すぐ別のものに切り替えられては困るというわけです。

組み込み用途は「動けばおｋ」の世界だからかなりとんでもないことをしている。

intelがAtomの売り込みに行ったら、「30年後も部品を売ってくれると約束するなら買うよ！！」といわれるぞｗｗ

490 ：
わがまま言うなら金出せよ。
半導体プロセス丸ごと1個おまえのところのために稼働させ続けるんだから、
1000億とかそういうオーダーになるだろうが。

491 ：
その為のセカンドソースであってソースが複数あると供給にも安心感がある
ARMがヒットしてる一因もこれがある

492 ：
>>490
こういう奴をアホって言うんだろうなぁ

493 ：
> 例えば NECのPC-9801の生産打ち切りはJR各社に衝撃を与えています。
こういう奴をアホっていうんだよ。

494 ：
>>487
> DOSに、アプリが保護されるようなモードがあったかよ。
>>480 で「アプリのバグ」なんて書かなきゃ突っ込まれなかったのに…
アホな上に見苦しいやつ。

495 ：
>>494
×「アプリのバグ」なんて
○「アプリのバグ」しか

496 ：
アプリが保護されるようなモード
ってのはWindowsにも無いと思うが。

497 ：
まあ、「他のアプリから」は保護されてるから、アプリが保護されるようなモードは
ないというわけじゃない。
ただ >>480 の文脈だと「意味わかんないこと言うなよ」レベルだが。

498 ：
悪意ある意図した不正なアクセスも、悪意無き意図しない不正なアクセスも、OSとドライバーとアプリに影響させない、というのは大変そうだ。

499 ：
OS/2のWINアプリもってS/2も落としたりしたの?

500 ：
>>490-493
ガ●アックスのアニメじゃあるまいし、試作品をいきなり本番に投入できるかよ｡ 人命と膨大な銭が掛かってるんだぜ？

「バグったら誰か死ぬ」「バグで億単位の大損害」「バグで大都市がパニック！！」が発生する可能性がある分野では
性能二の次、三の次で耐久性や信頼性に冗長性を最優先にたたき出す工夫をしている。
「電子連動Ｉ型」という国鉄時代に開発された鉄道の連動装置ならばCPUとメモリを3個並列に並べて、同じ動作をさせ、出てきたのを
比較回路で多数決処理。1系不良の場合は残る2系で処理を継続しますが、残りが不一致したら出力監視回路を遮断して、リレーを落下。
ウォッチドッグタイマーのしくみも、ＰＣに入っているようなもんじゃ、勝手にタイマーそのもののプログラムがバグ吐きそうで信用できないから
ちゃんとプログラムが正常に動作していないとリレーが落下するようなしくみのやつがついている。
この電子連動装置はCPUが8086を3個内臓でメモリは64KBなのに、なんとダイヤ管理機能まで持たせていた。
ただし、処理性能が大幅に犠牲になっていて進路設定してから信号機に現示が出るまで、
ポイント転換時間を除いて6秒以上かかるという、リレー式より格段に遅い。

しかも、まだ現役バリバリかもしれないらしい・・・。

501 ：
>>500
中国なら、人命にかかわる所にだっていきなり実践投入もバンバンやるぜｗ

502 ：
俺、全くスポーツには疎いんだが
インテルってサッカーチーム持ってたのかと思った

503 ：
多重化してbug freeにできるなら、トランジスタ使い放題のこのご時勢
誰もbugで苦労しやしないわ。

504 ：
一生懸命昔の知識を引っ張り出してきたんだよ。
察してやれよ。

505 ：
>>502
スレチだがサッカーのインテルってIntelと無関係なの？

506 ：
>>502
インテルサットはインテルが作った人工衛星だと思ってた？

507 ：
インテルのモラッティ会長「マイコンは手放さない」
http://news.searchina.ne.jp/disp.cgi?y=2010&d=0701&f=national_0701_003.shtml

508 ：
インテルのオッテリーニCEO「x86アーキテクチャは手放さない」
http://pc.watch.impress.co.jp/docs/news/event/20090923_317302.html

509 ：
>>500
ガ●アックスって何だよ?
燃料かよ?
インターネットコミュニティサイトかよ?

510 ：
ＰＣ９８＞＞＞＞＞＞＞６８

511 ：
アハ〜♪”

512 ：
アハ〜♪”

513 ：
ハア〜♪”ビバビバ♪”

514 ：
アハ〜♪”

515 ：
98ゆっとり ゆっとり

516 ：
ここでも涌いてるのか。

517 ：
アハ〜♪”

518 ：
PC-9801で売れるゲームはエロゲーだけだった。

519 ：
98が悪かったスレが1000で落ちたからこっちで粗相か

520 ：
スレチだが、トランスメタってどうなった?

521 ：
アハ〜♪”

522 ：
変なのが涌くと何処もなぜか過疎るな。

523 ：
関係ないが、SHARPが携帯にガラパゴスって名づけたのには心意気を感じた。
…心意気だけは…

524 ：
>>500
某旧共産主義国連邦だとそれは事実として裏付けされている。

525 ：
Z80パクッたんだっけ?

526 ：
日立は63000でも作ればよかったのに(63C09みたいな奴)

527 ：
>>526
どんな仕様になるのかいまいち想像がつかない

528 ：
まぁ、「これが欲しい」って機能はあらかた盛り込まれていたから、拡張するって
いっても大したものは残っていない気がするね。
速度的に不満だった部分は68020以降改善されていったし。
しいて言うなら、8bit CPUのプログラムを移植しようと思ったときに、Aレジスタと
Bレジスタを合体させてDレジスタとして使えるみたいな機構があると楽だったと
思ったな。
ついでに奇数アドレスからのワード、ロングワードアクセスが可能だと相当機械的
に移植できるのにと当時は思っていた気がする。

529 ：
超越関数も含めて68882の互換命令をフル実装した68K同等品を出せば
少しは486DXに対抗できたかもしれないと思う

530 ：
H8のときに訴訟で懲りたんじゃないの？互換路線は。

531 ：
過去に縛られるのがいやだったんだろう
未来もなかったけど

532 ：
H8って訴訟あったっけ？
H16じゃない？

533 ：
>>530
63C09とかCMOS版の68000勝手に作ってトラブルになったんだよ

534 ：
マイクロコードいじって誤魔化したんだよな

535 ：
>>533
丸一つ多いぞ。

536 ：
ベンチャーが開発した68KのIPまで訴えたのには引いたな。

537 ：
いっそ、日立は63C09を更に進化させたらよかったのに。

538 ：
なにがよかったのにだ

539 ：
具体的に想像してみな。
出来上がるのは386より汚いコード体系で386よりレジスタの少ない
ゴミのようなアーキテクチャだと思うよ。

540 ：
いや、r0からr7まではあるだろ

541 ：
AとBとXとYとUとSとなんとかだっけ。
ボッコボコのアーキテクチャだよな。

542 ：
63C09を拡張するなら、まずやらなきゃならないのはアドレス空間の拡張だろうな。
バイナリ互換とか言っていると、68HC16みたいなバンク切り替えとかセグメント方式
になるから、お得意のソース互換・バイナリ非互換でX/Y/U/S/V/Z/PCを32bitに
拡張する形だろうな。
と考えてきて、既に目の前には68000があるわけだが、拡張版63C09を使う意味って
一体どこにあるんだ？となるだろうな。
レジスタ本数は多いし、命令の直交性は充分だし、大抵の妄想はそこで行き止まり
になると思うよ。

543 ：
68kはメモリバス幅を16bit確保できないとひたすらマゾいだけの贅沢アーキテクチャだから
命令長から8bit単位でコンパクトにまとめられる方が現実的には身の丈に合っていた
けど70年代末の時点でそういう製品を作れなかった時点でモトローラの負けは確定していた

544 ：
thumbモードみたいなのがあっても嫌だぞ

545 ：
>>543
80年代半ばくらいまではね。
こんな「とりあえずアーキテクチャ」が30年以上も延命しようとは
夢にも思わなかったインテルは、今プリフィックス地獄にはまって
ボトルネックの悪夢にうなされているね。

546 ：
勝ち負けしか語れない奴は相手にしないほうがいいぞ。

547 ：
IA32はRISC陣営から8bit時代の因習を引き摺る古臭い命令体系と散々叩かれて来たけど、
PenPro以降でRISCっぽいμopコードに分解して実行するようになったら
むしろコンパクトかつ符号化も完了済みでメモリ効率も高い命令体系となって、
叩いていたRISC陣営が逆に放逐されてしまうという泣き笑い状態だった訳だが
プリフィクス地獄にしたのは、IA32にプリフィクスを置くだけでAMD64とか言っちゃった
どこかの三流メーカーのせいだなあ…これじゃやっとれんって事でIntelはAVXへ。

548 ：
AMD64を採用しちゃったMSのせいじゃね？

549 ：
ハァ？
山のようにトランジスタ投入して鬼のようなワイヤードロジックを力技でねじ伏せるなんて、
とてもあんたの所以外真似できませんわ、と呆れ半分で退散したんだけどな。
そのせいで電力消費は泣き所だし。

550 ：
もし、ザイログがZ8000じゃ無くてZ180orZ280を先に作ってたら世界は変わったかな。

551 ：
[百周年記念サイト]　IBM 100年の軌跡
IBM PC　パーソナル・コンピューティングの発達
ttp://www.ibm.com/ibm100/jp/ja/icons/personalcomputer/
テクノロジーの飛躍的な進歩
ttp://www.ibm.com/ibm100/jp/ja/icons/personalcomputer/breakthroughs/
↑このタイミングで(1980年の後半)、CPUの外部調達を考え始めたIBMのチームに
ザイログやモトローラが積極的に石を売り込めていたら…
世界は変ってたかもしれない。
でもたぶん、8bitバスで内部16bitの‘適当な石’の選択肢が 8088
以外になかったんだと思う。
余談だけど、IBM-PCの型番(5150)が、タイムトラベラー(オカルトw)の
ジョン・タイターの話で出てくるポータブル機 IBM-5100 シリーズの
後継機扱い?なのが面白い(知らなかった)。

552 ：
あと Intel (と日本の賛同各社)も本当は、IA-64 (Itanium) が
普及してほしかったんじゃないかなぁ。
でも市場は互換性の呪縛から逃れられなかった…
前にも他のスレで書いたかもしれないけど、自分はいつもこの話題に関連して
キーボード配列「QWERTY」の件を思い出す。
もっと合理的な配列が20世紀初頭に色々提唱されたらしいけど、けっきょく
欧米のタイピスト(秘書?)市場に受け入れられず、そのまま世界標準に。
最初に‘なんとなく’決めた規格や採用したものが、そのまま市場を形成して
あとで改善しようにもできなくなる例って多いよね。
日本だと交流電源周波数50/60Hz問題とか、鉄道の狭軌/標準軌問題とか
半角バックスラッシュ→￥円マーク問題とか(UTF-8でも新￥コードは
なかなか普及しないらしい(過去のDBシステムとの互換性の関係?)。
ずいぶん横道にそれた年寄りの長文で、すみません

553 ：
AVXって言っても今はSIMDしかサポートが無いしねぇ。
それにAVXが解決するのはSSEnのプリフィックス地獄だけな気がする。
一般のx86命令についてはいまだに改善の方向性を示せてないのでは？
x64なんか、1命令が7バイトとか8バイトなんて珍しくなくなったし、もう
勘弁して欲しい世界。

554 ：
>x64なんか、1命令が7バイトとか8バイトなんて珍しくなくなったし、もう
>勘弁して欲しい世界。
本当にAMDはどうしようもないクズ企業だな。無能しか居ない

555 ：
ttp://www.kumikomi.net/interface/sample/201107/if07_054.pdf
ttp://documentation.renesas.com/jpn/products/mpumcu/rjj09b0465_rxsm.pdf
ルネサス・エレ(日立＋三菱＋ＮＥＣの合体技)
RXってCISCだったのか…。63C09の正統進化形？(んな訳はないかw)

556 ：
中森章の名前、久々に見た

557 ：
だから、これのどこを見れば63C09の発展系になるのよ？w
プログラミングモデルはどう見ても68000の派生アーキテクチャだけど。
命令の直交性とかを犠牲にして、コードサイズの縮小を狙った感じだな。
まぁ、今時命令の直交性うんぬんとか気にする時代でも無いが。

558 ：
もう終わってるアーキテクチャでさらに不毛な架空の論争をしてるなんてここは加齢板どころか電波板が相応しくなってきたなw

559 ：
ボケが厨房並みなら煽りも厨房並みだな

560 ：
>>559
よう厨房

561 ：
CAS命令はないのか？

562 ：
過去の16ビットリアル、16ビットプロテクト、32ビットプロテクトがそのまま使える64ビットなら

563 ：
また680x0の生産再開して欲しい

564 ：
需要の問題だな

565 ：
オレだけじゃダメ(´・ω・`)

566 ：
68040のV付きでようやく3.3Vデバイスだからねぇ。
今時5Vデバイスは往生するよ。

567 ：
自分はこれで我慢
ttp://www.cqpub.co.jp/interface/sample/200809/if09_048.pdf
部品買ってハンダ付けもしたけど、すごく熱くなるので物置行き。
つうか、もう３年たつのか…　加齢＝高速忘却マジやばいなw

568 ：
>>565
まだ再生産してたかも。オーダーの単位が数千だがな!、まさに外道

569 ：
今からならColdFireだけど、バイナリ資産が生かせないのは辛いか。

570 ：
なんか68kネイテブで生かせる資産て今更ある?

571 ：
OSや周辺ハードに依存しないルーチン、つまりシステムコールを使わず
I/Oマップ領域を触らず、S/Uモード(スタックの見え方)や割込みの違いに無関係で、
$A0〜や$F0〜ラインの未定義命令ジャンプも使わず、単純に引数を受け取って、
何かローカルな処理(演算とか)をして、$4E75 (RTS)で戻る…
みたいなシンプルな68kバイナリ・コードなら、そのまま ColdFire でも
走ると思うんだけど、これを資産と呼べるかどうかは、用途によると思う。
何せ LED チカチカを実験するだけでも、(物理アドレス)ポート叩くからなぁ…
何か特殊な、高速演算？ライブラリとかの類も ColdFireなら、積和演算レジスタを
使って作り直したほうが速そうだし、そういうパッケージも頒布されていそう。

572 ：
今調べてみたら68kの、MOVEP 命令 (1バイトずつ飛ばして読み書きする)
やっぱり ColdFire では削除されてるっぽい

573 ：
アセンブラソースが無ければdisればいいじゃないですか

574 ：
ColdFireの命令長は最大3ワード(6バイト)じゃなかった？
対する68000は最長5ワード(10バイト)なので、命令長から
来る制限がまずあるはず。
例えば、 MOVE.L #$12345678,$FEDCBA.L みたいに拡張
ワードがずらずら続く命令はNGだったんじゃ？
その他にも、3ワード以内であっても、ソース・ディスティネー
ション共にインデックスアドレッシングを指定するMOVE命令
とか、RISCとして複雑すぎる組み合わせもNGにしてるみたい。

575 ：
ABCD命令はあるのか？

576 ：
Cold Fireは68kから色々命令が削除されてるね。

577 ：
この辺りを参考に。
ttp://retropc.net/x68000/software/develop/as/has060/coldfire.htm

578 ：
>>574　な、なんだってー!　そんな重要なことを俺は見逃していたのかw
ゴメン、ちゃんと小さい文字で注意書きが書いてありました orz
MOVEの転送元　　　　　　　　　　　　　　　　　　　転送先として使えない場合
(d16, Ay),　(d16, PC)　　　　　　　　　　　　　　　　(d8, Ax, Xi),　(xxx).W,　(xxx).L
(d8,Ay,Xi),(d8,PC,Xi),(xxx).W,(xxx).L,#<xxx>　　　(d16,Ax),(d8,Ax,Xi),(xxx).W,(xxx).L
>>575　ABCD命令もちゃんと削除されてたw

579 ：
>>577　わかりやすい日本語の早見表、サンクス!
さっきまで辞書片手に、ひぃひい言いながら↓これと格闘してたw
ttp://cache.freescale.com/files/dsp/doc/ref_manual/CFPRM.pdf?fsrch=1&sr=48

580 ：
余計な文字がついたので、URLの貼り直し (キャッシュ鯖ぽいのでダメかも)
ColdFire Family Programmer's Reference Manual　(約1.7Mバイト 興味ない人ゴメン)
ttp://cache.freescale.com/files/dsp/doc/ref_manual/CFPRM.pdf

581 ：
retropcだと
ttp://www.retropc.net/x68000/software/develop/as/has060/has060.htm
hasのマニュアルに、削除命令がある。
DBRA(DBcc)が削除されたのは痛いな。あとEXG

582 ：
>>581
同意
x86がマイクロコード実行パイプを残して対応したような部分を、バッサリ切って捨てたような印象。
まぁ会社としては上位にPowerPCがあって、そっちに注力してた最中だろうから中途半端になる
のは判るけど、そんな68ｋ一部互換に意味があったんだろうかと疑問を感じるね。
名前に反してSuperHOTだったみたいだしw

583 ：
68000ってアドレッシングにスケールファクタ使えたっけ？
というか040を元に命令を減らしているのか？＞ColdFire
6800に対する6502ぐらい違えばいいのに。

584 ：
バレルシフタ導入のお陰かどうか知らないけど68020からだね。

585 ：
>>583
68000で命令中のスケールファクタ部は単純に無視されるので、020以降かどうかのMPUの判別に使えたりも。

586 ：
060はどう?

587 ：
どうってなにが？

588 ：
そういえば、68060って68040の上位版だよね。
どこが違うの?

589 ：
パフォーマンス上一番大きな拡張は、実行パイプを1本から2本に増やしたところ。
その他分岐予測が新たに付いた。

590 ：
>>588
movepほか、いくつか命令が削除された。

591 ：
バレルシフタは020からだったんた。
気にしなかったな。
x86だとローテート命令の移動量がマスクされたと言うのがあったのがバレルシフタの副作用だとか怪しげな話しは聞いたが。

もうどっちもアセンブラでなんか使わねーなー…

592 ：
確か8086と286以降で挙動が違って、複数幅のローテート・シフトの時、
幅が15より大きい場合に、実際にそれだけシフトするか、上位桁を
無視するかの違い、だったと思った。
カウンタと1ビットシフタでシフトするか、バレルシフタでシフトするかの違い。

593 ：
おまいら座布団用意しといたか

594 ：
cx回正直にシフトしちゃったのって、どこの実装だっけ？

595 ：
ホントにｷﾀ

596 ：
Coldfireですが実機がないと不便なのでは？
評価基盤やエミュレーションあると思いますが、実機どうしてます？

597 ：
FT-86

598 ：
最近は自転車専用当屋って言うのがいるんだってね。
ブレーキ無い自転車にわざとぶつかって数万〜数十万ゆするそうだ。

599 ：
どこに誤爆したんだ。まあノーブレピスト乗ってるやつには痛い目見て欲しいけどw

600 ：
ColdFireで削られた機能って、意外とインパクトあるものが多いなぁ。
>>581さんも言ってるDBRAはもちろんだけど、ローテート命令は削除か。
暗号処理とかで泣く場面は無いのかな？
それとADD/SUB/CMPのロングワード限定。
バイト・ワードサイズのデータを比較して、その後Cフラグで分岐とか、
そういうのはEXTか、もしくは上位ゼロ拡張してからやってねってことか・・・
めんどくさ。
そのわりにMOVEMみたく、マイクロコード実行の権化みたいなのは削除
されずに残ったんだな・・・
やっぱり、性質の悪いサブセットを見てる気分だ。

601 ：
>>600
ColdFire V4 の MCF540X のユーザーズマニュアル眺めてみたけど、
http://cache.freescale.com/files/32bit/doc/ref_manual/MCF5407UM.pdf
cmp.b と cmp.w はあるみたいだけど、違うチップの話?

602 ：
>>601
へ？
・・・よく見たら命令セットのリビジョンで違うみたいだ。
ISA_A（V2/V3)：CMPはロングワードのみ可
ISA_B(V4〜）：CMPはバイト・ワード・ロングワードが可
よほどクレームでも入ったのか、変更されてるね。
ADD/SUBは相変わらずロングワードのみのまま・・・
同じアダー使うんだからこっちも変更しちゃえばよかったのに。
なんか、製品としての軸もブレてる気がする。

603 ：
いまどきのプロセッサならとりあえずC言語が動けばいいんで
ローテートやint未満の演算なんかは要らないってことでそ

604 ：
C言語にローテイトやint未満演算って無いの?

605 ：
言語仕様としてのローテイトはない
基本的に整数演算はintに符号拡張して行なわれる
ただし結果が同じになるなら符号拡張しなくてもよい

606 ：
int未満の演算要らないと言うなら、最初からMVSとMVZ命令は
用意しておくべきだったね。
ISA_Bから追加とか、泥縄もいいところ。

607 ：
無くなった命令はマクロで復活だな。例外でやってもいいけどオーバーヘッドが。

608 ：
ソースから再ビルドが要るなら68kアーキテクチャにこだわる必要ないよな。

609 ：
68kに思い入れが無ければSHでもARMでも。スレチだけどな。

610 ：
日立の68Kは隠し命令無かったの?

611 ：
>>610
HD63C09でモトローラに怒られたしなかったんじゃない?

612 ：
H16はなんかダメな石だったと聞いたな。現物を大学の先生が手に持ちながら。
（片付けしてたら棚から出てきたw）

613 ：
68Kには不正命令トラップがあるから、トラップされる/されないで
確実に判別できるんだけど、いかんせん未定義になってるバイナリ
の数が多すぎるからねぇ。

614 ：
Z80や8080系、68系等の8bitは未定義命令はNOP？Flagも変化無し？

615 ：
何が起きるかはその命令次第
昔68でHCFっていう伝説の未定義命令があったなー
Halt and Catch Fire
実行するとハードが火を噴くという・・・

616 ：
未定義命令を一つ一つ解析してた記事を見た覚えあるなあ。
レジスタとフラグがどう変わるか書き出してた。
モノによっては使えるものもあったな。

617 ：
>>616
それが残ってないってコトは、使えるないようではなかったってことカナ？

618 ：
>>617
リビジョン変っちゃうと動作が変っちゃったりしたんじゃないかと。

619 ：
中身がマイクロコードが直接見えるデザインに近くなってるもんで、それっぽい
オペコードでそれっぽく動作しちゃったりする石はたまにあったよね他にも。
>>615
特定の信号線がローとハイに目一杯切り替わり続けるとかいう奴ねw
ロー側とハイ側のトランジスタが同時にオンになるとかもあったりしたら怖いが。

620 ：
ロー側とハイ側のトランジスタ?

621 ：
>ロー側とハイ側のトランジスタ?
確かに。CMOS化後の話？

622 ：
68030 + 68882 ぐらいの時代が最強だったなぁ、と思う
ttp://ja.wikipedia.org/wiki/MC68882
68040 の浮動小数点演算内蔵化で、三角関数が外されたのが残念
ttp://ja.wikipedia.org/wiki/MC68040
いや単に、MacのIIvx (030採用機)をローンで買った直後に
Mac Centris (040採用機)が発売されて悔しかった自分のグチなんだけどさw

623 ：
この間ヤフオクにPC68040ってのが出品されてたんだけど、あれってなんぞ？

624 ：
>>623
よくあるES(エンジニアリングサンプル)品。 PC68060とかも存在するよ。

625 ：
ほう、ESはXC型番になるのかと思っていた。
ということは PC → XC → MC というような流れで量産が立ち上がっていくのかな？

626 ：
PC型番には「RC25」等のクロックの表記が無いです。
PC68040はわかりませんが、PC68060を持っている方の話では、かなり高クロックでも動いたらしいですよ。

627 ：
SC型番もあるよな。

628 ：
SX/Gの上位機種に060使ってたけど、FM-Gにも使った機種有った?

629 ：
NSも32Bit出してたよな?

630 ：
NS32000な

631 ：
>NS32000な
「68kシリーズは32bitプロセッサ」と言い切るぐらいのトンチンカン

632 ：
>>631
へー、なぜなのか説明してほしいなあ

633 ：
>>632
NS32000というプロセッサは存在しない。俗称的に使われるシリーズ名である。
シリーズ初の製品NS32016(当初はNS16032、後に改名)は16ビットプロセッサ。

634 ：
>>633
はじめっからそういっとけばいいんだよ

635 ：
っていうかWikipediaにも書いてある程度のことを
得意げに言われてもなぁ

636 ：
Wikipediaなんか信じちゃってる男の人って…(ｸｽｸｽ

637 ：
wikipedia で言い負かされて逆切れ？
かわいそう…

638 ：
wikipedia引き写して「論破ｷﾘｯ」とか

639 ：
で、wikipedia を負かす反論あるの？ (w

640 ：
誰一人そんなこと言ってない

641 ：
草まで生やしてなにをそんなに必死に煽ってるんだろうか
なんか都合が悪かったんかね

642 ：
wikipediaを引き写したことを笑われてるのにそんな程度のことも理解してないようだ

643 ：
>>642
>wikipediaを引き写した
え？どのへんでそう思ったの？ｗ

644 ：
今になってやっと引き写したことを否定しはじめたか

645 ：
どこが笑われてるのか説明してもらって慌てて否定しはじめたんだなwwww

646 ：
>>644
>今になってやっと引き写したことを否定しはじめたか
同じこと言ってる箇所って
>シリーズ初の製品NS32016(当初はNS16032、後に改名)
ってとこだけじゃん。

647 ：
>>640
>>636
なんかアホみたいに wikipedia に反応する奴いるけど、
誰一人それ以上の情報出せない件。

648 ：
>>647
>誰一人それ以上の情報出せない件。
>>633にはWikipediaに載ってないこと書いてあるけど。

649 ：
>>647
>なんかアホみたいに wikipedia に反応する奴いるけど、
そんな暇人の素人が書いたようなもんを有難がるかね?

650 ：
と、素人以下の人がおっしゃってます。

651 ：
>>650
素人以下なら尚更、Wikipediaみたいな不正確なもん参照して間違いに気付かない
危険性は念頭において、できるだけ一時情報当たったほうがいいんじゃないの？

652 ：
誤)一時情報
正)一次情報

653 ：
>>651-652
で、どっか間違ってたの？

654 ：
>>653
不確かなWikipediaは最初っから信用しないってことだろ

655 ：
雑誌記事とかでも信用できないものは多かったけどな

656 ：
>>654
そういうことはもっと確かな情報出してから言うことだな。

657 ：
>>656
そういうことはどこが間違ってるか指摘してから言うことだな。

658 ：
>>630 間違ってはいない
>>631 適切な突っ込み
>>632 痛い
>>633 Wikipediaのコピペ? 間違ってはいない
>>634以降 とても痛い

659 ：
>>658=>>631

660 ：
>>659
残念、ハズレ

661 ：
>>658
俺様が判断してやるってか
お前が一番痛いな

662 ：
痛いとこ突かれちゃったみたいだな (w

663 ：
>>661
自分でもそう思ってとても痛いに入れておいた

664 ：
32032はいいと思ったなー

665 ：
x86のプロテクトモードへの移行とPC-ATのお約束(A20ラインだっけ？)とかが面倒で低レベルなプログラムを作る気にならない

666 ：
>>524-666

667 ：
?

668 ：
Z8000

669 ：
>>665
そんな仕事、今時はboot loaderがやってくれます
GRUBが、その面倒なのをすべて処理した上で実行してくれるので、
低レベルなプログラムも書き放題

670 ：
低レベル処理と言っても、DOSとの互換性とか意識する必要がないなら
プロテクトモードで書いてしまえば良いのだし、
モニタに相当する処理を1から書くのが面倒だと言うなら
他のメモリ保護やマルチプロセスに対応した32/64bitCPUでも手間は変わらん。
「x86だと、俺様の気分が乗らない(信仰上の理由でIntelを生理的に好かないから)」
くらいの理由だろ、馬鹿馬鹿しい。

671 ：
インテルは当時8ビットCPUを無理矢理拡張したアーキティクチャの8086をして
68000と互角かそれ以上の性能を発揮するかのような出鱈目な誇大宣伝を
繰り返していた罪深いメーカーだ。
最近ではＡｔｈｌｏｎ64のＡＭＤ相手に劣勢に立たされた時に
札束攻撃で提灯記事を書かせメーカーの抱え込みでＡＭＤのＣＰＵを締め出すなど
政治的対策でライバルを排除し独占禁止法違反に問われていたことも記憶に新しい。
インテルが好かれないとしたら信仰上の理由ではなく、正当な競争を妨げることもある
限りなく黒に近いダークな側面を持った企業だからなのである。
まあパソコンの需要がスマホおよびタブレット端末に食われはじめ
x86自体の独占が崩れつつある今となってはどーでもいい話ではあるが。

672 ：
x86も思ったより頑張ったね。半導体業界全般を牽引してた功績は認める安らかに寝てよし。

673 ：
>>671
>インテルは当時8ビットCPUを無理矢理拡張したアーキティクチャの8086をして
>68000と互角かそれ以上の性能を発揮するかのような出鱈目な誇大宣伝を
>繰り返していた罪深いメーカーだ。
そんなことあったっけ? ないでしょ。

674 ：
68k系の方がてんで見掛け倒しだったな
リニアアドレスだけが取り得で、隅っこで生き長らえていたようだが

675 ：
68k系はMMUすらない劣化版が多い上に
スーパーバイザのメモリ空間が完全に分離している設計もありえる
環境耐性が高いだけが取り柄の素人お断りの変態MPU

676 ：
>>675
素人乙

677 ：
68kは010仕様で出すべきだった。

678 ：
どうかな？
仮想マシン/仮想記憶関係が不完全だったけど、当時だとたいして影響無かったと思う。
この業界出したモン勝ちの傾向あるから、リリース時期は重要だし。

679 ：
リリース時期でいえば、6809の時に出すべきだった。どうせ6800とはどちらもバイナリ非互換。09大好きで今も持ってるけど。
010との違いでいえば、スタックフレームの非互換が痛い。
上とも重なるけど、当時はバイナリの互換性が重要な時代だった。
EEP-ROMはまだなかったよね。

680 ：
http://ja.wikipedia.org/wiki/EEPROM
> 歴史 [編集]
> 1978年、インテル社の George Perlegos は初期のEPROM技術に基づいて Intel 2816 を
> 開発したが、酸化膜の層を使い紫外線を使わなくともチップ自身がビットを消去できるように
> した。

681 ：
スタックフレームの変更は、例の68k単体では不可能だった仮想記憶を
どうにかするためにはどうしようもなかったんでは？

682 ：
x86みたいにモード変更できるようにすればOK

683 ：
286のディスプリクタは虫食いで386ン時に面倒だった。
ラッパー関数で隠蔽したけどね。
68008用に書いたプログラムをなぁんにも知らない奴がリコンパイルしただけで「割り込みがうごかねぇ！バグだごらぁ」と
部署変わったのに怒鳴り込んできたことがあったっけ・・・

684 ：
68010 のスタックフレームってそんなに問題だったけ？
OSとかデバッガーとか書いてる人はちょっと手直しが必要だったけど、
修正量はたいしたことなかったはず。
そもそも、68系使ってる人は元々バイナリの互換性を当てにして無かっ
たと思う、8bit 時代からそういう会社だったし。

685 ：
X68000(68010)
X68020
だったらよかたな

686 ：
X68030すら遅かったしな。
今はエミュレータ様々だけど、当時のwktkはもう戻らない。

687 ：
PICとかAVRで電子工作、楽しいぞ。非力なプロセッサであれこれする楽しみがまだある世界だ。

688 ：
非力といっても100円のマイコンが68000の何十倍も速いからな

689 ：
ハードはダメダメだからXM6gでちょこちょこ楽しんでるわ＞懐かしコーディング。資料もそろってるしね
ATと86を始める元気は無いし

690 ：
>>688
いま100円で買えるマイコンはまだ8ビットとかそんなだ。そこまで速くはない。

691 ：
x68エミュ板がないのでココで聞くしか無い
（x68本スレ？は変に荒れてるし）お許しを
アレの塊（68＋98の奴）のことなんだけど、ファイルが多くてデカすぎて中身がわからない
とても40g全部いくわけにはいかない
空の不動産・あの素晴しい　をもう一度のx68版が
入ってる圧縮ファイルはどれなのか教えて欲しい


692 ：
夏だなーって感じ

693 ：
>>691
エミュでさえウザイのに、その上違法ダウンロードかよ
もうどっかいってよ

694 ：
Wikipediaでこんなん見つけたｗ
FM TOWNS - Wikipedia
http://ja.wikipedia.org/wiki/FM_TOWNS#cite_note-31
> 28. ^ 富士通はかつて8ビットパソコンの時代にもFMシリーズで6800系パソコンの老舗で
> あった日立の独自アーキテクチャのパソコンを消滅に追い込んだ過去を持つ。

695 ：
こんなところにまで自演しに来なくていいよ。
おとなしく巣に帰れ。

696 ：
あちこち書き込んでるからどちらかと言えばあらしだろう。

697 ：
前はX68KのWikipediaの内容が地味にTownsと比較してdisられる内容だったなあ

698 ：
せめてX68Kノートが有ったらなあ。

699 ：
SONYプロデュース

700 ：
NEWSはどうなった?

701 ：
平成の早い時期にmipsに変わった

702 ：
０４０ジャンク屋で発見

703 ：
>>702
買った?

704 ：
680000とか作らないかな。

705 ：
つPowerPC

706 ：
Coldfireたんが世界を制覇していれば！

707 ：
そういや、シャープがPowerPC搭載のX68K後継機を出す予定じゃ
なかったか？

708 ：
何寝言言ってんの
薬でもしているのかいな

709 ：
零式なら満開からあちこち放浪してポシャったよ

710 ：
8bit、両方削除してどうすんだよ。

711 ：
>>710
両方とも伸びなかったからな〜。
も１回スレ立てるので、援護射撃たのむぜ。
最初の１週間が肝心だから。

712 ：
コンピュータ歴史博物館 ( Mountain View, California )
http://www.computerhistory.org/
http://maps.google.co.jp/?ie=UTF8&ll=37.41429,-122.077251&spn=0.002855,0.006207
「インテル 386 マイクロプロセッサのデザインと開発　口述史パネル」
参加者: John Crawford, Gene Hill, Jill Leukhardt, Jan Willem Prak, Jim Slager
司会: Jim Jarrett (386開発陣への回顧インタビュー　2008/12/02録音)
http://archive.computerhistory.org/resources/access/text/Oral_History/102702019.05.01.acc.pdf
(別スレで依頼があったので、面白そうな所を適当に抜粋・意訳。英語は苦手なほう
なので日本語が変だったり、誤訳があったらすみません。p4 の中盤あたりから)
[Jill Leukhardt:] We were not cognizant of the importance of software that
was being developed for the PC and its user base, so what is obvious today
in terms of the installed base of software and the vast importance of that
compatibility was not at all obvious when we were entering into the definition
phase for the 386.
私達はPCユーザーベースで開発されたソフトの重要性を認識していませんでした。
インストールベースのソフトの見地では互換性の重要さは、現在では当たり前ですが
386の設計段階に入った当初はまったく明白ではありませんでした。
In terms of the competitive environment, the Motorola 68000 was a superior
machine, and we knew it and felt it very strongly. We perceived that we were
going to be later than the 68020, the Motorola 32-bit product that we would
be later to market with the 386 and so we felt that very strongly and that
created a real sense of urgency in terms of what we were trying to do.
競合他社としてモトローラの68000が優れていることを私達は強く感じていました。
さらにモトローラの32bit製品、68020にも遅れをとっていると認めてました。これは
386が後から市場に参入することになるので、私達も本当に緊急性を強く意識していました。

713 ：
Third, we were stuck with the 8086 approach to segmentation that was wildly
reviled; everybody hated 64K-byte segments. They limited the size of data
structures and that was perceived to be and was actually a limitation in
certain applications. Programmers in particular and compiler writers and
others just saw that as a huge limitation. Jim you want to say something?
第三の点は、8086のセグメント方式で行き詰っていたことです。激しくののしられ
誰もが64Kバイトのセグメントを嫌っていました。データ構造の大きさに限界があると
理解され、実際にいくつのアプリでは制限がありました。プログラマー、とくに
コンパイラの作者はこれが大きい制限だとみなしました。Jim, 何か言いたいかい?
[Jim Slager:] Oh yes it’s just humorous when you look back…that we thought
it was so important to have a segment-based memory management scheme because
of the Zilog MMU and it was defined into the 286 and we just thought it’d be
the greatest thing in the world but customers just didn’t agree, I don’t
know what was wrong with them <laughter.>.
ああ、はい。振り返ってみると滑稽な話ですが、当時ザイログのMMUにならって
(訳註 Z8001用のZ8010のこと?) 私達はセグメント型のメモリ管理方式がとても
重要だと考えていました。そして286の設計にも組み込んで、これで世界一偉大に
なるだろうと思ったのですが、顧客層はそっぽを向いたのです。彼らは何が
気に入らなかったのか私にはわかりませんね(笑)。

714 ：
司会 [Jim Jarrett:] So it’s early 1982 you’ve got the 286 out; there’s;
nobody particularly wild about it, but it’s moving along and now a new effort
is beginning to develop: a follow on to the 286, and that’s where you all
come together. What was the environment within Intel at that point and the
thinking about this new chip?
では1982年の初めに286を世に出して、誰も特に熱狂はしなかったがそれは続き
今度は286の後継機を新たに開発するために皆さんが集められたわけですね。その時点
で新チップに関するインテル内部の方針や環境(雰囲気?)はどうだったのでしょう?
(p5)
[Gene Hill:] Well actually that chip started as a non-chip; the 286 was so
unsuccessful, Bill Gates called it “Brain Dead”. IBM said there could not
be a follow-on; it was a dead-end architecture.
実際はチップ以前のスタートでしたね。286はとても不成功で、
ビル・ゲーツは「脳死」と呼びました。IBMは、後継機はあり得ない、
行き詰まりのアーキテクチャだ、と言いました。

715 ：
[Jarrett:] If you couldn’t do a follow-on to the 286, what was the next
processor that Intel was thinking of bringing out?
286の後継が不可能とすると、次期プロセッサとしてインテルは何を考えていたのでしょうか?
[Crawford:] This was all in the shadow of the 432 microprocessor development
at the time. The 432 was a very ambitious project that Intel was very firmly
committed to and unfortunately it was also late and had slipped pretty
significantly; so we had a number of gap fillers that were thrown into the breach.
That was a little before my time, but my understanding is the 8086 microprocessor
was the first of those gap fillers, followed by the 8088, the 186 and the 286.
That’s another key piece of information here: the 432 project was really
supposed to be our big thrust in the microprocessor market and these other
efforts were really more or less gap fillers.
すべて当時 432マイクロプロセッサ計画が影を落していました。432はインテルが強く
進めていたとても野心的なプロジェクトですが、残念ながらこれも遅れてかなり時期を
逸しました。したがってそれを埋め合わせる‘場つなぎ’がたくさんありました。
私の担当より少し前の話ですが、私の理解では8086が最初に投入された場つなぎの製品
であり、それは186そして286と続きます。ここで鍵となるのは、432プロジェクトが、
マイクロプロセッサ市場でインテルの大きな推進力になると本当に思われていたので
それ以外の努力はみな多かれ少なかれ、場つなぎだったのです。

716 ：
[Prak:] There was a variety of proposals to come up with a new architecture
because there were a lot of people who realized the 432 was fatally flawed.
So the project I joined originally was code-named the P4 and it was a whole
new architecture that was very VAX-like. It was developed by Glen Meyers and
the people in Oregon who had been responsible for the 432 wanted to try again.
A number of them realized there were problems, so they wanted to do it over
basically. So they had a proposal and as Gene indicated the 386, 32 bit
follow-on was kind of the step child already in that discussion.
多くの人が432は致命的に欠陥だらけと考えていたので様々な新アーキチクチャの提案が
ありました。私が前に参加していたのはP4というコード名のVAXライクな計画でした。
432の責任をやり直したがっていた、オレゴンのGlen Meyers達の開発です。たくさんの
人が問題を認識していて基本から作ろうと提案していたので、Geneにとって後継32bit
の386は既に‘まま子’のような扱いでした。
(p6)
[Jarrett:] So this 386 effort was launched and I guess the first thing we need
to talk about is the definition of it. I guess Jill and John you were quite
involved in that process; tell us about it.
さて386の取組みが開始されたわけですが、その設計定義の話を最初に伺いましょう。
JillとJohnがそのプロセスで大きくかかわっていたと思います、お聞かせください。

717 ：
[John Crawford:] So the definition effort started-- I was there a little bit
before Jill, just a few months before and there actually were two architects
on the 386. There was the effort that Gene talked about earlier that Bob Childs
had pulled together. It was a proposal for a 32-bit extension of the 286 and
Glen Meyers had asked me to step in and do one, and so we had these two
sketches of what an extension might be. So we had kind of the battle of the
architectures going on a little bit.
設計が始まりました、私はJillよりほんの少し、数ヶ月前からですが、実は386には二人の
設計者がいました。先ほどGeneの話にあった取組みは Bob Childs が主導していたのです。
それは286を32bitに拡張する提案で、Glen Meyersは私にその一つに入るように指示し
拡張がどうあるべきかを、二つのスケッチ(方針)で社内競争させるようなものでした。
George Alexy was the Marketing Manager and he took Bob Childs and me out to
seven selected customers to bounce both sketches off of the potential
customers and get feedback from them.
営業マネージャのGeorge Alexyが7つの潜在的な顧客を選び、Bob Childsと私をそこに
引き合わせてフィードバック意見を聞きました。
[Jarrett:] So what were the key differences between the two approaches:
yours and Childs?
あなたのとChildsのと二つのアプローチのおもな違いは何だったのでしょう?
[Crawford:] My proposal was a simpler upgrade and I think kind of the essence
of it was to focus on the key issues, which were to extend the address space
to 32 bits and in particular provide a flat addressing of 32 bits.
That was a key failure or lack in the 286 that I think was mentioned earlier.
私のほうがシンプルな提案で、32bitのフラットなアドレスにおもな重点をおいてました。
先ほど指摘したようにそれが286の失敗の鍵・欠けていることだったので。

718 ：
(p7)
Second thing was to make it a full 32 bit machine so have some way of giving
it a full 32 bit instruction set.
The other thing that we wanted to fix was to increase the number of registers.
The proposal I put forward was a more minimal extension and admittedly it
fixed two of the three issues. It provided the flat 32 bit addressing.
It supplied a full 32 bit instruction set.
It did not change the number of registers. The proposal and the instruction
set looked-- the instruction setting coding was very similar to the 8086.
So the instruction decode piece would have been a small change or a much
smaller change.
二番目として、フル32bit機つまり完全な32bit命令を何か実装する方法です。
その他にはレジスタの数を増やしたいこともありました。私の提案する方式は
そのうち二つだけを直しました。フラットな32bitアドレスとフル32bit命令です。
レジスタ数は変えませんでした。命令セットは8086によく似ているのでデコーダも
より少ない変更ですむだろうと思われました。
Child’s proposal on the other hand tried to address all three and in doing
so he ended up with a much more complicated instruction encoding strategy.
In particular the 32 bit instruction set was quite different from the 16 bit
instruction encoding. It did provide the opportunity though to increase the
number of registers, which addressed the third point.
Today I can’t remember how well it did on the first two but he did have the
distinguishing factor that it increased the number of registers.
いっぽうChildsの提案方式は(前述の)三点すべてを直そうとする試みで、もっと複雑な
命令エンコード戦略でした。特に32bit命令セットは16bit版とかなり違っていましたが
レジスタの数を増やす機会が得られました。
最初の二点を彼がどううまくこなしたか、今となっては思い出せないのですが
レジスタ数を増やすという三番目の点が、はっきり私のと違っていました。

719 ：
[Jarrett:] The customers gave you input and chose your approach -- correct?
顧客の意見はあなたのアプローチを選んだ…　ということで正しいですか?
[Crawford:] Well I think we got mixed feedback from the customers.
There were some customers that didn’t care at all about 8086 compatibility.
We wanted to see a broad range of customers, some of whom weren’t even using
our products, so clearly they wouldn’t care much about the compatibility.
Others were quite concerned about it, but I think overall the feedback was
compatibility would be nice to have but not critical, and that is kind of
curious looking backwards.
On the other hand, our field application engineers gave us very strong
feedback that we had to run the old software, and that would be critical for
success of the project and also critical for continued success of the 286
and the other products.
賛否とりまぜたフィードバックだったと思います。8086との互換性を全く気にしない
顧客もいました。幅広い分野から聞いたので、中には私達の製品をまだ使っていない
のもあり、明らかに互換性はどうでも良かったのでしょう。他の顧客では、互換性を
とても気にする意見もありましたが、全体としては「互換性はあれば望ましいが
クリティカルではない」という感じでした。思い返してみると奇妙ですね。
いっぽうその逆に、社内の現場アプリ技師達は、古いソフトを動かさねばならないので
互換性が極めて重要だと私達に強く主張しました。そしてこれがプロジェクトの成功や
286その他の製品の持続的な成功にとってクリティカルなのだと。

720 ：
[Jarrett:] Was this was PC software they were concerned about?
彼らが懸念していたのは、PCソフトウェアの互換性だったのでしょうか?
[Crawford:] Oh no, not at the time, I think it wasn’t that long since August of
1981 with the big IBM PC introduction. It seemed that the PC was an interesting
design but not one viewed as really the key thing to win and to do well on.
Instead there was still a broad range of designs from the terminals to kind of
little minicomputers to the personal computers which were just emerging.
いえ、あの頃は違います。大いなるIBM PCが発表された1981年の秋からさほど経って
なかったと思います。PCは興味深いデザインではあるが、後に善戦・勝利の鍵となる
ものだとは、みなされてませんでした。その代りにまだ、ターミナルから小規模ミニコン
や始まったばかりのパーソナルコンピュータに至るまで、広いデザイン(分野)がありました。

721 ：
[Jarrett:] How about the work stations? At this point was that considered to
be a market to focus on?
ワークステーションはどうでしょう? これについて、市場の焦点として考慮しましたか?
[Leukhardt:] Well we thought that was a key market segment for the 386.
It was not a market segment where the 286 was doing well at all;
it was a market segment where the 68000 was cleaning up principally because
the 286 was not viewed as a machine that ran Unix well and the 68000 was viewed
as a natural Unix machine. So when we were working on the 386 definition we
wanted it to have as one of its attributes being able to run Unix well.
So that’s one of the things that influenced us in terms of wanting to have a
way to run the 386 as a flat 32-bit machine, and that’s one of the things
that led to all the angst in the definition process about compatibility versus
a flat 32bit machine and how they would coexist.
ええ、386の主な市場分野として考えていました。286は全くだめでした。主として
68000が総ざらえしている分野でした。なぜなら286はUnixをあまり良く動かせず、
68000は自然なUnixマシンとみなされていたからです。なので386の設計を開始したとき
私達はUnixが良く走るという特性を持たせたかったのです。これはフラットな32bit機
として386を動かしたいという点に影響します。したがって、互換性とフラットな32bit
マシンの共存をどうするかが、設計プロセスのすべての苦悩のひとつでした。

722 ：
[Jarrett:] So that shapes up as a key challenge architecturally;
how did you address that?
アーキテクチャ的に挑戦すべき鍵となる点が形作られたわけですが、どう取扱いましたか?
(p8)
[Crawford:] In fact that was one of the most difficult architectural issues
that I had to wrestle with: how to keep that compatibility with the
segmentation yet provide this thing and I know we went through endless
iterations and had a lot of advice from many people.
In the end the thing that worked was inventing a fictional address space in
between the programmer’s virtual address space and the physical address that
you go to memory with; in fact we had to invent a new name for it,
so we called it the “linear address space”
We kept the segments but we provided the ability to have a segment that was
four gigabytes in size and that let the workstation guys and the Unix people
address this four gigabyte flat address space basically by setting up one
segment and having all of their programming objects within that one segment.
実際、私が取組まなければならなかった中で、最も難しいアーキテクチャ上の問題でした。
いかにしてセグメントの互換性を維持しつつ新機能も提供するか、繰返し際限なく
多くの人から助言をもらいました。結局、プログラマーの仮想アドレスと物理的な記録
アドレスとの間に、架空のアドレス空間を創案することで対応しました。実際、
「リニア・アドレス空間」という新しい名前を考案しました。
機能はそのままサイズが4ギガバイトのセグメントを持てるようにし、ワークステーション
やUnixの人は、このセグメントを一個だけ用意して、全てのオブジェクトをその中に
いれれば、基本的には4ギガのフラットな空間をアドレスできるわけです。

723 ：
[Slager:] Of course there’s controversy about all of this and, you know,
it’s incredible and one thing that I remember well is that the architect of
the 8086, one of the two architects, Steve Morris, who started the whole X86
phenomenon… he was bitterly opposed to the segmentation model that was
installed in the 286. When the 386 turn came he was very active-- he was still
at Intel in software somewhere-- and he was very much opposed to the segmentation
model because of the two-part pointers. In fact he called it software poison.
もちろん、知っての通りこれら全部について議論はありました。私がよく覚えてるのは
8086を設計した二人の開発者のうちの一人、Steve Morris つまりx86現象を始めた張本人
である彼が、286に組み込まれたセグメンテーション・モデルに厳しく反対したことです。
彼はソフトウェアか何かの部門でまだインテルに在籍してましたが、386の段階が来ても
とても積極的で、ポインタが2パートになるという理由で、セグメンテーションにとても
反対でした。実際彼はそれを、ソフトの害毒と呼んでました。
This was the environment that John had to work in and he did come up with a
brilliant solution. We ultimately ended up with the best of all worlds: we had
the compatability, but that whole segmentation model which was pretty much
generally hated could just move over to the side and not interfere with the
software.
It still had to be there, we had to design it in and test it and that was pretty
bad, but it could get out of the way and not prevent the success of the 386.
こういう環境の中でJohnは仕事に取組み見事な解決策をもたらしました。究極的には
全世界で最善の形で仕上げました。私達は互換性を維持しましたが、一般的にかなり
嫌われていたセグメントモデルは、ソフトに干渉しないように脇にどけることができます。
それはそのまま残し、設計上もテストも大変でしたが、そこから抜け出すことができ
386の成功の障害にはなりませんでした。

724 ：
[Leukhardt:] Now in some ways we’re getting ahead of ourselves because we got
to the solution that included segmentation plus a flat address space, sort of
the “have it your way” approach after we made the decision that we had to
build a fully compatible machine that is an object code compatible 386, and
that took a long time to decide. In retrospect that seems like a completely
obvious decision but we wrestled with that decision for months and it was a
tough decision-making process.
オブジェクトコード完全互換として386を作らねばならないと決めた後に、セグメントと
フラットアドレスの両方を含み、いわば「あなたの好きな方法でどうぞ」のアプローチを
とる解決策を得て、やっと私達は前を向くことになります(?)。この決断には長い時間が
かかりました。思い返してみるとまったく明白な決断に思えるのですが、当時の私達には
何ヶ月も要する大変な意思決定プロセスでした。

725 ：
[Jarrett:] So John, you came up with this new approach that would accommodate
both segmentation and paging. Was there any kind of a performance price that
you paid as a result of this?
そうして John, あなたはセグメントとページングを両方内蔵する新しいアプローチに
辿り着いたわけですが、その結果、何かパフォーマンスの劣化がありませんでしたか?
[Crawford:] That’s an interesting question; in fact it was obviously a big
concern because we were putting in two translation steps.
Of course it’s a critical path on any computer, and that was a big concern
all through the internals of the chip and even the BUS definition that was a
careful concern. But the advantage was, I think it was mentioned before, we
got the best of both worlds: we had segments for compatibility and paging for
a flat address base; that was pretty much everybody.
いい質問です。実際、二段階の変換ステップを入れるは明らかに心配でした。もちろん
どんなコンピュータにもクリティカルパスはあり、内部だけでなくBUS設計でも注意深さ
が必要な懸念材料です。しかし利点が(勝って)いました。先ほど言ったように、両方の
良い所を得られます。セグメント互換性とフラットアドレスベース用のページングです。
これは皆にとってちょっとしたものです。

726 ：
[Jarrett:] Now internally, did everybody buy into this immediately or was
there some debate on this approach?
社内的には全員がすぐに賛成したのですか、それともこの方法に何か議論がありましたか?
[Crawford:] Well, I think that came at some point in 1982, but before that
there were many proposals, obviously which didn’t survive, that didn’t solve
the problem as completely. At some point there was a decision taken to go with
my architecture as opposed to the Bob Childs architecture. As I remember, a key
part of that was involved the software compatibility question and how efficiently
we needed to run old software, and whether there would be a mode bit and
basically have two machines in one or something more tightly integrated.
ええ、これは1982年のどこかだと思いますが、それ以前は多くの提案がありました。
明らかにどれも生き残りませんでした。完全には問題を解決できなかったからです。
ある時点で Bob Childsのアーキテクチャでなく、私の案で行く決定がなされました。
私の記憶では鍵となる要素には、互換性の問題や古いソフトをどの程度効率よく動かす
必要があるか、モード・ビットを使って基本的に二種のマシンを入れるのか、それとも
より緊密に統合するのか、という点を含んでました。
I think for reasons of simplicity and for efficiency and time pressure we opted
for the simpler model, which is the one that I had proposed that gave us the
32-bit extensions but without having a mode bit and without having a huge
difference in the instruction sets. As I mentioned earlier, the price for that
was we kept the eight-register model which was a drawback of the X86, but not a major one.
簡便さや効率性や時間的なプレッシャーが、モードビットなしで命令セットの大きな
違いのないシンプルな私の案を選んだ理由だったと、私は思います。先ほど話したように
代償はレジスタ8個のモデルで、x86の欠点が残りましたが、大きな問題ではありません。

727 ：
[Crawford:] (続き)
I guess in addition I got half credit for the register extension because I was
able to generalize the registers. On the 8086 they were quite specialized and
the software people hated that too. One of the things I was able to get into
the architecture was to allow any register to be used to address memory as a
base or an index register, and was even able to squeeze in a scale factor for
the index.
さらに、レジスタを汎用化できたことで半分は面目を保てたと思います。8086では
とても特殊化されていて、これもソフトウェアの人々から嫌われていました。
私がアーキテクチャに組み込めたことの一つは、どのレジスタもアドレスのベースや
インデックスとして使え、さらにスケールファクタも入れられる点です。

【8bit機】CRTC,VDP,ALU,メモリマップ,MMU 専スレ
http://ikura.2ch.sc/test/read.cgi/i4004/1221375066/290-
からの話題で、一部だけ紹介のつもりだったけど、大長文になってしまいすみません
突っ込み、おかしい点のフォローなど、よろしく

728 ：
いやはやあっぱれ、あっぱれじゃ
楽しく読ませてもらいました

729 ：
インテルは２８６出した後でも「モトローラに追いつかなきゃ！」って頑張ってたんだな

730 ：
80286と同時期で68020だからね、そりゃ頑張るしかないだろ。

731 ：
今日学校にあったX68000とX68030？？の十数台
ちょっと覚えてないけど型番にXVと付いてるのと小型のが数台
整理するためにみんなで解体（破壊）して不燃ゴミの準備をしました
中にはちゃんと動くのもあってかわいそうだったけどひと思いに破壊
けっこう気持ちよかったけど、これ欲しい人がいたのかな？

732 ：
いただろうな…が、
不燃ごみはダメだろ、リサイクルしなきゃあかんで

733 ：
ゲームスクールかなんかかな？

734 ：
>>733
それに近い感じです
直前まで使われてたものもあったみたいですが先生の「古いものを使っていると
脳が進化しない」ということで片付けることになりました

735 ：
ヤフオクに出せば全部で10万以上にはなったと思うよ
コツコツ少しずつ出せばそれ以上になったはず

736 ：
メモリ増設されたX68030(含compact)くらいじゃないと値段つかんだろ

737 ：
>>731
面白いネタだね
今度はTOWNSに挑戦だ

738 ：
今時ならX68もTOWNSも産廃だろ

739 ：
この板に来てそれを言うか、痴れ者め

740 ：
古いモノを使っていると進化しないのではなく、それは人間側の問題です。
コンピュータは良くも悪くも道具なので、使う側の人間性が問題になります。
古い設計のマシンの中には貴重な発想や遺産があるのです。身近にあると気づかないものですが。
本田のエンジンや黒澤、北野映画でも同じですが、その価値を評価するのは例外なく海外の人なのです。
日本のエンジン模型を作っている企業が海外メーカであったりします。
そうした伝統を捨てるのは、日本の場合、不思議な事に当事者なのです。
日本では殆ど例外なく家も農家も会社も三代以上続かない事が多いです。

741 ：
>日本では殆ど例外なく家も農家も会社も三代以上続かない事が多いです
政治家は？

742 ：
>日本では殆ど例外なく家も農家も会社も三代以上続かない事が多いです。
日本の農家って代々続いてるのが多いんじゃないの? 異業種からの転職の方が珍しいと思うが。

743 ：
>本田のエンジンや黒澤、北野映画でも同じですが、その価値を評価するのは例外なく海外の人なのです。
その男、凶暴につき - Wikipedia
http://ja.wikipedia.org/wiki/%E3%81%9D%E3%81%AE%E7%94%B7%E3%80%81%E5%87%B6%E6%9A%B4%E3%81%AB%E3%81%A4%E3%81%8D
> 評価
> たけしの処女監督作品は、『キネマ旬報』ではほぼ賛辞一色であったという。山根貞男は、
> 当時数多く登場していた有名人の新人監督の一人と見くびっていたが、徹底してハードな
> 暴力描写に度肝を抜かれたとし、突出した新人監督だと才能を評価した。監督予定だった
> 深作欣二も「面白かった」と感想を述べ、松本人志は北野武作品で一番好きな作品として
> いる。
> 『ソナチネ』や『HANA-BI』が国際的に高く評価されて以降は、「（特にバイオレンスにおける）
> 北野映画の原点」として重要視されている。

744 ：
>本田のエンジンや黒澤、北野映画でも同じですが、その価値を評価するのは例外なく海外の人なのです。
本田のエンジンって、スーパーカブの超低燃費エンジンのことか

745 ：
>>744
CVCC とかでしょ

746 ：
> 古い設計のマシンの中には貴重な発想や遺産があるのです。身近にあると気づかないものですが。
新しいものは、べつに過去のものを無視して作られているわけではないので
過去にだけこだわり続けるのは、古いものが今のものにどのように活かされて
いるかを見失い、活かせないものにこだわり続けているだけように見える。
新しいものの中にある取捨選択を見極めて、その理由を考えるほうが重要。
いまどきの 86 なんて、メインメモリに展開される命令コードが同じでも
いいだけで、他の共通点はほとんど見当たらないけどね（笑）
逆に、そこが86の重要な点なんだし、68の Coldfireにしても同様のことが
言えるのも、過去ばかり見ていると気づけないんじゃないの?

747 ：
>>746
Coldfireは68Kとの命令互換はそれほど重視してないのでx86とは考え方が違う

748 ：
>>747
元々 68 系はソースレベルの互換性でよしとしてたからなぁ。

749 ：
>>748
68Kならニモニックが同じならマシンコードも同じだよ。

750 ：
幾つか消えた命令がへちまでどうのこうの

751 ：
>>747
だから、今の製品で取捨選択された機能を見極めるのが重要だと言っているんだけど？？
86系の互換性なんてあってないようなものだし、Coldfireだって互換性という
意味では同様にあってないようなものだと言っているんだよ。
命令互換性が重要視されているのが同様だと言っているんではない。
誤解を与えたのなら、スマソ。
そういえば、今どきだと 233MHz 超えの 68000 が製品化されているんだ、ふーん。
しかもアドレスバスが 31or32bit、3段の命令キューと2段のデコーダ、ほえ。

752 ：
>86系の互換性なんてあってないようなものだし、
インテルがどれだけ互換性重視してるかわからん奴は平気でこういうこと言う

753 ：
>今どきだと 233MHz 超えの 68000 が製品化されているんだ、ふーん。
>しかもアドレスバスが 31or32bit、3段の命令キューと2段のデコーダ、ほえ。
ColdFireかなんかを68Kと勘違いしてるのかな??

754 ：
>>751
>だから、今の製品で取捨選択された機能を見極めるのが重要だと言っているんだけど？？
86系で捨てられた機能ってどういうののこと言ってる？

755 ：
>>751
> 233MHz 超えの 68000 が製品化されている
そんなもんは無い。需要も無い。

756 ：
>>749
マシンコードが同じで、動きが違うだろ。
68000 では普通の命令だった move sr,... を 68010 以降は特権命令にするとか平気でやるから。

757 ：
>>752,754
インテルは事あるごとにコンパイラへの最適化情報やコンパイラを流しているのをご存知ない？
バイナリの後方互換性が非常にしっかりしているのは私も知っている。
でも、それ以外の互換性って何があるの？教えて欲しいくらいです。

758 ：
>>753,755
C68000

759 ：
>インテルは事あるごとにコンパイラへの最適化情報やコンパイラを流しているのをご存知ない？
過去の製品との互換性とどんな関係がある話なんだか意味わからん

760 ：
>C68000
どれだけ動作するかも分からんIPコア例に挙げて何言いたいんだかわけわからん

761 ：
>>760
スピード最適化したサンプルで238MHzの結果があるって書いてあるんですけど。

762 ：
>>761
それと、「233MHz 超えの 68000 が製品化されてる」ってのと、何か関係ある話ですか?

763 ：
http://morphyone.info/wiki/index.php?%A4%C8%A4%E8%A4%BE%A4%A6%B8%EC%CF%BF%A1%D6%A4%C8%A4%E8%A4%B4%A4%ED%A1%D7#content_1_20
> 「来年は絶対、６８Ｋ互換300MHzのフリーＣＰＵを作るぜ！」という誓いを立てた
これちょっと思い出したｗ

764 ：
>>761
開発ベースの話と製品ベースのそれと区別が付かない人?

765 ：
>>762
わりー、正確に書けば
「233MHz超えで動作確認された68000のIPが製品化されている」
だね

766 ：
モトローラのデザインとは別に実装されたIPコアなんて互換性とかサッパリわからん代物なわけだが
それを「68000のIP」と呼んでいいものかな?

767 ：
>>757
> でも、それ以外の互換性って何があるの？教えて欲しいくらいです。
それ以外の互換性って何が必要なの？教えて欲しいくらいです。

768 ：
> 86系で捨てられた機能ってどういうののこと言ってる？
↓
> インテルは事あるごとにコンパイラへの最適化情報やコンパイラを流しているのをご存知ない？
わけがわからん

769 ：
カオス具合が煮詰まってきたぞ
誰か図入りでまとめてくれ

770 ：
　特権　　　　　　　ヽ　丶　　＼
　　命令　　　＼　ヽ　　ヽ　　　　　ヽ
／　　/　　　　ヽ　　　 ＼　ヽ　　　ヽ
　/　　　| 　ヽ ＼　　　　　＼　　ヽ　　ゝ　　　　　　　　　　　(238MHz)
ﾉ　丿　　　　　 　＼　　省 　＼　　　ヾ
　ﾉ　　| 　　| 　丶　 ＼　　　　　＼　　　　　　　　　(233MHz)
　　　/　　　　　　 　　 ＼　　　　　＼／| 　　　　　　　　　　　　　　　(233MHz)
　ﾉ　　　| 　　|　　　　　　＼　　略　　　 | 　　　　　　　　↑
　　 　　／＼　　　　　　　　＼　　　　　 | 　　　　　　　　（　　↑
　　　／　　　＼　　　　　　 ／　　　　　 | 　　　　　　　　 ）　 （
　 ／　　　　　　＼　　　　　￣￣￣￣￣　　　　　　　　 （　　 ）
／＿　　　　　　　 ＼　　　　　　　　　　　　　　　　　　　　）　（　　　　　　　　製品化
￣　 | 　　の　コ|￣　　　　　 　　 ノ⌒￣⌒γ⌒￣⌒ゝ　　　　　　　　　　　/　/
　　　| 　　最　ン|　　　　　　 　　ノ　　　　　C68000 .　　ゝ　　　　　　　　　 /　/
　　　| 　　適　パ|　　　　　　 　丿　　　　　　　　　　　　　　ゞ　　　　　　＿/　∠
　　　| 　　化　イ|　　　　　　 丿／|／|／|／|＼|＼|＼|＼|＼ゝ　　　　 .＼　 ／
　　　| 　　情　ラ|　　　　　　　　　　　　　　 │　　　　　　　　　　　　　　　 V
――| 　　報　ヘ|――――――――――┼―――――――――――――――――
　　 / 　　ヽ　　巛巛巛巛巛巛巛巛 人巛巛巛巛巛巛巛巛巛巛2段のデコーダ、ほえ。

771 ：
>>770
わかりやすい図を thanks!

772 ：
今のCOREって直(エミュじゃなくて)で8086の16bit命令が動くの?

773 ：
そりゃ動くよ

774 ：
[ソフトウェア]
　↓
[x86/x64インターフェース(ハード上層)]
[真のコア＼(^o^)／86も64もシラネ(ハード下層)]

775 ：
6809→68Kのコードコンバータの説明書の英文眺めてたら、
３つに分割されるという命令があって、なにこの低機能って思った。

776 ：
>>775
68k→6809なら3つじゃ効かんよ

777 ：
当たり前田のクラッカー
問題は→x86でどうかって話じゃないか？
80はソース互換だろうけど。

778 ：
>>777
8080のXTHLは8086だと何命令になると思う?

779 ：
>80はソース互換だろうけど。
何だバカか。

780 ：
>>41は嘘？

781 ：
>>780
「アセンブラのソースコンバーター(8080→8086)なんかもIntelは配布してた」ってことは
そのままではソース互換がなかったって意味だけど?

782 ：
>>41
>8086だって5MHzなら6MHzの選別Z80の方がマシ。という企業
>ユーザも多かったね。
命令実行サイクル数がけっこう違うのでこれは出鱈目

783 ：
コンバーターがあるならソース互換だろ
命令互換ならともかく

784 ：
>コンバーターがあるならソース互換だろ
謎理論乙ｗ
それじゃ>>775の言う6809→68kもソース互換だなｗｗ

785 ：
ソース互換　ソース非互換も間違いない
共通命令はソース互換
新規命令は非互換って意味をいいたいんじゃないかな？
ふつうのPentiumにMMXがでたようなレベルの話を想像すればいい

786 ：
>>785
ん? それじゃあ8080のPUSH PSW/POP PSWに相当する命令が8086にあるっていうの?

787 ：
アセンブラなんかやめてFORTRAN77にしようぜ

788 ：
>>785
>共通命令はソース互換
NOP命令があるプロセッサはソース互換てことか。

789 ：
>>785
>新規命令は非互換って意味をいいたいんじゃないかな？
8080→8086で廃止された命令はどういうことになんの?

790 ：
8080→8086コンバートはトリッキーなことしていなければ普通に通って動いてしまいそう。
8086の設計は8080とのソースレベル互換ありきだったかもしれん。
実際には手を加えないと動かない事が多かったってどっかで聞いたけど。
>>789
廃止された命令については複数の命令で置き換えるか、ハードに近すぎる命令は実行不可能につき無視じゃね。

791 ：
>>786
PUSH PSWは
LAHF
XCHG AH,AL
PUSH AX
POP PSWは
POP AX
XCHG AH,AL
SAHF
ちょい重いけどこんな感じかな？
もちろんAHは使われていない前提で。　

792 ：
オブジェクトレベルの互換性が無いものをソースレベルでコンバートした場合
特定のイミディエート値や命令コードを直で書き直したり
テーブルジャンプの代わりモジュールを4バイト、8バイト、16バイトとかに区切って
ソース値を4倍、8倍、16倍してからモジュール郡の先頭アドレスを加算して飛ぶとか
ちょっと変則的なテクニックを使ったプログラムだと
当然のごとく命令の値やコードサイズが同一でないために破綻必至となる。
そのテの事をしていない行儀のいいソースを変換するんなら8080→68000コンバータだって
作ろうと思えば作れるがオブジェクトはオリジナルの数倍から十数倍に巨大化し
実行効率は劣悪になる。

793 ：
>>791
>PUSH PSWは
>LAHF
>XCHG AH,AL
>PUSH AX
それじゃ実行後にALの内容が変わっちゃうじゃないの。

794 ：
劣悪でもなんでもスレ的には条件同じにして比較できればよくね？
あと、スレタイはx86なんだしなにがなんでも8086引っ張り出す必要はなくて、
その後の改善を語るのも面白いと思うけどな。

795 ：
>>793
MOV AL,AH忘れてた。
5ステップにもなるともっと速い方法ありそうだな。

796 ：
>>775
68Kに移行した頃、それ考えてた時期があった。ほとんどの命令は68Kにあるし、
フラグの動きも同じだろうから行けるんでね？って高をくくっていたんだけど・・・
6809のDレジスタがネックでね orz
Aが上位8bit、Bが下位8bit、Dって言われたらAとBを合体させるっていう機構
68Kには無くて、それを68k側で展開するとえらく馬鹿らしいことになるんで、
結局素直に書き直したような覚えがあるよ。

797 ：
Dなんて大して使わんのにそんなとこで効率を評価とかｗ

798 ：
6809と68000のフラグ変化の互換性は実はあまり良好とは言えない。
一番マズいのは6809のLD命令ではキャリーが変化しないのに対して
68000のMOVEではいつもクリアされちゃうこと。
これをまともに再現しようとするとLD命令のたび常に数命令以上命令余計に展開されると言う事態が起きる。
結局6809→68000のコンバートは8080→8086のコンバートほど実用性無かったはず。

799 ：
余談だけど68000のプログラムと言えばGCCがこなれてきたら結局そればかり使っていたなあ。
これは下手なアセンブラ使いより速いコードを吐く優れものだった。
ICEを使う開発環境の関係でMCC68Kというのも使ったことがあったけど
GCCの半分ぐらいしかスピードしか出なかった。
基盤屋さんにそのCで開発をしていると言ったら処理速度が心配になったのか
10Ｍｈｚの基盤を16Mhzにアップグレードしてくれた。

800 ：
>>797
まぁどういうプログラムを書いていたかにもよるけど、ウチじゃあまり馬鹿にできなかったよ。
Dって出てきたところで自動コンバートを諦めて人間がその部分の変換をやるとか、ロクでも
ない話になりそうだったんで、各々Cかアセンブラで書き直してた。
>>798
なるほどね。コードコンバーターの件は深く検討する前にDレジスタの扱いで頓挫したから、
多分そこまでちゃんと見てなかった。LD/ST/TFRはMOVEに書き換えるとして、TFRでCCが
変化しないように退避・復帰が必要だな程度の認識だったような。

801 ：
>>798
>一番マズいのは6809のLD命令ではキャリーが変化しないのに対して
>68000のMOVEではいつもクリアされちゃうこと。
68000のキャリーは実質Xフラグだろ。

802 ：
>>797
追加クロック極小で処理能力が倍なんだから絶対使うべきじゃないか？
しかしなんでAX相当のレジスタがないの？
16bitなのに。

803 ：
>>802
>追加クロック極小で処理能力が倍なんだから絶対使うべきじゃないか？
ADDD/SUBD/CMPDなんてそんな張り切って使う機会そんなないだろ。
ADDDならインデクスレジスタへのLEA命令やABXのほうが便利だったりするし、
CMP命令はインデクスレジスタに対しても使えるし。
Dレジスタの価値は、MULやSEXの結果を格納する16bitレジスタというのが
主だと思う。

804 ：
>SEXの結果
って、イヤらしく聞こえるな

805 ：
16bitアキュムレータという割にはできることが限定的だった＞Dレジ

806 ：
別に限定されてはいないだろ。
普通に8bit命令使って処理すればいいだけなんだから。

807 ：
16bitのローテートなんて8bit命令組み合わせても面倒なんだけど

808 ：
>>806
>普通に8bit命令使って処理すればいいだけなんだから。
じゃあDレジなんていらんね。

809 ：
フラグ使う命令があんだろ。
っていうかここ8bitスレじゃないよな？

810 ：
>>808
インデックスレジスタで同じことできるん？

811 ：
インデックスレジスタで
→ できない
16bitアキュムレータで
→ できない
結論: Dレジは不要。8ビットアキュムレータがあれば良い。

812 ：
つまりAレジだけでよくてBレジは要らないと？

813 ：
8ビットアキュムレータはいくつあってもいいだろ

814 ：
Cでもなんでもペアがないぼっちレジスタ勝手に作ってれば？
16bitの話はどうした。

815 ：
今読み返してみると、実際、68kの設計がここまで酷いとは。
当時の雑誌のマンセー記事でボクたち夢見てたんだね。

816 ：
社内会議でよくいるよね
会議中は自分の意見は持ってないのに全知の重鎮のふりして黙って聞いてるかっこするけど
最後に締めのつもりかおいしそうなポイントを繋いだ総括的なこと一言言ってスベッちゃう人。

817 ：
長年中小勤めなためか見たことないです
815みたいなのがよくいるとですか

818 ：
>社内会議でよくいるよね
>>816がそういうところにお勤めしてるというだけの話じゃないの

819 ：
いきなりなに言ってるんだ？

820 ：
68kマンセー記事書いてた人なんでしょう。

821 ：
68K使ったパソコンはX68以外なんか有ったっけ?
SORDはパソコンと言っても完全ビジネス機だったし。
Z8Kや65816(ゲーム機は除く)でパソコンは?

822 ：
MacintoshとかAmigaとかAtari STとか

823 ：
65816はApple II GSとかAcorn Communicator (BBC Microの後継機)
とかに使われた。
ちなみにAcorn Communicatorの更に後継機のために新たに設計された
CPUが、今をときめくARMの元祖。

824 ：
★マインドコントロールの手法★
・沢山の人が偏った意見を一貫して支持する
　偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法
・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
　誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法

↑マスコミや、カルトのネット工作員がやっていること
TVなどが、偏った思想や考え方に染まっているフリや常識が通じないフリをする人間をよく出演させるのは、
カルトよりキチガイに見える人たちを作ることで批判の矛先をカルトから逸らすことが目的。
リアルでもネットでも、偽装左翼は自分たちの主張に理がないことをわかっているのでまともに議論をしようとしないのが特徴。

825 ：
メガドライブのおかげで安く買えるようになった68000を使って、
MSXの終焉で空席となった「テレビにつなげる安価なホームコンピュータ」
的なものが出ればよかったのにと妄想。TOWNSのMartyとコンセプトは
似ているけど、シリパラと一つでもいいからまともな拡張スロットは欲しい。

826 ：
なにそのAmiga500/CDTV

827 ：
ラズベリーパイでいいじゃん
68000でもx86でもないけど

828 ：
Arduinoでいいじゃん
68000でもx86でもないけど

829 ：
>>825
安価なコンピュータならジャンク品のノートパソコン1000円で売ってるだろ
LINUXでもいれろよ

830 ：
>>829
1000円で売ってるジャンク品のノートパソコンがテレビにつながるかな?

831 ：
>>830
テレビによってはアナログ D-Sub 持ってるやつもああったりするから、なんとも言えないな

832 ：
日本では過激な68kの原理主義が問題なのだろうと思う。
原理主義者に限って何も理解していない事は明らかだし多くの人がそれに騙された。
エンジニアでもなくコード書いたことも無い人物が原理主義を煽る技術カルト
というものは社会病理そのものといえる。

833 ：
>>825
68000 12.5MHz
スプライト 128枚、BG 3面
カラー 65536色中16色×16パレット
サウンド FM音源 8音、PCM 4音
こんな感じのスペックで定価128000円ぐらいだと最高だな。

834 ：
>>832
と、エンジニアでもなくコードを書いたことも無い人間が言ってみる

835 ：
>>830
ノートパソコンにわざわざtvつなぐメリットおしえろや

836 ：
>>835
>>829は>>825へのレスって理解してる？

837 ：
複数人で同時に同じ情報を大画面で閲覧できるのはリビングの主役たるテレビならではだろう。
大画面でのゲームプレイの迫力もノートパソコンの画面とは雲泥の差がある。

838 ：
>>833
ラズベリーパイがＯＰＥＮＧＬかなり高速で動くじゃないか
スプライトとかもうわすれてよくないか？

839 ：
>>838
メガドライブとかあの当時の話をしてるんだが。

840 ：
となると今このスレで求められてるのは、当時の制限っぷりをエミュレートする仮想フレームバッファか

841 ：
保護モードとか冷静に考えたら制限そのものでしかないんだよな。
なんで皆あんなもの賛美してたんだろ？

842 ：
えっ

843 ：
>>841
コード書けば馬鹿でも分る。

844 ：
世の中には馬鹿にも満たない奴もいることを理解すべき

845 ：
セーフティネットに頼るから皆ボケちゃったんだよ。

846 ：
80188採用の電卓(ポケコン)と68EC010(000かも)採用の電卓持っています
前者は既出、後者はまだ売ってる

847 ：
http://education.ti.com/en/us/products/calculators/graphing-calculators/voyage-200/

848 ：
>>845
セーフティネット無いところで早めに死んじゃってください (w

849 ：
命綱が無くても死なないからプロの技は拍手喝采なのです。

850 ：
ソフトウェア危機で素人にプログラム書かせる為の必要悪としての導入とすれば
わからんでもないけど、実際には大域変数バリバリなBASICなんかの方が、
感心するほどうまく素人は扱うんだよな。

851 ：
開発期間短縮には貢献したんだろうけど、それは人海戦術が使える大手の一人勝ちであって
少数精鋭の技術集団は儲からない仕組みを作った結果が、昨今の惨状ではないかと？

852 ：
どちらかというとソフトウエアの危機ではなくPCハードにも問題がある。
電源周りのアース線の扱いが漏洩電流を流すんで長時間使うと体の具合は悪くなる。
電気的絶縁が不完全だから作業者はハード的にも保護されてない。俺はそれでUSB端子で２回感電した。
バッテリー動作のノートやタブレット、ワイヤレス入力機器を使うべき。

853 ：
昔は10Base-2/5は同軸の黄色ケーブルだった。だけど同軸GNDが共通なので機器間が共通になるため
多数のネットワークだとものすごいリーク電流が流れる。同軸GNDと他が接触したときに火花が出る。
それが実験室に配線されてるもんだから、周囲に引火性ガスがあれば火災になる。
で、むかし実際に某大学などで事故起こった。
だから今の100BaseTツイストケーブルRJ-45は絶縁トランス(パルストランス)が入ってる。
PCのスイッチング電源の根本的な問題なのでアース線接地云々じゃ解決しない。今でも同じ。

854 ：
>>853
>昔は10Base-2/5は同軸の黄色ケーブルだった。
10BASE-2は違うよ

855 ：
>>853
>昔は10Base-2/5は同軸の黄色ケーブルだった。
>だから今の100BaseTツイストケーブルRJ-45は
10BASE-T知らない人かな?

856 ：
俗にイエローケーブルと呼ばれてたのは10BASE5のみで、しかも実際にケーブルが
黄色かった（黄色いケーブルが主流だった）のは普及初期のみだったが

857 ：
>>853
>だから今の100BaseTツイストケーブルRJ-45は
100メガビットイーサにそんなのないよ
http://ja.wikipedia.org/wiki/100%E3%83%A1%E3%82%AC%E3%83%93%E3%83%83%E3%83%88%E3%83%BB%E3%82%A4%E3%83%BC%E3%82%B5%E3%83%8D%E3%83%83%E3%83%88

858 ：
>>853
>だから今の100BaseTツイストケーブルRJ-45は絶縁トランス(パルストランス)が入ってる。
ケーブルとコネクタの区別も曖昧な人かな? パルストランスが入るのはジャックやボードの方だけど。

859 ：
なんで「10Base」は「てんべーす」って発音するのに
「100Base」は「ひゃくべーす」って呼ぶの？

860 ：
単純に「はんどれっどべーす」と「ひゃくべーす」とどっちが言い易いかってだけの話

861 ：
わんはんどれっどべーすって普通に言うだろ

862 ：
言わねーよ
いちまるまるベースだろ

863 ：
>いちまるまるベース
自衛隊に限ってはその通り

864 ：
自衛隊なら「ひとまるまる」だｗ

865 ：
外人だと「わんおーおー」とか言うのかな？

866 ：
（∪＾ω＾）わんわんお！

867 ：
誰がビューティフル・サンデーやねん

868 ：
田中星児＝ビューティフル・サンデー
ビューティフル・サンデー＝田中星児

869 ：
>>859
日本人だから。

870 ：
>>869
俺はおはよう720の方を良く覚えている。

871 ：
新聞のテレビ欄に「セブン」と書かれてて、「ウルトラセブンの再放送やってるのか」と思って観てみたら騙されたことも今となっては良い思い出です。

872 ：
ははんははん８時半

873 ：
8080/z80からのアップグレード目的なら8086は使いやすいよ。

874 ：
68K使うと友達を失くすからなぁ。

875 ：
お前正確歪んでて友達いなさそうだな

876 ：
日本でX68000、Mac、メガドライブ持ってた奴って本当に友達いたの？
ソフトの少ないマイナー機種選ぶ時点で交流少なさそう。

877 ：
>>876
Amiga、ATARI-ST、ATARI Jaguarを忘れてるぞ

878 ：
コピーソフトを回してくれるヤツだけが友達だと思ってないか？

879 ：
>>876
それを知らない時点でお前が友達いなかったということだ
俺の友達はX68持ち、メガドラ持ち、PCE持ち、幅広くいたぞ

880 ：
まあ2chは自分のことが出てしまうらしいから友達Nothingなやつが
こういう>>876　2chセリフ好むのは納得

881 ：
>>879
まじかよ!!! おまえすげーよ!!!

882 ：
ここはCPU（MPU)そのものの性能、アーキテクチャを比較する場なので
持ってたパソコンの自慢貶し合いをしてる昔の子供（今はジジイ）にはついて行けないと思う。

883 ：
金次第で好きなだけ魔改造出来るから金持ってる方の勝ちでいいよ
金の流れを掴んだほうが速い

884 ：
>>882
さすが68K使い。

885 ：
今のマカーは68K？なにそれ？なんだろうな。
あんなに86を馬鹿にしていたのに。

886 ：
>>876
まぁ、自分の人生を振り返って一番傷つくネタで巻き込もうとしたんだろうけど、
友達はそこそこ居たよ。
確かにね、どこぞの国民機ユーザーみたいなカジュアルな連中は少なくて、
どこかが確実に濃い面々だったことは否定しないけどw

887 ：
68kのスマートさには美を感じたけど、
寄らば大樹の木で8086しかいじらなかった。昔はPC-9801たったし。

888 ：
ビッグエンディアンなプロセッサのどこがいいのかわからんなー

889 ：
>>888
ダンプが読み易い

890 ：
正直、8086のライバルは6809であって
32bitアーキテクチャ然とした68000とは比較できないと思うんだ
ある意味、x64で汎用レジスタ増えてやっと68000に追いつけた感が

891 ：
ソフトを組む側から見ると32bitCPUだしね＞mc68000
率直で使いやすくて好きだけど
結局ごちゃごちゃしたx86系列が蔓延ってしまった

892 ：
Z80Aで挫折した俺でもMC68000のアセンブラなら数日で楽々プログラム書けるようになったもんな〜。

893 ：
>>890
> 正直、8086のライバルは6809であって
まあこれはいいとして
> ある意味、x64で汎用レジスタ増えてやっと68000に追いつけた感が
ないわ〜
386 辺りでほとんど追い付かれてるよ

894 ：
>>893
技術的には近くなったけど、汎用レジスタの不足と8bitからの拡張色は相変わらず
実際の使われ方をみてみると、WindowsMeが終了するまでDOSエクステンダを使って
16bitな世界と32bitな世界を行き来するのと同等という惨状だったわけで
32bitWindowsの時代になってフラットなメモリモデルを採用してマシにはなったけど
汎用レジスタ不足は解決せず、開発面でも実効性能でも足を引っ張り続けてたから
68000の快適なで素直な世界に近づけたかというと……
68000にゾッコンだけど、x64の設計をみるともうx86に対するような忌避感がわかない
x86の不満点はほぼ解決されたからね
逆に言えば、x64世代を迎えるまではx86は8bit世代からの拡張でしかなかったわけで

895 ：
>>894
> 実際の使われ方をみてみると、WindowsMeが終了するまでDOSエクステンダを使って
> 16bitな世界と32bitな世界を行き来するのと同等という惨状だったわけで
WindowsNT も知らない奴が語るなよ…
そもそもそれって CPU の問題じゃないし
> 汎用レジスタ不足は解決せず、開発面でも実効性能でも足を引っ張り続けてたから
汎用レジスタが少ないのは事実だけど、言うほど不便でもないよ
まあ、メモリー、HDD/SDD と同じで多いに超したことはないけど

896 ：
結論
OS/2が天下を取っていれば、幸せは10年早く訪れていた

897 ：
>>895
レジスタ増えたら、退避させる手間も増える。

898 ：
>>897
毎回全レジスタ退避してるのか？ w
レジスタ増えて困るのは
命令中のレジスタ指定フィールドのビット数が増える
⇒ 命令長が長くなる
ってことだろ

899 ：
80386は直交性が×

900 ：
68kなぁ、アレでまともな、せめて286レベルの仮想メモリができてりゃなぁ。プロセス保護がちゃんとしてたらなぁ。

901 ：
>>900
初っ端から68020レベルだったらまさに神だったのにね！

902 ：
>>900
一応 MC68451 MMU はあったので、MC68010 と合わせれば仮想記憶も仮想マシンも実現できたんだよね
ただ２チップ構成はコストもかかるし、設計上の問題もあって性能がちょっとよくなかったので流行らなかったな

903 ：
68020もなぁ、遅すぎつっーか、タイミング逃したっーか、だったからねー。

904 ：
68020はRISCが大頭するまではワークステーション御用達だったわけで（だよね？）
値段が高くてPCに採用されなかったのが残念
スピード・値段・普及を脇にのけると
68040辺りがスッキリ使いやすい完成形なのかな？
68060？ColdFire？
これらの命令セットが今のCPUのガワとして普及してればなぁ

905 ：
x86系が命令セットが386で、チップとしては486DXで『完成形』と言えるレベルになった、と言える。
一方68kは、68000の完成度が、今からしてみれば未完成だけど、当時としては高かったからそこで停滞しちゃって268がでても「まだまだ68k優位」と驕ってた。
コンセプトと基本設計は良かったのに詰めが甘かったよねぇ。

906 ：
SPARC,MIPSなどのRISCチップが台頭してきた時に
CISCの代表格だったx86はそれに対抗して命令セットは変えずに
CRISCと呼ばれる程のアーキテクチャの変更でRISC vs CISCの
戦いに勝ち残ったが68kはそのような対応を取らずに680x→68k
の時のように過去に縛られずにRISC風味のPowerPCへと開発を
移行させて事実上68kを放棄してしまったのだからx86と68kに
決定的な差が生じたのは仕方ないと思う。

907 ：
x64はAMD主導だからIntelx86系列の完全敗北だよね
別に68系列ではないけど、汎用レジスタ多くしてレジスタ間の機能差を少なくした時点で
思想面でやっと68000に屈服することでおいつけたとしか言いようがない

908 ：
>>890 >>893
確かに8086/88は良くできた8bit CPUではあるけどトランジスタ数29,000個、
対する6809は9,000個だそうだ。同じ土俵に乗せるのはチト酷ではあるな。
それと無理やり強弁するなら、x64でようやく追いついたのはレジスタ数なんか
じゃなく、PC相対アドレッシングモードをようやく持ったという点じゃね？
まぁいまさらアセンブラでプログラムなんぞ組まんから、バイナリパッチ宛てる時
くらいしか意識して使うことは無いけどさ。

909 ：
IBMのPowerPCにのっからず680x0アーキテクチャを磨いていればなぁ…
PowerPCも一時期Macやゲーム機に使われたけど結局表舞台から消えたよね

910 ：
一から作り直すより、多少のパフォーマンス犠牲にしてもソフト資産使えた方が売れるし。

911 ：
>>909
当時は RISC に行くしかないって感じだったからねぇ
インテル i960 とかモトローラ MC88000 とかもやってたんだよね
まあなんだかんだ言っても、結局は半導体専門のインテルとカーラジオ屋のモトローラの違いやね
インテルはチップが売れてなんぼの会社だからチップの使いやすさや開発ツールの充実にも相当ソリソース割いてる

912 ：
68000はメガドラのお陰で生産量が一気に増加して単価下がって普及したけど
68020や30は高いままだったので普及しなかったな。
シェア握るために赤字覚悟で020や030を格安で放出すればよかったのに。

913 ：
020の在庫処分のために作ったマシンがMacintosh LC（初代）だよ

914 ：
http://cpplover.blogspot.jp/2016/01/linus-torvaldsmicrosoftintelamd.html
> Windowsの業界では、そんなことは望みようがなかった。Microsoftが、「おう、ジャンプしてみろよ」と言ったならば、IntelとAMDはどちらも「どれだけ高く飛べばいいのでしょうか？」と言ったものだ。結果として、x86はどのRISCよりも柔軟だった。

915 ：
また大袈裟な事言いやがって、どこのテクニカルライターだよ
ってリーナス御大の発言かよw

916 ：
理想を追求しても、現実にそぐわなければ、無駄に終わる。

917 ：
モトローラの罪は理想を追求することを放棄したことだね。

918 ：
この世界にはデファクトスタンダードっつーものがあるからへタに理想を追うより多少不完全でも早く出した方が勝つことが多い
そもそも作り手の理想と使う方の理想が一緒とは限らんし

919 ：
PCの搭載メモリが1MB程度、CPU速度もぼちぼち、HDDやI/F速度も低速な時代だと、
64KBのセグメントモデルが致命的
というケースはあまり無く
64KBのセグメントモデルでも意外になんとかなる、むしろメモリ消費や速度的なメリットもある、
というケースの方が多かった。

920 ：
68kの命令セットで多くの命令がオペランドサイズの指定フィールドを2bit持っていて、
00-BYTE 01-WORD 10-LONG とエンコードするんだが、64bit時代になって
11-LONG LONG とすればいいか…というと多くの命令が11は別の命令に解釈する
よう使い尽されているんだよな。
16bitの空間がありながら意外にオペコードのエンコーディングはギチギチに詰まって
いて、デコーダは複雑化していた。
もしも64bit時代まで68kが生き残ったとしたら…64bitMPUは、またアセンブラソース
互換、バイナリ非互換っていうお得意のパターンだったのだろうか

921 ：
1980年代に32Bit設計されていたのでもたいしたものなのに
64BitCPUへの拡張を見込んでの設計はいくらなんでも無理だろうw
しかも単純にオペランドサイズの拡張だけではなく新興のRISCチップ勢と
戦うためにレジスタ数の拡張も余儀なくされるだろうからバイナリー互換の
維持は無理だな。

922 ：
>>921
下手に64 bit 化してたら、コスト上がりすぎて即死だったと思う。
バイナリ互換はあまり意味無い。
メモリーやハードディスク容量の増加速度半端無いから、定期的に処理の見直し必要になる。

923 ：
64bit拡張にあたって一番デカイのはMOVE命令で、src/dstともに6bitのEAフィールドを
必要とするので、68kで残された0xAxxxか0xFxxxを丸々MOVE.LL(64bitのMOVE)に割り
当てざるをえない。
しかし、これは各所で問題を起こしまくるはずなので多分無理…ということで、現実的な
解としては0x4xxxにある未使用のbitパターンを「プリフィックス」として使用し、オペランド
サイズや、追加されたレジスタを指定する際のレジスタ番号の一部等々を格納しちゃえば
いい…となるかもしれない
…って、それって何てREX…まんまx64だなw

924 ：
68kのOPコード0xFxxxは浮動小数点命令用じゃなかったけ？

925 ：
ああ、そうだった、64bit化なんて言うんなら68000だけじゃなく020〜060とも互換が無いと
マズいな。
0xFxxx(いわゆるFライン命令)は020以降コプロセッサ命令群が占めることになったので、
その時点でプロセッサが未使用と言えるのは0xAxxx(Aライン)だけか。

926 ：
たまにPowerPCって出てくるが、PowerアーキティクチュアとPowerPCシリーズ名の混同が見られるな。
ちなみにウチはZ-1GR(256KBytesRAM)とTi-92が転がってる。

927 ：
>>926
> たまにPowerPCって出てくるが、PowerアーキティクチュアとPowerPCシリーズ名の混同が見られるな。
お前だけだろ

928 ：
　 ﾉ
　('A`)
　(　(7
　<　ヽ

929 ：
68000系を放棄したモトローラって何考えてたんだろう・・・

930 ：
x86を倒したくてRISCに行った
けどペンティアムがフルボッコ

931 ：
>>929
AIM連合に再興の夢を見てしまったんだろうな。
ただの負け犬連合だったのに過ぎなかったのに。

932 ：
ビッグエンディアンは糞だ

933 ：
goto >>10

934 ：
何でビッグエンディアンなんて不自然なもの出来たんだろうな。
レジスタの下位バイトが低アドレスに入るのが凄く自然なのに。

935 ：
人間中心主義とかなんかそういうバカっぽい思想のせい。
機械語で人間中心もクソもねーよバーカ、っていう単純な話が、CISC時代には通用しなかった。
RISCの時代になって「ヒトの都合なんか知らねーよ、低レベル処理以外で機械語なんか直接書く奴馬鹿だろ」って時代になってようやく
「あれって馬鹿っぽかったよなー」「主張してる連中、頭わいてると思ってたわー」って言えるようになった

936 ：
>>934
16ビットレジスタにメモリから16ビット値をロードするときは16ビット転送命令を使う、
という当たり前のことをやってれば、エンディアンなんてどっちでも同じ。
多バイト長の計算をするときにはリトルの方が分かりやすい。
'A'、'B'の２文字をパックしてワード値に変換するときなどは、
リトルの0x4241よりビッグの0x4142形式の方が分かりやすい気がする。

937 ：
マニュアル：RGBA32bitカラー
*(unsigned int*)p = r<<24 | g<<16 | b<<8 | 0xff ;
…あれ？

938 ：
>>934
ビッグエンディアンのほうがバイナリダンプ読みやすいじゃん。

939 ：
読みやすいだけでプログラム書くのは混乱するとまでは言わないが、いちいち意識しないとダメなシーンが多かった。
ぶっちゃけかったりー。

940 ：
混乱しているのはいつものことでしょ
「エンディアンガー」って言い訳できてむしろありがたいだろ

941 ：
>>938
いえ、別に…

942 ：
？かいすやみ読

943 ：
バイナリダンプと日本語の区別つかない奴がいるのか。

944 ：
01 00　これ読みやすいか？16進の100hと思うだろうが実は1なんだぜ。

945 ：
処理するのはプロセッサーでプログラム書くのは人間出し。
人間が処理する訳じゃないから、人間が読みやすいより、人間が書きやすいほうが重要だろ。

946 ：
>>939
> いちいち意識しないとダメなシーンが多かった。
ダメ設計乙
エンディアン意識する必要があるのは外部（ストレージ含む）とのやり取り
そう言う処理があちこちにばらまかれてる時点で低脳

947 ：
アセンブラだとIOデバイス叩くとかするからね。
机上の知識だけじゃ何も作れないよ。
実務経験ない素人はこれだから。

948 ：
CPUが68Kでメモリマップドの16ビットI/Oがリトルエンディアンとか普通は無いんじゃね？ｗ

949 ：
プロセッサがビッグエンディアンでデバイスがリトルエンディアンは、普通に当たり前にあったよ。
パソコンのアプリ作るだけの簡単なお仕事なら違うだろうけど。
「この回路、実績あるから」って一言で（設計期間短縮とかもあるんだろうけど）回路流用とかされると・・・

950 ：
奇数アドレスがD0-7とかもうね、Rよばか野郎、たよね。

951 ：
全く根拠の無い説なんだけど
68Kが、インテルと比べて高速化出来なかったのは
ビッグエンディアンを採用した所為だと思っている。
ビッグエンディアンなんて、人間への見た目重視の
仕様だからな。

952 ：
>>944
＞16進の100hと思うだろうが
思いません。

953 ：
>>949
> プロセッサがビッグエンディアンでデバイスがリトルエンディアンは、普通に当たり前にあったよ。
パソコンじゃなくても、設計期間短縮とかで既存の回路をそのまま流用するとか特別な理由がないかぎり、
普通はそんな設計にはしないと思うよ、わざわざそうする理由が無いもの。

954 ：
あとは今みたいにFPGAで手軽に回路組めなかったとか、カネや時間の制約が多かったとかあるな。
バブル弾ける直前ぐらいまでは富士通、松下、日電から仕事受けてだけど、どこも短納期ばっかりだったし仕様変更多かったし。
試作上がったあとでプロセッサー替えろとか言われてケツ変わらないとかもあったしなー。
改めて思い出すとむちゃくちゃな時代だったな。

955 ：
>ビッグエンディアンなんて、人間への見た目重視の
>仕様だからな。
メモリダンプの仕様をアドレスの大きいものから小さいものへの順にすればいいだけ。
一般の数字の表記は大きい桁から小さい桁の順が普通であり、メモリダンプもそれに倣うのが正しい。大きい桁の値が大きいアドレスに格納されるリトルエンディアンは仕様として正しい。

956 ：
ビッグエンディアンの利点はメモリダンプだけってよく判る。
他に利点なし。

957 ：
リトルエンディアンは最初8bitCPUのZ-80のLD HL,xxxx命令
で見た時には面食らったものだったけど、実際に自分で
多倍長コード(2Byte以上)を組んでみてその合理性に納得したので
x86でも自然だったなあ。
ビッグエンディアンのDumpの見易さもx86で気の利いたDebbugerなら
Byteだけでは無くWordやDword表示（場合によってはfloatやdoubleも可)を
選択出来たから絶対的なアドバンテージでは無かった。
逆にビッグエンディアンでCのunion宣言やキャスト宣言はどーするんだろうと
当時疑問に思ったものだ。

958 ：
ネットワークバイトオーダーはビッグエンディアンであり、最上位ビットから転送するのがスタンダードであるが
リトルエンディアン信奉者は8bitマイコンの世界から出てこられず全てを8bitの積み重ねでしか理解できない
だからx86のような汚らしい拡張を有り難がり続ける気違いばかりなのだ

959 ：
>>956
> ビッグエンディアンの利点はメモリダンプだけ
それはそうなんだが、昔は見る機会が多かったし、デバッガどころか箱でダンプが届くとかもあったからビッグエンディアンでないとやってられなかったんよ

960 ：
>>958
> 最上位ビットから転送するのがスタンダードであるが
話はずれるが、たいていのシリアル通信は最下位ビットの方が先に転送する

961 ：
>>936
char2文字処理はDOS時代にJIS漢字コード⇔Shift JISで多用したな。
でもアライメント制限の無いx86はそのままWordをStore出来たけど
68kはByte単位に戻してStoreしなければならなかったのでWordにする
メリットは無い。

962 ：
68kのアセンブラって、btstは0がLSBでbftstは0がMSBって設計者はシャブでもやってたのかと思う。

963 ：
>>961
突っ込まれる前に。
x86はWordでStoreする前に上位下位をXCHGする必要があるのを忘れていた。

964 ：
ネットワークバイトオーダーがビッグエンディアンなのは「目の前にあるマシンのアーキテクチャがビッグエンディアンだったから、という程度の理由でしかない」で技術的な優劣は関係なかったんだよなぁ。

965 ：
結局ビッグエンディアンのメリットってダンプの読みやすさだけか。

966 ：
ビッグエンディアンのメリットを書いているのを見ると
可読性以外だと形変換で大きな型(例:long)を小さい型(short)の
範囲に丸める（圧縮）場合を例示しているのが多いが
RZ丸め(Round Zero；切捨て）しか想定されておらず一般的な
RN丸め(Round Nearest：最近偶数丸め）やRP,RM丸め(有向丸め)
だと意味が無い特殊ケースなんだよな。
まあリトルエンディアンのアドレスがどの型でも確実に下位の
同一データを指し示しているのに対抗するための反例のようだが
もう少しまともな実例を示して欲しい。

967 ：
本当にビッグエンディアンの技術面での優位性の主張って無いみたいだな。
自分の経験で多倍長整数処理の中で比較処理だけは優位になるのになぁ。

968 ：
ロングワードをワードｘ2に改竄する時インデックスを付加する必要がなくなる分１ワード稼げてよかったよ

969 ：
ビッグエンディアンの利点で挙げられている>>966の数値丸めの例や
>>968の言うインデックス不要という例が判らない。
もう少し具体例を出して貰わないと意味不明だ。

970 ：
仮にビッグエンディアンのx86、リトルエンディアンの68Kとか想定してみても、
それで性能が変わるとは全く思えないわけで…どっちでもいいんじゃね？

971 ：
8086がbig endianなら普及に失敗したけどね。

972 ：
>>971
> 8086がbig endianなら普及に失敗したけどね。
より正確には8080、Z80と同じエンディアンじゃなかったら…だな。

973 ：
>>970
それゆえに不毛な宗教論争と言われる所以で。
ただその内容が論理vs感性で全くかみ合ってないところが…
>>969
整数値で考えるならばlong⇒shortの丸めなんてC言語風に表現すれば
>>16に過ぎないのだがこの整数値が固定小数点数として使われているならば
多少はその目的を納得することができるのかもしれない。
ちなみにIBMは伝統的なビッグエンディアンを採用するメーカーだが
System360あたりで採用されてた浮動小数点は倍精度(64bit:符号1,指数7,仮数56bit)の内
上位4byteを取れば単精度(32bit:符号1,指数7,仮数24bit)へのRZ丸め型変換になる。
まあIEEE754を使う68kやx86では意味の無い技法だが。

974 ：
>>972
そこはPowerPCみたいにバイエンディアンで。
ただ最新Chipはビッグのみ見たいだけど。
そういえばIntelのItaniumは共同開発のHPとの関係で
バイエンディアンだったそうな。

975 ：
そもそもエンデアンを切り替えられるプロセッサーがある時代に何を言ってるんだよ…

976 ：
無駄にトランジスタ使いやがって。

977 ：
もしIBMがDATA形式の互換を目的にIBM PCのCPU選択をビッグエンディアンCPU
にしていたら今の状況は大きく異なっていただろうな。
IBM PC以前のIBM 5100はどっちを採用していたのだろうか？

978 ：
ダンプリスト見やすいってのがよくわからん

979 ：
ビッグエンディアンだけになったらアップルに見捨てられたよなPowerPC。

980 ：
アップルってほんと最低だよな。

981 ：
SonyとAppleは、自分達の権益を守るのに
余念が無いからな。

982 ：2016/02/10
68kがリトルエンディアンだったとしても奇数番地へのワードアクセスで例外起こすアレがジャマになると思うんだよな。
個人的には68kがリトルエンディアンだったら、68kへの評価は上がるな。

x68000　ｖｓ　Amiga
べーしっ君！！
バボさんについて語るスレ
昔のログイソを語ろう Part2
昔のＰＣを売ってるお店（中古可）
御三家の筆頭はPC-8801
ここだけ永久に1995年なスレ【Win95 OSR 5】
【IDなし】MSXスレッド Part 46【安全】
486DXを語るスレ
Ｎ８８−ＢＡＳＩＣ入門
--------------------
4号機の思い出を語るパート22
宇野は盛りすぎて危うく優勝するところだったｗｗ　79盛り目
金ネ申同人ヲチスレ20
【福岡】「うるさい」暴走族への苦情、外出自粛で増加　一斉検問…タイヤ「ハの字」中古の高級セダンに整備命令 [ばーど★]
【老後】年金制度はなくらない「加入しなかった人」の悲劇 …iDecoにも入れない ★3
全然かみあわないのに話が進むスレ Part171
なぜガンダムデカールはすぐに補充されないのか
アナログレコード好きな人のスレ２８
Windows 7 ｱｸﾃｨﾍﾞｰｼｮﾝ 総合ｽﾚｯﾄﾞ Part.29
オーロラ観察スレ
【闘球】ラグビー総合実況スレ10.19 Vol.2
アラフォーこどおじの犯罪が相次ぐ理由
【埼玉】マスク販売、広告の有効期限…実際には限定されず　マスク通販で県が「夢グループ」に措置命令　別に手数料や送料も [Lv][HP][MP][★]
【バーチャルYoutuber】にじさんじ有ンチスレ10159【笹木のちっぱい応援スレ】
航空管制をするスレ
【考察】ポルナレフが味わった「恐ろしいものの片鱗」、裏側では何が？　海外のジョジョファンが再現（？）動画で考察
喪女の喪女による喪女のためのアンケートスレ　34題目
東方キャラ＋タイツ★8足目
ツイ4ヲチ4
【mobage】アイドルマスターシンデレラガールズ23707人目
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼