16Bitパソコン時代のMPU/CPU 68kとx86を語るスレです。
68020,386以降の32BitやZ8kや658xxの話題もOKです。
過去スレッド
68k v.s. x86 Round 3
ttp://hanabi.2ch.net/test/read.cgi/i4004/1458450955/
68k v.s. x86 Round 2
ttp://hanabi.2ch.net/test/read.cgi/i4004/1455196631/
68K v.s. x86
ttp://hanabi.2ch.net/test/read.cgi/i4004/1220728356/
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured
俺の日記じゃないけど。
MS1社が「ｺﾞﾗｧ!」するだけとは言え影響範囲が段違いだよな。
なんか古いWindowsでサポート切るとかいってるの
86はごちゃごちゃして嫌いだけど互換性を大事にする点は良い所だと思っているんだが
なにやらかしたの？
Microsoft、Skylake PCでのWindows 7/8.1サポート期間を1年延長
～緊急セキュリティアップデートはその後も継続提供
（2016/3/22 13:58）
ttp://http://pc.watch.impress.co.jp/docs/news/749310.html > 米Microsoftは18日(現地時間)、先日2017年7月17日までに短縮
> されることとなった、Skylake PCでのWindows 7/8.1のサポート
> 期間を、2018年7月17までに延長することを決めたと発表した。
これとWindowsのサポートとを直接関連付けている記述は見つからないかな
ttp://solomon-review.net/skylake-bug/ 当たり前のことでサポート延長はむしろ意外な感じ。
最新プロセッサの互換性が理由というのは穿った見方だと思う。
新しい機能（64bitとかマルチコアとか）が追加された場合
古いOSじゃサポートせず新しいOSでのみ活用するなんて普通にあったし
なんてジンクス発動しないだろうな？
それを互換性だなんだと足を引っ張るのはおかしい
すっぱりと切り捨てて新アーキで勝負してよかった
powerpcは中途半端だが
組み込み向けにはもっと効率の良いＭＰＵがある
ちょっと何言いたいんだかわからん
モトローラの態度が中途半端だったから仕方ない。
インテルはプロジェクト管理が下手すぎだし。
妄想で終わっちゃったというべきか。
8086と68000との決定的な違いは特権モードの有り無し。
特権モードがある68000はオペレーティング・システムを想定前提としたEDP向けミニコン志向。
特権モードを欠いた8086はハードウェア割り込み処理を想定した組み込み用のコントローラ志向。
68000の方がハイスペック。
単なる制御用のプロセッサをIBMがPCで採用したことで8086/88は大成功したが、IBMは実は
8088がゴミ同然の安物低機能だったから採用した。高機能すぎると本業を脅かしかねないから。
ゴミでなければならなかった。という話。
68000はそこそこ売れたが、68010以後にユーザモードの命令を特権モード移行させて
互換性を損なったので特権モードで動くOSを有していたamigaやatariはゲームや言語、
ビジネスアプリが上位機でクラッシュするとか問題起こし、上位機種への移行が難しかった。
その点で、macは天才ハーツフェルドがアホで無知だったから、
OSもアプリも同じ特権モードで動くようにしてしまったことで互換性の問題は生じなかった。
マイクロコントローラレベルで十分だった時代でもあったしね。
だが286は。
そりゃマイクロコントローラーには不要だろうがミニコンには必要なんだよ
最初期の、というのもあって技術的蓄積が無かったから仕方ないといえばそれまでだけどぶっちゃけ信者が言うほど優れた実装にはなってないんだよなぁ。
思い出補正で「68000は素晴らしかった！」って言いたいだけのクソジジイ共はとっととクタバレやがれ。
いや、まて、オレがくたばったときに数年の差で先輩面されるのはイヤだな。
とっととボケて寝たきり老人してろクソ共！
こいつのアタマの中に知識知恵の痕跡すら見当たらないね。
あるのは、恨みつらみの恨怨恨の悪感情が腐った膿だけ。
突いてみればそんなイカスミのウダグチャっと撒き散らされる。
キモい汚い、逝ってよし
↓ 膿の吐き出しショウが始まるよ。徳利とご覧あれw
マカーとかになるともう末期、エンドステージ。
なるべく永く苦しんでからくたばってね。
841 : ナイコンさん 2014/03/11(火) 16:06:17.08
保護モードとか冷静に考えたら制限そのものでしかないんだよな。
なんで皆あんなもの賛美してたんだろ？
843 : ナイコンさん 2014/03/11(火) 19:36:02.20
コード書けば馬鹿でも分る。
844 : ナイコンさん 2014/03/11(火) 19:37:19.80
世の中には馬鹿にも満たない奴もいることを理解すべき
効いてるｗ効いてるｗｗ
68010 のループモードは先見の明があったな w
概念そのものは古いみたいだけどね。
今じゃキャッシュでメガバイト単位とか・・・
時代が変わりすぎたﾜｲ
> 概念そのものは古いみたいだけどね。
古いと言うかキャッシュを気軽に載せられなかったのとマイクロコードの解釈をサボるための苦肉の策だな
32ビット化が早く進み、Windowsは最初から32ビットで開発となったかな？
実用レベルで使う技術が普及してればね。
汎用機では実現してたから未来ガーって言うほどではない
実用的には単体で仮想記憶をサポートできるようになった方に意味があったな
68451や68851の外付けMMUを使わずに単体で仮想記憶をサポートできたの？
ああ、すまん
68000 は中断したメモリーアクセスを継続できないので、メモリーアクセスで物理メモリーにデータがなかったら止めて他のプロセッサがディスクからデータを読み出したりする必要がある
要するにメインプロセッサの他に仮想記憶の処理用のプロセッサが必要ってこと
68010 はこの点が改善されて自分で処理して中断したアクセスを継続できる
68kシリーズ全体に言える事だけど、中途半端すぎ。
まさかスーパーバイザーモードとか言わないよな
68k信者が言うほど凄い石じゃないよ、68kは。
すごかったのはMacやX68を設計したエンジニアやそのシステムを組んだプログラマー。
まともに使えるのは68040以降(ECなしの030でもいいけど)になってから。
それ以前は「機能はある。実用的ではないけど、あるにはある」だからね。
モトローラはナにやるにして中途半端で放り出してて嫌いだわ。
組み込みとかでそう言う使い方してるのはいくらでもあったし
機能があるなら使いこなさないといけない病にでもかかってるのか？
あんなもん、有るだけ邪魔。
レジスタも1段2段も格下の8086のペアレジスタと機能そのものは大差がない。
それ以外の機能はあるだけ無駄の、クズ石が68000。
「メモリ空間」だけで売れたようなもんだから、時代のニーズには合っていたってことだろうが、よくまぁ売りに出せたってレベル。
> 1段2段も格下の8086
メモリ空間をコードとデータで分離するハーバードアキテクチャっぽいモードの存在は、さらに忘れられている感。
あとintelがもっと複雑な保護レベルを作ったけど結局たいして活用されてない事とか
コントローラーしか頭になけりゃ確かに無駄だけどな
010ならまだしも68000では欠陥と言っていいレベルの不備があり、
単体では例外は起こせてもそこから復帰させることはできず、仮想メモリも実現できなかった。
旧スレで何度も出ている話だと思うが。
MacOSがSVモードで突っ走り、プロセス保護やメモリ保護も無いMSDOSやCP/Mと同レベルのゴミで、
そのヤッツケ実装はモトローラの技術者を嘆かせた…という逸話も、なぜか都合よく忘れられているよね。
結果として、SVモードは現実に活用されなかったし、意味もなかった。
ApolloだかSunだかの68000(010や020以降ではなく真正の68000)を搭載したワークステーションで
特権違反例外から復帰する「だけ」のために68000をもう1個積んでいる
（割り込みが発生したら起こされ、スタックに復帰用のアドレスを書いてメインCPUをリセットするだけのために）
…という、アホみたいな実装まであった。
どうせゲーム機としてしか使ってこなかった連中ばかりと踏んで、UNIXと言えば怯むだろうと思っているのだろうが
（自分自身でそれが何なのか、どういうものであったのか理解もしていないだろう）
こういうゴミに毒づきながら仕事していた世代の夢も希望もない現実は、綺麗な話ではないから避けられがちだよね。
>macは天才ハーツフェルドがアホで無知だったから、
>OSもアプリも同じ特権モードで動くようにしてしまった
これ、けなしてるんじゃなくて、彼を誉めてるんだよね? w
Andy Hertzfeld 氏が、自ら語る初代 Mac 開発談
ttp://http://www.folklore.org/StoryView.py?project=Macintosh&story=Were_Not_Hackers!.txt Macのメモリ管理(NeXT-Stepに移行する前)の一般論・問題点については
英文Wikipediaが比較的よくまとまってると思った
ttp://https://en.wikipedia.org/wiki/Mac_OS_memory_management 個人的には に概ね同意だけど、業種/職種は様々なので の主張も妥当かと。
(というか さんと さんの意見が拮抗してるわけでもないか)
詳しくは知らないけど、Lisaには一応メモリ保護機能があったらしく、それをコスト・
容量的な理由(速度の問題もあったかも?)でごっそり削ったりして、初代MacのOSや
QuickDrawの開発を進めたらしいから、納期・コスト的に修羅場/やっつけ仕事なのは
仕方なかったのかも
技術競争で抜きつ抜かれつだったから、ちょっと年代がずれても比較の話題に
齟齬が生じるかもと思って、今更ながら簡易年表を作ってみた
1979 68000
1982 68010 + (MMU)68451
1984 68020 + (MMU)68851 + (FPU)68881
1987 68030(MMU内蔵) + (FPU)68881/68882
1990 68040(MMU,FPU内蔵 ※超越関数なし)
1994 68060
1979 8086
1980 (NDP)8087
1982 80286(保護モード) + (NDP)80287
1985 80386(32bitFlat,NDP内蔵)
1986 i486DX
1993 Pentium
MacOSは簡略化どころじゃなく無能がデッチ上げた欠陥OS。
信者を放置してると何もかも先行して成功していたかのように騙るが
（それも今時は「当時お前は何歳だった？まだ生まれてすらいないんじゃないか？」って連中がだ）、
プリエンプティブマルチタスクの実現なんて、Win95より遅かったんだぜ？
どの口でWin3.1を笑うの
286の286モードを活用していたら、面白いDOS系マシンが出来ただろうなあ…というタラレバ
SHARPのMZ末期のPC98互換モードが286のプロテクトモードを利用していた…というのが、
自分が耳にしたほぼ唯一の実装例
まあ次世代(386)で仮想86の実装が見えてたら、使わんよな今更…ってのはある
ATARI-STのTOS/GEMはほとんどDR-DOSのようなものだが特権モード配下。
特にMIDIポート制御はユーザーアプリとは隔絶したモードで走っていたから
正確なタイムシーケンスを刻むことができていたの。その点、ヒープマシンな
macはヒープ移動・ガベコレが発動するとIO止めちゃっていたから、苦し紛れに
MIDIマネージャーみたいなシステム拡張でこて先騙ししたものの音飛びボロボロ。
ということで、ことさらMIDIなDTM用途に限って言えばSTは実績信頼抜群だったのよ。
macで本格MIDIやるにはfx使えとか。力技推奨だったし。
OS/2は286AT専用OSでしょ。ただし、開発請け負っていたM$は同時期WIN3.0と互換機市場に
浮気して古女房のIBMに未完成なままのOS/2を手切れ金代わりに押し付けて離婚。開発撤退。
そうこうしているうちに386や486が市場登場とかWIN3.1とかね。
ユーザーモードでアプリに割り込み止められると止まっちゃうけどそれは無作法だし外法だって事にして回してたし
特権モードが無いと安定した通信やバッファ処理が出来なかった訳でもない（当たり前）
割り込みを止めるような外道なアプリがあったら例外発行して「コイツ(アプリ)が割り込み止めようとしたので俺(OS)がこいつを止めた」ってエラー出せるだけなのが68kのSVモード
OS/2はPS/2用に開発。
PS/2は最初から386モデルがあった。つまり386が存在する時代に開発された、286用OS。
wikipediaによるとFM-R用も有ったらしい
元々はGUIのない素のMSDOSとかと同様のCLI環境だし、
それでも真のプリエンプティブマルチタスク環境は当時は面白かった。
コマンドラインで何やってもOSは落ちない、凄え、偉い…ってレベル。ガキか。
ジョイスティックのボタンに割り込みで任意のプロセスをアサインして
ボタン叩くとデバッガ起動とかできて楽しかった
Mac OS関連で一番ワクワクしたのはsystem 5.0とswitcher。6.x以降のマルチファインダーの
前身で、ハーツフェルド作でアップルが買い上げて市販した4アプリ切り替えソフト。マジで凄いな
と思ったものですよ。85年だったか86年。アプリがヒープというコンテナに閉じ込められているから
ああいった切り替えができるのね。という仕組み自体、親プロ子プロとは異質で面白くすっげー。とね。
X68Kの場合先頭から2MBの範囲に対して8KB単位でスーパーバイザー領域を設定出来た。
この機能でメモリ上のOS本体をユーザーモードからは書き換えられないようにし、また
SYSTEM I/Oもスーパーバイザーモードじゃないとアクセスできないように保護した。
DEBUG中にCOMMAND.Xを飛ばしても、Humanのプロンプト表示には大抵復帰した記憶がある。
派手なI/O操作をするプログラムでは気休め程度かもしらんが。
68000のスーパーバイザー/ユーザーモードの違いはSRの上位バイトに書けるかどうかと、
スタックポインタがそれぞれのモードで切り替わることと、数個の特権命令程度のものでしか
ないが、それはCPU単体で見ているからそう見える。
外部でFCをデコードし、ユーザーモードで許されないアクセスにBus errorを返す簡単な回路
を付加すれば初歩的ながらメモリ保護を実現できるよ。
おー Switcher !。まだ自分は持ってなかったけど、友人に見せてもらって
凄いな～と感動した記憶が。苦心の(というか苦肉の?)策で、内部的に
どうやってるのか不思議だったけど、友人の環境のせいか、けっこう爆弾が…w
Multi Finder の前身なわけですね
自己レスの訂正 i386のNDPを間違えてた
1985 80386(32bitFlat) + (NDP)80387
1986 i486DX(NDP内蔵)
ATARIの話とかOS/2のPM以前の話とか、当時の自分が知らなかった話しが色々聞けて
このスレ、とても勉強になります(ってこの歳でいまさら学習しても不毛だけどw)
突っ込みどころ満載過ぎ w
> SVモードがあっても、少なくとも68000の時点では現実にほとんど活用されなかったし、
の言うように簡易的なメモリー保護や I/O 保護をしていたシステムは普通にあった
> MacOSがSVモードで突っ走り、プロセス保護やメモリ保護も無いMSDOSやCP/Mと同レベルのゴミで、
> そのヤッツケ実装はモトローラの技術者を嘆かせた…という逸話も、なぜか都合よく忘れられているよね。
それって単に MacOS の問題だろ...
> 結果として、SVモードは現実に活用されなかったし、意味もなかった。
そうマッキントッシュならね w
> 特権違反例外
特権違反例外からは普通に復帰できる
できないのはバスエラー
> （割り込みが発生したら起こされ、スタックに復帰用のアドレスを書いてメインCPUをリセットするだけのために）
全然違う
バスエラー発生時にメインプロセッサを止めてサブプロセッサがディスクからデータを読み出してその後メインプロセッサの該当バスサイクルをリランする
リセットとかアホなことはしないよ
ちなみに Apollo ではサブプロセッサは通常はグラフィックス処理を行っていた
懐かしいわ。
スタックじゃなくて、ベクタに復帰アドレスを書いてリセットだったね
（そりゃそうだ、例外起こして止まったCPUのSPなんか外からどうやったって読みだせない）。
もちろん現在の感覚なら、CPUより遥かに小規模なロジックを組めば
「それだけのために同じCPUをもう1個」なんて間抜けな事をする必要は無いけれど、
当時はそんなロジックを製品レベルで起こすだけでしんどかった（安くなる前のMC68000をもう1個使うより高くついた）。
で、それもアポロの話じゃないっていう…鼻息荒くして突っ込んだつもりでデタラメ三連発、という情けなさ。
ttp://http://www.st.rim.or.jp/~nkomatsu/mc68k/MC68000.html >MC68000を用いて仮想記憶を実現するのは困難で、[～中略]
>MC68000のバスサイクルはデータアクノリッジ信号を返さなければ任意の時間だけ
>CPUを待たせることができますし、バスエラー信号の与え方によっては、ある信号が
>変化するまでCPUをバスから切り離し、その後でもう一度同じバスサイクルを再実行
>させることができます。この、後者の機能をうまく使うというのがタネです。
ttp://https://ja.wikipedia.org/wiki/MC68000 >[3.9.1節] MC68000 でのデマンドページングの実現
ttp://https://en.wikipedia.org/wiki/Apollo_Computer >When a page fault was raised, the main CPU was halted in mid (memory) cycle
>while the watchdog CPU would bring the page into memory and then allow the
>main CPU to continue, unaware of the page fault.
ttp://https://en.wikipedia.org/wiki/Motorola_68000 >Several companies did succeed in making 68000-based Unix workstations with
>virtual memory that worked by using two 68000 chips running in parallel on
>different phased clocks. When the "leading" 68000 encountered a bad memory
>access, extra hardware would interrupt the "main" 68000 to prevent it from
>also encountering the bad memory access. This interrupt routine would handle
>the virtual memory functions and restart the "leading" 68000 in the correct
>state to continue properly synchronized operation when the "main" 68000
>returned from the interrupt.
-----
投稿者によってWikipediaの内容の真偽が曖昧なのは仕方ないとしても
和文と英文とで微妙に食い違ってる気がする…
個人的には IC-Collection 小松さん(?)の解説が好み
すぐ後継の68010で修正されて以後問題になってないのに
その一点だけを繰り返して68000は糞みたいに言うのはどうかと思うけどね
MMXペンティアムで誤演算したから全ての86はCPUとして使いものにならないって言うのと同じじゃね？
Appleじゃダメ。ジョブスがピーキーで嘘つきだからな。
68020はRISCのRシリーズが席巻するまではワークステーションを一手に握っていた感じだけど
Mac以外のパソコンにはこなかった
Macは当時はかなり高価だったよね
ジョブスはカリスマ経営者というか営業マンというかだけど技術はお察しだから
>当時としては世界を取るかどうかはIBMが採用したかどうか。
実はIBM(正確にはその子会社)も68000を採用した機種を販売している。
恥の上塗り乙
> スタックじゃなくて、ベクタに復帰アドレスを書いてリセットだったね
> （そりゃそうだ、例外起こして止まったCPUのSPなんか外からどうやったって読みだせない）。
SP の値もわからずにどこから復帰アドレスを取得するんだよ w
そもそもリセットかけたら SSP の値も上書きされるのにバカすぎでしょ
> で、それもアポロの話じゃないっていう…鼻息荒くして突っ込んだつもりでデタラメ三連発、という情けなさ。
の爪の垢でも煎じて飲めよ w
68000 は 68010 出てからも普通に売ってたからバグ付き Pentium の話と一緒にはできないだろ
あと MMX Pentium でもバグあったんだっけ？
> Macは当時はかなり高価だったよね
AMIGAやATARIのシリーズはなかったことになってんのかな
用途によってはバグ（？）有りの68000でも、まったく問題無かったって事だな。
突っ込んどくよ。
>メモリ空間をコードとデータで分離するハーバードアキテクチャっぽいモードの存在は、さらに忘れられている感。
MC68000の話をする文脈で、ハーバードアーキテクチャって単語出したら「コイツ判ってないんじゃない？」って
思われるだけなので普通は持ち出さないと思うよ。
>ApolloだかSunだかの68000(010や020以降ではなく真正の68000)を搭載したワークステーションで
>特権違反例外から復帰する「だけ」のために68000をもう1個積んでいる
>（割り込みが発生したら起こされ、スタックに復帰用のアドレスを書いてメインCPUをリセットするだけのために）
>…という、アホみたいな実装まであった。
伝言ゲームの5人目位かよw と言いたい位色々おかしい。
登場する単語からエスパーして、仮想記憶を実現するときのページフォルトへの対応と取るならば
の記述や で引用されている IC Collection の記述で対処できるよ。
もし、本当に特権違反例外からの復帰ということを言っているのなら、特段外部の助けも要らない話。
OSがユーザープログラムの動作継続を不適当とみなすなら、その旨表示してユーザープログラムを強制
終了させるなり好きにすればいい。そこはOS次第。
>スタックじゃなくて、ベクタに復帰アドレスを書いてリセットだったね
>（そりゃそうだ、例外起こして止まったCPUのSPなんか外からどうやったって読みだせない）。
どうも特権違反やBus errorがあるとMPUが停止すると思い込んでいるフシがあるけど、MPUが止まるのは
ダブルバスフォルトが起きた時だからねw
特権違反例外は上に書いたとおりベクタ8番に従って処理ルーチンに飛ぶし、Bus errorにしてもスタックへの
各種保存に成功してベクタ2番(とそれが示す1ワード)へのアクセスが正常に出来る限りOSが用意した処理
ルーチンに飛ぶだけ。
>鼻息荒くして突っ込んだつもりでデタラメ三連発、という情けなさ
ビール返してよw
用途によっては 68000 の「仕様」でも問題なかったと言うだけ
80年代や90年代頭ではまだハーバードアーキテクチャ神話は信じられてたんじゃね？
キャッシュが普通に使われるようになった頃だろ
今でも内部キャッシュが命令とデータで別になってる奴とかあるからアーキテクチャとして廃れた訳じゃない
> ハーバードアーキテクチャっていつぐらいから「無意味」って言われるようになったんだっけ？
初耳。ハーバードアーキテクチャって現代でも使われてる仕組みだけど
どこのどいつがそんなこと言ってたの?
キャッシュのお陰でメモリーアクセスがボトルネックとなることが軽減されたから汎用プロセッサで性能を求めてハーバードアーキテクチャにすることはあまりなくなった
DSP とかプログラムコードにアクセスされたくない組み込みプロセッサではハーバードアーキテクチャの奴はあるよ
CPU の中身では、イストラクションとデータが別れてるのが多い。
ノイマン型アーキテクチャの利点の一つを捨ててる訳だし
コードの書き換えがしたかったらそういう機構を用意すればいいだけの話だね。
x86ではバスは共通なもののメモリとI/Oで異なる命令で読み書きする機構があるし、
組み込み用のAVRではコード領域に配置したデータを読む専用の命令がある。
大した変わらん話だろう。
今のPC用のプロセッサって馬鹿に幅の広いバスが複数あったりするし
キャッシュのお陰でボトルネックが軽減ってもう随分昔の話だろ。
あれ今でも本気で有用だと思ってる人っているんだねw
ttp://https://en.wikipedia.org/wiki/IBM_System_9000 BYTE誌の紹介文が面白い
>The magazine speculated that with some changes it would be
>"a natural candidate for a business or general-purpose computer"
ttp://www.columbia.edu/cu/computinghistory/cs9000.jpg ttp://http://www.columbia.edu/cu/computinghistory/cs9000.html もしこれの廉価版みたいなのを作って、IBM-5150 の後釜として
大々的に売り出してたら、世界は変っていたかもしれない… w
コード領域の書き換えができなかったらプログラムのロードすら
思うようできんだろアホか
ただしこの場合コード領域から読み取ることはできない（コード側に即値として書き込まれている数値は演算に反映されるが）
スレタイ読めよ...
ここはそう言う昔話をするスレ
> MC68000の場合は、コード領域に16MB取った上でデータ領域も16MB持つことも可能だった
各々スーパーバイザー/ユーザーモードがあるから全部で 64MB 持てる
って言ってたような気がする
> 物理メモリが16Mに制限されてる
64M にしてもいいんですよ
68000 でそれやると外部回路無しではＯＳがユーザープログラムに触れなくなるけど w
アドレスバスちょっと減らしただけでそんなにコストダウンできるもんなの？
あえて性能下げて安く売るって今のインテルもやってるよね
ダメじゃん・・・
それ逆だろ。物理メモリが64MBでプログラマーから見たメモリ空間が16MBでしょ。
スーパーバイザー/ユーザーはいいとして、後はコードとデータで別々の空間を意識する。
まぁ8bit世代でBASIC用のテキストウィンドウなんて仕組みがあったけど、そういう類の
仕掛けを持ってくればOSは64MB全域にアクセスできるでしょ。ゲートアレイ起こせる
なら大したことない。TTL並べて組めって言われたらゲンナリだが。
と言っても、これは空想の羽を広げるためのネタでしょ。
16MBの空間を使い尽した後でもなければ、追加ハードウェア・対応OS・対応コンパイラ等
対応開発ツールの要る話で、その一方68000登場時点でDRAMの世代は64kあたりだから
16MBを埋め尽くすのは現実的じゃないし。
この辺のネタも、よく判ってない ﾜｯﾁｮｲ 6732-D2ET 程度のいい加減な営業が煽りを入れる
ために宣伝目的で一文を書き足したんじゃないかな？
ちなみに、よく判ってない ﾜｯﾁｮｲ 6732-D2ET のために言っておくけど、これは64MBアドレス
モードとか特別なモードを用意したとかじゃないからw
ユーザーがFCをデコードして、アドレスデコードの条件に加えればメモリ空間4倍になるね！
っていう思いつきレベルの話だから。
よく知らない。
今手元にInterface 1986/10号があって、新製品情報を拾ってみると
・68020搭載 SUN-3/200シリーズ(RAM 標準8MB/最大32MB)
・VMEバス仕様 8MBメモリーボード(1Mbit DRAM使用)
・4Mbit DRAMのサンプル出荷(TI 88年/沖 87年末 それぞれ予定)
この辺が時代を把握するのに役立つかな。
68020が広まり出すタイミングでも、製品搭載レベルでのDRAMは1Mbit世代ってことで。
1Mbit DRAMで16MBを埋め尽くすには128個必要だけど、EWSなんかなら無くはない世界
に踏み込んだというレベルかと。
DRAMのパッケージも DIP → ZIP → SOJ(SIMM) と省フットプリント化してきているし。
1Mbit DRAMについては、日立が 1984年に発表しているということで、68020の発表年と
一緒という感じ。
なので、68000で16MB到達する頃には68020に移行できる道も拓けていたんじゃないかと。
どうしても！という向きには68012(見たこと無いけど)という選択が…あったのかな？
Portable とか IIfx かな。
plusでさえ売り出し定価は64.8万。4MBやらHDDやらimagewriterまで
セットにすれば100万超えてた。
ttp://http://simasima.info/archives/948 兄貴が IIcx 買ってて HP のプリンターやソフト込みで 150万とか言ってたな
Macはユーザーじゃなくてオーナーだっけ？
ttp://https://www.bloomberg.co.jp/news/articles/2016-10-27/OFPJFD6JTSEW01 今度はNXPがクアルコムに買収か。
クアルコムに未来を見る能力はない。
あるのはカネにガメツいボスだけ。
(´・ω・`）y━・~~~
カベを作って乗り越えて世代交代して買い替えを促すビジネスモデルなどと遅レス
8086で8080上位互換（）のためにセグメント導入したのがそもそもの始まり。
「壁の外側に新しい世界を作った」から「それまでの世界の果て」が「壁」になっただけのこと。
段階的に更新できるユーザーに優しい商売のやり方じゃないかw
広い庭で満足しちゃったからだろ。
EMS/XMSは爆発的に普及したけどVCPI/DPMIねぇ。
VCPIでバリバリプロテクトモードのアプリとか、書くのはともかくデバッグ環境の貧弱さ考えるとねぇ。
1. 68kはすごい石ではなかったけど、
2. 同時期のx68の使いにくさは半端なかったからなあ。
3. 簡単なものを開発するのも結局は68kのASが楽だった。
4. で、だんだん難しいものも作れるようになっていったわ。
2.○68kの使いにくさは半端なかった
3.×簡単なものを作るのも楽な方法などなかった
4.×だんだんユーザがマゾになって難しいものも作る苦痛に快感を覚えた
と言うよりセグメントをいちいち意識しないとダメ
って言うのが面倒だった
書きたきゃfar～とか非標準な書き方が必要でソースが汚くなり可搬性が損なわれたし性能もガタ落ちした
UNIX環境でちょい富豪的プログラムに慣れた後だとDOSのメモリーアクセス環境は正気の沙汰じゃなかったよ
8bit時代からバンク切り替えは当たり前にやってたのに8086のセグメント叩きは異常。
16bitCPUって括りが数値扱うにしろ、ポインタ、アドレス空間扱うにしろいろいろ中途半端にさせる。
> 8bit時代からバンク切り替えは当たり前にやってたのに8086のセグメント叩きは異常。
人って一度うまいものを食っちゃうとそれまで普通に食ってたものも不味い～って感じるものなんだよ...
複数のレジスタを組み合わせるのは避けられないから
それを専用のセグメントレジスタを用意する8086や汎用レジスタの
ペアでアクセスするZ8000の形式は仕方ないと思うが
386でレジスタ長が32bitに拡張された時に下位CPUと互換を保つ為に
64KB制限をかけたのがなぁ…
Intelは64KBオーバーのメモリ取り扱いたければプロテクトモードに
移行しろという事だったのだろうが実際にはUnrealモードという
抜け穴があったのだから正式に公開していたならばx86のメモリ利用も
もう少し違ったものになったと思うな。
当たり前だろ
過去のソフトを確実に動かすのが大前提だし
68K はそこを結構バッサリ切ったりするから今の状況になってる
個人的は 68K に肩入れするけどビジネス的には泥臭い x86 に分がある
そんな程度で目くじらたてるとか、正気を疑うレベルだなw
おまえさんがUNIXや68k向きじゃないのはわかった
DOS+セグメントがお似合いだから自分の楽園にお帰り
過去のソフト(8086，80286)は16bitレジスタしか持たず通常は64kB以上の
メモリアクセスが出来ないから互換は保てるけど。
（16bitレジスタで64kB境界をまたぐメモリアクセスの場合は挙動に差が出る
可能性があるが本来は不正なコード）
32bitレジスタでアクセスする場合に64kB制限を外しても支障は少なかったりする。
実際リアルモードのDOSでUnrealモードを使ったフリーソフトも存在していたりする。
スキルが無いのがモロバレ基地外くんはユニッスwにしがみつてればいいよw
もともと64kが限界と判ってるプロセッサなんだから、その程度のことしかさせないのが正解なのにね。
自分のスキルの低さをハードのせいにする低脳クズの典型ですわwww
> 可能性があるが本来は不正なコード
不正だろうが動かないソフトがあっちゃダメなんだよ
業務用のプリンタやってたけど他社のバグをエミュレートするモードとかあったし
リアルモードでのセグメントリミットを単一のものではなく
16bitレジスタで使用の時には64kBに32bitレジスタの時には
4GBに変化させるという方法もあったりする。
まあ実際には単一のリミットを使っていたので64kBに制限していた訳だが。
ちなみにこの64kB境界の挙動は8086と286でも違っており
8086はラップアラウンドしてアクセスするが
286の場合はプロテクトモードと同様に例外を発生させる。
8086と286の非互換部ではあるがそれが大きな問題とされることは無かった。
（286がHMA領域をアクセスしてしまうという非互換性問題に類似するが別問題。
この286の非互換部が後のDOSのメモリ拡張に活用され恩恵を受けることとなった。）
製品自体存在したのか知らないが
8bit CPU はたいてい 256バイトを越えてリニアアクセスできますが？
質問の答えに全くなってない。何を言いたいのかもさっぱり分からない。
Z8000のレジスタペアでのアドレス表現は23Bitリニアアドレスではなく
下位レジスタは16Bitオフセットだが上位レジスタは8Bit左シフトして
MSBをセットした特殊な形式を使っていたはず。
V33が持っているのはセグメント(16Bit)：オフセット(16Bit)で生成した
20Bitアドレスを論理アドレスとして8＋12Bitと分解して上位8Bitを
ページングで24Bitアドレス空間に割り付けるというのだったと記憶しているが。
16ビットCPU ⇒ 16bit幅レジスタという条件
がお馬鹿って言いたいだけなんだが
お馬鹿には難しすぎたか w
8086は連続したアトレスバス20bit分はアクセス可能だろう。
どれだけ条件を満たせばリニアアクセスと言えるのか聞いてる。
> どれだけ条件を満たせばリニアアクセスと言えるのか聞いてる。
セグメントやバンクの切替操作なしにアクセスできること
伝える側に責任はあれど受け手に責任はない
正しく伝わっていない事を受け手の責任にするのは伝え方が下手なだけ
>>質問の意図が難しすぎたか。
質問の仕方が下手すぎなんだろう
バカは無責任でおKw
意味わからん
バンク知らないのはお前の方じゃね？
そんな相手に質問の意図を理解してもらっても答えようがない質問なのでは
セグメントモデルの利点は拡張された8ビットCPUとして見たときなんだよね。
ttp://https://www.google.co.jp/search?q=8086+%22linear+address%22 約 13,200 件 （0.45 秒）
ttp://https://www.google.co.jp/search?q=8086+%22linear+access%22 > 約 822 件 （0.27 秒）
馬鹿はおまえだよ。
日本語読めない馬鹿か。
リニアアクセスなんて謎用語使ってる奴が一人いるからどういう意味かと聞いてるだけだ。
だが答えは出た。
リニアアクセスとは「セグメントやバンクの切替操作なしにアクセスすること」
つまり386のプロテクトモードはリニアアクセスできないし、今時のCPUもリニアアクセスができないらしい。
しかも386のプロテクトモードのセグメントでも、利点は拡張された8bitCPUと見たときらしい。
単なるアホだった。
よほど誰にも相手されなかったくだらない人生だったんだな。
馬鹿なことにはかわりないけどw
リニアアドレスもリニアアクセスも明確な定義がないのにねぇｗｗｗ
どうやったらこんなアホに育つんだろう...
おまえ以外の人はどんだけの範囲をリニアアクセスできるかを問題にしてるんだよ
落ち着いて から読み直せ
その事実が悔しいのか、8086信者は。
って事ですね（笑
あー、ばからし。
> ﾄﾞｺｸﾞﾛ MMff-j6UX「うきー！ 俺のすきな8086を貶すのは許せん！！」
> って事ですね（笑
どこからそんなアホな結論持ってきたんだよ w
俺は 6800 の時代からモトローラ派だよ
> あー、ばからし。
ならレスしなきゃいいのに...
可哀想だから にはあえて突っ込まないでおくよ w
ソフトのないCPUは道端の石ころと変わらない。
FM7、メガドライブ、X68K、PowerMAC。青春の頃にマイノリティだと性格歪むよね。
かわいそう。
6809はマイナーだけど68000はメジャーだったでしょ
まあそんなx86をARMが叩いてくれてちょっといい感じよねARMがi5並に成りそうらしいけど
i5とi7って大して変わらないんだっけ頑張れよ
真実は、wintel連合が再投資し続けて進化し微細化した最新プロセスルールにタダ乗りする
パクリ屋アップルとARMという構図なんだけどね。
唯一無二絶対正義のインテル目線から見りゃそうだなでもインテル以外が伸びてればそこが再投資してたろ
王道の右翼路線で性格歪んでたら世話ねーな
IntelのCPUが高性能と宣伝することで幸せになる人々がいる。
それでいんじゃないかな。
> AMD64がデファクトスタンダードとなってしまった
と思い込むことで幸せになる人々がいる。
それでいんじゃないかな。
馬力にものを言わせて単純化するほうこうに進むだろ、10年か20年は。
ただ386以降オフセット指定が32bit幅に拡張された後、4GBを1セグメントのフラットアドレスとして使用され続けた理由は単に、
OS開発者、コンパイラ開発者が他のCPUとの移植も考えてハード固有の機能に頼らない実装にしたに過ぎない。
リアルモードのセグメントとプロテクトモードのセグメントは別物だぞ。
馬鹿なこと言ってんじゃねーよ、屑。
ファミコンのCPUが80系とは別物って話は訊いたのですが、どのくらい変態的だったのかご教授下さい。
ttp://hanabi.2ch.net/test/read.cgi/i4004/1474548959
スレ違いごめんなさい&誘導ありがとー
そのまま動く場合もあるが
6808のようにニーモニックにsexがないぶん紳士的だよ。
(´・ω・`）y━・~~~
どこの異世界の話だよw
モトローラ信者ってどうして馬鹿でクズな奴しか居ないの？
中学生レベルの人間しかいないの？
っていうか、HC08にSEX命令は無いよw
制限を解決した386登場以降も386が64kBリミットのリアルモードOSを使い続けた理由が理解出来てない。
モトローラの失策は80年代前半PC領域は8BitCPU6809で戦えると考えたことだな。
相対的に高機能高価格の68000はそれより上位の市場に投入していたのに後発のRISC勢に奪われて
その市場を守りきれず、本格的にPC領域への浸透を試みた時には既に8086/286が築き上げた
膨大な資産を突き崩すことが出来ずニッチな市場に生息するのが精一杯だった。
386はその拡張された機能は当初は32Bitプログラム環境に使うのではなく仮想86モードと
ページング機能を用いた仮想EMSの様にDOSの機能強化に回してPC環境を改善して
DOS資産を保持しながら時間をかけながらWindowsで32Bitプログラミング環境へ移行した。
プログラムを作る人は過去のしがらみにとらわれない方が楽
ってだけの話だろ
これが妄想。開発者がMSを支持し、アップルとは関わりたくないと思う理由が分かってねーな。
この言葉の重み知らないﾆﾜｶが知ったかぶりしてるだけ。
楽しいって書けばわかるかな
MSのみならずソニー・任天堂を見限って
アップルに寝返ってますが？
最近は泥にごっそり客とられてるけど。
でもコストパフォーマンス悪かったし、性能もモトローラが吹くほどのことは無かったし。
いろいろ面白い機能はあったが、セガが買わなきゃタダでさえ悪いコストパフォーマンスがさらに悪くて市場からは見捨てられてただろうな。
その程度の製品だったが、思い出補正で美化しすぎるｼﾞｼﾞｲが多いだけの事。
メジャーが嫌い、金持ち、意識高い系、この三つの条件が必要だ。
なんか気持ち悪い
フロッピーが1枚720KBしか入らない時代に68k採用したATARIやAmigaは
512KBからスタート（しかもVRAM込みで512k）だし、
Macなんか128KBだからな（toolboxをROMで持ってたが）
最強のX68000（笑）だって1MBからスタートで、フォントやIOCSもメモリに読み込むから
MS-DOS環境の640KBを笑ってられない状態だった
そもそも扱うデータが数KB単位だからな…
> MS-DOS環境の640KBを笑ってられない状態だった
その640KBを扱うのが面倒かどうかの話なんだが...
言ってることがとんちんかんでびっくりする
機能も性能も、技術的蓄積がないのがモロバレの中途半端。
あるのはモトローラの自画自賛だけ。
モトローラの口先だけは凄かったが。
ソースファイルの機械的な置き換えで流用できる8086と以後のバイナリ互換を維持したx86系で成功したインテルと、68kで断絶しPowerPCで断絶しとジリ貧一直線の失敗をしたモトローラの例をとれば。
技術的にもノウハウの蓄積があるかないかは大きな違いだし。
8bit資産を切り捨てたからNECに負けたかどうかは知らないが、
6809のゲームで68000に移植するゲームの案件なんてほんとにあったのだろうか。
CPU変えてもサウンドや照明や入力デバイスが変わらなかったら、そこら辺りのロジック使いまわせれば使いまわしたほうが手間がはｂ・・・実績があるロジックが使えるもの。
ゲーセンのゲーム基盤。プロレスのゲームとか
3Dっぽい視点の猪木のでてくる2本レバー操作の奴かな？
どちらが良かったのかは、今のシャープと富士通みれば明らかだなw
Xboxが登場するまで、インテルCPU採用を聞いたことがない。
Xboxのペンティアム3より前はそれだけ扱い辛かったってことか？
不必要に大規模だから何処も採用しなかっただけでしょ
あとになって、PCがコモディティ化してx86が低価格化し
当時のアーケード業務機で使われていたSH-4とコスパが逆転したのがきっかけ
WinNT系OSとDirectXの普及で汎用ゲーム開発が主流になっていった事も一員
8085とか使ってたゲーム基板見たことあるよ。
使用言語云々よりも柔軟な根幹技術を吸収できると思うの
インベーダーの業務機は8080だったな。
秋葉原のジャンク屋で実物見たことある。
ttp://http://gigazine.net/news/20120829-arcadegame-engineer-cedec2012/ ttp://https://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%9A%E3%83%BC%E3%82%B9%E3%82%A4%E3%83%B3%E3%83%99%E3%83%BC%E3%83%80%E3%83%BC ワンダースワン
雷電シリーズやR-TYPE以降のアイレム製ゲームもだろ
V30はインテルじゃなくてNECだろ！
あれ？
何のゲームだったか知りたいな。
ゲーム雑誌で8086を使ったイギリス製のコンシュマー機、なんて記事を
見たことがあるが、試作品だけで結局発売されなかったんだろうね？
WOFLシステムってサイキックフォース2012だけ？
WOL FSYSTEMはサイキックフォース2012のみ
但しTYPE X以降AT互換機化してIntel CPU＆Windows XP & 7 Embeddedを採用している。
詳しくは下記参照
つ
ttp://http://www.system16.com/ タイトーだけではなくコナミ，ナムコ，カプコン等主要なメーカーの
ハードウェアスペックとボードの写真を見ることが出来るよ。
V60は386SXより安く、V70は386より安かった？
ただし、性能はいまいちだったらしいが。
実際初期は入力遅延とか不意の処理落ちとか問題も多かったらしいが
…まあ、これはCPUではなくOSの問題だな
3.xと同じに。
プログラムぐらいはちょっといじったことはあるが、
コンピュータ好きではなく、ただのゲーム好きだと気が付いた。
色々なゲームをやったが、メンツ集めさえしっかり出来れば
卓ゲーに勝るゲームは無し！
20年ぐらい前からゲームはもっぱらコンピュータ不要の
ボードゲームばかり
そんなコンピュータの専門家ではない、ビジネスソフトや
ブラウザのためにコンピュータを利用する人間としての質問だが
これでだいたい合ってる？
まとめて扱えるプログラムとそのデータは64キロバイトまでである。
DOSの時代に既に64キロバイトを超えるプログラムやデータを
扱うことが増え、多くのプログラマーが32ビット幅の汎用レジスタを
持つ68000だったら、しなくて良い苦労をDOSマシンでさせられた。
インテルが8086を作った時は、まだそんな大きなプログラムを
使うことは想定していなかった。
それでも念のため8086に、アドレスバスだけは16ビットではなく
20ビットまで持たせた。
ただし、２進法のコンピュータにとって、２の累乗ではない幅の
汎用レジスタは効率が悪く、アドレスバスが20ビットや24ビットの
CPUでも汎用レジスタも20ビットや24ビットにすることは無かった。
オフィスで使われるようになり、旧機種との互換性が
重要になったDOSマシン以外では
CPUの性能やメモリをさほど必要としないコンピュータには
Z80や6502が使われ、そうでないコンピュータには
32ビット幅の汎用レジスタを持つ68000が使われた。
IBMは、本業のより高価格のコンピュータの売れ行きに
影響するから、IBM-PCを低性能低価格にしたｗという説も
あるが、68000の汎用レジスタ幅の広さや本数の多さは
高コストになり、8086にはさらデータバス幅８ビットの
8088があり、よりコストダウンになることでIBM-PCが8088を
採用した理由の１つになった。
| ノ＼ ,＿ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ ()
彡､ |∪| | J
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
＼ " ／ ｜ |
＼ ／￣￣￣ ／
8ビットCPUは8ビットの汎用レジスタを持ち データバスが8ビット
8086は16ビット68000は32ビットの汎用レジスタを持っていてデータバスが16ビット
まず8ビット世代があってそのあと高価な16ビットが出てきた
両者値段で住み分けて共存してたがwinに切り替わる頃を境に消えていった
IBMが8088選んだ理由は知らんがぐぐればたくさん出てくるだろ
IBMがより大型のコンピュータが売れなくならないように、わざとIBM-PCを
低性能にしたって説は、DOS/Vが普及して来た頃のコンピュータ雑誌で見たよ。
まあ、説だけどな。
具体的に挙げてくれ。
できなきゃ風評の流布って奴だなｗｗｗ
おまえは電化製品買ったことないのか。
> どの製品が該当するんだ？
> 具体的に挙げてくれ。
>
> できなきゃ風評の流布って奴だなｗｗｗ
風説の流布では？？
データバスが8ビット幅だったんで、最小限の手間で済んだからでしょ。
「とにかくさっさと動かせ！」といわれたら8ビットバスで設計した方が楽。
8237なんてフライバイしかできんし。
繊維メーカーが丈夫で売上が落ちるから、こっちのほうが長持ちだと
分かるぐらいにだけ新素材を混ぜた服を作るようなもんか？
と言うより、曲がりなりにも将来多くメモリが使えるように
Z80じゃなくて8088にした？
初代IBM-PCなんかメモリたった16KBだ。
2chはオワコン
そんなデカい基板作って商売になるのか？
別に一枚にする必要はないでしょ
ところで256個ってことは一個32KbitだけどそんなRAMあったっけ？
64k×1bitとか16k×4bitのDRAMが出てくるのは80年代に入ってからだったはず。
32kbitとかいうのはDRAMではありえず(DRAMはRAS-CASの2分割でアドレスを与えるため）
SRAMだとコストとんでもないことになる。
アドレッシング出来る領域を全部埋めなきゃならないという法律もないので、32kbitというDRAMも
世の中には存在したようだよ。MC6662/6663/6632/6663 がそうらしい。ま、見たこと無いが。
2msで128Rowアドレスのリフレッシュを要求するみたいだから、Rowアドレス7bit、Columnアドレス
8bitという構成の様だ。Rowアドレスを入力する際はどこか1bitがDon't careになるんだろうな。
当然アドレスpinは1本増えるが、５V単一になっているので4116と同じ16pinに収まる。
遅レスだが、外部アドレスデコーダの設計によっては、
命令専用メモリエリアとデータ専用メモリエリアを分けて作ることはできたはず
扱いにくくて採用例がなかっただけで
Wintel連合の関係の石を採用したアップルはともかく、ARMはwintel連合の半導体投資の成果は流用してなくないか
いや、RISC勢が発達したのは68kの性能が伸びなくなったせいで順序が逆だろ
MacはともかくX68ｋはさほど高くはなかっただろ
98のローエンドよりは高いがハイエンドほど高くはない程度だったじゃん
金持ちってフィルターはMacだけでX68ｋには…… いやでも、当時はPC持ってるだけでも金持ちだったっけ?
素の状態のX68000はフォントやIOCSはROMに置いたままだぞ、RAMに読み込んだりはしてなかった。
のちに機能強化などのためにRAMに置くことができるように拡張された（と言うか改造された）だけだろ
どっちも瀕死になってて大差がない気がする
PC事業を売り払った富士通と会社ごと売り払ったシャープ?
FC で分ける話かな
User Code, User Data, Supervisor Code, Supervisor Data, CPU Space の5種類に分離できて、CPU Space を除いた4種×16MB=64MBまでアクセス可能って宣伝してたな
68000 でそう言う設計すると Supervisor Mode で User Data にアクセスできなくなるからプログラムのロードや Supervisor Call のデータの受け渡しにも困っちゃうとか使い辛いと言うレベルでなかった
68010 からは MOVES 特権命令で Supervisor Mode なら任意の空間にアクセスできるようになったからそんな苦労はなくなったけど 68020 からメモリー空間が 4GB になったことと MMU が普及してきたことからそもそも空間別にする必要性が薄れちゃった
それそれ
初期の古い試料には使用例（案）が載ってたけど、すぐ載らなくなっちゃったね
実際に使ってみたら使い物にならないと分かったってことかな
ちょっと想像するだけでも困難そうだと思うんだけど、
ひょっとしたら一部には本気の人も当初にはいたのかもね?
＞いや、RISC勢が発達したのは68kの性能が伸びなくなったせいで順序が逆だろ
いや、1987年にSunがSPARCを使ったSun-4を出して業界全体に衝撃が走った
VAX8800と同じ性能で価格が1/10
RISCの衝撃はすごかったんだよ
だから、SunがDECやIBMから目の敵にされたんだぞ
IBM-PCはApple II対抗で本来なら8bitCPU使うところを
Z80や6809よりも高機能な8088を採用しただけでは？
もともと、16bitパソコンを作りたかったわけじゃなさそうだぞ
だから8086ではなく、8088を採用したんだろう
PC-9801のメインメモリが640KBが標準になったのは1986年に出たVM21からで
VM2までは初期状態では384KBしかなかった
1MBのアドレス空間で足りなくなったのは1980年代中ごろからなんだよな
286で68000のようにレジスタを32bit化してれば何も問題なかったんだよな
初代SPARCは性能がCISCなみのありきたりなレベルにすぎなかったと言うが……
68030より多少マシな程度じゃないの?
5～6倍の性能を出しているよ。
68030はSunでは採用例が無いので他機種の結果を引用。
CPU MIPS MIPS
System OS CPU (MHz) V1.1 V2.1 REF
### ---------------------- ------------ ----------- ----- ------ ------ ---
254 Sun 4/280 SunOS 4.1.2 MB86900 16.7 12.5 10.5 17
271 Atari Mega ST 4 MiNT/TOS1.04 68030 25.0 2.2 2.6 40
272 Atari Mega ST 4 MiNT/TOS1.04 68030 25.0 2.2 2.6 40
273 Sun 3/160C Sun 3.0 68020 16.7 2.4 ----- 0
275 Sun 3/180 Sun 4.2 68020 16.7 2.2 ----- 0
276 Sun 3/75 Sun 4.2 V3 68020 16.7 2.0 ----- 0
参考：
279 VAX 11/785 VMS ----------- ----- 1.2 ----- 0
280 VAX 11/785 UNIX 5.2 ----------- ----- 1.2 ----- 0
282 VAX 11/785 UNIX 4.2 BSD ----------- ----- 1.03 ----- 1
285 VAX 11/780 UNIX 5.0.1 ----------- 5.0 0.93 ----- 1
287 VAX 11/780 UNIX 5.2 ----------- 5.0 0.89 ----- 0
出典：
ttp://http://www.netlib.org/performance/html/dhrystone.data.col0.html 286でレジスタが32bit化されていても64kBリミットが
掛けられていたら全く意味は無いけどな。
まあにあるようにUnreal Modeが解禁されていたならば
糞面倒なEMSとお付き合いする必要は無かったと思うが。
Intelだって32bitの組み込み向けではRISCのi960を使ってそこそこ成功してたようだぞ
忘れ去られたCPU黒歴史 StrongARMの前に破れたi960
ttp://http://ascii.jp/elem/000/000/631/631450/ ARMはアセンブラでもプログラミングしやすいCPUだよな
ttp://http://pc.watch.impress.co.jp/docs/column/1month-kouza/684769.html 
ttp://pc.watch.impress.co.jp/img/pcw/docs/684/769/01.jpg 【写真1】と【写真2】は、2002年10月に行なわれたあるセミナーの資料からの抜粋だが、
1998年～2001年にかけて世代交代があったことが分かる。
【写真1】を見ると、1998年にはMotorolaの「68K(MC68000系)」が最大勢力だったのが、
1999年にはARMがこれを大幅に凌駕しているのが分かる。
ではMIPSは? というと、1998年にはARMを抑えていたのが、
1999年にはARMに抜かれ、2001年にはPowerPCが迫ってきつつある状況だった。
もっともこのARMの躍進は携帯電話、
もっと正確に言えばNokiaのSymbian OSの躍進に助けられている部分が多く、
逆にこれを除外するとARMとMIPSの勢力はほぼ互角に近かった。
16bit長の命令セットのThumbを実装したARM7TDMIかららしい
ARMの歴史 ARM1からARM7まで
ttp://http://www.cqpub.co.jp/hanbai/books/33/33291/33291_pro.pdf 自レスになるがSPARCstationを出荷した同時期に68030を採用したモデルを出していたのね。
で、その性能だがSun-3/470(68030 33MHz)で7MIPS,0.6MFLOPSというところで68020モデルの1.5倍程度
しかなく、20MHzのSPARCstation(12.5MIPS,1.4MFLOPS)の半分の性能しかなかったそうだ。
680x0が見切りを付けられたのは仕方ないと言えるな。
ある程度メモリが安くならないと使いようがなかった。
16bit命令長のthumbモードなんか出して来る頃には逆に時代遅れという有り様で。
RISCが68kの失敗が確定してからってのも、噴いた麦茶返せ級の。
パソコンとゲーム機しか知らないボウヤのまま歳だけ取ったらしい。
いまやRISCこそ時代遅れで、x86やx64命令を半ばバイトコードのように読み込みデコードしてパイプラインへ充填する86系が覇者となって久しい。
もう性能でもRISC要らないよね、ってご時世に至ってもRISC信者は「x86命令のデコーダを実装するトランジスタコストがIntelを殺す」と言い張っていたが、
それも今や熱密度を上げすぎないように、ダイ上に実装するロジックに何を詰めようか？…という時代となってしまい。
ARMは64bit化の際にバイナリ互換性を放棄したので64bitアーキテクチャは綺麗なもんだが、
そのアドバンテージがありながら性能は上がらないよねえ…どんだけ無能なの。
ttp://https://thepedia.co/article/922/ > ARMのチップ出荷台数は、148億個以上で、インテルの約40倍。
> また、ARMのマーケットシェアをみると、
> スマートフォンで95%以上、
> タブレットで85%以上、
> ウェアラブルで90%以上、
> ストレージで90%以上、
> 車載情報機器で95%以上であり、
> 半導体設計では市場を独占している。
プライスリーダーになれない薄利多売企業。
売れてるだけいいだろうに
>そのアドバンテージがありながら性能は上がらないよねえ…どんだけ無能なの。
32bitモードも使えるんじゃなかったっけ
性能は一昨年でi5がどうのと言ってたけどi5とi7って大して変わらないよね
今年は3G動作で50%性能アップだってよまあクロックアップは上品じゃ無いけどな
組み込み用途のARMの出荷数や省電力性能を持ってくるとか68k信者はプライドないの？
そのせいか、32bitの組み込み向けCPUとしてはSH（スーパーひたち）とかV800? みたいな16bit固定長命令のチップが一時期は勢力を伸ばしたが、
おくれてThumb命令を搭載したARMに食われて死滅したな
デコード部分のトランジスタコストがx86の弱点として立ちはだかっていたのは、Pen4時代頃までだろうか?
少なくともﾌﾟﾚｽｺの低速さの原因または遠因にデコードの複雑さも関わってはいただろ
ttp://www.takeoka.org/~take/cpu/endian/bit-endian.html >しかし、68000の機械語命令のビット名前の付け方から通常 想像される点の位置と、 実際に点の表示される位置が違うので、ソフトウェア屋は混乱した。
終わってる話をいちいち蒸し返すとかどんだけ悔しかったんだよ w
ttp://matsuri.2ch.net/test/read.cgi/i4004/1474548959/221-
知らないとどっちが正しい設計かなんて分らないよ。
LSBをBit0としていたと思うが。（Bit操作命令を持っていたのはZilog Z80ｂｾけだが）
その慣習がそのまま68000にも使われただけのことでその時代を知っている人間に
とってはMSBをBit0にされる方が混乱を生んでいたと思うけどな。
それとGraphicのBit並びについても間違いがあって8Bit時代では
左端はMSBとするものの方が多かったと思うが。
例えばNECのPC-8801はMSBから表示しておりそれとの互換性に配慮した16Bitの
PC-9801はCPUから見るとByte単位でMSBから、GDC(μPD7220)からはWord単位で
LSBからとなるように変則的なことをやってたぐらいだ。
（PC-8801がMSBからの表示を採用した理由は推測になるが当時のキャラクタROMが
MSBを左にしていたからと思われる。）
MSBとLSBはなんの略称だろうまあググれば出てくるか
least significant bit
最も重要なビット、最小限に重要なビット（最も軽いビット？）
最上位桁または符合を除いて最上位の桁と最下位の桁ってことだろ
例えば8bitならMSBの「重み」は128。
significant figures 有効数字
significant digit 有効数字、有効桁
って訳されてるから、意味のある、有意という意味のほうが近いだろう。
当時のキャラROMなんてUV-EPROMに焼いたものとか散々あったように記憶しているんで、
どちらかと言えば
LD (HL),80H HL:VRAMの先頭 とか、
POKE VRAMの先頭,&H80
とやってみて左から8ドット目に点が打たれるということが説明出来なかったからの様な。
より重いbitは左側に書くと学校で習い、それを4bitずつの塊で表せばダンプリストもアセンブラ
（これには例外があるかも)もCもBASICも全部MSBは左側。なのにグラフィックだけMSBは右側
って説明しずらいと思うし。
それにキャラROMからのbusとVRAMからのbusの並びを捻ればそれらがどう並ぼうと設計者の
思い通りの表示は出来るわけだし。
そもそも自分は見たこと無いんだけど、LSBファーストで表示されるプレーン方式のグラフィック
って98のGDC周り以外他にもあります？多分自分の知見が狭いから知らないんだと思うんで、
教えてもらえると目からうろこを落とせるかも。
>LSBファーストで表示されるプレーン方式のグラフィック
有名どころではSHARPのMZシリーズの80Bとか2000とかがそうだったはず。
但しX1などはMSBファーストでメーカー内で統一されてなかった。
おお、そんなところにあったとは…
一応自分でも調べてみて
>HP9000/300のモノクルフレームバッファって MSB側が右 なのか……
などというツイートを見つけてみたりしたんで、あるところにはあるんだと
認識はしたんだけど…案外身近にもあったんだ。
あ、ちなみに上のツイートの機種、PA-RISC機じゃなくてMC680x0機
だそうで、それでいてLSBファーストとか…そりゃ、ソフト屋も混乱する
なぁと。
を信用しない訳じゃないんだが、帰省したついでにI/O誌で確認。
X1 V-RAM MSBファースト/PCG MSBファースト
MZ-1500 PCG MSBファースト
MZ-2200/MZ-2500 グラフィック周りがゲートアレイ化されていて回路図からは読み取れず
PASOPIA LCD出力はMSBファーストっぽい/CRT出力は信号名が追えず不明
肝心のMZ-80Bは回路図を発掘できなかったものの、掲載されていたプログラムの
グラフィック表示データを見たところ、表示パターンが左右反転されていたのでこれを
以て確認できた。
同じ事業部のMZでも、プレーン方式グラフィックはLSBファーストなのにPCGはMSB
ファーストとか、どうにも統一性の無い印象。以上脱線終了。
性能が低いからまともには使えない、という論法が有効ならx86もまともに使えるようになったのは486以降もしくはPentium以降だな
386以前はwindowsが実用的には動かないから実用的なCPUではなかった
って何年前のレスに文句言ってんだオレ
ただでさえレジスタ数が少ないx86でレジスタペア使ったらレジスタがすごく足りなくなるだろ
つまり68kのメリットはレジスタ長ではなくレジスタ数だ、アドレスレジスタもあわせて16本もあったからな
まあ、アドレシングモードの複雑さと相まってクロック向上の妨げになったネック機能でもあるが
一次キャッシュに限っては命令データ分けるのが大半だろ
今じゃ二次キャッシュでも分けてるのが増えてないか
PPC601とか486みたいな命令データ分けてない一次キャッシュが懐かしい、遺物的な意味で。
16kbitや64kbitと違って品目が少ないけど、ないわけではなかったはず
D-RAM だとアドレスが奇数になって半端なんだけどあったっけ？
ちょっとググった範囲じゃ見つからんかったけど、型番わかる？
MCM6662
MCM6663
MCM6632A
MCM6633A
いずれもMotorola
あたりが手持ちの古い規格表に載ってる
同じくハンパ容量品で8Kビット128kビットあたりも少数ながら存在してはいるし、マイナー品とは言え存在してはいたんだろう
その型番で思い出した
に書いてあったからググったけど詳細わからなかったんだわ
多bit品だともっと面白いものがあったりする。16kx4bitの品種でTMS4416なんかは
14bit分のアドレス入力があればいいのでA6-0がパッケージに出ていると思われがち
だけど、実際にはA7-0がアサインされている。
アドレスをどう分割して入力するかというと A7-0にRowアドレス8bitを入力し、A6-1
にColumnアドレス6bitを入力する。
TMS4416は4msで256Rowアドレスのリフレッシュなので内部は本当に256Rowアド
レスの構成のようだが、互換品と目されているMB81416なんかは2msで128Row
アドレスなのでちょっとだけ注意が必要。富士通製の方の内部は128RowX128Column
で構成されているんだろうね。64kx1bit品と同じリフレッシュ回路が使えるけど、
センスアンプの台数が倍になるからコスト的にキツイよね。
もう少し容量が増えてからは同じじゃない方が主流に変わらなかったっけ？
無茶をしている部分もあったんだよね。
だから使うpin数が最小になるようRowアドレスとColumnアドレスが同数になるI/Fとしてきた
わけなんだけど、実は64k世代でそれはすでに壊れ始めていたんだよ。
大抵の64kx1bitのDRAMって2msで128Rowアドレスのリフレッシュというのが仕様でしょ。
でも、Rowアドレスって8bit入力してRASをストローブしてるよね？これじゃ全Rowアドレスの
半分しかリフレッシュしていないことになっちゃう…実は、RASでストローブしている内の
1bit、A7に入力したアドレスは内部でColumnアドレスを先行して与えられたものとして
ラッチされていて、Columnデコーダーへと接続されているんだよね。
なので内部は (等価的に)128RowX512Columnという構成になっていたりした。
中にはTIみたいに4msで256Rowアドレスリフレッシュみたいな256RowX256Columnって
いうメーカーもあったけど少数派で、4116世代と同じリフレッシュ回路が使えますということ
をウリにして大多数のメーカーは変則構成の方を選択している。もちろん日本メーカーは
全部そう。
1Mbit以降は16pinDIPの枠に収めようが無くなったし、パッケージもDIPからZIPさらにはSOPと
多pin化が進んだので色々と自由になったと。多bit品が主流にもなったし。
さらにSDRAM世代まで進めばbit幅は色々あったにせよ 128Mbitとか512Mbitみたいに4の
n乗とかもあまり気にしなくなった。
複数命令に展開しないといけないマクロ展開ものの命令が、それも一部の専用レジスタ向けにあるだけだろ
あ、マイクロOPを再パックできる組み合わせじゃなくて複数マイクロOPsになるレベルのやつね
LEA r32, [r+r*8+disp8]って結局1clockで演算できるようになるし。
メモリオペランドをディスティネーションにすると確実に複数のマイクロOPsが必要になる
x86の欠点はプレフィックスバイトだらけで命令のデコードがとても大変なこと
CISC CPUの中でもダントツに命令のデコードが大変
RISCでもARMはアドレッシングモード豊富だよ
プレインデックスやポストインデックスなんてのもあるし
スケールインデックスみたいな機能もある
ARMは64bitになって性能重視に変わってレジスタは31本
命令も32bit固定の命令セットのみになった
ただ、インデックスとして使えるレジスタもしくが1個増えて
disp+R+R*4みたいなのが出来るだけ
ARMでも
R+R*4みたなのとかdisp+Rみたいなのはできる
逆にレジスタ間の演算は3オペランドなのでディスティネーションを破壊せずに演算ができる
レジスタが多い場合は3ぺランドの方がmov命令を省略できるので効率がいい
また、ARMではx86にないポストインデックス、プレインデックスがある
ttp://http://pc.watch.impress.co.jp/img/pcw/docs/684/769/html/01.jpg.html ttp://pc.watch.impress.co.jp/img/pcw/docs/684/769/01.jpg 逆にレジスタが少ないくせに3operandだとレジスタ不足でmove命令ばかりになるよな
かといってメモリオペランドは最適化時に遅くなりすぎる、ぜひ避けるべき代物だし。
2年半前の記事か
いまじゃ68kコアの製品そのものがラインナップから消え去ってるよな
68k後継らしい、一部の命令が違ってるcoldfireも、すでにほぼ消えてるはず
今は組み込み向けはARMの勢いがすごいな
2000年代はMIPSも結構健闘しててNECや東芝もMIPSの組み込み向けチップを作ってた
NECはルネサスと合併して、今のルネサスはARMもやってる
東芝もARMになった
PowerPCをやってたFreescaleはNXPに買収されてメインがARMになって
そのNXPもQualcommに買収された
今、組み込み向けのプロセッサ作ってる半導体メーカーでARMやってないところは少ない
ttp://https://www.cisco.com/c/ja_jp/products/switches/catalyst-9500-series-switches/index.html YAMAHAのルータのCPUはここで公開されてる
ttp://http://www.rtpro.yamaha.co.jp/RT/hardware/cpu.html 8086は64KBのセグメントの壁があったから大きなデータを扱うのは苦労したけどな
最近のCPUは命令数多すぎ
64bitのARMとか整数命令だけで200以上あるし、
MIPSの新しい命令セットのMIPS64R6は整数命令だけで300以上ある
OSに乗っかるプログラムなら生半可なアセンブラコーディングよりC言語他で作ったほうが良いコードになりそう
Huge modelで64K超えたプログラムと配列。
リアルモードからプロテクトモードに移行して短時間使用すること自身はさほど難しくは無い。
ところがプロテクトモード中に割り込み許可をしてリアルモードでの処理を実行させると
とたんに技術的ハードルが高くなってしまう。
まあ実際にはそれらを実現してくれるDOS-EXTENDER環境を使えばそんなことを意識する
必要がなくなったわけだが商用では実行環境，開発環境共にコストが馬鹿高く、
またMicroSoftがDOS環境では提供しなかったこともありFM-Towns以外では一般化することは無かった。
（Windows 3.xも広義にはDOS-EXTENDERの一種であるが）
ホビーユースでは実行環境ではKMCのEXE386評価版とかDJGPPのGO32で、
開発環境はgccを移植して利用するされた。
マイクロソフトが困ってCPUをリセットしてリアルモードに行けるようにしたっけ。
286はプロテクトモードからリアルモードに戻るにはリセットするしかない。
非公開の全レジスタsave/load命令を使って状態を保存してリセットして
リアルモードを実行してまたプロテクトモードに戻った
車のギアを変えるのに毎回エンジンを止めるようなもの、と言われた
68000のようにレジスタを32bitに拡張して
32bitオフセットを使えるようにすればよかったのにね
そうしてれば、みんなが幸せになれた
8086の実装は8086が出たあの当時としては最適だったのだろうけど
286が普及した頃は68000のような32bitもどきの16bitCPUが必要だった
68000シリーズも68000を高速化した16bitの後継を作るべきだった
1986年頃にはパソコンに32bitCPUはまだ早すぎた
68000は遅すぎたんだよねぇ。
まぁ8086とほぼ同時期のCPUだから当たり前なんだけど。
68020が高値止まりだったのが痛かった。
68EC020辺りをモトローラがもっと戦略的価格まで値下げしてくれれば移行が進んだのになぁ。
それよりは長生きしていた組み込み系68000もARMに取って代わられて終わっちゃったね
扱いやすくて良かったのに性能の伸び悩みや価格の高さ等で駄目だった、惜しい
386bsd、linuxの登場で瞬殺、駆逐された記憶しかない。
最終的には駆逐されたけど
386を載せたPC-UNIXがおもちゃ扱いから脱却するのには結構な時間がかかったし
そうなる前のワークステーション全盛期だって長い
68000が急速に価格低下したのはSEGAのメガドライブのおかげだが
68020以降のMPUに価格低下を起こさせるにはワークステーション市場での
シェアを失った状況でMACとAMIGA,ATARI ST等の販売量に求めるのは出来ないだろうな。
授業中に課題のコンパイルが終わらないから、紙にコード書いて提出とか。端末の体感速度は8bit機以下。
隣は同じNECの486国民機の部屋で爆速すぎて、EWSは遅い、不安定、使いにくいで、みんなブチ切れてた。
時代の流れの渦はすべてIntel中心と感じたね。これがあの時代の現実。
それプロセッサのせいじゃなくてメモリーのせいだろ
いつの時代のEWS4800使ってたのか知らんけど1990年くらいでも最大32MBとかふざけた仕様だったし
一方の486マシンのPC-UNIXは何十人も同時ログインして使ってたのか？
まさか1人で独占してたのと比較して言ってるなら笑うが
将来のロードマップも示して達成してきたから
他社は敗北した。
32bit命令は1から仕切り直しだし、16bitと行き来する仮想86モニタを書くとかでもない限り
フル32bitの環境なら16bitモードなんてブート時にやっつける程度しか触る事もない。
しいて言えば同時代のRISC系と比較してレジスタ数が少なすぎるのが致命的だｵﾜﾀと貶された程度。
もちろんパラメータなんぞレジスタに載らなきゃスタックに積んで渡すだけの話だし、
コンテキストスイッチの度に何十本もあるレジスタをいちいち退避するコストと比べたら身軽なもんだ
リーナス君が一人でしこしこPOSIX互換カーネル書けるくらいだからな
むしろx86系は64bitがひどいよ。AMDの仕業なんだけど。
32bitバイナリにprefix置くだけでAMD64を謳う、汚ねぇ命令作って残したから。
まあそれも今はx86-64バイナリはバイトコードみたいに読んでμopに分解してパイプラインに充填するという
優秀な命令デコーダを開発したことで、命令密度が高くコンパクトな実装となって並み居るRISC陣営を蹴散らしてしまった訳だが。
10年くらい前までは、「その命令デコーダのトランジスタコストがIntelとx86を殺す事になるだろう(ｷﾘｯ」みたいな事言うアナリストとか居たんだぜｗ
まあ今にして思えばまだまだ熱かったけどなcore2アーキテクチャ。
386でもプレフィックスが汚いと思う
同じ命令でもオペランドレジスタが違うと命令長が変わるとかムチャクチャじゃね?
68020積んだアーケードゲーム基板も少ないけどあったんだよねー
68030と68040のACゲームはなかったかな
にでもするしかなかったんじゃないの?
それだったら、IA32e拡張命令モードとIA32旧型命令が混在できない制限はあっても大した制限とは思えなくなる気がする
色々突っ込みどころが多くて目移りするんだが
>RISC系と比較してレジスタ数が少なすぎるのが致命的だｵﾜﾀと貶された
>むしろx86系は64bitがひどいよ。AMDの仕業なんだけど。
ボロクソけなしているAMD64のおかげでR8～R15が増設されたんだが、ご感想は？
>コンテキストスイッチの度に何十本もあるレジスタをいちいち退避するコストと比べたら身軽なもんだ
指摘したR8～R15も含め64bit長レジスタ16本を退避するコストについて一言どうぞ
それと、128bit幅もあるxmmを最低8本退避しないといけないことについても一言
ymmが使える環境だとxmm部分だけじゃなくymm全体を退避しないとダメだよね？だとしたら256bit幅の
ymmを16本退避する必要が出てくると思うけど、これについても一言
ああ、忘れるところだった、きっとmmxレジスタ 64bit長8本も退避しないとダメだよね？これについても一言どうぞ
>32bitバイナリにprefix置くだけでAMD64を謳う、汚ねぇ命令作って残したから
まぁ言いたいことは判る。
ttp://www.atmarkit.co.jp/ait/articles/1007/01/news131_2.html ここに例として挙げられている64bitコード(メモ帳というのが泣かせるが)の比較を見ると32bitコードは1,2バイト
コードが結構頻繁に使われていてコンパクトな印象、一方64bitコードはREXのせいでまずは3バイトからという
雰囲気。
この頃(今もかなぁ？)のIntelCPUの1次命令キャッシュと命令デコーダ間のBusは16バイトしか幅がないので、
REX分の1バイトが地味に痛い。それにこれだけ7バイト以上の命令が頻出したら同時にデコード出来るx86命令
の数が少なくなる。つまりここがボトルネックになりかねない。
その後段に比較的大きなμOPキャッシュがあるので悪影響は低減されているけれど、あまり嬉しい状況じゃない。
>命令密度が高くコンパクトな実装
これが何を指しているのかいまいち不明。
そう無茶苦茶にも思えなかったり。
昔、Yレジスタを使うと多くの命令でプリフィックスが付く関係上Xレジスタを使うより1バイト
プログラムが長くなり、かつ実行時間も1クロック分遅くなるって環境を経験してるからそんな
もんかなと…
その頃はYレジスタの方が頻繁に使われる状況に陥ったらソースを遡ってXレジスタとYレジスタ
を入れ替える作業が発生したけど、今はそんなのコンパイラの仕事だから気にしなくていいかと。
ちなみに、今現在でもその「ムチャクチャ」な環境は拡大を続けているという
ttp://www.wdic.org/w/SCI/VEX%E3%83%97%E3%83%AA%E3%83%95%E3%82%A3%E3%83%83%E3%82%AF%E3%82%B9 一番下の「最適化の余地」の項を参照
>ボロクソけなしているAMD64のおかげでR8～R15が増設されたんだが、ご感想は？
386には関係ない
386当時と比較すればメモリもメモリバスも何倍も速い
64bitRISCだと30～120本もレジスタ持ってるのがザラで64bit環境でもx86はレジスタ数が少ないとまだ粘着される（実害は無いが）
>指摘したR8～R15も含め64bit長レジスタ16本を退避するコストについて一言どうぞ
>それと、128bit幅もあるxmmを最低8本退避しないといけないことについても一言
>ymmが使える環境だとxmm部分だけじゃなくymm全体を退避しないとダメだよね？だとしたら256bit幅の
>ymmを16本退避する必要が出てくると思うけど、これについても一言
>ああ、忘れるところだった、きっとmmxレジスタ 64bit長8本も退避しないとダメだよね？これについても一言どうぞ
繰り返しになるけど、メモリも当時と比べりゃ速いしCPUにも広大なキャッシュメモリが内蔵されるのが当たり前になっているので
レジスタ退避に無駄にサイクル数食うよりそこそこの本数でパラメータはスタックに積んで渡す方が速くね？って読みは正に現代向け
そしてこれも繰り返しになるがx86-64は「同世代の」他社64bitと比較すればSIMD系のレジスタ数も少ない方
まあ馬鹿なフリして386とx86-64比較して「色々突っ込みどころが多くて目移りするんだが」なんてイキっちゃう程度だと
こうして馬鹿はフリじゃなくて本当に抜けてるだけだったと証明されて終わりだな。マゾなの？
3～4GHz動作が当たり前でオンダイで数メガバイトも二次・三次キャッシュの載った環境で
必要十分なレジスタ数で必要なパラメータだけスタックに積んですぐオンキャッシュで拾えるスマートさはもはや比較にもならんな
「色々突っ込みどころが多くて目移りするんだが」君はたぶん比較的新しい環境しか知らなくて
古い環境が実際にどうだったかを想像することができないのだろう
まあそんなことに想像力と時間を費やすのは無駄としか思えないが、ここは昔話をする場所なのでね
昔どうだったのか知らないなら、下唇噛んで膝抱えて黙ってろ、って事ですよ
>古い環境が実際にどうだったかを想像することができないのだろう
その割には最新の環境も想像することができないようだし、まあ何もかもが半端だな。それがこいつの限界。
話の前提がメチャクチャだからな
安いEWSなら200万以下で買えたのに何故何十人で共有しないといけないのかとか
486がPC-98のメインに下りてきたのが1992年
無料のPC-UNIXが出てきたのが1994年から1995年くらい
Windowsパソコンは95年のWindows 95が出てくるまで
何故パソコンは最新のものでEWSはそうではないのかとかあるし
C言語の授業でCUIのプログラム作成ならUNIXの方が自然に使えるし
プログラミングに関しては64KBのセグメントの制限を受けたからプログラミングの授業では使いにくかった
EWSをパソコンが凌駕しだしたのはPentiumマシンからだし、Windows NT 4.0が出てからだしな
ちなみにうちの学校ではうちの学科だけで120台のEWSを導入して1人1台で使ってたぞ
× Windowsパソコンは95年のWindows 95が出てくるまで
○ Windowsパソコンは95年のWindows 95が出てくるまで64KBのセグメントの制限があったし
しかも最大64KBのセグメントの制限があったので64KBを超えるデータは
複数のセグメントに分割しないと扱えない状態だった
Windowsがプログラミングの授業で使えるようになったのはWindows 95以降だろうな
そして、あの頃はインターネットが持てはやされててUNIXの知識が必須だった
インターネットのプロトコルのTCP/IPはUNIXではBSDで始めて実装されて
他のUNIXにも広まった経緯があったのでインターネットはUNIXと一緒に発展してて
インターネットの技術はUNIXに支えられてた
TCP/IPのプログラミングでよく使われるsocketはそもそもBSDのプロセス間通信で使われたもので
それを拡張してTCP/IPでも使えるようにしたものでBSDが発祥
パソコンLANが使われるとしても
当時はNetwareが多かったのでTCP/IPよりもIPX/SPXの方が主流だった
日本ではWindows 95が出るまでのパソコンはLANとは無縁の状態だったし
TCP/IPのソフトウェアも高価だったし、Ethernetカードとかも数万円した
Windows 95が出てからやっと1万円くらいで買えるようになった
1992年にIBMははじめての赤字を計上、DECも大幅な赤字決算を計上
UNIXが大型コンピュータの領域まで侵食していった
おそらく、2000年のITバブル崩壊はWindows 2000が出たので
UNIX企業であるSunやHPが大打撃を受けてITバブルが崩壊したのだと思う
(COMPAQを買収したHPはPC企業でもあったのでそれほど打撃は受けてない)
実際、Sunは2000年以降、赤字続きで最終的にOracleに買収された
Windowsがサーバ分野でUNIXの代わりに使われ始めたのは
Windows 2000 ServerやWindows 2003 Serverからで
Windows 2003 ServerではAMD64対応の64bit版も出てたし、
Opteronがサーバ分野で売れてた
するんでもなけりゃ本体価格8桁の高性能サーバなんて予算下りなかったんじゃねーの?
それに、上のほうに「コンピュータなんざ」なんてのが居たりしたら猶更。販売側ですら「安く上げ
たいからってそりゃねーよ、こんなのサポートしたくねーな」って思うようなユースモデルを平気で
圧し通しちまって後でどうしようもなくなると。
なぜか批判がAVXになってるという本末転倒な話になってるな
x86の64bitは32bitにないプログラムカウンタ相対アドレッシングをねじ込んでるところが面白いね
Linuxでは共有ライブラリはPIC(ポジションインディペンデントコード：位置独立コード)にしないといけないので
このプログラムカウンタ相対アドレッシングを多用してる
あと命令コードが長くなるというがx86はdispに使えるのが8bitと32bitで16bitdispがない
dispが8bitの範囲にないといきなり32bitのdispが付いて命令コードが長くなる
RISCだとSPARCが13bit、MIPS、PowerPCが16bit、ARMだと12bitのdispが使える
これらのdisp内に収まる場合、4バイトの命令コードでレジスタ間接のロードが可能
ARMだとさらに2つのレジスタ間接インデックス側のレジスタを自動的に加算、減算が可能な
ポストインデックスやプリインデックスアドレッシングがある
3オペランドでデータを格納するレジスタを指定できるので余計なmove命令が少なくて済むし
レジスタ数も多いのでRISCが有利
x86はレジスタ数が少なく、メモリとレジスタ間での演算をするのに向いた命令セットで
レジスタ間のみで演算するのには向いてない
自分のアセンブラ知識は8080 Z80 68000 8086までだ。
ああ、386についてですか。にしてもコンテキストスイッチってw 80386で？
随分とニッチなところで勝負を挑みましたね。
「6502はレジスタ少ない」って貶されて「うるせーコンテキストスイッチは
超速だ」って返しているみたいで微笑ましいです。
まぁいいでしょ。386で思う存分コンテキストスイッチの性能をRISC陣営に
見せつけた環境と言えば Sun386iでしょうか。1988年登場だそうで、その
前年にはSPARCに移行したSun4シリーズが登場していますから、Sun386i
は充分その高性能()でSPARC機を圧倒したことでしょうね。
特にレジスタウィンドウなんてものを持つSPARCには効いたはずです。
しかし、Sun386iのラインは1990年Sun486iが少量出荷された段階で消滅
しました。コンテキストスイッチ性能でSPARCを圧倒していたのに！
まぁ古い環境というか386なんて自分では持っていなかったし、速い8086
として使われる様子しか見てないから興味も無かったのは確かですよ。
唯一ある思い出としては、先輩が中古で買った激安386SXノートのCPUを
隣の作業台で楽しそうにCX486SLCに張り替えている情景くらいかな。
ああいうのは羨ましかった。
とっくの昔にインテル圧勝で終わったというのに。
Win95以前は64KBセグメントガーってのもニワカ丸出しだな
GO32(DOSエクステンダ)環境でGCCで32bitポインタ駆使してフーリエ変換のコードとか書いてましたよ
無知な奴に限って、てめえの限界を当時の限界と疑いもせず騙るから困る。
決定的になるのはNT3.51とPentiumProの登場。
PenProは今でいうXeonの先祖。
コンシューマしか知らないアホ共には失敗作CPU扱いされるが、
21世紀に入ってもまだPenPro鯖が運用されていた組織は珍しくない程の名CPU。x86躍進のマイルストーンともいえる。
97～98年頃になってLinuxやFreeBSD等のFreeUNIX系の実用化が本格的に進み始めたのも追い風。
ともかく、これで32bitのRISCワークステーションは片っ端から駆逐されて行くことに。
2000年から赤字に転落したというSunやSparcはよく踏み止まって善戦していた方で、
PenProの登場を期に32bitを捨てて64bit環境へ退避しなかった所は、軒並み21世紀を迎える事なくx86に狩られた。
opteronが売れた？xeonはその何倍も売れてましたよ。なぜ語らないんです？AMD信者だから？その口でAMD嫌いガーとか言うっちゃう？
まあ昔からこういう奴らだよAMD信者は。平気で嘘ばかり垂れ流す屑共だ。情けなど掛ける必要もないから、こうしていくらでも殴れる
DOSエクステンダーを採用して32bitネイティブな環境を実現してたから
DOSエクステンダーの存在をこの板では知らない人はいないはず
ただ、TOWNSは流行らなかったし、
他の機種ではDOSエクステンダーは高価でソフトもほとんどなかった
32bitネイティブな環境がほしいだけならTOWNS買うのが一番安かっただろうにね
97年だとHPがWindows NTのワークステーションを全面出してに宣伝してたな
HPといえばSunとUNIXワークステーションやサーバでトップ争いをしてた企業
97年にはUNIXワークステーションは完全に駆逐されてたな
97年頃には企業でも2000年問題対応も含めてオフコンだった端末のWindows NT4.0への入れ替えも進んだ
95年にWindows 95が出て、Windows 95がプレインストールされてたパソコンには
それまで高価だったPentium 120MHzやPentium 133MHｚが搭載されてた
Windows 95にはTCP/IPプロトコルスタックが標準で実装されてたので
TCP/IPによるLANも普及
LANでは100BaseTXが普及し100BaseTXのLANカードやHUBも低価格になった
個人向けではWindows 3.1の頃はDOSゲームばかりでWindows対応ゲームは少なかったが
Windows 95がDirectXを実装してたのでWindows対応ゲームが一斉に出た
94年頃はまだPC-98やDOS/Vでは32bitは早すぎて雑誌に付属したCD-ROMを見せると
12800円でWindows NT 3.5が買えるキャンペーンをやってたが
Windows NT 3.5を動作させるにはメモリが16MB以上必要で16MBのSIMMが6万円とかしてた
95年にパソコン業界が一変したんだよな
486の時代までx86系CPUは実質早い286として利用されてた
実際は386以上じゃないとEMM386とかのメモリドライバが使えずにUMBが使えなかったり
386以上のCPUにしか対応しないソフトも多かったが
アプリは16bitのプロテクトモードで動作してたからね
95年とそれ以前とはx86を取り巻く環境が全く違った
Windows 95がプレインストールされたパソコンにはPentiumが搭載され
486パソコン用には486からPentium 83MHzに差し替えられる
Pentium Overdriveが3万5千円くらいの当時では低価格で販売された
PentiumマシンにはPCIバスが使われ、
それまでの486のバスの規格をそのまま使ったローカルバスは一気に廃れた
x86パソコンで64bit Windowsがプレインストールされ始めたのは2010年頃
Windows Serverは2008年に出たWindows Server 2008が最後の32bitのWindows Serverになった
AMD64が出てなかったらもっと遅れてただろうな
AMD64版のLinuxも安定しだしたのは00年代終わりごろ
IntelはIA-64を推進してて、x86の64bit対応は後回し
IA-64を推進してた手前、x86の64bit対応を進めるわけには行かなかった
AMDはIA-64に移行されてしまったら互換CPUを作れなくなるので
AMD64はAMDにとって背水の陣だったんだよな
結局、IA-64はHPのHP-UX搭載のサーバでしか相手にされなかったようだが
64bitでは命令フォーマットを変えるべきではあったな
x86の命令体系はプレフィックスバイトばかりで非常にデコードしにくくなってるからね
最初の1バイト目を見ただけで命令の長さやフォーマットが決定するようなものに変えるべきだった
ARMは64bitで命令を一新したが32bitと全く異なる命令というわけじゃなくて
32bitと64bitを同時に実装しても無理の出ない範囲での変更に留めて移行に成功した
AMD64はもしAMD64が普及しなかった場合、AMD64の実装コストが負担になることを恐れて
最小限の変更に留めたんだろうけどな
Windows NTも元DECの人たちが中心になって開発された
元DECの人間同士で人脈もあったんだろうね
だからマイクロソフトはx86の64bit拡張としてAMD64を採用した
AMDはMSの手抜きしたい衝動を旨く利用してamd64を設計し勝利したのだ。
x86が互換性重視で勝利し続けてたのを忘れて、市場が見えないRISC技術者の口車に乗って
インテルはIA64という愚行をしてしまったのだ。
結局、μOPsに変換して実行し、
尚且つ内部でμOPsをキャッシュして再利用してる今のx86のようなマイクロアーキテクチャなら
よほどおかしな命令セットでなければどんな命令セットでも一緒だからね
重要なのは回路設計で如何にして設計費用を回収するかという方が重要
ある程度エコシステムが確立したものだと互換性維持が最重要視される
>32bitネイティブな環境がほしいだけならTOWNS買うのが一番安かっただろうにね
1990年10月まではその通りだが同月末にKMC(京都マイクロコンピュータ）がPhar Lap
互換のDOS-EXTENDER EXE386評価版をリリースした時点で状況は変わってるよ。
この時期にはFM-Towns Userが中心になって開発された移植版GCC（通称Towns gcc）が
既に存在していたのでFM-Towns以外にも急速に広がるものと見られたが、1ヶ月後の11月末に
開発グループから自主企画のGNU CD-ROMが販売されるまでの『GCCのBBS間転載禁止』
宣言が行われ、PC-VANやASCII等では大炎上，反発が広がりNIFTY以外のBBSではUserが
離反する形になってしまった。
しかも皮肉なことにこの後91年2月にアメリカでDJGPPがリリースされ、それが国内に
入って来て4月末にはPC-9801に移植されBBS間で転載された。
（移植者は実はPC-VANでの炎上時の批判者の一人）
GNU CD-ROMは当初春頃の予定だったが夏までリリースがずれ込みその告知が
されたのとほぼ同時期にソフトバンクのCマガジン誌が2周年記念としてDJGPPの掲載を
発表、FDで配布して一般的な知名度を確立させ、両者はこの後93年ぐらいまでは並存状態になった。
まあTowns gccとDJGPPの関係を見ると結構どろどろした黒歴史を見ることが出来るよ。
（特にCマガが出た直後のNIFTYとか）
さすがにPentium時代だとローエンド鯖での使用に耐えられる下限には入った程度じゃなかったか。
PentiumPro時代でも、互角に近い戦いができる性能を手に入れたとはいえ置き換えまではいかなかったし。
その頃のHPはすでに、次期CPUの独自開発を諦めてItanium開発に社運をかけてた時代のような?
その一環として他社より先駆けてWinNTのワークステーションを積極的に出したとかじゃないの?
Win95時代になってWindows対応ゲームが一斉に～ とはいっても、本格移行は97から98年頃になってからでしょ。
当初はWin対応版も出すけどまだDOS版メインって感じで、よくて両対応、まだまだDOS専用も多かった。
Win95 OSR2からWin98あたりにかけての時期が本格的な転機で、Win95の初期は、まだまだだったと思うよ
486マザーボードでもVLじゃなくPCIを積むのが主流になってVLバスが消えた頃だったかな。
その直前までは、PentiumマザーボードでもVLバス搭載モデルが少なくなかったから、ホントに一気に変わったね。
（本来は486のCPUバスを単純延長しただけのようなVLだけど、PentiumにVLバスを使わせるための変換用チップセットが出回ってたんだよね）
Visuaｌ C++ 4.0のStandard版は当時の開発環境としては高くなかったし
Win32が扱えない人でも32bitネイティブアプリをお手軽に開発できるDelphiの32bit版が1996年に出てる
Win32のアプリ開発も簡単なアプリ作るくらいならそれほど難しかったわけじゃないし
プリエンプティブなマルチタスクとスレッドが使えるようになったのでかなり便利になった
IA64で失敗した頃までは、Intel自身も少なからぬ数の失敗作品を世に出してきたじゃん。
i860とかi432とか、いろいろとさ。
それに当時はまだ、RISCへの切り替えを進めないと負けるかもという懸念がIntel側にあってもおかしくなかった時代だ。
結果だけ見てIA64を貶すのは考えものだよ。
μOP変換を前提にするなら、内部アーキテクチャをIA64にして実名零セットはx64なんてのも可能と言えば可能だし、
逆に熱湯にIA64命令用デコーダ付けて両互換CPUとかも可能ではあっただろうな。
実際には出なかったけど。
Win GとVideo for Windowsで動作するやつ
Windows 3.1用のゲームは当時はめずらしかった
VMware上のWindows 98でも起動オプションを正しくしていして起動すれば動くｗ
当時、16bitの開発環境としてはBorland Cの3.1とDelphi
32bitの開発環境としてはVisual C++ 4.0 Standardを持ってた
試してみたらWindows 3.1用のアプリのコンパイルとIDEを使うだけならVMWareのWindows 98でもできる
TurboDebuggerは起動するとフリーズするけどｗ
簡単なWindows 3.1アプリを作ってコンパイルしてみたらWindows 98上で動いたｗ
結局、Windows 95が出る前にお手軽に32bitプログラミングができたのはX68000だったんだな
と思ったが違った、16bit用のか。
まあWin95自体が、できるだけWin3.1用アプリも修正ナシに動くよう努力して作られたと言うし、非互換部分をわざわざ使おうとしない一般アプリは動くものだったんだろうな
X68000はフリーウェアのGCC使ってたからXCについてはよく知らないんだよねぇ
の発言見るとTOWNSがいまいち盛り上がらなくて
X68000が盛り上がってたのはコンパイラの問題もあったんだね
68000は扱いやすい32bit CPUって内容だったしね
性能は8086よりは良い位だしモトローラ自身16bit CPUとして売ってたから32bitだと強弁する気は無いけど
もしかしたらもう少し違った展開もあったかもしれないよなあ
さすがに2010年代まで生き延びることはないにせよ。
コンパイラの問題というより開発グループの方針の問題。
当時の状況は非UNIX環境で初めにgccの移植に成功したのがX68K版gccで
1989年にリリースされておりXCの置き換えとして使われていた。
Cマガ1991年3月（ソフトバンク）のRMS(Richard.M.Stallman)のインタビュー記事の掲載と一緒に数回に
亘って配布され、また活用研究として連載もされ、その後記事をまとめた物が書籍になっている。
FM-Townsでの移植はそれに追従するように試みられ、早くもTheBASIC90年1月号（技術評論社)には
gccの記事が確認されており、結構早い段階でフリーソフト配布団体JUG-CP/Mや
技術評論社関連企業のビレッジセンター直営店とかで販売配布されていた。
（これ以外にもgcc移植グループの記事は関連雑誌に掲載されるなどしている。）
このような状況下で突如の配布制限宣言が行われた。
(長文なのでUploaderを指定してくれたら当時のBBSログからの当該メッセージをUpするよ。）
> 21世紀に入ってもまだPenPro鯖が運用されていた組織は珍しくない程の名CPU。
Pentium Proは1995-1998に発売されてる
サーバー買っちゃったら５年程度は最低使うから21世紀でも使ってるのは当たり前
名CPUとかアホすぎる
だが違うんだよ。過去を切り捨てただけなんだよ。だから誰もついて来なかったんだ。
プログラマのドリームマシン。
最近ネットとかで調べるとamiga凄いよね
あの時代にあの内容とかオーパーツじみてる
当時の学校系のコンピュータ部になら1台位は貸し出していたな。
大学だとニフティの課金は無料だったよ。
freeBSDじゃなくnetBSDが移植されてた気がする
X-Window systemを動かすためにピンを1本断絶させたり
書籍+CD-ROMの形で販売もされました
ログの抽出が完了したのでUploaderに上げた。
配布制限告知文が
ttp://https://www.axfc.net/u/3858386 それで発生したPC-VAN炎上記録が
ttp://https://www.axfc.net/u/3858387 共にDLKeyはgccです。
あとこの炎上を受けて書かれたと思う開発者のコメント文が
TheBASIC 91年3月号に掲載されているのでPDFをUPすることも
考えたのですがさすがに書籍のUPはまずいと判断して見送っています。
この辺の一連のごたごたでTowns GCCは事実上NIFTY限定となってしまい、
その影響かとは思われるがDJGPPやEMX（OS/2ベースのDOS-EXTENDER，DOSでも使用可）
が現在でもVectorとかで入手できるのにTowns GCCは辛うじて個人HPで保存されている
という形で状態になっている。
Townsでの移植はBSDではなくLinuxだったと思うけど。
X68030のBSDはMPU交換必須。
まあMPU交換をしないですむMINIXの移植例もあったはず。
もう、その頃には日本では68000系のCPUは完全に勢いをなくしてたのでは？
PC98、DOS/Vでは完全な32bitのWindowsのWindows NT3.5が1994年に出たし
DOS/VやPC98では486が一般的になって68030のX68030では性能では太刀打ちできなかっただろうしね
MacintoshもPowerPCに移行したのもその頃だったはず
DOSのゲームに興味がなく、尚且つ16bitのWindows3.1が嫌な人はMac買ってたんじゃないかな
Power Macintosh 6100は価格もMacintoshとしては手ごろで結構売れてたはず
1994～1998年頃ってアマチュア界でX680x0めちゃくちゃ勢いがあったよ
さすがにそのころにはX680x0はかなり末期だよなあ。Oh!Xのムック版移行よりあとか
PowerMacはNT3.5と同じく94年だよな
freeBSDの98移植じゃない本家が本格稼働したのも94年リリースの2からだっけ。（リリース1は93年だけどライセンス問題で配付できなくなったし）
その勢いを100としたら、DOS～Winの勢いは1億ぐらいなんだよ。
それまでのx86の最大の欠点であった16bitモードのセグメントの64KBの壁が取り払われ
また、Windows 95の時代はPentiumが主流になり性能面でもRISCに対抗できるようになった
486ユーザー向けにもPentium Overdriveという486や486SXと差し替えできる
83MHzのPentiumが3万円くらいで販売された
プリエンプティブなマルチタスクとスレッドが使えるようになって
尚且つ、TCP/IPが標準装備になりLANが普及した
Windows 3.1までは多くの欠点を持ちながら仕方なく使ってた部分もあったが
そういう欠点がなくなりUNIXやMacintoshがあこがれの存在ではなくなったな
むしろメモリ空間だのマウスだの、ハード環境だけが自慢でソフトがないX68K、Macがなんとも哀れで惨めに見えた。
PC98のメリットがなくなってやっていけなくなりNECも98NXというDOS/V機に切り替えちゃったな
すべてがWindows 95で変わった
286の設計の悪さが原因
286が68000のようにレジスタを32bitにして
16MBのメモリをリニアに使えるように設計してあれば何の問題もなかった
286はトランジスタを134,000個も使ってるのにあの状態
68000の倍くらいのトランジスタ数
386は32bitなのに275,000個しか使ってない
市場はまだ速い8086を求めていた。386が出てもDOSソフト全盛時代が続いたから
32bit化してもほとんど使われなかった事実をそろそろ認めないとな。
あそこでIntelが過去を切り捨てて完全32bit化してたら
同じスタートラインで68Kにも勝機はあったかもしれないな。
386を搭載したパソコンは100万円くらいしたからな
普及するわけがない
そうではなくて、68000のような32bitもどきの16bit CPUに需要があったんだよ
だからX68000やAmigaなどが出たわけ
286が68000のようにレジスタを32bitにして16MBのメモリをリニアに扱えるような仕様だったらよかった
あくまで16bitCPUとしてね
PC-98の場合、PC9801VM2で既に640KBのメモリをフル実装してる
8086の1MBのメモリ空間では足りないから苦肉の策で
バンク切り替えメモリみたいなEMSメモリが出たわけだしね
C言語のXCのint型は32bit
68000そのものは16bitCPUだが
BASICやC言語を使うユーザから見ると32bitパソコンのように使えたわけだ
68000そのものもレジスタは32bitでメモリからのロード、ストアは32bitでもできたし
加算、減算、シフト、ローテートも32bitで演算できた
乗算、除算が16bitのみで32bitの乗算、減算が用意されてなかっただけ
x86で広く使われてたMS-DOSはリアルモード、
Windows 3.xはアプリ側はプロテクトモードの16bitセグメントで動作していたため
32bitの386や486が普及しても16bit由来の64KBの制限に苦しめられた
（Win95でもそのまま動作させることが可能なWin32s用バイナリを作れたと言うべきか）
superPI benchがこのWin32sバイナリだな。いまでも広く使われてるけどさ、最初はWin3.1で動いてたはずだ
win32sはwin32のサブセットだから足りないapiが山ほど有って、win32s用に書かないとまず動かない。
ものの主客が逆だな
＞（Win95でもそのまま動作させることが可能なWin32s用バイナリを作れたと言うべきか）
と訂正入りで出したじゃん
Win3.1時代のもふくめて16bitコードで書いたものはx64Windowsでは動かないけどWin32s用のなら(使ってるAPIしだいだけど）いまでも動く可能性があるってだけ
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆
―――――――――――――――――――――――――♪
コンピュータ技術者ではない、コンピュータは道具としてしか
使ってないワシが、ちょっとCPUの構造について調べたが
連続してアクセス出来るメモリの容量は、実行する命令のアドレスを
保存するプログラムカウンタのレジスタ幅で決まる。
ただし、アドレスバス幅が狭い場合、それに合わせて下がる。
プログラムカウンタのレジスタ幅が
１６ビット＝連続してアクセス出来るメモリの容量は64KB
8080
Z80
6800
6809
6502
65816
8086～80286
Z8000
３２ビット＝連続してアクセス出来るメモリの容量は4GB
68000～68040
Z80000
80386～Pentium 3
Power PC G4以前
６４ビット＝連続してアクセス出来るメモリの容量は16EB
Power PC G5以降
Pentium 4
Core 何ちゃら
ただし、アドレスバス幅がこれより狭ければその分少なくなる。
だが、移植がし易い程度のものでしかなく、メモリがどんどん安くなった上に
使いたいソフトのプログラムを自力で作る時代ではなく、大掛かりなプログラムの
アプリを買って使う時代になり、64KBの壁のほうが問題になった。
メモリが安くなり大容量になることを考えず、１６ビットで十分と考えたのも失敗か？
80286に３２ビットのプログラムカウンタを採用すれば、IBM-PC/AT以前の
8086や8088を積んだPCは早めに役目を終え、新しいバージョンのDOSが普及し
64KBの壁の問題は解消され、インテル嫌いが増えることはなかった？
８ビットCPUもプログラムカウンタが８ビットでは、256Bのメモリしか扱えず
使い物にならないから、１６ビットとし64KBのメモリが扱えるようにしていた。
68000は
ALU（演算装置）にあるように乗算除算が１６ビットで他は３２ビット
汎用レジスタ ３２ビット（68000ではアドレス 用とデータ用に分かれている）
プログラムカウンタ用レジスタ ３２ビット
アドレスバス ２４ビット
データバス １６ビット
この３２ビットもどき感ｗでなかなか安くならなかった386と違い
68000のほうが回路数が少ないこともあり、コストダウンが要求される
家庭用ゲーム機のメガドライブに採用され、大量生産により
回路数の少なさ以上のさらなるコストダウンになった？
プログラマーのしなくて良い、無駄な苦労が無くなって欲しいと思っただけだ。
たまたまあのIBMが互換機を作り易いほど情報を公開したパソコンに
8088を採用してくれたおかげで、x86が商業的に成功しただけだ。
インテルの営業がIBMへ上手く売り込んだのなら、売り込んだ従業員が
その後辞めてAMDに行ってたとしても、頭が上がらんなｗ
8086互換のV30を作っていたNECの文豪を除けば
専用ワープロは68000が多かったって話も聞く。
68系は68系で68020を出した時に、68000と完全互換じゃなかったことが問題だ。
マックは互換性のために、ＯＳを出来るだけハードに依存しない
設計をしているって聞いたことがある。
当時の時代の遅いパソコンで、そういう考え方をするって珍しいな。
それによって68020のクソな所をにもあるように乗り切れたが
アミーガやアタリやX68030はそうは行かなかった。
＞単なる制御用のプロセッサをIBMがPCで採用したことで8086/88は大成功したが、IBMは実は
＞8088がゴミ同然の安物低機能だったから採用した。高機能すぎると本業を脅かしかねないから。
＞ゴミでなければならなかった。という話。
だが、が言ってるように、個人向けコンピュータであるパソコンは安さが重要だろ！
高性能だが高いコンピュータは、当時はパソコンより上位のコンピュータで良い。
8086はプログラムカウンタが１６ビットしかなかった。
アドレスバスが２４ビットあるのに
80286はプログラムカウンタが１６ビットしかなかった。
そのため64KBを越えるメモリをまとめて扱うことが出来なかった。
インテルは何でそんなバランスの悪い設計にしてしまったのか？
だったら最初から８ビットCPUのように、アドレスバスを１６ビットに下げて
配線を減らし、製造コストを下げたほうが良いじゃないか。
８ビットCPUで64KBを超えてメモリを扱う時の、バンク切り替えような
1MBを超えるメモリを8086でも扱えるEMSという方法を作り出したわけだし。
アドレスバスが２０ビットではなく１６ビットしかないことで、問題が大きく
なるんだったら、逆に80286のプログラムカウンタの３２ビット化を促し
8086が早めに切り捨てられ、64KBの壁が早く無くなったかもしれない。
８ビットCPUもプログラムカウンタが１６ビットの、１６ビットもどきCPUだった。
Z80はALUが４ビットだから４ビットCPUだって情報もあるな。
そういう必要に迫られた場合68系ならさほど難しくないけど86系(プロテクトモード)は書ける気がしないわな
286のプロテクトモードは386を完成させるまでの試作品という感じで
使い辛かったらしいけど、プロテクトモードが使われなくても
V30より速いV30で構わないと言う立ち位置で製品化したって所かな。
データバスの幅より、アドレスバスからみ色々面倒な思いしたから
68Kシリーズはスーパバイザモードだけで動かせるから、その点だけは286に勝ってるな。
286のプロテクトモードはアセンブラでコード書くもんじゃない。
つか、x86系のプロテクトモードなんてのはOSとコンパイラが知ってれば良いんだよ、ニンゲン様が手を出す領域じゃない。
AMIGAとX68Kは必要な時に一時的にスーパーバイザーモードになって通常は違った
UNIXとかは普通に使い分けてる
OSにおんぶにだっこでアプリ書く分にはx86(プロテクトモード)でも別に困らないと思うよ
昔みたいに64kバリアもないしレジスタと機能が結びついたりもしてない（よね？）し
そうじゃない場合はx86使い辛いというか使えねーってなるだけ
仮想86モードの無い286でどうやってリアルモードからプロテクトメモリにアクセスしてたんだろう。
リアルモードになるにはリセットを自分にかける。
と思った。
暗黙の参照とかいってオペランド明示しないのにアクセスするレジスタがあるもよう＞386ネイティブコード
x64でも同様にあるのかどうかまでは、残念ながら知らない
レジスタへの設定だけでモード遷移せずにアクセスできた
通称Unrealモードというらしい
386以降で使用可能
文字表示する度にリセットしてたら大変だ
DMAC自体は対応してるみたいだけど、DMACで制御可能なアドレスは下位16bitだけで上位は別レジスタだから
せいぜい同一セグメント内でしか転送できないわな。
EMBからVRAMへの転送はどうやるんだろう。XMSドライバも同じことが言えるけど。
>でもPC/ATってDMAでメモリ-メモリ間転送するのかしら。
PC/ATはメモリtoメモリのDMAには対応してないよ。
プロテクトメモリ（EMB)との転送はhimem.sysを利用だから286CPUの場合は
LOADALL(０Fh 05h）を利用するはず。
CRISCってのも出てきたっけ？
しーりすく か くりすく か、どっち？
USBを「うすぶ」とは読まない(読めない)
ASCIIだって略語だ
SATAは、えすあたと呼んでる。さたとはよまないなあ
主流とは違う読み方というと（上記の読み方の中にもありそうだけど）オレ的には「あさすてっく」かな、さすがにこんな読み方してる人はいまい
他人に通じたかどうかは知らん
CISC 「しすく」
eSATA 「いーさた」
FEP 「ふぇっぷ」
RISC 「りすく」
SATA 「さた」
SASI 「さじー」
SCSI 「すかじー」
ATA 「えーてぃーえー」
CPU 「しーぴーゆー」
USB 「ゆーえすびー」
う～ん、読み方の基準というか閾値がわからんなぁ。
さすがにCPUをクプとかUSBをウスブとか呼んだりはしないけど。
アタ呼びの副作用でSATAをサタじゃなくエスアタと呼んで、eSATAのことはエサタと（変に）呼んでたりする。
心の中だけで、会話では使ってないけどさ
80186 vs 68010 たぶんインテルはﾌｧﾋﾞｮってて、モトローラはﾎﾙﾎﾙしてた(印象薄いから、186って
80286 vs 68010 インテルはハンカチを噛みながら泣く、モトローラは口元を扇子で隠しながら高笑いｗ
80386 vs 68020 インテルが不敵な笑いを浮かべ、モトローラの顔は引きつる
80486 vs 68030 勝負有り、インテルがモトローラを置き去りにする
80186は組込み用なので一般人には印象薄いのはしかたない
てか、80186より80286の方が早くに出てるし w
1978 8086
1979 68000
1982 80286(2月) 68010
80186(6月)
1984 68020
1985 80386
1987 68030
1989 80486
1990 68040
80386で一気にひっくり返されたって感じ
68020や68030の時代はワークステーションなどのよく使われてたが
486や68040の時代には680x0を使ってたところは軒並みRISCに行っちゃったしな
組み込み分野ではARMが台頭してくるまでかなり使われてたようだけど
ttps://pc.watch.impress.co.jp/img/pcw/docs/684/769/01.jpg PowerPCが上位モデルとして確固たる地位を築きあげないと68040が中～下位に降りて来れなかったんだからさ
足音どころではないよ
68020が早い段階で価格が下がってパーソナルユースに下りてきてくれてればよかったのになぁ
1984年発売なのに1990年頃になっても68020は高いままだったので68000が出荷のメインだったもんなぁ
68000で十分だったんだろ
だね、'80年代なら一般人が買えるメモリーとしては16MB程度で十分だったしHDDも高かったから仮想記憶とかも実用的じゃなかったしな
80286に後塵を拝したのはやっぱりMS-DOSの存在がデカイと思う
いやあ68000と68020じゃ速度が全然違うよ
1990年前後に68000はCPUが遅すぎる
DOSは依然として16bit環境がメインだったのであまり32bitの恩恵は受けられなかったけどな
68000は16bitのアーキテクチャとしては画期的だったけど
32bitのアーキテクチャとしては普通
386SXや386や286マシン用のCyrix 486SLC搭載のCPUアクセラレータが普及した時点で
パソコンでは68000系に勝ち目はなかった
モトローラには販売戦略をもっと頑張ってもらって
68EC020でいいから386SXと同価格まで値下げして欲しかったね
386SXは、特別なハードウェアを使わなくてもプロテクトモードメモリを仮想EMSにできる点だけは良かっただろ
もっとも、サードパーティー市販メモリの多くがバンクメモリとプロテクトモードメモリとEMSメモリのすべてに兼用に使える機能付きのCバスメモリだった頃だから、
実のところメリットが薄かったけどさ
＞68000は16bitのアーキテクチャとしては画期的だったけど32bitのアーキテクチャとしては普通
対するに386はx86の16bitからの拡張としては自然な形で素直だったけど、汎用32bitCPUとしては特殊すぎた
とはいえ、プログラムの最適化とかはプログラマの仕事じゃなくコンパイラの仕事になって行きつつあった時代だから、奇妙なアーキテクチャでも困らなくなりつつあったのも事実
価格性能比で差をつけられた感じかな
出荷台数もAT互換機>Macだろうし
ワークステーションはRISCに取って代わられた
レジスタの数も命令の直交性もMIPSの方が上
68000系はデータレジスタとアドレスレジスタに分かれてるしね
68000系は組み込みでは駆逐されちゃったけどMIPSはまだ残ってる
MIPSコア搭載のワンチップマイコンならPIC32が有名で
安いやつだと1個200円から300円くらいで買える
ttp://https://www.digikey.jp/products/ja/integrated-circuits-ics/embedded-microcontrollers/685?FV=fffc0238%2Cffe002ad%2C7e80068%2C7e80049%2C7e8004a%2C7e8004b%2C7e8004c&quantity=&ColumnSort=1000011&page=1&pageSize=25 >実のところメリットが薄かったけどさ
仮想EMSドライバーの利点はプロテクトメモリをEMSメモリとして利用できること以上に
640kB以上のメモリ領域に仮想UMBを設定してFEP等デバイスドライバーをUMB外に逃がして
コンベンショナルメモリの占有を開放してメモリ空間の圧迫を解決したことだな。
未使用の拡張ボード用ROM領域の利用は当然、本体が占有するROM領域すら可能な限り
UMB化してMS-DOSの環境を改善したものだ。
286マシンでもCylixの486SLC搭載のCPUアクセラレータが載せられたりしたので
それらの恩恵を286マシンユーザでも受けられるようになったよな
DOSエクステンダーがもっと普及してればよかったのにとは思うけど
ARMはRISCなのにアドレッシングモードが充実しててアセンブラでも書きやすかったりする
Cortex-A8やA9やそれ以前のARMは整数除算命令がないけど
Cortex-A7やCortex-A15以降のCortex-AシリーズやCortex-M3、M4、M7は整数除算命令がある
また、Cortex-M3、M4、M7はThumb-2というコード密度が高い命令セットのみで従来のARM命令はサポートされない
Cortex-M0やCortex-M0+はThumb-2のサブセットでサポートされる命令数がさらに少なくなってる
Cortex-M0やCortex-M0+は8bitや16bitの置き換えを狙ったもので
32bitプロセッサとしてはあまり使い勝手は良くないがC言語で書くならそういうことはあまり関係ない
Cortex-M3コアがゲート数3万3000ゲート、Cortex-M0が1万2000ゲートと
32bitのコアとしてはとても小さい
32bitのARMはThumb-2というコード密度の高い命令セットと小規模なコアで組み込みで絶賛普及拡大中
この命令があったからこそ携帯電話向けで採用された
Thumb-2は16bitの長さのみの命令からなるThumbに32bitの長さの命令を追加して機能を増やした
16bit/32bitの可変長の命令セット
MIPSでもThumb-2の真似をして16bit/32bitの可変長命令セットmicroMIPSという命令セットがある
PIC32ではmicroAptivコアやM5150コアを採用したものでmicroMIPSが使える
初期のPIC32のM4Kコアを使ったものはmicroMIPSは使えない
(microAptiveコアやM5150コアは通常のMIPS命令も使える)
名前は486だけど実態は386互換のコアにキャッシュ乗せただけだとか聞いて驚いた記憶もある
といっても、真偽の定かではない昔話として、だったけど。
68kで採用されてたアドレシングモードのうちでも、用途の有効性が理解しにくかったメモリ間接アドレシングのような厄介な代物はさすがに却下してるよな
ぶっちゃけコンパイラ側がやったらいいことまでマイクロプログラムに任せちゃうとか、かなりヘビーなアドレシングモードだった気がする
重すぎて高クロック化を妨げたとまでいわれたシロモノだったか
>DOSエクステンダーがもっと普及してればよかったのにとは思うけど
DOSエクステンダー関係は色々ドロドロした話があるからなぁ。
FM-TOWNSが採用したPhar Lap社RUN386は国内他機種では互換のEXE386が評価版という形で
当時各種雑誌のおまけFDでばら撒かれたけど開発環境の入手に問題があって使用者が広がらず
限定されてしまったし(参考)、DJGPPはPC-9801移植版をCマガジンがおまけFDでばら撒いて
国内Userを確保したもののこれまたトラブルが発生して最終的には移植者がモチべを無くして
離脱してしまうというアレな話が有るからなぁ。
あとOS/2から出てきたEMXはOS/2自身のUserが広がらず最終的にはVer1.0に達することなく
開発が終了という憂き目に…（とは言えDEMACSはDJGPPと共に開発されたけど）
まあDOSエクステンダの存在を意識しない形で有ったならば各種アプリやGAME等で
結構使われた。
ttp://https://en.wikipedia.org/wiki/DOS_extender#Notable_DOS_extended_applications 386BSDとかの時代が既に遅かったってこと？？
1992年02月 386BSD
1996年04月 GNU Hurd
HurdはともかくLinuxもBSDも４～５年前倒しってのは87年のMINIXと同時期に出せってこと？
Compaq Deskpro 386が86年だし、MINIXと同時期にPC-Unixリリースってのは技術知識の蓄積が間に合わないと思うぞ。
お互いの開発者同士がネットで議論したのも面白かった。
初期のコードはLinuxがamigaで作ったマルチタスクで動作するターミナルソフトじゃなかったっけ？
移植とは全然違うと思うが
○Linuｓ
なんかよくtypoる…orz
ttp://https://youtu.be/pxx6brHlwJI ホビー向けではWindowsなんかよりもFM-TOWNSのようなDOSの32bit化の方がありがたかったけど
OS/2モドキになるんじゃねーのか？
そのレベルでシングルタスクだともったいないから
コンソールベースでマルチタスクになる感じ？(バックグラウンドジョブとか)
UNIXだってGUI無しでもマルチタスクだし、まあそんなん？
ゲーム特化でシングルタスクだとフラットメモリーでプログラム組むのが楽になるくらいじゃない？
※他は「速い8086としての80386」と大差無いかと…レジスタ増えるから楽とか？
プログラムで32bitの変数は多用されるから、16bitと32bitでは性能が全く変わる
64bitのWindowsは広まるまでに時間がかかったがWindows 95だってあっという間に広まった
あとは8086だと1MBとかアドレス空間がなかったのでそれ以上のメモリが必要な場合に
苦肉の策としてEMSメモリが使われたが32bit化すればEMSメモリは不要になる
32bitのDOSがあれば、32bit専用でVRAMも大きく取れるので、
多色対応のグラフィックモードも新設できたはず
68000は16bitCPUだけどX68000のX-BASICやC言語のint型は32bitだったからね
TownsOSはMS-DOSにDOSエクステンダーを使ったものだった
X68000はあの時代に32bit環境を先取りしてたんだよね
SHIFT-JISみたいな1バイト2バイト混在のデータ処理するのは意外に面倒だったんだよ。
通信系アプリ作ってたけど、可変長データを読み込みながら解析するロジックで奇数アドレスからワードアクセスしちゃって・・・なんてバグはお馴染みだったんだよね。
その手のデータの解析はx86系のほうが余計なこと考えなくて良い分、プログラム作るのは楽だったね。
こーいうシロウト臭いこと言われてもフーンてだけだなあ。
DJGPPの98版にそういう構想があった。
98版はPC/AT版と異なり擬似LRUメモリ管理を組み込んであったので
管理テーブルの未使用ビットを使って複数のPageTableを管理して
各プロセスごとにPageTableを与えて最初のプロセスでシェルを起動して
コマンド待ちにしておいて子プロセスでa.outを起動させるというものだった。
（プロセス毎にセレクタ配置を一定にすることが出来る）
さらにマルチタスク化も検討されていたが（DJGPPはJMP TSSを多用していた）
これは16Bitコードに移行してる時の問題を解決するのが面倒ということで
当面は見送りということだった。
まあNIFTYと喧嘩して日の目を見ることも無く98版の公開をVer.1.10で
打ち切ってしまったけど公開を継続されていたならば事実上の32Bit DOSに
なっていたと思う。
（これ以上書くと移植者が見たら身バレしてしまう）
9821のS3 928ボード(PC-9821A-E01)のDJGPPドライバーを記述した時に
1MBのビデオRAMをメモリに設定してアクセスしたな。
画面モードの設定などを商用ソフトに依存してたからプライベート用で
公開することは出来なかったけどね。
1バイト目でデータ長フィールドのサイズを１／２／４バイトで示して、パディング領域なしでつづけてデータ長フィールド、続いてデータ領域（１／２／４バイトのエレメント混在）なんてデータフォーマットでね。
新しいデータ部の定義が増えるたびに解析部分をつくるわけだが変態アドレス（）の６８０００では「あ゛っー！」はなくならないわけよ。
x86じゃそんなクソな理由でバグったりしないわけ。
素人クンの君にはわからない世界だろうね。
020以降はコスト性能比がクソだったからハード設計部隊がなかなか採用しなくてなぁ・・・
RISCは境界またいでアクセスできないCPUばかりだよ
そういうのも扱えないのかな
そういう人は無理にアセンブラで組まないでコンパイラにお任せするのがいいよ
MIPSやARMなんかのRISC CPUでも同様の問題が出るよ
ttp://http://www.kumikomi.net/archives/2008/05/08hard2.php?page=3 エンディアンがわからんけどビッグエンディアンとしたら
GetWord:
move.b (a0), d0
lsl.l #8, d0
move.b 1(a0), d0
rts
みたいなサブルーチンとかマクロ作っときゃいいだけだろ
当時は16bitで足りるように仕様を設計することも多かった記憶が
ロードモナークのパラメータがのきなみ8bitと16bitに制限されてて、それ以上のサイズの数値が使われてない、みたいな。
しかもソフトで簡単に対処できる問題なのにプロ?
ほら、プロには高度な物を作る系のプロもいれば、程々の物を短時間で早く作る方向性のもいるじゃん
後者の見習いだと、制作速度が早くもないし出来映えがよいわけでもないって事で、ちょうどピッタリじゃないか?
最初から68020を出すべきだったよ、モトローラは。
CISCとRISCの境界の一つでもある
CISCのはずの68000が非採用とかの例外はあるが
> 新しいデータ部の定義が増えるたびに解析部分をつくるわけだが変態アドレス（）の６８０００では「あ゛っー！」はなくならないわけよ
「ミスを繰り返さないためにどうした」みたいな話もできない癖にプロ気取りとは恐れ入ったわｗ
セガのメガドライブは欧米ではジェネシスという名前でかなり人気あったらしいぞ
後から「〇〇するべきだったよ」とかは誰でも言える
日記にでも書いとけ
68000登場時期の他のCPUの方がよっぽどゴミだと思うけど
登場時期も考慮しないと
セガのゲーム機を出すなら次世代のサターンでも使っていて
国内ではこっちの方が売れたんだよね。
まあメインCPUはSH-2に取って代わられてサウンド用だったけど。
SH-2機用のソフト開発とか罰ゲームだっただろうなぁ…
と思ったがもうその頃はゲームエンジンもC言語で実装の時代か
68kからアドレシングモード減らしたのと大差ない感じなんじゃなかったの?
当時も68kの機能フルフルに使ったハードとソフトが無かったし。
中途半端と言うか未完成というか出来損ないというか。
8086と比べなきゃ優位に立てないワケだよ。
あの時期は68000が一番マシじゃないか？
Z8000も微妙だったしな
一番マシって言えばそうだけど使われない機能てんこ盛りの時点でお察しください状態だろ。
「なぜ020相当を最初からださなかったのか」と稀によく言われるけど、それだけ「中途半端」って評価してる人が多いってことの裏返し。
SH2は普通のRISC。68Kとは全然似てない。
Z8000は正統な16bitプロセッサだったな。PDP-11的な。
68Kは32bitプロセッサの16bitバスバージョンだった。
個人的にはNS32032が至高。異論は認めない。
業界に痕跡を残して消えたメーカー 優秀なマシンを輩出するも業績に悩まされたApollo Computer
ttp://http://ascii.jp/elem/000/001/550/1550550/ ＞1980年というのはSun Microsystemsの創業よりも2年早い。
＞1981年には、最初の製品であるDN100ワークステーションをリリースする。
＞8MHz駆動のMC68000×2に縦型モノクロモニターを組み合わせ、
＞この上でAegisという独自OSが動作していた。
＞DN300は「VAX/11-780の性能を4分の1の価格で提供」がうたい文句であり、
＞OSの使いやすさもあってたちまち普及した。
＞ちなみにDN300の後に登場したDN330は、プロセッサーを12MHz駆動のMC68020に変更し、
＞さらに性能を引き上げたことでより人気を博している。
それと張り合える性能をもってた68000
SUNのワークステーションでも使われていたからそうでもないのかもしれんが
あの時代のPCでプリエンプティブマルチタスク＋ウィンドウシステムが動くとか
そんなこと言ったら8086はなんで最初から80386で出さなかったのかと思ってる人めっちゃ多いでしょｗ
特に80286とか中途半端のクソ過ぎってみんな思ってるんじゃないかなｗ
SSEなんてよほどツボにはまらん限り使っても性能上がらんし逆に落ちる場合も多い
AVXなんかはシャッフル命令さえ実装されていないし
最初から386相当でリアルモード互換のためのややこしいアレコレがなければ随分マシだよね
まず386として動作させるまでが面倒臭いとか…
ソフトウェア資産が山積みだから売れなかったんだろうね
だからこそ最初に(性能はともかく)32bitとして設計してればば…68kならなってなるわけだが
68系もスーパーバイザーモード(と極一部のユーザーモード)に非互換があるけど
8086と80386に比べれば大した事無いし
Atari ST (´･ω･`)
Windows/386じゃなくて？
OS/2 Warp用です
Windowsはイベントドリブン、プリエンプティブマルチタスクのDOS窓使うには386が必要だったが
すぐ思い浮かぶのでOS-9があるけど68000はあったけどx86は386位しか具体的な記述がみあたらない…オリジナルが6809用だし動かないことはないと思うんだが
68000はUNIXワークステーションに使われていたしOS-9/68000とかもあるな
あー、ぐぐったらElmicは両方あったわ
ttp://www.elwsc.co.jp/page.jsp?id=2450 マイクロソフトのXENIX
286ならOS/2 1.x
ググると昔のNetNewsに
> CP/M-86 was effectively replaced by Concurrent-CP/M-86 in 1983, full
preemptive multitasking using EEMS (eg AST RAMPage card) to give bank switching so it could run several programs up to 400Kb each.
とか書いてあるみたいだからCCP/M-86はプリエンティブだったみたい
技術的にはタイマーで割込かけられれば8080/Z80/6800辺りでも実現可能、実用的かどうかは知らんけど
それだけでなんちゃってプリエンプティになるという。
win3.1もDOS窓だけならプリエンティブマルチタスクだったでしょう。
窓アプリはプリエンティブじゃないけど。
8086だと機能しない(リアルモード限定)
Z80でUZIX(MINIXよりさらに小型のUNIXっぽいOS)があるし
タイマー割り込みができればマルチタスクは作れるけど
商品というか組込み用モニターよりも規模の大きいもの…DOS程度には実用的なデスクトップOSだと8086はほぼ無いのかなと思ったけど
それなりに有るんだね
パクリ元はMP/Mなんていう拡張版があったらしいけど。
68000と以後のMPU間の非互換は、386のリアルモードとプロテクトモードの差異と概念的に別世界の問題でしょ。
8086向けのバイナリは286/386のリアルモードでそのまま動くんだし。
価格が6万円くらいしてて、SDKが60万円
だから個人向けには全く普及しなかった
(業務用ではPOSレジなどに使われたらしい)
OS/2 Ver 1.xはプリエンプティブなマルチタスクで
プレゼンテーションマネージャーというWindowsに似たGUIも備えてた286向けに作られたOS
マイクロソフトは公式にはDOSの後継はOS/2と公言していて
LotusのようなメーカーはOS/2用のアプリを開発していたが
Windows 3.0が人気が出たのでマイクロソフトはさっさとOS/2を見限り、Windowsにシフトした
GEMというGUIをオプションでサポート
(6809用のFLEXとは全く関係ない)
FlexOS
ttp://https://en.wikipedia.org/wiki/FlexOS MS-C 5.1で小さいコマンド作るぐらいしかしたことないから知らんかったわ。
Ver2はWIN-OS/2で「安定したWindows3.x」としてしか使わなかったし。
1995年のWindows 95が出るまで残ってるとは考えなかっただろうな
1991年、1992年頃には386SXや386、486が普及して32bitOSが普及してるだろうと考えていたはず
その隙を狙って商売できたともいえるね
286/386のリアルモードは8086との互換性が高いけど、それでも一部に非互換がある
かなり限られてるけども。
互換性などと無縁なアーケードゲームでも何故か8086系のCPUはほとんど使われず68000が好まれた
知ってるのだとアイレムのM72システム基板(R-TYPE等)がV30使ってたぐらいか
SVモードしかない68000、68008が有ったら売れたんじゃなかろうか？
それを16bitバスで実現したのが68000
すべて16bitのままで実現した8086は64KBのセグメントの壁が残った
ビットマップグラフィックスを扱うような応用は64KBのセグメントの壁が問題になりやすい用途の一つ
32bitアーキテクチャになるとメモリが極端に少ない場合を除いて
開発は主に高級言語で行われるので、命令セットなどどうでもよくて性能がすべてになった
一部、組み込み用途では16bitのメモリバスでも性能が出せる命令セットや
コード密度の高さも重要な要素になったけどね
誰でも思いつくのは画像だけど、VGAの640x480(16色)モードだと1プレーンは64kに収まっちゃう。
コード密度の差なんだろうけどV30が同クロックの68000の1.5倍だっけ？
「64KBを超えるメモリをフラットに扱いたかったら」っていう要求がなきゃV30で十分ってことなんだよな。
４年ほど時差あるけど。
16色だと4回ビットマップ操作が必要になる
64KB以上のメモリをフラットに扱えるなら1ピクセルを4bit、8bit、16bit、24bit、32bitの単位で扱える
1ピクセルを操作する手間そのものが削減できる
意味不明
ユーザーモードでも8メガバイトとかレベルのメモリをアクセスできるのだが
さすがに16MB全部はユーザーモードではアクセスできないけどさ、
スーパーバイザーモード専用に設定したエリアをアクセスできないから。
640 x 480で256色扱うのに約300KB
640 x 480で65536色扱うのに約600KB
640 x 480で16777216色扱うのに約900KB
64KBの壁があると原色ごとにプレーンを分けて
(16色なら4プレーン、256色なら8プレーン、65536色なら16プレーン、16777216色なら24プレーン)
それぞれの操作が必要だが
64KBの壁がなければ原色ごとにプレーンを分ける必要はなく
パックド方式で1ピクセルを4bit、8bit、16bit、24bitの塊として扱えばよくなる
パックド方式の方が明らかに操作は簡単
そのせいで不便な点も多いのにプレーン型VRAMが長く残ってたんだろ
Windows普及後は完全にピクセル型のVRAMに置き換わったじゃん
歴史を見ればどんどん色数、解像度、vramは増えるんだからvramがフラットで見れるなんて逆に拡張の足枷にしかならない。
あれ、68000ってユーザモードでも16MBのアクセスが可能じゃなかったっけ？
もちろんスーパーバイザーモードの領域は無理だけど
X68000だってメインメモリは12MBだよね？
68000はスーパーバイザー領域、ユーザ領域、プログラム用、データー用と
それぞれのメモリ空間を分けられるだけでそれらを一緒にすることも可能だよね？
それらはハードウェアの設計に依存するってだけだよね
元々プログラマ視点ではなくハード屋視点の設計。
？？？
そういうアホな主張すると
86の系譜は補助回路無しのCPU単体じゃビットマップすらまともに扱えない欠陥CPUっていわれちゃうぞ？？
グラフィックは専用ハードがほとんどの処理をこなす。おまえの無知さにドン引き。
ならなんでプレーン型は完全に廃れたのか説明してほしいもんだが
この板にいてデジタルRGBからアナログRGBへの移行を知らないのかよ。
？？？それってプレーン型には拡張性がなかったってことですよね。
＞歴史を見ればどんどん色数、解像度、vramは増えるんだからvramがフラットで見れるなんて逆に拡張の足枷にしかならない。
自分で書いたことも忘れちゃったのか・・・
自分で自分を論破するアホは久しぶりに見たわ。
FM-77AVやX1turboZはプレーン型でアナログRGBやってたのを知らないやつがこの板にいるとはね（苦笑）
え、ユーザーモードでもスーパーバイザエリアになってなければ16MBリニアにアクセスできるでしょ
320 x 200で２５６色でパックド方式だった
320 x 200なら8bitのパックドでもギリギリ64KBに収まるな
画像処理って知ってる？
画像(ビットマップ)を加工したり解析したりするんだけど
そういうのはVRAMではない通常メモリーにデーターを展開して色々処理する
処理内容によっては小さい範囲を少しづつずらして実行するものもあるが
他方、画像全体を常時参照するような処理もある
そういう事をやるときに64kbセグメントとかの処理するのはとても面倒くさいし遅くなる
昔のウインドウアクセラレーター(今のグラボ)みたいな外部ボードを挿してハードウェア化する場合もあるけど
CPUで処理するほうが普通だし、そもそも研究段階や専門的過ぎてそんなもの無い場合も多い
あと初期のUNIX(ウインドウシステム有り)やMACが68000を採用した理由…逆に言えば86が採用されなかった理由が
メモリーをフラットにアクセス出来る出来ないの差だったりするんだが？
GUIを処理するのにセグメントが邪魔だったんだよ
ftp.packardbell.com/pub/itemnr_old/NECDOCS00610100/191000AA.htm
256色はPacked Pixel Modeと書かれてるね
ハード支援なんて何でもかんでも付けられるわけじゃないんだから、ソフトから単純に弄りやすい方が良いに決まってる。
プレーン型は使いづらいから廃れた。それだけの話だよ。
64KBを超えるメモリを扱うシーンなんていくらでもあるでしょ
PCMデータだってデカいしな
V30が同クロックの68000の1.5倍ってのも大嘘だし言ってることが無茶苦茶
DOS標準のGUIはなくても、アプリレベルで独自のGUI実現してたDOSアプリがあるわけだし、
プレーン方式のVRAMでもGUI実現はできるわけだよ。
1pixel/byteという使いやすさも大きかったのではないかな。
プレーン型は重ね描画がメチャクチャ面倒くさいんだよね。
そだねー、俺が想定して話題にしてる時代から10年もすればそうなるねーｗ
空気読めないバカだな、お前はｗ
だから256色出せるハードウェアなの640 x 480では16色なんだろうね
それなら150KB程度のメモリでいいわけだし
X68000だとグラフィック用のVRAMだけで512KBの領域使ってたんだっけ？
68000やV30の時代にPCMデータが易々と扱えたと思ってるのか。時代錯誤すぎるぞ。
あとピクセル数が少なくて処理が速くできたっていうのも大きいと思うぞ。
プレーン方式640x400しかなかった某国のPCの画面周りの遅さは有名なわけで・・・
64KBだと4秒録音しただけであふれるなｗ
プレーンを分けることで重ね合わせを完全にハード側に委ねるというテクニックも可能だ。
8bitゲームではよくあっただろう。
ただVGAで著名なリアルタイムゲームなど全く知らん。PCゲームで記憶に残ってるのはテクザーとかイースぐらい。
おれが使ってた8bitPCだって使えたわ。
640x200モードはあったでしょ。
ピクセル数が少ないから処理が早く出来たってのはないな。
メモリ容量自体は、640ｘ200-16色なら320x200の256色と同じだからね。
16色で4プレーンあったとして、最大4枚しか重ね合わせ出来ないんだが？
4枚しか重ならなくてゲームが作れると思ってるの？
テグザーもイースもプレーンを分けた上で、苦労してソフトで重ね合わせ処理してるんだが。
なにが完全にハード側に委ねるなんだか。知ったかしてくるのも大概にしておいて欲しいわ。
VGAの件で論破されてもまだ適当な事言って来るところが恥知らずだけど (ﾜｯﾁｮｲ b114-RYnA) は。
プレーン型はピクセル単位でやろうと思ったらビットシフトしないといけなくなるから
なめらかな移動描画なんてとても・・・
こんな板にいる老人ならこんなの常識の知識だと思ってたんだけど。
640x200モードってあったっけ？
使った覚えがほとんどない、というか640x400しか使ってなかったから記憶になかったわｗ
VGAの320x200の256色モードだと、ワークエリアからまるっと転送でも64000バイト、ブロック転送1度ですむからね。
ワークエリアでグラフィックに文字重ねた画像データ作っておいて、1回の転送で更新ってのをやった時に「こりゃ便利」って思ったわ。
X68000にもPC88VA2にもPCM(ADPCM)搭載されてたでしょ
64KBのセグメントさえなけりゃと何度思ったことか
セグメントがあるから名作が生まれないとか言ってる奴は無能の言い訳に過ぎない。
米国ではジェネシスという名前だったらしい
>セグメントがあるから名作が生まれないとか言ってる奴
誰も言ってない、強いて言うならお前が言った
他の奴が言ってるのは
おまえがゲーム描画用として優れていると主張してるプレーン式VRAMはゲームでピクセル単位のなめらかな動きを実現するのに不向きだと言う主張だ
そしてファミコンはスプライトとBGスクロールという外部ハードウェアを利用してなめらかなピクセル単位の動きを実現しているからCPUやプレーン式VRAMはまったく関係ない
プレーン式はプレーンシ式でそのメリットを活かしたゲーム作りはいくらでもできるというだけの話だ。
ハードの特徴に合わせてコードを書くだけ。スプライトが横に描ける制限があるなら、ギャラクシアンのようにキャラクタで並べて対応するし、
色数が制限あるなら、MSXのイーアルカンフーのよう片方はスプライト、片方はキャラクタで描くだけ。
セグメントを理由にビットマップがまともに扱えないなんて言い訳にすぎない。実際に98はエロゲだらけ。
32bitでは実際に制限に引っ掛かったけど、それはx64版Windowsの登場直前になってからだしな、
さほど深刻な制限にはなってないぞ
ああ、うん
スーパーバイザーに指定されたエリアにアクセスするときにアドレスエラーだっけ？でアクセス拒否される以外はリニアアクセスできると書きたかったつもり
アドレス空間としては2MB確保されてる
容量は512kBだが。
PC-98はスプライト使えなかったから、シミュレーションゲームやRPGやエロゲが多かったね
同社のスタートレイダーは内容は好きだったが8ピクセル単位の描画でゲームとしては台無しだった
シューティングはピクセル単位で動かせないと駄目だよね
それだけ64KBのセグメントの壁に苦しめられた人が多かったんだろうけど
Windows 3.x用のゲームはあまりなかったし、386や486に特化したDOSゲームもあまりなかった
CPUもPentiumになってRISCに対抗できるようになったしね
メモリの価格も下がって最低16MB以上必要だったWindows NTもやっと使い物になるようになった
Win x86（32bit）時代末頃、ハイエンドビデオカードで搭載されるVRAMが大容量すぎてフラットにアクセスできなかったことを言ってるんじゃないの
現行システムなら10GBオーバーでもバンク切り替えの必要なくフラットアクセスできるから問題なしだ
第二世代A-MATEやB-MATEはメモリが16MB以上のメモリが使えたから
Windows 95時代にもなんとか使えた
486をPentium OverDriveに差し替えて使ってた人も多かったかも
Windows NT 3.5を買ったんだがそれを動かすために買った16MBのSIMMが6万円もした時期
1994年末はまだWindows NTの敷居はまだ高かった
＞だから256色出せるハードウェアなの640 x 480では16色なんだろうね
初期VGAでは640ｘ480の256色を取り扱える量のVRAMを詰んでないし
256色出せるのは最大640ｘ400の解像度までだ
＞X68000だとグラフィック用のVRAMだけで512KBの領域使ってたんだっけ？
X68000のメモリマップでは、VRAM用に割り振ったアドレスは$c00000-$dfffffの2MB分ある
同じ512kBのテキストVRAMが$e00000-$e7ffffの512kB分なのとは違ってな。
グラフィックの方は1ワード1ピクセル固定だったんで、16色モードだと1024x1024ドット分x1ワード＝2バイトの2MB分だよ
アドレス空間の領域としては2MB、VRAMの物理的容量は512kB
あった。ググってみたところ参考によかったのが
ttp://http://island.geocities.jp/cklouch/column/pc98bas/pc98disphw1.htm ＞1982年、テキスト用に8KB、グラフィック用に96KBのVRAM、μPD7220をテキスト用とグラフィック用に2個搭載したPC-9801が発売。
＞画面モードは 640x200/モノクロ/6面、640x200/8色同時発色/2面、640x400/モノクロ/3面、640x400/8色同時発色/1面 の4つ。
286どころかV30で動作するかどうかが壁だった気がするが
x86がRISCに対抗できるようになったのはPenPro/PenIIからだろ
Pentiumのころだとまだ、Alphaのx86エミュレーションを超える速度は出てなかったのでは?
＞x86がRISCに対抗できるようになったのはPenPro/PenIIからだろ
＞Pentiumのころだとまだ、Alphaのx86エミュレーションを超える速度は出てなかったのでは?
PenitumではRISCの性能は超えてなかったが
486ではお話にならなかった浮動小数点演算性能が
Pentiumで大幅に強化されて、なんとかRISCと戦えるようになったとかだったはず
(初期のPentiumではリコール問題があったけどね)
Windows 95マシンにプレインストールされたパソコンのCPUは
120MHｚもしくは133MHzのPentiumが多かった
(120MHzや133MHzのPentiumはリコール問題になったバグは解消されてる)
ttp://http://www.atmarkit.co.jp/fsys/pcencyclopedia/008procs_hist02/procs_hist03.html > しかし、Intel486 DXではついに浮動小数点演算機能が内蔵された。
> 一般的に浮動小数点演算ユニットやキャッシュ・メモリは、プロセッサと同じダイに内蔵（統合）されると、
> プロセッサ・コアとのデータ転送速度が大幅に向上して劇的に性能が高まる。
> Intel486 DXの浮動小数点演算性能は、RISCプロセッサに比べるとまだ見劣りしたとはいえ、
> 以前に比べれば大きく改善された。
ttp://http://www.atmarkit.co.jp/fsys/pcencyclopedia/008procs_hist02/procs_hist04.html > これでも、当時のハイエンドRISCプロセッサには、
> 浮動小数点演算性能で追いつくことはできなかったが、その差は確実に縮小した。
> また、互換プロセッサ・ベンダ製を含むx86プロセッサ全体の中で、
> Pentiumは抜きん出た浮動小数点演算性能を誇ることになる。
> これはAMDのAthlonプロセッサが登場するまで基本的に変わらない。
UNIXワークステーションで大きなシェア持ってたのがSunとHPだったはず
SGIも人気あったのかもしれないがよく知らない
Pentiumはそれらとある程度、張り合えれば良かったのかもな
SPARCはソフト資産は多かったようだがRISCの中ではあまり速くなかったと記憶してる
ttp://http://www.iaea.org/inis/collection/NCLCollectionStore/_Public/27/063/27063627.pdf SPEC INT92 Summary
ttp://http://performance.netlib.org/performance/html/new.spec.cint92.col0.html SPEC CFP98 Summary
ttp://http://performance.netlib.org/performance/html/new.spec.cfp92.col0.html 68040から自社開発のSPARCに切り替えたのに大して高速化できなかった激遅失敗作じゃなかったっけ、SPARCって?
高速化競争で躓いてるうちに衰退した印象
HPも似たり寄ったりか、あまりにも難航したことで起死回生を図ってitanium共同開発に乗ったまま消滅した印象
シェアはあっても速度はなかったんじゃなかったかなあ
その後でてきた色々なのは個々のメーカーが自前で使ってるというだけで
特別印象には残ってないな
HPはWindows NTワークステーションにも力入れて宣伝してた
DECもUNIXでは劣勢だったのでWindows NTに力を入れてた
WSじゃなくPCで動くLinuxだしね
場所によってはFreeBSD等も動いてるだろうが
基本、組み込みやスパコンまでLinuxになってしまった
PackedPixelを実現させようとするのは80年代後半まで現実的では無いんだよな。
当時のメモリではトリッキーなことをしないと実現できなかった。
具体例で示すと水平640dotをPC-9801のCRTに表示することをPlaner(3bpp)とPackedPixel(8bpp)で
考えると表示期間30.4μs中にGDCはPlanerでは40word(1word=16dot)でメモリアクセスは
760nsで済むものがPackedPixelでは320word(同2dot)で1/8の95nsとなってしまい当時の
DRAMのアクセスタイムが150nsとか120nsから考えると全く間に合わない。
そこでNEC μPD7220 GDCや日立 HD68484 ACRTCあたりではアドレス生成を+2や+4として
メモリをDoubleやQuadでアクセスするインターリーブやメモリのアクセスを高速化する
ページモードなどを実現する必要があった。
更に8bppのPackedPixelだとPalletを記憶する高速なSRAMやD-Aコンバーターも必要で
これらは全てコスト増となってしまい68KであってもPersonalComputerでは実現は困難であった。
（Workstationでの実績は知らね）
それを証明するかのように68K愛好家が自慢する機種のAMIGA(1985)はPackedPixelではなく
Planer方式のGraphicを採用していた。
当時のRISCってクロックが全く伸びてなくてあっという間にINTEL VS AMDのクロック競争による
性能向上においていかれたような気がする。
特にINTELなんかはHPと組んで開発していたItanium(Merced)が開発が遅れたのもあるが
出荷時には既に陳腐化してしまっていてこの時の評価は後々のItanium2 にも大きく影響して
しまったぐらいだ。
×日立 HD68484 ACRTC
○日立 HD63484 ACRTC
DRAMの高速アクセスを実現する手法、カラムモードとかニブルモードとかはすでに80年代に出てただろ
それを使った連続アクセスで読み出せば、DRAMのアクセスタイムよりかなり高速に連続アドレスの読み出しは十分に可能
間に合わないのはお前さんの頭の中だけだ
＞当時のRISCってクロックが全く伸びてなくてあっという間にINTEL VS AMDのクロック競争による
＞性能向上においていかれたような気がする。
命令セットを簡略化して高速化するはずなのに、高速化の妨げとなるボトルネックを見誤って、削るべき部分を削らずに放置したせいで高クロック化ができなかったんだよ
命令自体よりもレジスタ数の影響が大きかったんじゃないのかね
本当にネックだったのはアドレシングモードの複雑さであって命令本体じゃなかったんだろうが、そちらはとりあえず削ってたから、初期段階で配置横行クロック化できたけど、
2番目にボトルネックとなったレジスタ数が削れなかったから厳しかったのかと。
といっても、リネームレジスタを使ったx86でも内部的なレジスタ数はワークステーション向けの高速RISCと変わらないだろうし、あんまり関係なかったのか?
高クロック化できなかったのはなんだかなーって
やはり大資本で工場もってる企業にはかなわないのかって思った
レジスタ数がネックになるのは知らなかったが
それだと大量のレジスタ使ってメモリアクセスを最小限にするロードストアアーキテクチャ自体がボトルネックという話になってしまうな
レジスタ数は程々に押さえないとダメだと、後になって分かったらしい
30とかレベル(32本)ならともかく100を越えてくると(128本とか192本とか、それ以上)、当時の製造プロセスでは厳しかったんじゃないか?
いまでも生き残ってるようなのはたいてい32本か、多いのでも64本じゃん
まあ、リネームレジスタの数は100を超えてるけどさ
サーバやワークステーション向けだけだとどんなに売れても数十万から数百万個程度しか無理なのでは？
数が売れないので半導体工場への投資も回収が難しくなり製造プロセスの更新が遅れるとかもあったかも
今ならスマホの普及でファンドリが既にIntelに追いつき、追い越しつつあるが当時は無理だったからな
あとはDECの経営が傾いたためにDECから大量にIntelやAMDに人材が流出したしな
AMDのAthlon、Athron64やZenを開発したJim KellerだってもともとDECでAlpha作ってた人でしょ？
DECはソフトウェア技術というよりハードウェア技術が売りの会社だったようだしな
スマホ向けで大量に製造の注文が入るからだしな
ハイエンドのGPUチップやFPGAやサーバ向けなどの高付加価値の半導体製造の注文も入る
AMDのZenが好調なのでGLOBALFOUNDRIESも儲かってそうだ
最初は6bitCPUだったとか
たしかCompacに吸収合併されて消えたと記憶してる
そのCpmpacも今は消えてしまったが当時新興企業だったPC-AT互換機メーカーに名門が…ってショックだった
68kが落ちたのだってモトローラがMPU(CPU)にそこまで本気じゃなくなった（本業は他にある）からだしね
それで自前開発をやめてPowerPC連合に入ったけど、これも目立つ用途はPowerMac位しか知らない
68kみたいに産業用（組み込み）とか、もしくはサーバー用とかに使われてるのかな？
日本では東芝やNECがMIPSの製造をがんばってた
富士通がSPARCをやるようになったのは
最初のSPARCが富士通のゲートアレイを使ってた関係だろうね
MIPSのWikipedia見るといろんな会社がMIPSのライセンスを受けて製造してたのがわかる
ttp://https://ja.wikipedia.org/wiki/R4000 ttp://https://ja.wikipedia.org/wiki/R5000 ttp://https://ja.wikipedia.org/wiki/R8000 ttp://https://ja.wikipedia.org/wiki/R10000 DECのPDP-7はUNIXが初めて開発されて使われたミニコンとして有名
PDP-11はUNIX Version 6やVersion 7が使われたりして有名
68000のポストインクリメントやプリデクリメントはPDP-11を真似したと言われてる
VAXは1970年代終り頃に出てDECの主力製品になった32bitミニコン
BSD UNIXは4.3BSDまでターゲットマシンがVAX11だった
VAX11/780エミュレーターで4.3BSDまでのBSD UNIXが動く
DECはIBMと同じく1992年に創業以来初めての赤字を計上して経営が傾いた
そういえばMIPSはファブレスだったね
それだけ当時のCISCに対しては画期的だったんだな…本当にあっというまに塗り替えられちゃったし
でも最終的にはCPU一筋だったIntelに抜かれてしまったのは覚悟（他に商材が無い）というか本気度の違いかね
今のARMが当時のRシリーズに似た印象を受ける
もう歴史の世界になっちゃったね
ミニコン→ワークステーション→消滅・・・となって、これらはPCに置き換えられてしまった
68kのスタックポインターが汎用レジスタなのもDECの影響で
DECのCPUはプログラムカウンターも汎用レジスタだったけど特許だかの関係で68kには採用出来なかったという話を聞いた覚えが
そういう話を聞くとDECはUNIXや68kの母と言えるかも
VAX開発したカトラーもMSでWindowsNT作ったし
今に続く色々な技術の源流に居たメーカーの１つだった
そのFreescale Semiconductorは主にARMをやってるNXPに買収され
そのNXPをQualcommが買収
すでに出てるMIPSと、あとはARMがすでにあった
SPARCもCPUに関してはファブレスじゃなかったっけ？たしか富士通の半導体工場使ってたような気が？
TSMCとか、もともとIntelより少し遅れてる程度でずっと追従してきてなかったか
スマホ好調になる前に一時期は遅れが大きくなってたけどさ
PowerPCも、一時期にはPC同様な規格作ってワークステーション市場に出ていこうとしてたはずだ、死んだけど。
ARMがファブレスでCPU事業はじめたのは90年代前半だろ
MIPSが全盛期を迎える以前からずっとあったはずだが
＞68kのスタックポインターが汎用レジスタなのもDECの影響で
＞DECのCPUはプログラムカウンターも汎用レジスタだったけど特許だかの関係で68kには採用出来なかったという話を聞いた覚えが
その影響が残ったからかな、PCで使える命令やアドレシングモードは汎用レジスタと大差なかったよな
00年代だとPC機器類で結構PowerPCは使われていたよ。
例えば3WareのRAID CARDなんかはAMCCのチップが使われていた。
（その後3WareはAMCCに吸収。 AMCCもLSIに吸収される。）
ちなみにLSIのRAID CARD9260はPowerPCではなくARMを使っていたな。
viじゃダメだよ。DOSは早期にIDEが普及したからね。
68kはDECのミニコンをルーツに持つが
x86は電卓がルーツだっけ？
元々の生まれが正反対だし、そりゃ設計も違うわな
90年代って急速にハード性能が上がった時代だから初めと終わりで全然違うよ
1991年だと、例えば日立3050RXで、PA-RISC 50MHzで128MBメモリーとかだから比較にならないレベル
1998年だと、NECのExpress5800/58WaでXeon II 400MHz × 4で4GBメモリーだからまあなんとか比較できる程度
そのFreescale SemiconductorがARMに力を入れてるNXPに吸収合併され
さらのそのNXPがQualcommに買収された
68kやってたところが今はARMに力を入れてる
32bitのARMは変態RISCだったが64bitのARMは典型的なRISCらしい命令セット
ARMはサーバ向けでは苦戦してるが
数万円クラスの比較的安いNASや安いルータとかのコントローラはARMになってきてるね
あとはIoT関連でもARMが強い
サーバー系は68系→R系→R系も含めメーカー毎の独自RISC群→x86系(386以降)で
組み込み系はZ80→8186→68000系(含むDragonBall等)→ARM系…って感じかなぁ
SuperHはSEGA SATURN以外でどの程度使われたんだろう(これも68系列っちゃ系列っぽいが)
CPU性能だけでいえばPentium3並
全4コア合わせてようやくノート用CoreDuoの1.5GHz相当ぐらい
命令セットアーキテクチャを決めてるARM社は今もfreescaleやらNXPやらQualcommと資本的に無関係なままだぞ
つかむしろsoftbank子会社になったが
だから変態アーキテクチャなり正統派アーキテクチャなりに変わったとして、68kの関係とは関わりは無いだろ
30年前……88年と比べると、3倍とは行かなくても2倍程度には速くなってないか、レイテンシのことだろ。
当時の120とか100nsに比べると、多少は速くなってはいると思うんだが。
転送レートが一桁以上上がってるのと違って、あんまり速くなってないのはたしかだけど。
SHはHDDコントローラーとかで使ってる事例を見たことはある
カタログ上はかなりいろいろな用途に使われてそうだったけど、
実際の採用例ってよくわからんね
それだと変態アーキテクチャの頃の方を言ってることに
ヘンタイがヘンタイを作っていたとかまともからヘンタイになったとかヘンタイからまとも
になったとか色々ややこしい
プリンタコントローラで使ったことあるわ
8bit時代は6502と6800が同じ系列だと勘違いしてたけど別物だし
8bitの6800と16～32bitの68000系もメーカーは同じでもアーキテクチャは別物だったな
wikipedia見たら6502は6800を参考に簡略化して高速動作したとかあったが
68000に対するColdFireみたいな感じなのだろうか
参考にしたというか、「大いに影響を受けた」ぐらいじゃないの？
そんなに似てなくはないけど、違う部分も大きいし・・
ARMの初期開発者であるAcorn computer とか言う会社が元々は6502をつかった教育用コンピュータの会社で熱心な6502ファンだったらしいってのはあるが、
それより以上の関係はなかったんだよな
しかし6800と6502は似ている。6502ではレジスタサイズが小さくなり、インデクスやスタック配置ア
ドレスなど6502特有の制限はある。
設けてるのは実際にチップ製造してる側だろう。いまやIntelよりサムスンが半導体世界一だからな。
Cortex-Aの64bitは実際にはアップルやサムスンが独自改良してスマホに組み込んでるから。
そこいら辺のコア部分の設計はARM側の話ではない。
ARMがソフトバンクの子会社と言っても、ISAを提供しているだけであって他は何一つやっていないから。
16MBの制限のないフラットなアドレス空間
速度は遅いがある意味32bitを先取りしてたようなもの
1986年頃にこれを実現してたのだからある意味すごい
1986年頃、386のパソコンは100万円くらいしてたからな
486が普及してWindows NTやWindows 3.1のWin32SやLinuxやFreeBSDなどで32bit環境を使えるようになって68kの魅力はなくなったけどね
x86も486以降では性能が向上して68kの魅力はなくなった
組み込み向けではARMの命令の長さが16bitの命令のThumbを実装したARM7TDMIが出てくるまで
組み込みで一番使われてたCPUだったようだけど
日立の2050なんて68010, 2MBメモリー, 40MB HDDだったりするからメモリー増設してHDD繋いだx68kと性能はたいして変わらん
Panixとか商用のPC-Unixもあったんだけどね。
P6で本格的に32bit化して(16bitコード用のしがらみの多くを切り捨てて？)から
PCワークステーションみたいな感じで採用され始めたかな
本格的に使われ始めたのはXEONブランドでキャッシュとか強化したものを積極的に売り出してからだと思う
2050は68020か68030だね、2020が386だったりする
両方並べて触ったことある(68020,68030はわからん)けど2050の方が動作が軽くてキビキビしてた
ただし2050はX-Window Systemだったのに対して2020は専用GUIだったから、その違いも大きかったんじゃないかと思う
ttp://http://museum.ipsj.or.jp/computer/work/0007.html 同じ処理をDOSやWindows上で、486やpenで実行できるならはるかに高速。
> ただし2050はX-Window Systemだった
2050シリーズはH-Windowだよ、Xになったのは3050 (68040) から
2020がキビキビ動いたのは画面解像度の問題もあったと思う
特に2050 (68010) は長残光CRTでスクロールが波打つぐらい遅かった
そのPentiumProを基準にすると32bitコードの性能では486やPentiumは性能が低く、もっぱら16bitコードに振って高速化してたって事だろう
ワークステーションで使うことを想定するなら32bitコードが前提だからPentiumまでは遅かったと表現せざるをえない
さすがに68000の十数MHzとかと比べたら雲泥の差があるとは言え、な
X-Windowを（695の説に従うならH-Windowか）動かすには性能不足だから専用GUI使ってたんじゃないの? って、その専用GUIってのがH-Windowなのか?
それでも2050のほうがきびきびしてたって事でしょ
まあ386は68020や68030とちがってキャッシュメモリを内蔵してない点が大きなハンデだったけどさ。
020や030の積む、数百バイトしかない微小な一次キャッシュでも無いよりは大きかったんじゃないかな
あれ、693では2020より2050がキビキビと書いてて695では2020がキビキビ?
どっちが書き間違えてんだろ?
いや型番は2050だったよ非標準な使い方してたのかもしれないけど
3050とうい型番は初めて知った、H-Windowってのも(2020のGUIがこれだったのかもしれないけどわからない)
俺が書いたのは「X-window system(ウィンドウマネージャーはuwm)を使った2050のほうがキビキビ動いていた」…ね？
当時、どんなスペックだったかはCPU含めて把握しておらず最近ググって調べた
それから、さっきのリンクは2050/32 2020/32になってて/32無しの2050は確かに68010だった
ttp://http://museum.ipsj.or.jp/computer/work/0002.html 型番に/32は付いてなかったと思うから触ったのはこっちだと思う(68010 vs 80286)
> PentiumProが出た当時、16bitコードの性能はPentiumと大差ないが
いや、16bitコードはPentiumより遅かった（Wikipediaによると殆どの場合で200MHzのPentiumProでも133MHzのPentiumに負けてた）
なのでWindows95ではほとんど早くならない始末だった
> 32bitコードでは大幅に速いとか言われてた
まあ早いのは事実だけど200MHzのPentiumProが133MHzのPentiumの約２倍の性能だからクロック上がった影響の方が大きい
> X-Windowを（695の説に従うならH-Windowか）動かすには性能不足だから専用GUI使ってたんじゃないの? って、その専用GUIってのがH-Windowなのか?
違うと思うよ、は2020って書いてるし俺の記憶でも2020はDOSベースでGUIはアプリケーション任せだったと思う
> それでも2050のほうがきびきびしてたって事でしょ
2050/32(68020)や2050/32E(68030)になってかなりマシになってたけど画面は明らかに2020(CPUが386と言ってるから2020/32)の方が速かったよ
> あれ、693では2020より2050がキビキビと書いてて695では2020がキビキビ?
> どっちが書き間違えてんだろ?
X-Windowは重いので有名だからのタイポだと思う
まあ20年以上前の話だし記憶違いもあるかもだが
当時は単純に数字が大きい方が高性能なんだって理解してたから自分の体感で2050>2020だったのは確か
※主にターミナルエミュレーターの動作ね、viとかlsとか
もしかしたら2050は/32で2020は素だったとかの記憶違いがあるのかもしれないけど今となってはわからんな
ちなみに現場は日立系列の末端だった
あとGUIだけどXはuwmでターミナルエミュレーターを開くだけの至ってシンプルなデスクトップだったのに対して
2020の方はMacとかWindowsみたいな文字通りGUIっぽいものだったので個人的には重そうって思った
Pentium ProとWindows NT4.0の組み合わせでUNIXワークステーションの優位性が崩れた
Windows 95用の32bitビジネスアプリやグラフィックスアプリも増え
それらの多くはWindows NT 4.0上でも動作した
3DアプリもUNIXからの移植が進んでたな
1997年には16bitコードも高速に実行できたPentium IIが出た
それまでオフコンを使ってた大企業でも西暦2000年問題への対応も兼ねて
Pentium IIとWindows NT 4.0の組み合わせは多数採用されてたはず
486でRISCに対抗できるようになったとは書いてない
486の登場で680x0の魅力がなくなったと書いただけ
> あとGUIだけどXはuwmでターミナルエミュレーターを開くだけの至ってシンプルなデスクトップだったのに対して
すまん2050Gの存在忘れてた
これなら68020でX載ってるから話は合う
こいつは3Dグラフィックプロセッサも載ってたから相当高速だったはず(触ったことないけど…）
> 2020の方はMacとかWindowsみたいな文字通りGUIっぽいものだったので個人的には重そうって思った
こっちは使ってたアプリケーションによるからなんとも言えん
そもそも2020でフルビットマップのGUIなんて見たことないからそれが本当なら2020の方が遅いのはまあわかるわ
2020/32ですら20MHzな386だからWindows 3.1でもカツカツに近い
それは、今の基準で見ればだろ？
当時のPCがまだ386や486の時代ならば
充分にEWSの速さを実感できたんでは？
ARMのThumbやSuperHは16bitコードあるでしょ
MorphyOneと同じところに落ちるのか
Windows10(64bit)で既に16bitコードは切り捨てられてるっぽいよ
Windows3の時に作ったプログラム、ずっと動いてたけどWindows10(64bit)にしたら動かなくなった
互換性で勝者になったWintel連合も16bitコードはもう要らないと判断したんだろう（まあ超古いプログラムの利用価値は限定的だろうが）
もちろん64bitOS上で仮想PC動かしてLegacyモード、32bitOSなら、その中では16bitコードも動く。
今じゃAMDもそれなりにあるから「IntelCPUの場合のみ動きます」ってわけにもいかんわな
いつの話だよ w
10以前の64bit Editionで既に切り捨てられてるぞ
XPのx64版以後すべてのx64版Windowsで16bitコードをサポートしてないだろ
Windows10を入れるまでずっと32bit版を使ってたから気付かなかったんでは？
もともと仮想PCでWin3.x／Win9x環境あるし。
今になって欲しくなってるのはWIN-OS/2環境だけど、ないものねだりだからあきらめた。
アプリ本体はwin32アプリなのにインストーラーだけ16bitコードの古いインストーラ使ってるアプリがけっこう多かったんだよな
もう十何年も前のことだから、あんまり思えてないんだけど、
ユーティリティソフト類やらゲームがインストーラだけ16bitのヤツが多くて
一時は阿鼻叫喚の様相、になりそうなほどだった
386のころはアドレス空間最上位を実行できる特殊なリアルモード(16bit)だったと聞いたけど
16ビットコードなアプリは仮想マシンでやれってことかな
ttp://matsuri.5ch.net/test/read.cgi/sky/1537927336/l50 VZエディタと16bit日本語環境がVistaで動きました 2
ttp://mevius.5ch.net/test/read.cgi/win/1524997783/ ttp://https://www.youtube.com/watch?v=6dwR7LByCVM NECのワークステーション EWS4800紹介動画
90年代初期かな？3:06のとこでUNIXワークステーション市場が
今後8000億円規模になると、、
でもそのころにはPentiumProが登場してRiscの」優位性が崩れるわけで
出先でUP4800も扱ったことあるわ(こっちはR系)
正直wintelNTワークステーションが普通になるとは思ってもみなかった
×wintelNTワークステーション
○wintelNTワークステーション + Linux
当然ワークステーションやRISC CPUが残ると思ってたし
PC-UNIXもBSD系が天下を取ると思ってた
PC～WSレベルに飽き足らず組み込み制御からスパコンまでWindowsやLinuxとか想像を絶する
21世紀入ってから。ヤフオクなんかで中古が安く出回るようになったが
「今のPCより遅いマシンを買ってもねえ」って感じで購買威力が失せた。
386載せ替えるCPUアクセラレータが流行したころ、住んでた地域の郵便番号が386だったから家人に「どうして郵便番号貼ってるの？」って訊かれた。
上田市民乙
ttp://http://merc.e.u-tokyo.ac.jp/mmrc/dp/pdf/MMRC171_2007.pdf 平成の大合併で上田市になってしまったよ・・・
MIPS16ってのもあるぞ
ARMのもSuperHのも、16bit命令じゃなくて16bit長命令でオペランドは32bitだろ
x86の16bit命令とちがうぞ
初めてのARMって本には、Thumb作ってみたら1度の読み込みで2命令読めるから微妙に性能向上した、みたいな事が書いてあったな。
他にもフラグの状態見て命令スキップする機能とか、いろいろとARMの面白い機能知って「こんな発想するやつがこの世界にいたのか！」って目からうろこが落ちる思いだったわ。
＞初めてのARMって本には、Thumb作ってみたら1度の読み込みで2命令読めるから微妙に性能向上した、みたいな事が書いてあったな
ええと、試してたSoCの内部構造でバス幅が16bitだったとかの落ちがありそうな気がするんだけど……
32bit長命令は2回アクセスしないと1命令読めないから遅くて、16bit長だと1アクセスで1命令読めるから速いみたいな。
もう手元に本が無いから正確にはわからないけど「３２ビットの命令１つ読むコストで２命令読める」という意味の文章だったかもしれない。
物理的に１命令あたりのビット数が半分だから当然だけどさ。
３２ビットバスで一度に２命令読んだら、２つ目の命令はフェッチ済みだからそのままデコーダに突っ込めるし、その分メモリアクセス減るから、微妙な高速化にはなるはず。
エンディアンについても「人はいろいろ言うが、私はリトルが（ＣＰＵにとって）判りやすいと信じるからデフォルトはリトルエンディアンにしたのだ」（これも文章はうろ覚え）って開発者のコメントが書いてあったり、ＡＲＭ入門の読み物としては面白かったよ。
密林に注文するほどでもなし、近所の古本屋巡りで見つけたら買ってみる程度だけど、なんとなくもう一度読みたい本ではある。
もちろん遅いんだけど、そもそも最大でも数メガヘルツとか十数メガヘルツでしか使わん世界、しかも最大クロックで使うことが少ないとかで。
元々CPU性能を要求しない分野だったし
そういうこと
x86の16bit命令は16bitアーキテクチャの8086や286との互換性のために残されてる命令
ARMやSuper Hはそもそも32bitからのスタートだからアーキテクチャ的に16bitの命令は存在しない
ARMやSuper Hの16bit命令はあくまで命令の長さが16bitの命令
x86_64からは特に欠点という欠点もない
強いて言うなら命令のデコードが大変なことと、実質的にIntelとAMDの2社しか使えないこと
ARMのThumbが出てきた時代はまだメモリバスが16bitなんてのも普通にあったからな
任天堂のゲームボーイアドバンスだって
32bitバスのメモリは小容量のみで、メインのメモリは16bitバスのメモリだったようだ。
ARMのThumbは演算命令で利用できるレジスタがR0-R7とかかなり制限が多い
だから32bitメモリバスのシステムでは性能的には落ちる
それを解消してThumbに32bit長の命令を追加して
ARMの大部分の命令をカバーしたThumb-2というのが新しくできて、今はこっちが主流
Thumb-2だとARM命令と比べてもほとんど速度低下はない
＞フラグの状態見て命令スキップする機能みたいな便利そうな機能はThumb命令に含まれないのが残念な感じはある
ThumbはどうだったかわからないがThumb-2ではIT命令というのがあって
IT命令と組み合わせることで同様のことができるよ
x86だと命令長が8bit単位だから命令長が基準だと8ビット命令などと呼ばざるを得なくなって意味不明になるよな
しかも8ビット単位なのはx64命令でも同じままだし
x64の６４ビットモードの命令ってありゃなんだい？ってぐらいに面倒な構成してるよね。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。
――――☆
x86の場合、AMDとIntelの独占状態なのでこの点に問題がある
ARMのいい点はARMからライセンスを受ければどの会社でも使えること
RISC-Vは命令セット自体がフリーなのでさらに自由度が高い
680x0は16bitアーキテクチャとしてはフラットな16MBのアドレス空間が使えて画期的だったけど
32bitアーキテクチャとしてはそれほど優れてるわけじゃない
ただ、68000は命令数が少なくて覚えやすかったのは利点だったな
今は、MicroOPsへの変換やマイクロフュージョン、マクロフュージョンによって
あまり命令セットアーキテクチャの優劣でCPUの性能が決まる時代じゃなくなっている
より高性能な32bit RISCプロセッサの登場によってパソコン、ワークステーションでは衰退
RISCに比べてコード密度が高かったため組み込み分野では使われ続けたが
ARMにコード密度の高い命令セットの16bit長命令が搭載され組み込みの分野でも680x0は衰退
中身の薄い長文書く奴はやっぱりいろいろ認識がおかしいな
32bitアーキテクチャとして不足する部分はごくわずかだ
メモリ間接アドレシングみたいな、アセンブラで書くのには便利だが処理が遅いものを搭載したのが死因じゃないの
アーキテクチャと言うよりインテルの物量作戦に勝てなかったってことだと思う
アキュームレーターとデーターバスが16bitだっけ？
性能とか内部ハードウェアとしては16bitカテゴリだけどソフト書く分には完全に32bitだった
性能問題はモトローラーとインテルの力の入れようの差としか…
重い命令を削除してRISC化したColdFireとかもあったけど
今一番速いCPU(≒Intel86)は命令解釈部分と実行部分が完全に別れていて命令自体の差異は誤差レベルっぽいし
アラブの金持ち()がIntelCPUの命令側を68kの命令にすげ替えたものを作ってくれたら性能的に同等な68kシリーズは作れると思うよ
8086は体も頭も16bitだけど両方とも少々発育不良な感じ
80年代後半に68000は見向きもされなかっただろうな
物量の問題もあるけど、やっぱり内部回路の過剰な複雑化のせいでクロックをあげれなかったのが致命的
68040の33MHzでは486DX4の100MHzと戦えないじゃん
アキュムレータってデータレジスタどれも32ビットのサイズだぞ
16ビットのサイズのレジスタはステータスレジスタだけだ
複雑さだけなら386も相当複雑だよ
命令はバイト単位だしプレフィックスとかもあるし
まあ間接アドレッシングはキャッシュとかメモリーフォールトとかも考えないといけないから大変なのは確かだけど
Z80は4bit CPUダーって言う人でしょ w
アーキテクチャと実装の区別がついてないからスルーでいいよ
すまんレジスタじゃなくて内部の演算回路の事
32bitだったっけ？
ハイハイうざい
アドレスバスもｱﾚだけど。
そのまま置き換えるんじゃなくて回路構成を大幅に変えずに386化できるって話
どこかで見たような気がするがRISC命令に分解できないコードって無いよね
86が今の2層構造になったのってどこからだっけ？
Pentiumまでは普通でPentiumProから2層構造化？
1命令でロードストア命令3つとか4つぐらい含むような厄介なのまであるんだぞ
10命令ぐらいザラなんじゃないかな
今の技術を使えたら、680x0の命令でもそれなりに高速動作するものを作れるだろうけど、
x86に対抗することはできない程度の性能にとどまるだろうしな
うん
68は一部の命令を制限する事で2層構造化する事なくRISCっぽくしたColdFireがあるが
86(386～)は2層構造化しないとRISC化できなかったみたいだし
8086はともかく80386からの86命令は68より複雑じゃないの？
需要とメーカーのやる気やら金やらが無いから仮定の話にしかならないけどね
で、速度が上げられなかった
040やColdFireで簡略化を図ったが時すでにお寿司
○ 直交
強いていうならPentium(Proじゃない)感じか
68kは86に押されて儲からなくなったのか
モトローラが本気で改良続けずPowerPC連合に舵を切った時に命運が尽きちゃった
レジスタ数はある程度多いほうがいいというのは言われてたがな
x86位少ないと無駄なやりくりで脚引っ張るだろ高級言語で特に
いちばん厄介なのがアドレシングモードだと思う
マイクロプログラムを多用しないと駆動できないほど複雑な動作をするアドレシングモードをたくさん用意してしまったのがネック
そこを排除したらそれなりにクロック上がるってのがcoldfireじゃないの？
事情は変わらんのでは
ASMで命令の依存関係を考えながらのコーディングとか面倒そう
複数の依存関係ないコードを合成したりずらしたり
レジスタ待ち合わせによるハザードはレジスタが少ないほど多発するからx86の方がひどいのではないか
一方で、元の命令から生成されるマイクロOP（?）の数は、アドレシングモードの複雑さゆえに68Kの方が多く、ハザードの少なさに反して遅くなりそう
6502のゼロページみたいな
それが逆に高クロック動作を妨げて高性能化を推し進める上での足枷になった
はずなんだが、x86ではあんまり足枷になってるように見えない
話飛ぶけど今のCPUってキャッシュ(メモリー・MMU)のヒットとかパイプラインの乱れ(分岐予測失敗)とかで実効性能が乱高下するから
リアルタイム制御系だと使い辛そう(本職じゃないので憶測に過ぎません)
そこまでシビアな性能が要求される部分を担当したことないってのもあるけど。
あと「実際のコード吐くのはコンパイラ」だしｗ
例えがCPUから飛び出しちゃうけど
線路内に人や車が侵入した事を検知して列車に停止信号を出すシステムが有ったとして
検知→信号を出す時にメモリー不足でディスクが回って数秒間システム停止状態になったら間に合わないでしょ？
今のCPUはCPU単体で似たような事が起こるから扱い辛そうだなって思った
安定したステータス取れるまでの時間は、CPUの命令単位で処理してる階層から見たら時間の単位が違いすぎるから８ビットCPUの頃のように「NOP続けてタイミング調整」なんてのは実現できない。
ただ、「ステータス安定してからンマイクロ秒以内に〇×を処理しなさい」って感じの仕様になることは多い。
タイマーICなりなんなり使ってねって感じじゃ無いかね？
ステート数計算だとCPUクロックの変更にすら耐えられない訳だし。
動作中の消費電力削減は程々にしてスリープ・待機時の電力削減で本気出すのが多い感じだし。
その辺の小規模リアルタイム系だとメモリスワップとか起こさない前提のシステムが普通だろ?
その手のシステムでメモリー不足って言うか動的メモリー確保すらあり得ないから
命令実行時間がキャッシュとかパイプラインストールとかで変わる件は基本最悪値で計算するのは当たり前
キャッシュやパイプラインストールなんてレベルまで行かなくても組込みの設計する人ならWECTは常に意識してないとあかんと思う。
間違えて覚えたらなかなか治らんなぁ、たぶんきっと絶対歳のせいだけど。
上の人も書いてるがそもそもスワップはおろかHDD持ってない（あっても起動時のみアクセスな）のが普通だと思う
OSも同様WindowsやUNIXとうぜん使わず、せいぜいITRONとかのレベル
うまい例が思いつかなくてそういう例を持ち出してしまった
同じく上の人が書いてるけど
たぶん最悪値でってのが正しいんだろうけどスペックシートにそういうの書いてあるのかなとか
コンパイラが出すコードをアセンブルコード出力にして調べるとかやってらんないだろうと思って
古いタイプならテスト環境が用意できれば実際に動作させて間に合うか試せばいいけど
今のはテスト時はOKでもなんかのひょうしでNGなケースが発生するんじゃないかとかそういう事
キャッシュも禁止することができる。
キャッシュの方はプログラム中で設定変えたりもできるはずで、特定ルーチン内だけキャッシュ切って速度測ったり余裕
スワップというかページの概念とか難しくないぞ
処理速度たりなくて実用かどうかのほうがネックになるだろ
パイプラインがアドレス変換のサイクル吸収しちゃって実質的に遅延なしなんてのも今時のCPUなら当然だろうし。
セグメントとページングの両方をもってるx86は贅沢だと思う。
PowerPCにもSRってあるけど、使い方がよー判らんｗ
1.CPU内部の変換テーブルキャッシュに目的のアドレスがあればそれで変換
2.無かった場合は特定のレジスタに記述されたメモリーアドレスから始まる変換テーブルツリーをたどって目的のアドレスを含むテーブルをキャッシュに読み込み、それを使って変換
って感じだからキャッシュヒットしないとだいぶ遅くなると思うよ
シビアな組み込み系はMMUをOFF(にできればOFF)にして使うと思うから関係ないけど
x86はx64じゃなくてもセブメント方式を使えば4GB以上のメモリ扱えるんだけどね
CS=SS=DS=ESの４つは固定でFSとGSをワークとして使えばオーバーヘッド軽減できるのかな？
プロテクトモードで複数セグメントなんてやったことないから、良くわからんｗ
C言語を基盤(他の言語処理系やOSがC言語基盤)とする今のソフトウェアモデルとは相容れないという問題があるのがね
C言語を使う場合はCS=SS=DS(=ES)として扱わないとポインターが正常に機能しなくなるから実質セグメント機能無いのと変わらない
farポインター？…あれはC言語じゃない
え？
IA32のプロテクトモード・・・？
それって美味しい？（VPCI／DPMI使うプログラム書いたこと無いやつ感
DOS時代に64kの壁って、一部で騒いでるやつが言うほどの障害にはにはならなかったなぁ。
640kの壁とEMSのウィンドウが4ページしかないことのほうが障害だった。
C言語の配列宣言でchar[65536]が指定できなかったのは、int86()やintdos()で直にメモリ確保のDOSファンクション呼んで確保した領域をfarなりhugeなり付けたポインタで保持するだけだったし。
Cだけで開発するとかよほど要件がゆるゆるでないと無理。
遅くなるっていうけど、near*とfar*の差も吸収できない能無しなの？
って言われてそれでも「64kｶﾞー」なんてこだわってたら首切られて終わりじゃんｗ
実際、どのコンパイラ使うかってのほうが影響でかかった。
MS-Cの吐くコードは遅かったし・・・
でも会社が指定してきたのはMS-Cだったｗ
DOS時代はまだオールアセンブラのソフトが現役なくらいCPUは遅かった。
むしろWindows初期、90年代半ばまでそうだった。
Windowsには大量のアセンブラコードを含み、至る所で64KBの制限を受けた。
速度必要になるような割込み処理なんかはデバドラやTSRとして実装してTinyやSmallモデルとして実装する、みたいな工夫はしたけど。
Farが～Hugeが～って言うひと、本当にDOSのアプリ組んだことあるのかね？
伝聞をうのみにして出鱈目を言ってるだけじゃないの？？
それともPCでFarが～Hugeが～って言わなきゃならないような仕様を要求されるバカ丸出しの仕事したのが誇りなのかな？？？
farみたいな方言が不要でポインターを正しく動作させるためにはtiny(64k制限有り)か
huge(ポインターはセグメントとオフセットのセット)しかないみたいだね
配列処理やポインターを使ったループ処理なんかで単純にレジスタを加算するのと
オフセットレジスタを加算してからオーバーフローチェック、必要ならセグメントレジスタとオフセットレジスタを調整するのじゃ
倍以上の速度差がでると思うが
当時の今ほど速くないCPUでも気にならない程度だったのかな？
※その程度のコード・データ規模ならtinyで済む気がするが
int ans=0;
for( i=0 ; i < 100000 ; i++)
ans += *(p++);
ってやるより
int ans=0;
for( j=0 ; j < 10 ; j++){
for( i=0 ; i < 10000 ;i++)
ans += p[i];
p+=10000;
}
ってやるように64kに収まる範囲は要素番号指定してやるほうが処理にかかる時間は短い。
ポインタ変数の計算するたびにセグメント：オフセットの計算するから、ポインタを移動させる回数を減らせばそれだけ速度低下は抑制できる。
x86使いなら常識というか、基礎教養レベルで必須の知識でした。
それを知らない人ぐらいですよ、ｾｸﾞﾒﾝﾄｶﾞーってさわぐのは。
huge配列をfarポインタで操作してることを突っ込んだ方がいいんじゃねえの？
farポインタがオフセット部しか可変でないことは常識の知識でしょ。
それだったらもう一度ケーススタディを練りなおして再提出だね。
自分は86Cはtinyでちょっと触った程度だからfarポインター等の仕様はよく知らないけど
それと同じレベルの奴が86を持ち上げてるのか
アセンブラで適当に書いてしまえばほぼ最速コードになる。
それほどCと8086は相性が悪い。
貶すだけならだれでもできるよね。
ｾｸﾞﾒﾝﾄｶﾞーってほんと、馬鹿でクソな人格してるなぁｗ
intで二重ループにしたら速くなるのは言うまでもない。
さっさとまともに動作するの修正コードを書いてみたらどうだ。
オフセットを＋２する。
オフセットが１６を超えてたらセグメントを＋１する。
オフセットを１６で割った余りを、オフセットに入れる。
という感じのコードになるから、そこだけでも後者に比べて遅くなる。
お前が書いて「これが正解だﾄﾞﾔｧ！」ってやってみろよ。
できるならな。
やらない、できないで貶すだけならバカでもできるだろ。
お前はバカだから貶すだけしかできないけどなｗ
速度が問題にならないと言いながら、あーすれば速くなる、遅くなる、とか問題ありまくりじゃないか。
そろそろ認めたらどうだ。8086のセグメントは64KBを超えると途端に面倒になって遅くなるって。
設計者の意図どおり、バンク切り替えのソフト拡張として見れば便利なのは明らか。
いつも思うんだがなぜ286で68000のように32bitもどきのCPUにしなかったんだろうな
そうなってればOS/2 Ver1.xは32bitの仕様になっててコンピュータの歴史も変わってたはず
まだhugeポインタとfarポインタ挙動の違いが理解出来てないようだな。
DOS時代の代表的なC Compilerの一つであったTurbo CのマニュアルをUpしてやるから
よく読んでのコードを修正しろ。
ttp://https://www.axfc.net/u/3944515 人に教えを乞うならば世間には相応の姿勢というものが存在するんだよ。
お前みたいに悪態をつくならば自分の無知を晒し続けろ。
それは正しいがベースが8bitを継ぎ接ぎした16bitだったのが悲劇の始まり
最近は知らないが386は8086として起動して、おまじないを唱えないと32bitにならないよね？
ベースが率直な32bitだったら64bitになるまでは変な苦労と無縁だったのにと思う
基本デザインを別にしても86系はどんどん命令を拡張したため
最新性能と互換性を両立させるために要所で命令セット毎のコードを保持・分岐させるのがあたりまえ
結局コンパイラーやライブラリーに互換性維持を頑張らせてる
昔のバイナリーが最新ハードでそのまま動くという一点のみ68000系より優れているが
64bitになってとうとう16bitコードが切り捨てられてしまいwin3.xのソフトが動かなくなった
インストールさえできたら動くのにインストールできないから動かないってアプリが多く存在した
自分はwin16で作ってソースや開発環境を紛失したソフト（たいしたものじゃない）が動かなくなってしまって悲しかった程度だったし
さすがにいまさら16bitは…なはずだったんだが以外とそういうのが残ってたり
win3.1(PC98互換機用パッケージ)も紛失しちゃったからPC98Emuでも動かせないんだよなぁ
AT用のはPCにプレインストールしてるのばかりだし
98SEがあったはずだけど何処へ行ったやら
互換性維持はユーザーのためだけではなく、ソフト開発者のためにもやってるのに。
今は仮想機能つけてるから、今でも64bitOS上でも仮想PCで16bitOS走らせて16bitコードは動くし、
32bitOS上でも仮想PCで64bitOSを動かすことも可能。切捨てたとは言えない。
あとはレジスタがデータレジスタ、アドレスレジスタと区別はあったが15本あったこと
それだけ8bit、16bitのアーキテクチャと32bitアーキテクチャは別格だということだよな
16bitだと65536までしか扱えないが32bitだと4294967296まで扱える
アドレスにすると16bitだと64KBまでしか扱えないが32bitだと4GBまで扱える
386は汎用レジスタは実質7本で少なかったが32bit化した時にアドレッシングモードを大幅に変更して
直交性を増したのは大きかったな
386程度の32bitアーキテクチャでも性能が出るなら誰も文句言わない
今、32bit、64bitアーキテクチャでフリーなRISC-Vが出てきたがこれが普及すれば
命令セットでの囲い込みが行われることがなくなるから
純粋にマイクロアーキテクチャの性能競争が行われていい時代になるんだけどな
RISC-Vのエコシステムが確立するまでに10年くらい時間がかかりそうだけど
さらにやっかいだったのが16bitのWindows 3.0が普及してしまったこと
Windows 3.0が普及してなかったらDOSは32bit化されてたと思う
結局、Windowsを快適に扱うには486の33MHz以上が必要だったしね
Windowsが普及するのは1993年か1994年頃でよかったと思う
Windows 3.1用のゲームはあまり出なかったからな
Windows 3.0、3.1時代はゲームはDOSだったから
スタックポインタを汎用のアドレスレジスタとして使えるので、
スタックを全く使わないならレジスタは16本だろ
まあスタックを使わないとか考えられないけどな
サブルーチンコールですらスタック使うわけだし
逆に、どのアドレスレジスタも、ほぼスタックポインタ様に使えるので
セカンドスタックとか作れたな
意味あるかどうか不明だが。
あった。
しかも（X68000には関係ないけど）020以降ではスーパーバイザモードが拡張されて二重化したから、A7レジスタは3つに増えた
> まあスタックを使わないとか考えられないけどな
組込みだとRAMのテストが済むまではスタック使わないとか普通にあるよ
> サブルーチンコールですらスタック使うわけだし
68000だとA6,A5辺りをスタック代わりにして2レベルのサブルーチンコールをすることもできた
> セカンドスタックとか作れたな
> 意味あるかどうか不明だが。
ソフトウェアスタックとか普通に作らないか？
二重化って言うか割り込みルーチン専用のスタックが追加された
割り込みルーチンは実行中のコンテキストと関係なく起動されるから別のスタックにするのは合理的
68020以降では分けられたの？
割り込み＝スーパーバイザーモードへの移行って認識だからちょっと状況がよくわからないや
trap命令や0除算等のソフトウェア例外による移行とBusエラーや外部割り込みによる移行が分けられたとか？…やっぱりわからん
TRAP命令とか0割とかのソフトウェアの動作によって発生する例外はMSP(Master Stack Pointer)を使う
ハードウェア割込みとかの外部からの割込はISP(Interrupt Stack Pointer)を使う（現在実行中のプログラムと関係ないから）
バスエラーやアドレスエラーでどっち使うかは忘れた
マルチタスクを念頭にタスク毎に個別のスーパーバイザースタックを持つような実装をするのが楽になる
全体の構成が簡単になるのとプリエンティブはプログラマーが慣れてないとバグを作り込みやすいからだと思う
ちなみにノンプリエンティブなOSはMac OS以外にもWindows 1.x, 2.x, 3.x、Windows 95/98（16ビットアプリケーションの場合）、NetWareとかがある
その割にwin3.1はDOSアプリはプリエンプティブに動くっていう
必然的にウインドウシステムのイベント駆動に乗っかったマルチタスクになったんじゃないかな
最初からプリエンプティブマルチタスクを実現しよういう興味が無かったと思う
イベント駆動型のほうがCPU負荷が軽いという理由が言われていた(実際そうだ)けどAMIGAという化物があるし…
Win3.xのエンハンスドモードはOS/2と喧嘩別れしたために後付した苦肉の策かな？
※OS/2は普通にプリエンプティブマルチタスクなDOSの後継「OS」を作ろうとしていた
詳しく知らないけどエンハンスドモードはCPUの仮装86モード？を使って複数の8086仮装マシンを動かして
そのうちの1つをWin3.xに他を個別のDOS窓にしていたとか
そのせいかWin95でもWin3アプリは「Win95用のWin3.x」みたいな単一プロセス(仮想マシン？)を動作させて全てその中で実行されてるとか
Windows 3.0にも386エンハンスドモードはあった
Windows/386という製品がそれ以前にあったしね
単純に性能の問題かMacに倣ったのか
上に書かれてるようにシンプルだからか>Win
んで、3.0ではいまだ追加機能、オプション扱いだったエンハンストモードが3.1でデフォルト化されてスタンダードモードの方がオプションに変わった気が
32ビットのDOSアプリはサードのDOSエクステンダ使ってたな
MSがオフィシャルのDOSエクステンダを…言いたかったけど
Windowsがそれだった
ざっくり言うと
Human68K = MS-DOS
SX-Window = Windows 3.1（ノンプリエンティブ）
って感じ
AMIGAはプリエンプティブマルチタスクなマイクロカーネル+DOS+GUI
UNIXを生んだケン・トンプソンとAMIGAを生んだカール・サセンラスは個人的に信仰する神
Windows3.ｘみたいなマルチウィンドウもなくて、スマホみたいに全画面表示のアプリを切り替える程度だったんだっけ
背後に隠れた状態のアプリが処理を継続する必要がある場合って、あんまり多くなさそう
重い処理させて待ち時間中に別作業、みたいなことに耐えられるほどCPU性能が無いから、マルチタスクの必要性も低かったんじゃないかなあ
プロセッサの能力と言うよりメモリーの制限で複数のプログラムを実行させるのは実用的でなかった
デスクアクセサリっていう例外はあったな
DA枠でとんでもなく重くて多機能なアプリ作ればいいっていう流れになって
Finder代わりにアプリ使用中に使うファイラーまであったんだよな
その人が退職したら速攻で職場からアップル製品がなくなったｗ
サポ切れでやむなく
もともと役に立っていなかった
どれだろう
全国的に珍しい地域とは言われてたけどWinよりMacのが使われてる地域だった。
地元の商工会議所主催のパソコン教室ではMac使わされたし。
でも会社は本社が東京だったんで本格的に導入したのはDOS～Winの流れｗ
Human-OSなんてMS-DOSを68に単純移植しただけの代物。
ただ、日本で68用に真面目に最新OS開発してた層は存在してなかったし、アプリは98使ったクロス開発になるのが目に見えてたし、ファンクションコールもファイルフォーマットもDOSコマンドも98に合わせるのは現実的な仕様だった。
ゲーム機で忙しいハドソンがOSもC風味BASICも開発したんだし、できることは限られてる。
アセンブラで小物しか作らなかったからBG実行する程でもなかったわ
X68000が出るより何年か前、新規開発中もしくは構想中の斬新なOS諸々の中にハドソンが開発してるというHuMAN OSってのがあったが、
X68000に採用されたHuman68kとは似ても似つかない豪勢なシロモノだった。
結局は夢想の中に消え去ったけど、ホントに出てたら面白かっただろうにな
OS-9/X68000なんてものもあったんだけどね
…純粋なマイクロカーネルでそこそこ成功したのってQNXとMINIX3.x位かな？
お陰でジョブズとOS Xを手に入れた。
ちゅーかコーラ屋上がりのCEOが追い出してしまったのを
当時の偉い人が土下座してまで復帰させただろ
アップルにOSを作る技術力はない。
なんかこう……
Beがふっかけてこけなきゃねぇ
結果的にOpenStepで良かったんだろうけど
リリース断念って、完成させられなかったから断念したんだぞ
途中までしか作れなくてな
あと、ジョブズはネクストの商売をする前は商売ベタだった
あのときに大化けして成長した結果として、後の大成功があると思う
パフォーマンスは上手いが他は駄目
ジョブズのアイディアとされるものって部下のアイディア横取りしたものばかりじゃなかったっけ？
ウォズニアックを詐欺った件でアンチだから色眼鏡かけちゃってるが
口が上手い山師とか詐欺師の類だと認識してる
887的に言うなら逆で、名騎手となるためには自分の乗馬より速く走れなければならない 的なことになっちゃうね
秋葉原でBeBoxの実機見たけど、ただの憧れで終わっちゃたよ(´･ω･`)ｼｮﾎﾞｰﾝ
Dos/Vに移植されたときも、持ってたPCが動作スペックを満たしてなかったんで断念
成果物の質量共に勝ってるのに残業をしないという理由で能力が少ないために長時間残業してしかもできの悪いものしか作れない奴のほうが高評価なのがあたりまえ
ちゃんと（すくなくとも周りと比較すれば）水準以上の労働成果を残してるのに「サボるな楽するな残業しろ」と仕事を追加して給料据え置き（かつ忠誠心不足だとマイナス評価）とか
ジョブスに関してはジョブズの元で働いた事が無いから実際のカリスマ性・リーダーとしての脂質・経営能力はわからないが
外野から知りうる事としてプレゼンテーションがとても上手な事
ウォズを騙して報酬を掠め取った事や部下のアイディアを一旦却下したのに後で自分のアイディアのように持ち出し成功した等
伝え聞くエピソードから判断すると詐欺師になる
ヒトとしてはジョブスのほうが数段マシのようだけど。
気が向いたらくやしく
＞Human-OSなんてMS-DOSを68に単純移植しただけの代物。
似せようとしてただけで、ぜんぜん移植じゃないでしょ
むしろ外見以外の類似点が少ないと思う
移植ではないがCP/MとDOS Ver.1位の違いしかない。
…ところで(86)開発って逆アセンブラしてたのかな？
N88-BASIC(86)は外部仕様のみ互換、要するに見た目同じ挙動するように作り直しただけ
Pentiumの133で動かしても動作がV30の16MHzより遅かったな
GDI窓に一生懸命描画してる様子はGHz超えの今でも健在
なんだそりゃあ
スピードまで互換を持たせるようにわざとウェイト入れてるのかね
実物のN88とは挙動すら別物で
ただ似たようなフリをしてるだけのオモチャだよな
まぁ個人製作のフリーウェアだから仕方ないが、
高校数学のBASIC選択問題を解くのにすら使えるか怪しい
小数点計算の桁精度も違うし、末尾の誤差もある（PentiumのFDIVバグ持ち石ならそれも発言し）
グラフィックモードの描画フォントも漢字ROM書体じゃなくMS明朝
テープメディアの読み書きも省略
当時のソフトはまず何一つ動かなかっただろう
ネイティブアプリを生成可能なN88系BASICだろ
コンパイラは別売りじゃなかったっけ?
中間言語とランタイムのインタプリタをパックしただけのもんだろ
ちゅーか.NET Framework対応のN-88系が欲しいんだよ
スプライト関係はMSX BASICから流用してもいいけどな
頑張って自分で作れよ。今時、行番号制のプログラミング言語なんて需要ないと思うけど
家の中さがせばN88BASIC（V2）のリファレンスマニュアルがあるはずだけど、探す気力がががが・・・
CUIのみとかならそれほどでもないかなついでにファイル操作とお絵かき出来れば結構実用に
俺はできないが。
N88BAISCのマニュアルなんてどっかにやっちまったよ！
BASICならあるが
買ったばっかりのノートPC使ってんだけど、キーピッチが広くなりすぎで打ち間違いが多いのよｗ
スクエアなディスプレイのB5ノート（昔風に言うならサブノート）から今どきのフルHDのA4（より大きいやつ）ノートPCに変えたばっかで・・・
さて、秋葉いってくるかな。
定期で行ける地元民でよかったぜ（天気悪いけどｗ
