8086 vs. Z80 vs. 6809 vs. 6502　その14

1 ：ナイコンさん：2021/03/16(火) 23:44:11.88 .net

8086(8088)・Z80・6809・6502のうち、どのCPU(MPU)が優れているか議論するスレッドです。
CPU(MPU)アーキテクチャや周辺デバイス制御など
基本的に「石」に関連する議論なら、ほぼ何でもアリです。


　　　　　♪　　　　／.i　　 ／.i　　／.i
　　　♪　　　　 ∠__ノ　∠__ノ　∠__ノ　　
　　　　　　 　〈,(・∀・;)ノ・∀・;)ノ・∀・;)ノ
　　 　 　　　 └i===|┘i===|┘.i===|┘
　 　 　 　 　　 〈＿_〈　〈＿_〈　〈＿_〈

■過去スレ
8086 vs. Z80 vs. 6809 vs. 6502　その13 [無断転載禁止]©2ch.net
https://matsuri.5ch.net/test/read.cgi/i4004/1474548959/

8086 vs. Z80 vs. 6809 vs. 6502　その12 [無断転載禁止]©2ch.net
http://hanabi.2ch.net/test/read.cgi/i4004/1468637057/l50
8086 vs. Z80 vs. 6809 vs. 6502　その11 [無断転載禁止]c2ch.net
http://hanabi.2ch.net/test/read.cgi/i4004/1462424764/
8086 vs. Z80 vs. 6809 vs. 6502　その10
http://hanabi.2ch.net/test/read.cgi/i4004/1407651926/
8086 vs. Z80 vs. 6809 vs. 6502　その9 (再び)
http://hello.2ch.net/test/read.cgi/i4004/1365951318/
8086 vs. Z80 vs. 6809 vs. 6502　その9 (短命)
http://ikura.2ch.net/test/read.cgi/i4004/1362833400/
8086 vs. Z80 vs. 6809 vs. 6502　その8
http://ikura.2ch.net/test/read.cgi/i4004/1333965297/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

484 ：ナイコンさん：2021/05/28(金) 05:49:23.16 .net

> 8086(8088)・Z80・6809・6502のうち、どのCPU(MPU)が優れているか議論するスレッドです。
って書いてあるから誤記ではないと思う
まあ8080(8008)の誤記の可能性もあるけど…

485 ：ナイコンさん：2021/05/28(金) 08:56:47.08 .net

>>474
32bitに拡張して4GBのゼロページにすれば問題解決やな

486 ：ナイコンさん：2021/05/28(金) 10:23:48.28 .net

16bitジレスタあり 8086、Z80、6809
16bit演算可能 8086、Z80、6809

違和感、浮いてるのはむしろ6502だけである。

487 ：ナイコンさん：2021/05/28(金) 12:09:40.23 .net

アドレス計算のための16bit演算をいちいち命令並べて実行しなきゃならない80系が気持ち悪い
経営最優先で未完成のゲテモノを世に出した迷惑intel

488 ：ナイコンさん：2021/05/28(金) 12:27:11.37 .net

気持ち悪いと思うのは勝手だが
アドレシングモードのないプロセッサが優秀だと思ってる奴は居ないんだし目の敵にする意味がわからん

489 ：ナイコンさん：2021/05/28(金) 12:29:08.52 .net

>>485
じゃなくて、ワークエリアとして使うゼロページの部分が固定アドレスのままだとリロケータブルじゃなくないか?

他のプログラムとバッティングしないように頻繁に待避させるとかするのかな?

490 ：ナイコンさん：2021/05/28(金) 14:37:45.21 .net

>>486
プログラミングでCPU(MPU)を意識する際はアセンブラだろうけど「8086」だとハードルが高い。
「8086」でのアセンブラベース開発では効率が悪く無くなって行ったのではと。失敗談を聞きます。
なのでCPU(MPU)を意識する際に他の8ビットと同列に「8086」を語るには違和感が残ります。
また、Z80も16bit演算可能と言ってますがSUBはないので、説得力が弱い印象を受けます。

ただ、Z80にしても6502にしてもCPU(MPU)の制約があっても開発環境で補うことができたと思う。
当時は日本に6502を使うPCがほとんど存在せず性能が判らなかったけど意外と使えたのでは。
何より実用的には「VisiCalc」が存在して、ゲーム機としては「ファミコン」の成功があります。
下で「Z80 vs 6502」の比較をユーザーとして語ってる人がいます。 尚、自分は6809ユーザーです。
ttps://www.wizforest.com/tech/Z80vs6502/index.html

491 ：ナイコンさん：2021/05/28(金) 15:02:40.30 .net

ヤマハのYISに使われた6502はゼロページが複数あったとか
実装方法は謎だがAm9511やZ8001やハードウェア直線発生とかなんとも凄まじいマシンである

492 ：ナイコンさん：2021/05/28(金) 15:06:06.04 .net

ゼロページをCPU内蔵のローカルメモリなりにしてバンク切り替えしたらいいんでは

内蔵じゃなく外部メモリでもバンク切り替えなら複数のゼロページは持てるけど、それ以外の部分のメモリと別枠でバンク切り替えが要るから、内蔵の方が楽だと思う

493 ：ナイコンさん：2021/05/28(金) 16:44:24.09 .net

>>490
> なのでCPU(MPU)を意識する際に他の8ビットと同列に「8086」を語るには違和感が残ります。
お前8bit CPUでアセンブラ使ったこと無いだろ
8bit CPUで済む範囲なら同列どころか8086の方が全然楽だぞ
64KB超えると面倒になるけどそもそも8bit CPUだと外部ハード無しで64KB超えられないし

494 ：ナイコンさん：2021/05/28(金) 17:40:39.81 .net

>>492
全てのメモリを汎用レジスタとして使えるようにしようTMS9900みたいにね

495 ：ナイコンさん：2021/05/28(金) 19:12:27.37 .net

>>493
6809ですが使ったことはあります。尚、8bitCPUのアセンブラでも8086機で
クロス開発した方が楽とは考えますが、システム的に8bitで対応できるのに
何故わざわざ回路が複雑になる16ビットにするのかと、疑問が深まりました。
なので、どのようなシステムで8086を使ったのでしょう。尚、8bitCPUで
対応できない時は8086を使うとして「C言語」コンパイラが効率的と考えます。
勿論、8bitCPUでも可能なら「C言語」コンパイラが効率的と考えますけど。
因みに下は上手く表示できるか否かは判りませんが自分のコード例です。

CLRA
STA MFDA2
STA MFDA3
COMA
STA MFDA6
LDA MFDA0
LDA #$83
STA MFDA3
LDA #$2E
STA MFDA5
RTS

496 ：ナイコンさん：2021/05/28(金) 20:15:11.60 .net

>>495
何を言いたいのかさっぱりわからんがとりあえず
> 「8086」でのアセンブラベース開発では効率が悪く無くなって行ったのではと。失敗談を聞きます。
が脳内でないなら実例書いてくれ

497 ：ナイコンさん：2021/05/28(金) 21:37:46.64 .net

>>495
80年代前半で8086を積極採用していた業界は半導体製造装置とか
三軸同時制御的なアームロボットメーカーとかだね。東京エレクトロンとか
富士通ファナックとか。東エレはインテルの代理店もやっていたね。
ファクトリーオートメーションの世界では年追うごとに要求仕様が複雑化
高速化ネットワーク化していたから16bit移行は早かった。PL/MコンパイラとかICEとか。
かいはつかんきょうもよかった。対して68000やz8000にはマトモなICEが無かった。
組み込み業界ではムリぽだったみたいね。

制御モンでもパソコン用のプリンターとかの小型スタンドアロン機器は
は普通4/8bitCPUだった。ビデオデッキやエアコンとかは4bit。

498 ：ナイコンさん：2021/05/28(金) 21:50:56.67 .net

>>496
趣旨としては8bitCPUならアセンブラでも失敗せずに開発が可能と言うことと
16ビットでアセンブラなら開発効率は悪いし失敗の可能性が高くなると言うことです。
16ビット以上ならCPUを意識しない、高級言語を使うことが賢いのでないかと言うことです。

尚、失敗談は脳内ではなく実例で聞いていますが、先ずは貴方の下の疑惑に応えましたから
＞お前8bit CPUでアセンブラ使ったこと無いだろ

次に順序としては貴方が本当に「8086」をアセンブラで使っていたことの明示が先ではないなと。
貴方のレスかは特定できませんがZ80で16bit演算可能と言ったことで「えー、減算はないけど」と
逆に貴方にZ80でさえ本当にアセンブラを使っていたのか疑惑が湧いています。因みに下が質問です。
1）何故わざわざ回路が複雑になるのに16ビットにするのか？
2）どのようなシステムで8086用のアセンブラを使ったのでしょうか？

499 ：ナイコンさん：2021/05/28(金) 21:52:25.24 .net

> Z80も16bit演算可能と言ってますがSUBはないので、説得力が弱い印象を受けます。
SBC、DECあるだろう。6502にadd命令がないから8bit演算できないと言ってるようなもの。

500 ：ナイコンさん：2021/05/28(金) 22:07:34.78 .net

1)速度が必要だから
2)速度が必要なシステムで

486ですら速度に対する要求は満たされておらず、エディタですらフルアセンブラであることが売り文句になった。
vzはめちゃくちゃ売れた。

501 ：ナイコンさん：2021/05/28(金) 22:10:52.53 .net

8086ならCでも十分高速だから
アセンブラ派が少なくなっただけだろ？
使いにくいと言うか、Z80のアセンブラよりはずっと楽

502 ：ナイコンさん：2021/05/28(金) 22:24:31.11 .net

> 8086ならCでも十分高速だから
BASICと比べたらな。

503 ：ナイコンさん：2021/05/28(金) 22:34:08.52 .net

>>497
自分が書いてるうち応えてくれたので、先ずは応えます。
1）MSがアクセスを販売する前後に某大手メーカーが類似品を「8086」ベースのマクロアセンブラで開発して失敗とか。
自分は失敗後に配属され「C言語」で完了していたので「8086」ベースのマクロアセンブラの失敗を先輩が嘲笑してました。
2）「Z80」ベースかも知れないけど後に任天堂の社長になる故岩田氏のC言語を使う決断で企画を成功に導いたとか。
ttps://www.4gamer.net/games/999/G999905/20151225009/

因みに1980年代半ばならパソコン用のプリンターでは表示用にセグメントではないリニアな空間が必要なので
「68000」が使われることもありました。1990年頃にはインテルのリニアなCPUが使われて開発に参画しました。

それで貴方が実際に製作に関わったシステムは何ですか？

504 ：ナイコンさん：2021/05/28(金) 22:42:47.25 .net

アイレムのM72がV30使ってたけどな
R-TYPEとかのシステム基板で当然アセンブラ使ってたはず
自分はMS-DOSでアセンブラのソフトをいくつか書いたけど、Z80や6800、6502に比べると書きやすいよ
まあ68000よりは落ちるけど
Lotus123はアセンブラだったはずだし日本ではVzもあったし、TSRはCでも書けたけどメモリ節約のために普通はアセンブラだった
デバイスドライバもFEP以外はアセンブラが多かったと思う

505 ：ナイコンさん：2021/05/28(金) 22:51:09.66 .net

>>503
> 1）MSがアクセスを販売する前後に某大手メーカーが類似品を「8086」ベースのマクロアセンブラで開発して失敗とか。
それZ80なら成功してたのか？
8bit時代とは規模の違うものを出してきて8086のアセンブラは効率悪い言ってるだけにしか見えない

> それで貴方が実際に製作に関わったシステムは何ですか？
社内の設備屋だったから結構CPUは自分の好みで決めれたからHD6301, MC6809, MC68000, i80186, MC68020とか使ってたよ
6809まではフルアセンブラ、68000はForthを自力で実装してその上でアプリを書いてた
80186以降は基本CだけどブートとかI/O周りはアセンブラ

506 ：ナイコンさん：2021/05/28(金) 22:59:09.64 .net

>>499
「SBC」や「DEC」を使って16bit数値から16bit数値を引く減算のアセンブラコードを明示して下さい。

507 ：ナイコンさん：2021/05/28(金) 23:00:35.46 .net

>>503
アクセスって事はデータベースなんだろうけどdBASE IIはアセンブラだったはず
dBASE IIIでC言語で書き直されて性能低下したという話だったような
ようするに成功するか失敗するかは開発者の技術力の問題なだけで嘲笑したという先輩もたいした事はないですな
8086出始めの頃はメモリも高かったし速度も必要な場合、普通にアセンブラを使ってたはず
C言語にしても性能が良くなるまでには時間がかかった
繰り返しますが8086はコードデータがそれぞれ64Kに収まるプログラムであれば8bitCPUより書きやすいです

508 ：ナイコンさん：2021/05/28(金) 23:02:16.39 .net

アセンブラコードを多く含んたWindows95が大成功してる時点でなあ。
この人は一体なにが言いたいのだろう。ADC、SBC、DECの使い方知らないとかアセンブラど素人じゃん。

509 ：ナイコンさん：2021/05/28(金) 23:10:00.57 .net

キャリーフラグ知らなかったMIPS君かも

510 ：ナイコンさん：2021/05/28(金) 23:12:08.05 .net

>>503
岩田氏の記事ちゃんと読んでる？ゲームボーイのアセンブラソースをNintendo64用のC言語のソースにコンバートしたって話だよ
8086全然関係ないんだけど
あと組み込みでは意外と8086使われてるんだよね
そりゃ画像処理が必要なプリンタとかでは採用されないけど
適材適所って言葉知ってる？

511 ：ナイコンさん：2021/05/28(金) 23:18:24.32 .net

アセンブラソースをCにコンバートってこのスレの住人クラスならすげーって感じにはならないと思うが。
z80ならバイナリ直読みで解析する人も多いんじゃないかな。

512 ：ナイコンさん：2021/05/28(金) 23:19:14.62 .net

>>506
Z80のSBC命令だと16ビット値を入れたペアレジスタ（レジスタペア）の引き算ができるんだから、あらかじめキャリフラグをリセットしとけば普通に引き算できるだろ?

513 ：ナイコンさん：2021/05/28(金) 23:23:14.58 .net

>>504
なるほど。「68000」に思入れがあるのか、実際に使いやすいのかは判りませんが
このレスは納得しました。

>>505
＞それZ80なら成功してたのか？
意図が判りかねます。MSがアクセス販売する頃に類似品でZ80ではメモリ足りなすぎなので。
それで16bitになる訳ですがアセンブラで失敗したと言う事実を例示したまでです。
ともあれ、貴方の話が本当なら貴方は比較的優秀なのではと。

しかし、その貴方も8bitまでならアセンブラで、16bit以降は「C言語」ではないにしても
ハードとのインターフェース以外では高級言語を使っていたと言うことになります。

514 ：ナイコンさん：2021/05/28(金) 23:30:52.47 .net

いやだから8086で普通にアセンブラでかかれた大きめのソフトの例をいくつもあげてるんだけど
自分も色々なCPUでアセンブラでかいてきたけど8086は書きやすい部類にはいるよ
だから8086でアセンブラで書くのががハードルが高いってのはない
データベース類似で失敗したのは単に技術力がないだけ
あなたも書き込みみてると技術力あるとは思えないけどね

515 ：ナイコンさん：2021/05/28(金) 23:34:19.71 .net

マーケティング上の成否と開発言語を結びつけようとしてるのかな？
z80vs6809しかり、x86vs68kしかり、VHSベータ戦争しかり、DVD戦争しかり。

性能の違いが戦力の決定的差ではないということを坊やに教えねばならんな。

516 ：ナイコンさん：2021/05/28(金) 23:37:15.44 .net

貧乏システムハウスに転職してターボアセンブラのEXEファイルをROM化したなぁ
ミニコンのアセンブラソースを元にした改修だったから何とかなったけど
EXEファイルの解析なんてどうやったんだか完全に記憶がない

517 ：ナイコンさん：2021/05/28(金) 23:40:52.72 .net

>>508
商業的にはWindows95は大成功したかも知れないが、落ちまくって酷いと言う話は耳に入らなかった？

>>510
最後まで読んだかな。君は自信家みたいだけど自分の失敗を他人のせいにしたことがあるのではと？

HAL研究所の三津原氏が下のように言ってるけど、MOTHER2は「スーパーファミコン」が最初じゃないのか？
　あと，岩田さんの指示で印象的だったのは，C言語を使う決断をしたことでしょう。
　当時の一般的なゲーム開発はアセンブラで行っていたのですが，開発期間も長いしデバッグも大変だったんです。
　だから，C言語で作ったほうが開発速度が速くなる（MOTHER2のような，大規模なRPGの場合にはとくに）という確信が
　岩田さんの中にはあったようでした。

518 ：ナイコンさん：2021/05/28(金) 23:46:42.69 .net

C89で標準化も終わった90年代にアセンブラからC言語で開発しようという判断なんて普通すぎる話だが
あんたの論点がさっぱり分からん。

519 ：ナイコンさん：2021/05/28(金) 23:51:52.02 .net

>>517
あー最後まで読んでなかったすまんすまん
で、それと8086のアセンブラがハードルが高いのとどういう関係があるの？
あとWindows95も使ってたけど言われるほど落ちたりしなかったよ
デバイスドライバとかにも影響されるし人によるとしか言いようがない
そりゃNT系のカーネルよりは安定しなかったけど

520 ：ナイコンさん：2021/05/29(土) 00:17:11.16 .net

>>518
だから、君のような技術的に優秀な人が8086を駆使できれば値があったことは認めるにしても
話の始まりは、そもそも機能が上の「8086」を他のCPUと同列に語ることに違和感がある、と言う事。
　　
>>519
自分の間違いは「すまんすまん」で済ます、ちゃっかり者ですか。君のような人は今後を注意して行きます。

521 ：ナイコンさん：2021/05/29(土) 00:33:46.55 .net

>>514
＞あなたも書き込みみてると技術力あるとは思えないけどね
そうかも知れないが、ただし君が絶対正しいと言う訳でもあるまいにと。

>>519
＞あとWindows95も使ってたけど言われるほど落ちたりしなかったよ
その局面と頻度が問題なるかなと。
1）そもそもが16ビットと32ビットのハイブリッドの起因（GDIだったか？）でメモリリークで落るとか
2）途中まで作ったVBアプリで更にカスタムコントロールの貼りつけで落るとか（一旦分離して再結合でクリア）
3）ウィンドウハンドルのないコントロールを整理するためにアプリ終了後に落るとか

とにかくメモリ管理の問題が酷かった、今でも名残がある感じ、ローカライズとかも。

522 ：ナイコンさん：2021/05/29(土) 00:35:19.35 .net

8086が高機能だなんて照れますな。後発の6809君に悪いですよ。

523 ：ナイコンさん：2021/05/29(土) 02:40:19.25 .net

自称6809使いがZ80のSBC、DECの使い方が分からないという謎

524 ：ナイコンさん：2021/05/29(土) 05:09:46.21 .net

>>520
> 話の始まりは、そもそも機能が上の「8086」を他のCPUと同列に語ることに違和感がある、と言う事。
ならはじめからそう書いてくれ

> プログラミングでCPU(MPU)を意識する際はアセンブラだろうけど「8086」だとハードルが高い。
> 「8086」でのアセンブラベース開発では効率が悪く無くなって行ったのではと。失敗談を聞きます。
だとどう見ても8086はアセンブラでは開発しづらいクソCPUと言ってるように見える

> 自分の間違いは「すまんすまん」で済ます、ちゃっかり者ですか。
まあこれ見る限り煽る気満々なんだろうけどそこまで言うならこんな意味不明な文章書いてたら失笑されるだけだぞw
> 君のような人は今後を注意して行きます。

525 ：ナイコンさん：2021/05/29(土) 06:29:52.11 .net

互換性重視で拡張された8086より
6502のゼロページアドレッシング使いこなすほうが普通に難しい。

526 ：ナイコンさん：2021/05/29(土) 08:19:39.16 .net

6800のゼロページの高速化改良なんだから、6800を使いこなしてる人が使うのが簡単か難しいかでしょ
8080を使いこなしてる人が互換性有る8086を使うのと比較してどうするのよ

527 ：ナイコンさん：2021/05/29(土) 08:50:37.64 .net

6502は6800の高速改良というよりさらにトランジスタ削るために
徹底的にチープ化した結果の完全8bit縛りであって16bitレジスタ持ってる6800のノウハウは役に立たない。
そもそも6800機がないので6800熟知してる奴がまずいない。

528 ：ナイコンさん：2021/05/29(土) 12:07:58.60 .net

ゼロページと似たようなのが、組み込み用の8ビットCPUで広く採用されてるみたいだし、わりと便利だったんじゃないの

昔のSHARPのポケコンのカスタムCPUとか、マイクロチップ社のPICとかにも使ってたでしょ？

529 ：ナイコンさん：2021/05/29(土) 12:44:21.76 .net

>>524
君は捻くれてるのか？ 話の発端が、「8086」と「8080」の比較（>>481）で
「8080」なら他の3種類のCPU（MPU）とほぼ同性能だけど16ビットの「8086」では
性能が違い過ぎて、どのCPU(MPU)が優れているかの議論は無駄でしょ、って趣旨。
ただ使い方の例を明示して「8086」で実際にアセンブラ使った話は面白かった。

尚、煽る気は微塵もない。「煽り」と言って自分の勘違いを正当化しないで貰いたい。
他人は見下すし、自分の間違いは「すまんすまん」では上から目線で何様なんだろうな。

481ナイコンさん2021/05/28(金) 00:16:31.89
それとスレタイにある「8086」は「8080」の間違いではないかとの指摘がある。
「8086」は違和感大有り。脱線は阻止できないけどスレタイだけでも修正できないかな。

530 ：520：2021/05/29(土) 12:54:08.49 .net

追伸
煽る気は微塵もなかったが自分の間違いには寛容で余りに尊大な態度に
一言嫌味を言いたくなったことは認める。ギリシャ文字の人を連想した。

531 ：ナイコンさん：2021/05/29(土) 13:02:51.77 .net

>>528
MELPS740ファミリって素の6502上位互換な組み込みCPUのベストセラーもあるしな
ゼロページ分のRAMをチップ内に内蔵してたりして、
レジスタのように使うと言うよりレジスタそのものになってたりするがバイナリ互換で使える

532 ：ナイコンさん：2021/05/29(土) 13:51:04.57 .net

>>507
初代8801の頃に売れていた日本語ワープロの文筆は最初はテープ版。
ver2がDISK版。どっちもBASIC記述だった。次版は機械語版で出す。
とアナウンスしていて開発停滞でウダウダしている内に倒産。
失笑モノだったっすね。BASICと機械語の間にはポインタという小川が
あるけれど、それすら渡れないとかね

533 ：ナイコンさん：2021/05/29(土) 14:04:33.09 .net

>>529
8080は8224とか8228とか必須で単独使用は面倒。それ故の8085。ところが
DRAM制御を8080/85で行うのは面倒。z80はリフレッシュ信号有りで簡易。
intelは8202とかいうDRAM制御ICもあったが高価杉。z80がパソコン利用で
主流になれたのはDRAMとの相性に良さだよね。って常識か。

534 ：ナイコンさん：2021/05/29(土) 14:21:57.79 .net

>>509
俺はなぜかMIPS君と呼ばれてるんだが
初めて覚えたアセンブラは8086だからキャリーフラグを知らないわけないぞ

MIPSでADD命令やSUB命令使ってオーバーフローが発生すると
トラップが発生するから使い物にならないとか言ってて
トラップが必要ない演算(C言語では普通トラップは発生させない)では
ADDUやSUBUを使うことを知らない無知だったのはMIPS君呼ばわりする人の方
彼はキャリーフラグがなくても32bit CPUで64bit演算ができるのを知らなかったしな

535 ：ナイコンさん：2021/05/29(土) 14:26:14.22 .net

CP/M86の8086のアセンブラASM86はCP/Mとかの8080コードをソーストランスレータ
とかで逐行8086変換してアセンブルする64kスモールモデルなcomファイル用途で簡易。
アレでミディアム-ラージモデル記述は難しかったろうね。MASMはセグメントディレクティブ
をそれなりにサポートしてはいたがintel純正のROM焼き目的なASM86のシンタクスの
サブセットだったっすね。com/exeファイル生成できればいいわけでという。

536 ：ナイコンさん：2021/05/29(土) 14:30:57.42 .net

まあ、8086は8bit CPUに比べれば断然アセンブラで書きやすいと思うよ
あくまで8bit CPUと比べてだけどね

16bitでは最初に出てきたつなぎのマイクロプロセッサなので8bitと16bitの中間的なのはしょうがないよね
だけど、16bitでは8086が普及してしまって
DOSの末期や16bit Windowsの末期は大変なことになってしまった

Windows 95があれだけ絶賛されたのは8086ベースのDOSや80286ベースのWin3.xがそれだけ酷かったから
だけど、支持されたのはビジネス向けではパソコンは
表計算ソフトとワープロ、会計ソフトが使えればそれでよかった時代だったから
動画編集はまだパソコンでは荷が重かったし、画像編集やDTPはMacの独壇場だったしね

537 ：ナイコンさん：2021/05/29(土) 14:35:46.11 .net

Z80は、レジスタの扱いの制限がなくて対称性が実現できていたら、もう少しコンパイラと親和性出たのかね？

538 ：ナイコンさん：2021/05/29(土) 14:51:44.35 .net

>>537
Z80伝説という本によるとザイログはZ80でUNIXのようなマルチタスクのOS作って
Z-Netとして販売してたらしいよ
でも売れなかったらしい
需要がなかったんだろうね

16bitCPUではマイクロソフトがいろいろな16bit CPUにUNIXを移植して
ZENIXとして販売してたし
Z8000ではUNIXが移植されてミニコンとして販売されてた模様
68000はApolloやSunのワークステーションに使われたのは有名な話

539 ：ナイコンさん：2021/05/29(土) 15:20:08.54 .net

>>536
ラージモデルでセグメント境界ごえアクセスを多用するだけでも少しばかり面倒なのに、EMSメモリとか、一部の用途だけとは言えハイメモリ領域を駆使してメインメモリを圧迫しにくいのを書いたりとか、面倒な使い方が続々と開発されてたよなあ

540 ：ナイコンさん：2021/05/29(土) 15:23:29.84 .net

>>537
コンパイラのはくコードとか見てみたら、レジスタ使用の対称性って、意外と必要ないんじゃないかと思った
X68000の純正cコンパイラとか、68000ならではの対称性の高さもレジスタの多さもぜんぜん活用されてなかったしなあ

541 ：ナイコンさん：2021/05/29(土) 15:55:45.64 .net

68000のおかげでエンジニアリングワークステーションが誕生したからね
ApolloなりSunとかのね
それまではその分野で大きなミニコンが使われてたわけで
それだけでも価値あったのでは？
68000が良すぎたのでZ8000はあまり相手にされずに消えていった

542 ：ナイコンさん：2021/05/29(土) 16:05:30.14 .net

Z8000ってトランジスタ数は減らしての高性能を狙ってて、
量産さえ進めばコスパ良くなりそうだったのにな

543 ：ナイコンさん：2021/05/29(土) 16:06:51.44 .net

8086が出た時代はあれでよかったけど
80286で68000のようにレジスタの32bit化をしてほしかったね
そうすればDOSの末期にあんな酷いことにならなかった
時代は32bitもどきの16bit CPUを必要としてた

544 ：ナイコンさん：2021/05/29(土) 16:18:19.19 .net

>>537
IXとIYの代わりにSP相対アドレッシングとHL相対アドレッシングとを追加すれば良かったんじゃないかな
追加レジスタ操作に1バイト増やすくらいなら、更に1バイトアドレッシングに使って2バイト増えてる方がマシだった

545 ：ナイコンさん：2021/05/29(土) 16:25:42.98 .net

アーキテクチャ

546 ：ナイコンさん：2021/05/29(土) 16:46:36.06 .net

>>529
> 「8080」なら他の3種類のCPU（MPU）とほぼ同性能だけど16ビットの「8086」では
> 性能が違い過ぎて、どのCPU(MPU)が優れているかの議論は無駄でしょ、って趣旨。
だからその趣旨なら
> プログラミングでCPU(MPU)を意識する際はアセンブラだろうけど「8086」だとハードルが高い。
> 「8086」でのアセンブラベース開発では効率が悪く無くなって行ったのではと。失敗談を聞きます。
なんて要らんやろ
要ると言うなら理由を書けよ

> 尚、煽る気は微塵もない。「煽り」と言って自分の勘違いを正当化しないで貰いたい。
> 他人は見下すし、自分の間違いは「すまんすまん」では上から目線で何様なんだろうな。
もしかして相手は一人とか思ってる？

547 ：ナイコンさん：2021/05/29(土) 16:54:42.18 .net

いつもの事だが、大人気ない

548 ：ナイコンさん：2021/05/29(土) 17:11:32.99 .net

自分もスレタイになぜ8086が入ってるのかと違和感を感じていたほうだけど
>>2の過去スレ一覧から初代スレ見に行ったら
Z80 vs 6809 を唱ってる割には8086もそれなりに話題に登場してて
（ベストセラーとして外せないのは理解できる）
実情に合わせたスレタイ変更ということで納得した

549 ：ナイコンさん：2021/05/29(土) 17:46:41.70 .net

>>546
既に書いてるけど君とは感覚・意見が違うようだ。しつこいな、ワッチョイが必要かもな。

550 ：ナイコンさん：2021/05/29(土) 17:53:44.43 .net

>>546
この下の3行目が君のレスなら4行目が感想だ。
> プログラミングでCPU(MPU)を意識する際はアセンブラだろうけど「8086」だとハードルが高い。
> 「8086」でのアセンブラベース開発では効率が悪く無くなって行ったのではと。失敗談を聞きます。
＞だとどう見ても8086はアセンブラでは開発しづらいクソCPUと言ってるように見える
そんなことは「一言」も書いてないのに「君が勝手に妄想して」そう解釈しただけだろ。

551 ：ナイコンさん：2021/05/29(土) 18:16:53.57 .net

このスレはIDがなくて混乱するな

俺はMIPS君と呼ばれてる人間だが
8086の酷評は68000に対してのものだからね
他の8bit CPUと比べれば8086は高機能
だからIBM PCに採用された
IBMはApple IIを潰したかっただけだからね
アセンブラレベルでもZ80と8086や8088とを比べると
断然8086、8088の方が書きやすいよ

IBMはApple II対抗の8bitパソコンが欲しかっただけなので
データバスが16bitの8086ではなくデータバスが8bitの8088を採用した

552 ：ナイコンさん：2021/05/29(土) 18:18:22.00 .net

>>544
IX/IYでメモリアクセスする命令は2バイト増えてるから「2バイト増えたHL相対」だな。
SP相対はCの自動変数と相性がいいが、8080上位互換のために命令のビットパターンが空いてないか。

553 ：ナイコンさん：2021/05/29(土) 19:41:02.71 .net

> DOSの末期にあんな酷いこと
どんな妄想してるか知らんが圧倒的なソフト、ゲーム資産、アセンブラで書かれた高速なアプリ群。
DOSユーザーは天国でしかなかったぞ。

554 ：ナイコンさん：2021/05/29(土) 19:54:42.40 .net

1970年代に開発ではまだパソコンなんてジャンルはなく、
マイコン、組込的な用途を想定しての開発だろう。
8bitCPUでCを考慮した作りとか想定外だろうな。

555 ：ナイコンさん：2021/05/29(土) 19:57:51.41 .net

DOS窓でメモリ不足で動かせず、ランチャーとして使えない、DOSとWinを別物として使うしか無い状況の事かね？
日本語環境だとFEPの分でコンベンショナルメモリ足りなく、CONFIG.SYS弄りまくりで普通の人が使えるものでは無くなってたってな
Win入ってるのにフロッピー立ち上げとかな悲惨な人々を産んでたな

556 ：ナイコンさん：2021/05/29(土) 20:05:59.96 .net

それはDOS末期ではなくWindows初期の話ですな。

557 ：ナイコンさん：2021/05/29(土) 20:13:56.43 .net

IRQが足りねーって悩みはいつの間にか解消してたな

558 ：ナイコンさん：2021/05/29(土) 20:21:39.28 .net

>>551
貴方を「MIPS君」と呼んでる方とは、どのようなイザコザがあったかは知りませんが
少なくても、このレスに関しては納得すると言うか、ほぼ同じ感想です。

>>553
DOSエクステンダーとかもありましたけど、どうような使い勝手だったのでしょうか。

尚、MSが商業的に上手いのは「Win 95」で16ビットも使える32ビットOSを用意し移行させたこと。
また同梱されたネット用アプリの存在が後押ししたこと。ただ後に独禁法で問題になった記憶ありと。

559 ：ナイコンさん：2021/05/29(土) 20:21:39.30 .net

ISAバスとか旧型の割り込みコントローラとかがIRQ不足の原因で、
拡張割り込みコントローラとPCIバスを活用できたら割り込み不足は起きない

拡張割り込みコントローラをネイティブモードで使えるのはNT系以後で9xでは互換動作しか使えなかったから、9xの頃までは割り込み数が常に足りなかった

多くの人にとってはXP以後またはWin2k移行によって割り込み不足から解放された

560 ：ナイコンさん：2021/05/29(土) 20:31:58.82 .net

>>549-550
だから違うと言うならどういう意図で
> プログラミングでCPU(MPU)を意識する際はアセンブラだろうけど「8086」だとハードルが高い。
> 「8086」でのアセンブラベース開発では効率が悪く無くなって行ったのではと。失敗談を聞きます。
を書いたんだよ？って聞いてるんだが…
まあ答えられないからグダグダ言ってるんだろうけどw

561 ：ナイコンさん：2021/05/29(土) 20:37:37.74 .net

>>556
Windows 3.xの頃はDOS上でWindowsが動いてたんだから同じだぞ
それにまだゲームソフトの大半はDOS上で動いてて
CONFIG.SYSの設定をうまくやらないと起動しないゲームがたくさんあった

562 ：ナイコンさん：2021/05/29(土) 20:40:00.42 .net

ひとつの割込みを全部のイベントで共有しているPICでも問題がないというのに8086ときたら

563 ：ナイコンさん：2021/05/29(土) 20:47:26.73 .net

>>561
win95の頃でも、じつはブートローダーとしてDOSを使ってたから、DOS自体は動いてたけどな、
主要なコンポーネントがDOSから呼び出さないでwin95から呼び出すようになったから、DOS用のデバイスドライバを使わなくてよい分だけ安定するようにはなった

564 ：ナイコンさん：2021/05/29(土) 21:03:40.01 .net

8080や6502、6809でDRAMリフレッシュは実際
どうしてたのだろう。
8086/88でよく使われてるDMAなのだろうか。
6502でDMAってそもそもできるんだっけ。

565 ：ナイコンさん：2021/05/29(土) 21:19:39.60 .net

MIPS君は自分は32bitCPUなのに8bitCPUスレばかりを荒らしにくる人です。そして32bit演算できない8bitCPUを馬鹿にするのです。
キャリーフラグあるからadd,adc,adc,adcで簡単にできるが、MIPSは64bit演算するなら桁溢れは例外投げるからむしろ面倒と指摘すると、
adcの意味が通じなかったらしく、キャリーフラグがいかに害悪かを語りだしましたとさ。

しかし、自称RISCのARMやAVRはキャリーフラグがあっても高速、ストールしないと、あっさり論破され逃亡。

566 ：ナイコンさん：2021/05/29(土) 21:26:35.19 .net

>>564
Apple][の回路図とか
https://archive.org/details/applerefjan78/page/n149/mode/

567 ：ナイコンさん：2021/05/29(土) 21:34:52.94 .net

>>562
全部のイベントで共有すると、割り込みを使うアプリやドライバの調停が面倒になって製作を分業しにくかったのでは?

568 ：ナイコンさん：2021/05/29(土) 21:41:04.36 .net

>>565
また無知さらしてるよ
64bit演算で例外なんて投げないよ
$4:$5＋$6:$7＝$8:$9の64bit加算は
addu $9, $5, $7
sltu $10, $9, $5
addu $8, $4, $6
addu $8, $8, $10
でできる

569 ：ナイコンさん：2021/05/29(土) 21:48:07.85 .net

>>568
ハナから知ってる。なぜ知らないと思ったのかが謎。
だからそんな面倒のことしなくてもキャリーあれadd、adcで済むよねって話をしてるのに
MIPSだってできるとその面倒な演算を自慢されてもね。最初から面倒だと指摘してるだろうに。
しかもPSのゲームで桁外れでフリーズするゲームも見受けられる。

570 ：ナイコンさん：2021/05/29(土) 21:53:27.23 .net

>>569
知ってるならなんでこんなこと書いたんだろうかｗ

＞キャリーフラグあるからadd,adc,adc,adcで簡単にできるが、
＞MIPSは64bit演算するなら桁溢れは例外投げるからむしろ面倒と指摘すると

571 ：ナイコンさん：2021/05/29(土) 21:55:18.31 .net

例外投げるから例外投げないように
そういう馬鹿な書き方してることに気づいてないのか・・・

572 ：ナイコンさん：2021/05/29(土) 21:55:59.70 .net

ちなみにMIPSのC言語では加算は例外の発生しないADDUやSUBUが使われる
だからC言語で開発されたソフトで例外が発生するADDやSUBが使われることは
通常ないと思われる

573 ：ナイコンさん：2021/05/29(土) 21:57:45.15 .net

>>571
何度も言うが
ADDUやSUBUは例外は発生しない
オーバーフローで例外が発生するのはADDやSUB
ADDやSUBはC言語では通常使われない

574 ：ナイコンさん：2021/05/29(土) 22:00:31.32 .net

>>564
レスの内容からZ80は知ってることを前提として、6809はバスの状態を表すBA、BS
と言う端子があるから、FM-7 ではこの端子から出てる信号を利用して生成してるような。
秀和から出たF-BASICマニュアルI（基礎編）のP261に回路図が掲載されてるので
東京以外に住んでるなら国会図書館のコピーサービスを使うと良いのでは。

575 ：ナイコンさん：2021/05/29(土) 22:01:17.52 .net

命令削減することがRISCの思想。キャリーがあるとADD、ADCと命令増えてしまうと批判していた。
つまり、例外発生するから発生しないバージョンの命令を増やしてしまったMIPSは
RISCを名乗るなということです。

576 ：ナイコンさん：2021/05/29(土) 22:03:52.09 .net

CやUNIXに使う前提なら元から桁溢れで例外発生する必要はないよな。
キャリー捨てたことであらゆるところがおかしくなってる。

577 ：ナイコンさん：2021/05/29(土) 22:04:16.59 .net

>>575
都合が悪くなると話し変えるね、君は
そして自分の都合のいいように話しを変えて他で吹聴しまくる

578 ：ナイコンさん：2021/05/29(土) 22:06:42.24 .net

>>576
RISC-Vもキャリーフラグないけど、RISC-Vにもいちゃもんつけてるの？
RISC-Vの基本命令はMIPSに非常に似てるよね

579 ：ナイコンさん：2021/05/29(土) 22:07:35.26 .net

addu $9, $5, $7
sltu $10, $9, $5
addu $8, $4, $6
addu $8, $8, $10

これ見て面倒なことしてるなと思わない奴がこのスレにいるの？
このスレのチップじゃどれもadd、adc並べるだけだよ？

580 ：ナイコンさん：2021/05/29(土) 22:07:59.98 .net

RISC-Vは糞。このスレでは結論出てる。

581 ：ナイコンさん：2021/05/29(土) 22:11:05.92 .net

そういい張ってればいいのでは？
数年後が楽しみだね

582 ：ナイコンさん：2021/05/29(土) 22:16:47.05 .net

いやもう10年経ったんだ…

583 ：ナイコンさん：2021/05/29(土) 23:09:33.74 .net

>>555
まあ酷かったと言えば酷かった
OSでランチャーまでありながら、config.sysをアプリごとに持って再起動したりしてね
HSBとか駆使すれば問題なかったけど、環境構築に相当時間使ったわな

584 ：ナイコンさん：2021/05/29(土) 23:15:21.04 .net

MIPSとかWindowsとか他でやってくれ。ほんと32bitスレは他にもいろいろあるだろ。
どんだけ8bitCPUにマウンティングしたいんだか。