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

このエントリーをはてなブックマークに追加
952ナイコンさん:2009/02/24(火) 20:11:41
無限のテープがチューリングマシンノの条件だったっけ?
ラップラウンドさせれば良いだけのような気がするが。
953ナイコンさん:2009/02/24(火) 21:06:27
>>946
Z80もLDIRとかマイクロプログラムで実行してるんだろうか?
当時としては、驚異的なスピードが出てるから、
専用の回路が有りそうな気がする。
954ナイコンさん:2009/02/24(火) 21:38:40
当時は全部ワイヤードロジックでしょ
955ナイコンさん:2009/02/24(火) 21:54:51
>>953
> 当時としては、驚異的なスピードが出てる

カリカリチューンじゃなくちょいと工夫
しただけの'09にあっさり負けたわけだが。
956ナイコンさん:2009/02/24(火) 23:47:17
>有限オートマトンなら実現できるけどチューリングマシンはできないよ。
普通にできるって。
1番地あたりのビット数が無限大×無限大番地の容量で。

ただ、チューリング機械のテープの長さがNだったら
これのサイズは2Nになりそうだけど。
957ナイコンさん:2009/02/25(水) 02:56:30
史上最強命令LDIR
958ナイコンさん:2009/02/25(水) 03:34:16
>>953
LDIRの立ち位置は高速転送命令というより、便利命令だと思うんだ
959ナイコンさん:2009/02/25(水) 15:37:52
そんな命令使うよりDMA転送の方がいいなぁ。
960ナイコンさん:2009/02/25(水) 19:27:50
>>956
>普通にできるって。
>1番地あたりのビット数が無限大×無限大番地の容量で。

それは RAM(ランダムアクセスマシン)だよ。
ただ(可算)無限番地があれば1番地に記録できる語は有限でいい。

逆に1番地あたりに無限を記録できるなら、番地は1個でいいはず。
これはレジスタマシン、カウンタマシンかな。
もし、無限ビット長のラッチと無限ビット入出力の ROM があれば
946 の言うとおりチューリングマシンは作れるね。


961ナイコンさん:2009/02/25(水) 19:32:10
どうでもいいよそんなのスレと関係ないし
962ナイコンさん:2009/02/25(水) 20:08:06
>>953

LDIR は当時としても驚異的に遅かったよ。
なにしろ LDI 命令を並べたほうが速かった。
何のための繰り返し命令なのやら、と思われていた。
プログラムは短くなったけどね。

繰り返しの度に 2 バイトの命令コードをフェッチするうえに 5 クロック
のアイドルサイクルまであって、計 21 クロックもかかってたんだよね。

それから、マイクロプログラムだと遅くなると思っているようだけど
そんなことはない。事実 64180 はマイクロプログラム方式で LDIR
の繰り返し1回あたり 14 クロックになっている。

ほんとは毎回命令フェッチしないで 6〜7 クロックで回してほしいと
ころなんだけどね。
963ナイコンさん:2009/02/25(水) 20:09:35
速さなんかどうでもいいよいまさら
964ナイコンさん:2009/02/25(水) 21:29:38
1バイトは一しずくの汗
1クロックは血の一滴
965ナイコンさん:2009/02/25(水) 21:34:05
実際、トラ技の広告か何かで「プログラムの1行は、俺の血の一滴だ」
って文句があったような
966ナイコンさん:2009/02/25(水) 22:05:35
>>962
> なにしろ LDI 命令を並べたほうが速かった。

LDI はループ終了判定しなくていいんだから速いのは当たり前なんだが...
ループアンローリングも知らんのか?
967ナイコンさん:2009/02/25(水) 22:07:35
ローリングソバッドがなんだって?
968ナイコンさん:2009/02/25(水) 23:00:32
>>960
最適化するとそうなるのかも。
ただ、
>無限番地があれば1番地に記録できる語は有限でいい。
>1番地あたりに無限を記録できるなら、番地は1個でいいはず。
こうすると内部に状態を記憶できなくなるんじゃない?
俺が言ってるのは、ラッチは1サイクル遅延させるためだけのディレイであって、
状態記憶はROMが行うイメージ。
969ナイコンさん:2009/02/25(水) 23:45:45
>>962
まーでも、毎回フェッチしないと転送中に入る割り込みやらバスリクエストやらへの
反応が面倒になるし、リフレッシュも止まっちゃうから仕方ないところではある
970ナイコンさん:2009/02/26(木) 00:04:11
>>969
ご丁寧に2バイトもフェッチしなくても、ダミーのフェッチサイクルを1回入れるだけでいいと思わないか?
971ナイコンさん:2009/02/26(木) 00:57:34
てゆうか、
命令フェッチとDRAMリフレッシュは全く別次元の話として分離して欲しかった。
(後の日立のHD64180はそうした。)

RAMはSRAMオンリーでDRAMなんか存在しないシステムで
いちいち命令フェッチごとにリフレッシュサイクルが入ったらたまらん。
972ナイコンさん:2009/02/26(木) 02:46:05
>>970
それだとCPU内にLDIR/LDDR用の特殊な状態遷移が必要になるからなあ
内部的に(LDI+自分自身へ条件分岐)にしておけば
転送中も普通の命令を実行しているのと全く変わらないので、追加回路は全く要らない

高速な転送が必須なシステムでは、DMAを使ってねという設計思想だったんだろう。

>>971
それには全く同意ではあるのだが
SRAMオンリーとかどこのお大尽だよwな時代の石には少々酷かと…。
Z80がそのまま高速版になって使われ続けるとは考えてなかったんだろうな。
973ナイコンさん:2009/02/26(木) 02:47:25
ここZ80の人気高いな
974ナイコンさん:2009/02/26(木) 02:48:52
>>971
それは、話が逆だ。
元々は「命令をデコードしている間はバスが遊んでいるから、DRAMリフレッシュに利用しよう」なんだから。
SRAMオンリーでリフレッシュが不要なら、あの期間はCPU内部動作オンリーになるだけのこと。
975ナイコンさん:2009/02/26(木) 07:28:41
ブロック転送がRASだったかCASだったかを一回りする以上のサイズなら、命令フェッチなくても問題ない。
けど、それ以下とそれ以上の2種類のブロック転送命令を用意するか、
内部で判断する必要があるから、そんなのばかばかしいし。

そこまで気にする要件ならDMAC使ってね、っていう思想なんじゃないの?
976ナイコンさん:2009/02/27(金) 03:11:45
System/360のMVC命令ってZ80のLDIRに似てるね
977ナイコンさん:2009/02/28(土) 21:43:21
俺、レジスタファイルを豊富に具備して命令を単純化したCPUを思いついたよ
このアキテクチャで6HMzの壁を突破するぜ!
978ナイコンさん:2009/02/28(土) 22:04:25
6HMz
979ナイコンさん:2009/03/01(日) 01:33:58
そろそろ次スレの季節なんだが、8085の方がいいと思うんだけど?
980ナイコンさん:2009/03/01(日) 04:04:21
>>979
俺もそう思う。8086に激しい違和感があるし6800がないのもおかしいよね。
そうなると長ったらしいので元祖の「Z80 vs 6809」で良いんじゃね?

以下>>1テンプレサンプル作って見た。

スレタイの"宿命の対決" Z80 vs 6809 の他、

1974 i8080・MC6800
1975 MOS6502
1976 Z80・i8085・SC/MP
1977 SC/MP II
1978 i8086・SC/MP III
1979 i8088・MC6809・MC68000・Z8000

あたりでどのCPU(MPU)が優れているか議論するスレッドです。

皆様もういいトシなんだからもっとやれ。

※ 但しi8086/88,MC68000/08は主戦場にあらず。メインは8bitで行け。

前スレ
8086 vs. Z80 vs. 6809 vs. 6502 その2
http://gimpo.2ch.net/test/read.cgi/i4004/1213527504/
981ナイコンさん:2009/03/01(日) 05:00:49
6800/6802は6809があるからいらない子
8088は8086があるからいらない子
8085は8080があるからいらない子
SC/MP・SC/MPUは売れてなかったから入らない子
982ナイコンさん:2009/03/01(日) 05:03:13
次スレ

8086 vs. Z80 vs. 6809 vs. 6502 その3
http://gimpo.2ch.net/test/read.cgi/i4004/1235851359/
983ナイコンさん:2009/03/01(日) 06:54:50
>>980
> ※ 但しi8086/88,MC68000/08は主戦場にあらず。メインは8bitで行け。
まあ、ぶっちぎりでMC68000が優れすぎていて議論の余地ないしな。
984ナイコンさん:2009/03/01(日) 11:06:59
MC68000の、奇数番地からのワードアクセスがなぁ。
Cコンパイラがキチンとやってくれればパーフェクツ!だったんだが。
985ナイコンさん:2009/03/01(日) 11:42:05
スレタイ中では、腐っても16bitCPU、
8086がぶっちぎりだわな。
かと言って8080/8085では
相手にならないし。
986ナイコンさん:2009/03/01(日) 12:48:17
じゃあ8088で
987ナイコンさん:2009/03/01(日) 16:25:06
>>984
データテーブル作成時にバイトとワードのデータを分けとけば問題は発生しない。
x86からの移植で必要なときはバイトアクセス2回とシフトすれば。
Cコンパイラは奇数番地にワード置くなんて間抜けな事はしないと思うが。
回避できる問題のために速度低下を招く実装を望む?俺は望まない。
988ナイコンさん:2009/03/01(日) 16:57:28
>>987
共用体でやられたのさ。
989ナイコンさん:2009/03/01(日) 18:54:11
いまいち状況が判らんけどやらなくて良い事やって自爆したのかな。
素直にバイトアクセスすれば良かったんじゃないのかな。
990ナイコンさん:2009/03/01(日) 19:56:20
ファイルフォーマットによっては、奇数オフセットから 32bit データが入っ
てたりするから、組み方によっては問題になるケースもある。

ただ、それをコンパイラでどうにかしようとするのはちょっと違う気がする。
991ナイコンさん:2009/03/02(月) 01:42:06
>>981
> SC/MP・SC/MPUは売れてなかったから入らない子
 
っていうか、PCに搭載されてなかった時点で板違いだよな。
その意味では64180はぎりぎりセーフ、R800はOK。
Z280、Z380はNG。
HD63C09は、市販PCでは搭載されてないな。後付はあったが。
65816ってAppleIIIだっけ?
992ナイコンさん:2009/03/02(月) 02:58:26
>>991
> PCに搭載されてなかった時点で板違い

Apple II のパチモンのアレとか知らない世代か。
> R800
> 65816
この辺って8か16か扱い微妙だよなあ。
例のブロック転送みたいにコード書いて
くんならいいんじゃないの?
逆にSC/MPも名前出して来るだけなら
要らないよね。
993ナイコンさん:2009/03/02(月) 06:46:31
>>992
>Apple II のパチモンのアレとか知らない世代か。
 
そういや、そんなんあったね。
じゃSC/MPはOKって事で。
 
それから、65816は AppleIIIじゃなくてAppleIIGSだったね。訂正。

>この辺って8か16か扱い微妙だよなあ。
別に8に限定する必要ないと思う。
昔のPCに使われてたってのが基準でいいんじゃないの。
994ナイコンさん:2009/03/02(月) 07:36:30
>別に8に限定する必要ないと思う。
そうすると8086は入れろってことになるじゃん。
だったら68000も入れなきゃだし、ぐだぐだになる。
995ナイコンさん:2009/03/02(月) 09:14:47
68000入れたらZ80や8086が最強じゃなくなって発狂する人が出てくるだろ。
996ナイコンさん:2009/03/02(月) 13:46:12
別に入れようが入れまいが好き好きでいいと思うけど
一番新しい奴が最強と言われても、うんそうだねとしか答えようがない…。
997ナイコンさん:2009/03/02(月) 20:34:16
確かに68000は挙げられてる中じゃ最強だけど、最も面白味がない。
998ナイコンさん:2009/03/03(火) 08:24:34
M
999ナイコンさん:2009/03/03(火) 09:35:12
999
1000ナイコンさん:2009/03/03(火) 13:05:40
1000
10011001
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。