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

1 ：2012/04/09 〜 最終レス ：2012/12/05

8086(8088)・Z80・6809・6502のうち、どのCPU(MPU)が優れているか議論するスレッドです。
CPU(MPU)アーキテクチャや周辺デバイス制御など
基本的に「石」に関連する議論なら、ほぼ何でもアリです。
■過去スレ
8086 vs. Z80 vs. 6809 vs. 6502　その7
http://ikura.2ch.net/test/read.cgi/i4004/1319314159/
8086 vs. Z80 vs. 6809 vs. 6502　その6
http://toki.2ch.net/test/read.cgi/i4004/1286766300/
8086 vs. Z80 vs. 6809 vs. 6502　その5
http://toki.2ch.net/test/read.cgi/i4004/1280380374/
8086 vs. Z80 vs. 6809 vs. 6502　その4
http://gimpo.2ch.net/test/read.cgi/i4004/1252639237/
8086 vs. Z80 vs. 6809 vs. 6502　その3
http://gimpo.2ch.net/test/read.cgi/i4004/1235851359/
8086 vs. Z80 vs. 6809 vs. 6502　その2
http://gimpo.2ch.net/test/read.cgi/i4004/1213527504/
8086 vs. Z80 vs. 6809 vs. 6502
http://bubble6.2ch.net/test/read.cgi/i4004/1165801265/
6809とZ80 part 2
http://bubble4.2ch.net/test/read.cgi/i4004/1093190685/
6809とZ80
http://bubble2.2ch.net/test/read.cgi/i4004/1008496410/
■関連スレやサイトなど　※補足などあれば>>2-9あたりで
68K v.s. x86
http://gimpo.2ch.net/test/read.cgi/i4004/1220728356/
半導体コレクション展示会場
http://www.st.rim.or.jp/~nkomatsu/ICcollection.html

2 ：

おつ！

3 ：

>>1　乙です
小松さんのコレクションのサイトを閲覧してて、初めて知ったんだけど
AMDの石のセカンドソースを、Intelが出すような例が昔はあったんだね
AMDの数値演算プロセッサ Am9511　→　セカンドソース Intel 8231
ttp://www.st.rim.or.jp/~nkomatsu/peripheral/Am9511.html

4 ：

ああ、am9511は超有名だったからな。
そしていちょつ。

5 ：

Zilog Z180(HD64180)やIntel 8231/8257 (Am9511/9517のセカンドソース) への
柔軟な対応と、HD63C09へのどうしようもない対応が歴史を決定した。
オリジナルの6809のアーキテクチャに最大限の敬意を払って拡張され、
高速化され、CMOS化された優秀なセカンドソーサのチップを潰したMotrora。
MC68040、MC68060、PowerPC620、PowerPC G4と複雑化→開発遅れを
何度も何度も何度も同じ轍を踏んで、半導体事業撤退に至る。

6 ：

>>5
>高速化され、CMOS化された優秀なセカンドソーサのチップを潰したMotrora。
潰してないでしょ

7 ：

6309の独自拡張がモトローラと日立の紛争の原因とはなったようだが。
インテルやザイログは西海岸の企業だから製品や考え方に違いはあるだろ。
モトローラは西海岸の企業ではないから、企業文化としても災いしたのだろう。
現在はモバイルと通信に分社化され、モバイルはグーグルに買収という状態だ。
モバイル部門すら買収され影も形もないとなると問題は半導体部門だけじゃないだろうな。

8 ：

>>7
> 6309の独自拡張がモトローラと日立の紛争の原因とはなったようだが。
日立が勝手に拡張した内容をデータシートに載っけてモトローラに怒られただけ。
データシートの該当部分は削除になったけどチップの販売は普通に継続された。

9 ：

拡張仕様がリファレンスやデータシートに載ってない6309など、互換チップ以外に存在意義はないな。
実質的な圧力だろう。当時貿易摩擦もあったろうし東海岸の企業らしい。
モバイル部門がグーグルに買収されたら終了だろうかね。
モトローラという企業は、ビジネス的にチップだけでなく企業としてもイマイチだったのだろう。
そんな企業の作るチップを信じてしまった昔のPC板住人氏は残念でならない。

10 ：

>>9
>拡張仕様がリファレンスやデータシートに載ってない6309など、互換チップ以外に存在意義はないな。
CMOSだし、3MHz動作版もあったし、そんなことないでしょ。あんたバカじゃね？

11 ：

ロストテクノロジーで盛り上がってるな

12 ：

そもそもデータシートが外部非公開のエンジン制御用6301とかもっと魔改造されてるじゃん

13 ：

>>10
FM7系だと結構載せ替え流行ってたよ。

14 ：

>>13
マニアがどうこうした数なんて全体の生産量からすれば屁みたいなもんだろ。

15 ：

臭いって事？

16 ：

>>13
ないな。
ゲームが動かなくなるから。
あとFM77AV系はCPUが直付けだから、載せ換えはさらにハードル高い。

17 ：

>あとFM77AV系はCPUが直付けだから、載せ換えはさらにハードル高い。
DIPだし大したことない

18 ：

>>14
数が少ないからステータスになるのさ。
もちろんコテ持てない奴等はよだれ流してるだけ。

19 ：

いい加減な改造して不安定になるよりも
遅くてもノーマルで安定している方が良い
まして改造がステータスだなんて思っているヤツはアホゥ

20 ：

>>19
いいかげんな改造しか出来ない奴のいいわけだな。

21 ：

いい湯加減だよ

22 ：

6309はTFR,EXGの非互換さえなけりゃ神CPUだったのに。
惜しい、とても惜しい。

23 ：

この辺の話かいな?
http://www.6809.net/6809/?6309%CC%BF%CE%E1%C9%BD
> exg a,x のようなサイズの違うレジスタ同士の演算で、16ビット側レジスタの値は、 6809では
> 下位バイトが対象になるが、 6309では8ビットレジスタが16ビットレジスタペアになったときに
> 対応する位置が対象となる。 exg a,x なら 6309では xの上位バイトが対象となる。
> ※ 実のところ、サイズ違いの演算は あまり未定義アドレッシングと意識せずに使用されて
> いたと思われ (アセンブラで普通に指定できてたと思う)、 オーソドックスに組まれたと思われる
> ソフトが 6309にCPU換装して動かなくなる原因はこのへんだったらしい(?)。

24 ：

データシート上は互換だったのに、
未定義動作の互換性までは考えていなかったというオチ。

25 ：

まあ、8080→Z80でもけっこう非互換部分あるけど、あんまし文句言ってる人見たことないし、いいんでないの?

26 ：

オーソドックスに組まれてないだろそれ。
素人ならともかく、プロが未定義使うってどうなの。

27 ：

エラーにしないアセンブラが悪い希ガス

28 ：

使うヤツが悪いに決まっているだろ
アセンブラ、コンパイラのエラー報告は忠告程度
エラーがなくても疑うのがプロ

29 ：

>>28
アセンブルのたび、リンクのたびに出力されたコードをプログラマが精査ですか? プロって大変なんですね。

30 ：

全てやる訳無いだろ、バカかオメーはよ
アグレッシブなコードだけ精査するに決まってんだろ
とろい突っ込み入れてんジャネーヨボケが

31 ：

>>30
え、それじゃあ「エラーがなくても疑うのがプロ」てのは嘘なの?

32 ：

なんだ、テスト中は全然こなかったのに、テスト終わるとさっそくやって来たな。

33 ：

>>32
キミの頭の中はまだ学生気分なの?

34 ：

ていうか、意識して未定義使うとかの話じゃなくて、
意図せずにないsrc/dstの組み合わせをしてしまったとかの話なの？

35 ：

アマチュア製アセンブラやコンパイラが普通に使われていた時代
アマチュアとプロの境界線も曖昧だった時代
未定義動作の記述ハジくとか石の製造メーカーが作ったアセンブラぐらいしかなさそうな気が

36 ：

>>35
> アマチュア製アセンブラやコンパイラが普通に使われていた時代
そんな時代あったか？
俺は使ったことない。

37 ：

なんか、マシン語とか言いながらバイナリダンプを指すような人達の会話に見えてるな…

38 ：

>>36
お仕事でCP/Mとか使っていたヒトは知らないかもしれんけど
アマチュアホビーストはそんな高いモノ普通は手が出なかったから
ホビーストお手製のシステムプログラムでお茶を濁していたのだ

39 ：

この場合は6309だからCP/MじゃなくてOS-9とかだな。

40 ：

パソコン一台買って小遣いが干上がった子供はソフトは自作か雑誌で手入力

41 ：

>>38
お仕事の話じゃないのか…

42 ：

>>33
ならいいな、そろそろ赤いちゃんちゃんこに手が届きそうなんだよ。

43 ：

>>42
頭の中が学生気分であるか否かと、年齢ってあんま関係ないんじゃない?

44 ：

1D SEX

45 ：

符号拡張命令はホントに人気だねぇ

46 ：

CBWすげぇ

47 ：

別人の横レスですが、たとえば B を破壊せずに
X の下位バイトを A で使いたいとき
PSHS B
TFR X,D
TFR B,A
PULS B
等とする代りに
TFR X,A
だと一命令で済むから、少しでも節約したい場合(プロ/アマ問わずゲーム等)
もしかすると裏技的な常套手段だったのかも
これが 6309 だと、下位でなく X の上位バイトが転送されてしまうので
いきなり不具合に…　　単なる憶測ですみません
http://www.scribd.com/doc/72374827/6x09-Instruction-Sets

48 ：

だから、未定義命令を仕事で使っちゃだめだろ
純正品だってrevisionが変わったら動かなくなるかもしれん

49 ：

>動かなくなるかもしれん
その修正を有料で受けることを考慮した仕事を(ry

50 ：

TB級のHDDをカセットレコーダーエミュレーションさせて8bit機に活用出来ませんかね

51 ：

ICレコーダーでいいだろ

52 ：

999GBまど読んでエラーにする機能も実装

53 ：

>>48
ゲームとかでは使われている事が多々あって、実際MSXではHD64180機で動かないソフトが(ry

規格なんて、大手だって無視するんだぜwwww
iPadのUSB充電とか有名でしょw

54 ：

>>53
>MSXではHD64180機で動かないソフトが(ry
MSXでは64180の方が規格違反だろ。日立も64180のことをZ80コンパチとか謳ってないし。

55 ：

64180搭載機はZ80と切り替えられるから規格違反ではない

56 ：

>>55
動かないんだからどっか違反してんだろうな

57 ：

>>56
HD64180とかZ180とかZ380では
Z80のインデックスレジスタ関連の未定義命令が排除されてるってだけの事だな。
Zilog的には公式には存在しない命令なんだから
排除も何もない訳だがwww

58 ：

Z80も各命令の挙動についてマニュアルに全て書かれてる訳じゃないしな

59 ：

裏挙動があるのかー

60 ：

裏命令を使うとか今の基準で考えるとありえない事やってたんだな

61 ：

今は例外割り込みとかあるからな、普通に使えない。
(まぁまだCPUにもよるが…)
当時は速度が必要十分じゃなかったことと、メモリが高すぎたからな。
１バイト節約のためにトリッキーなことをするのも、たしなみみたいな意識もあったし。
(それはそれで色々問題あるが)

62 ：

ホントにメモリが逼迫していたり処理を速くしたくて
裏技を使うのは仕方が無いと思うけど
知っている事を自慢したくてとか、興味本位で使うヤツはギルティーだな

63 ：

64180とZ80じゃDAAしたときの挙動が違ってた気がする

64 ：

DAA命令って、8080でも、Z80でも、64180でも、マニュアルでちゃんとした動作の定義なかった気がする

65 ：

>>62
ある意味IOポート命令でVRAM(16bitアドレス指定アクセス)をするのもそうだな。
確か当初はOUT(C),Aとか上位バスにBレジの内容が出るとかいうのは、正式にはなかったはずだし。
DAAは8080A以降の命令じゃなかったかな、Aなしはなかったと思う。
それ以前に積極的に使う場所が限られてたような。

66 ：

>>65
>ある意味IOポート命令でVRAM(16bitアドレス指定アクセス)をするのもそうだな。
>確か当初はOUT(C),Aとか上位バスにBレジの内容が出るとかいうのは、正式にはなかったはずだし。
少なくともシャープのマニュアルには書いてあったぞ。
>DAAは8080A以降の命令じゃなかったかな、Aなしはなかったと思う。
Aなし→Aあり は電気的に改良されただけ。

67 ：

あ、そうだNECの偽物の話とごっちゃになってた。ぐぐって確認。
シャープのZ80だってところがミソってことだったんだろうなｗ

68 ：

Z80ってバグあったよね

69 ：

Zilogのマニュアルにも書いてあるがな

70 ：

>>65
>ある意味IOポート命令でVRAM(16bitアドレス指定アクセス)をするのもそうだな。
>確か当初はOUT(C),Aとか上位バスにBレジの内容が出るとかいうのは、正式にはなかったはずだし。
↓の269頁とか見れ
http://www.z80.info/zip/z80cpu_um.pdf

71 ：

288ページしかないんだが

72 ：

288ページもあれば、充分だと思うが。
まあ、out (c),a というニーモニックだし、"select the I/O device at one of 256 possible ports"
なんて書いてるから、たまたま A8-A15 に Bレジスタの内容がでるような設計になってて、
便利そうだということで仕様になったんだろうね。

73 ：

>>70
それ新しい版だから

74 ：

>>73
古い版のにはなかったとか言いたいならお前がそれ提示すればいいと思うよ

75 ：

ドヤ顔(笑)

76 ：

>>72
The contents of register C are placed on the bottom half (A0 through A7) of
the address bus to select the I/O device at one of 256 possible ports. The
contents of Register B are placed on the top half (A8 through A15) of the
address bus at this time.

77 ：

>>76
Bレジスタがアドレスの上半分に出てくるなんて書いてないだろ

78 ：

>>76
何を言いたいのか書いてくれないかな？
>>77
> The contents of Register B are placed on the top half (A8 through A15) of the
> address bus at this time.
> レジスターBの内容は、アドレスバスのトップの半分(A15によるA8)にこの時期に置かれます。

79 ：

ZiLOG Z80 Family User's Manual
OUT (n), A
Description: The operand n is placed on the bottom half (A0 through A7) of the address
bus to select the I/O device at one of 256 possible ports. The contents of the
Accumulator (register A) also appear on the top half (A8 through A15) of
the address bus at this time. Then the byte contained in the Accumulator is
placed on the data bus and written to the selected peripheral device.
OUT (C), r
Description: The contents of register C are placed on the bottom half (A0 through A7) of
the address bus to select the I/O device at one of 256 possible ports. The
contents of Register B are placed on the top half (A8 through A15) of the
address bus at this time. Then the byte contained in register r is placed on
the data bus and written to the selected peripheral device. Register r
identifies any of the CPU registers shown in the following table, which also
shows the corresponding three-bit r field for each that appears in the
assembled object code:

80 ：

ザイログ発行の資料にBレジスタの事が謳われていないんだから
それを見込んだプログラミングはトリッキーと言われても仕方が無いね
シャープについてはもう言う事無い、ただ異常としか
これからは使わないようにしようね

81 ：

>>80
>>79はZiLog発行資料な

82 ：

>これからは使わないようにしようね
そもそも、今後Z80のプログラムを組む可能性のある人は
ほとんど居ないんじゃなかろうか。

83 ：

>>81
だからそれのどこにもそんなこと書いてないじゃん
ザイログの資料にないことは全部裏技
裏技使えばどこかで問題が出る可能性が残る
だから使わないようにしようね
正統派のプログラマーは

84 ：

>だからそれのどこにもそんなこと書いてないじゃん
???

85 ：

>>83
>だからそれのどこにもそんなこと書いてないじゃん
>ザイログの資料にないことは全部裏技
http://www.zilog.com/docs/z80/um0080.pdf の15ページ、'Figure 7. Input or Output Cycles' に
A15-A0 のタイミングまで書いてあんのに?

86 ：

都合の悪いことは見えなくなる人かな？

87 ：

古いのもってこいよ

88 ：

レジスタBの値がアドレスバスの上位に出るから積極的に使ってネ
VRAMなんかI/Oアドレスに繋いでアクセするすると良いよ
とでも書いてあると思っているのか
マニュアルは事実だけしか書かれていない
それをどう使うかはユーザー次第
トリッキーなコード書くのもユーザー次第
ﾒﾝﾃﾅﾝｽが出来るならどんなコードでも良いんだよ

89 ：

>>70
それさところどころ間違ってるとこあるよね。
IN A(C)はED 7BじゃなくてED 78だよね。
ED 7B xx xx は LD SP,(nn)だよね。

90 ：

Z80の売りの一つなブロック入出力命令だと実質使えないんだから
積極的に16bitI/Oアドレス使ってねとは書けないよなwww

91 ：

>>90
Z80の売りの一つはDRAMのリフレッシュ機能だからDRAM以外は繋いじゃダメ、くらいナンセンスな話だな。

92 ：

>>90
Bレジスタがアドレスバスに出るから、OTIRとかINIRとかで
「あと何回で転送が終わるか」がCPUの外からも見えて便利なわけだなwww

93 ：

>>90
大活躍の間違いじゃないか

94 ：

I/OはA0-A7とA8-A15を入れかえて配線すると便利ですよ
とマニュアルに書いてて欲しかった
そうすれば公知の事実になったのに

95 ：

>>94
SONYのSMCﾅﾝﾄｶはそんな感じのI/Oマップだったらしいけど、なんか便利だった?
VRAMの並びがリニアでない時点でダメダメな気がするけど。

96 ：

なんでリニアでないとダメダメなの？

97 ：

16ビットでアドレス計算したあとペアレジスタの上下入れ替えるなんてしたくないよね

98 ：

I/Oのアドレス上下入れ替えて、VRAMはI/Oにぶら下げられるわ、1命令でI/Oは
アクセスできるわって話なら、I/Oのアドレス入れ替えるの止めてメモリの64KBの内
256バイト潰してメモリマップドI/Oにするのも考慮していいと思う。

99 ：

>>97
入れ替える必要ないんでないの？

100 ：

たとえば 320x200 の解像度で1ドット1バイトのビットマップを実現したとして、
アドレスがリニアなら 0000〜F9FF になるとこをアドレスの上下入れ替えて
0000〜FFF9(XXFA〜XXFF は非使用)に割り当てる。
そうすると VRAM を I/O 領域にマッピングできるし、XXFA〜XXFF の非使用
領域はアドレスの下位のみデコードして他のペリRルを繋げられ、アクセスも
OUT(n),A の1命令でアクセスできるってことだろ。
VRAMのアクセスは上下入れ替えが生じてる分面倒くさくなる。

101 ：

OUTI命令並べられるし16ビット計算は元々遅いから使ってないし

102 ：

SMCっリニアに見せ掛けてんじゃないの？

103 ：

702 : 名無しの挑戦状 : 2011/12/19(月) 21:24:17.72 ID:rrRB54Gw [4/5回発言]
>>700
いい加減に知ったかやめてマジでw
自分はZ80も6502もやってたゲームプログラマだよ
その流れで当然68000もいじってる
本当に斜めでしか知らない人とはわけが違うんで
クロックで当時のCPUを語るなんて愚の骨頂
ちょっと調べればわかるが6502の1MhzはZ80の4Mhz相当の処理能力で
アドレッシングモードの豊富さや割り込みが実質256使えるために
リアルタイムの例外処理に非常に優れている
テーブルジャンプが使えるので非常に効率良いプログラムが書ける
Z80は本当にちまちました処理を全部書かなきゃならないんで処理効率が非常に悪い
ただ単純なのでコード自体は書きやすいけどね
6502は特にリアルタイム性が必要とされ
音と絵をフレーム単位で処理しなきゃ行けないゲームでは相当の差が現れてくる
時分割処理のムダが分かってればZ80推すプログラマなんて居ないってくらい
アケではこれに加えてコイン関係の入力処理が加わる
どこで蓄えたクズみたいな知識か知らないけど
いい加減にしたほうがいいよ
恥晒してるだけって気づきなさい
そんな事も知らないのにウォズの名を上げるとかおこがましすぎる
元プロ相手にとことんまでやりますか?

104 ：

元プロが「hz」とか。
大丈夫か？
おめでたいな。

105 ：

>割り込みが実質256使えるために
どういう意味だろ?
割り込みの数を比べるならZ80の割り込みモード0に勝てるわけないと思うが。

106 ：

↓どう見ても割り込みが256あるようには見えんのだが。
http://www.6502.org/documents/datasheets/mos/
http://archive.6502.org/datasheets/mos_6500_mpu_preliminary_may_1976.pdf
それどころか6800で言うところのSWI(Soft Ware Interrupt)すら無さそうだね。

107 ：

>それどころか6800で言うところのSWI(Soft Ware Interrupt)すら無さそうだね。
http://www.6502.buss.hk/6502-instruction-set/brk

108 ：

106みたいなバカが相手なら「いい加減に知ったかやめてマジでw」というセリフが出るのも仕方ないかな。

109 ：

>>106
知らないくせに話題に参加しようという姿勢は評価する

110 ：

6502の1MhzはZ80の4Mhz相当ってのは正しいな

111 ：

>6502の1MhzはZ80の4Mhz相当の処理能力
知ってたらこんなバカなこと書けない

112 ：

>6502の1MhzはZ80の4Mhz相当の処理能力
何倍相当かなんて何やらすかにも拠るけど、6502で4倍のクロックのZ80相当に働かせるって
なかなかそんな処理ないだろ。

113 ：

>>110
その話は前スレでなぁなぁになったでしょ、お爺ちゃん

114 ：

ここには6500系がまともに使える奴は絶対にいないな
何せまともな話が出てこないものな

115 ：

何を持ってまともに使えると言ってるのか知らんけど、
普通に使ってた奴はいくらでもいると思う。
て言うか、そういう奴しか見てないだろ、この板。

116 ：

>ここには6500系がまともに使える奴は絶対にいないな
という奴がアセンブリ言語の話題を絶対に振らないという不思議Ｗ

117 ：

インストラクションの実行を考えないクロックの比較の無意味さとか、過去にやってたよな？

118 ：

コピペ連呼君は芸が無いからな…
今だったら、B-CASカードにも内蔵されてる6502最強!とか書くべきなのにww

119 ：

>B-CASカードにも内蔵されてる6502
芸がある人は流石だと思う。

120 ：

ARM使えりゃ十分だろ

121 ：

ARMだけだと消費電力に制限ある場合とか困る。
ついでにARM用語に慣れすぎてると、他のCPU使う時にまごつく。MPUとかw

122 ：

>ついでにARM用語に慣れすぎてると、他のCPU使う時にまごつく。MPUとかw
ARMしか知らんとこういう勘違い平気で口にできたりすんのか。

123 ：

ARM用語でのMPUはMemory Protection Unitの略で
コントローラー向けに使われる簡易版MMUの事。
他にもARM独自略語がふつ〜にあるので英文マニュアルを読む時は注意が必要。
日本語訳本も略語等の意味が間違ってる物があるのでマジヤバイ。

124 ：

ARM開発での会話だと「MPUって滅多に叩かなくね?」とか普通に言ってるwww

125 ：

АРМ

126 ：

別にARM用語じゃねぇだろ。
http://www.altera.co.jp/support/examples/nios2/exm-niosii-mpu.html

127 ：

http://japan.renesas.com/products/tools/os/itron/ri600_px/index.jsp
>対応MPU
>MPU(Memory Protection Unit)を搭載したRXファミリ RX600シリーズ
「MPUを搭載したMPU」みたいな会話はしたくないなー。

128 ：

まあ、略語なんてどんなプロセッサにも付きもんだし、
どうと言うこともないと思うが。

129 ：

>>126
最初、ARMが使っちゃったんだと思
その後、ARMコア対抗の奴が皆使い出したwwww
ふつう〜避けるでしょ〜MPUなんてのはwww

130 ：

>>125
ARM Partner's Meeting

131 ：

МПЮ

132 ：

6502-1MHz=Z80A-4MHz=6809-2MHz
つまり6502は8bit最強ってことだな

133 ：

>>132
6502って実際そんなに速くない。
命令レベルで見ても、同クロックのZ80の4倍に相当する速さの命令なんてほとんどないし、
256バイト超えるテーブル操作とかガクッと効率落ちる。

134 ：

インデクスレジスタ２本のおかげでシューティングゲームの当たり判定や弾移動は効率よく書けたな
Z80のLD r,(IX+d)は１９クロックだから6502のABS,Xの４クロックはムダがなくて気持ちよかった

135 ：

>6502のABS,Xの４クロックはムダがなくて気持ちよかった
ページ境界超えると+1クロック

136 ：

>>134
ADD命令すらないプロセッサで効率よく書けたもないもんだわ

137 ：

>>134
Z80慣れてるプログラマは、LD r,(IX+d)みたいな遅い命令は積極的には使わない。

138 ：

IX,IYレジスタ使うぐらいならメモリに退避させるわ。

139 ：

レジスタ使えよ

140 ：

インデックスアドレスもどきするためにRAM上にコード置いてjmpしてたな、昔は

141 ：

IX,IYレジスタ使うのと、それ以外のレジスタとメモリ駆使して処理するのとが
メモリ量的にも速度的にも変わらないからな。

142 ：

やっぱ6502信者って底が浅いな

143 ：

ゼロページが足りてる間だけは結構効率が良いと思う

144 ：

IX,IYは無いものと思っている

145 ：

Z80はIX,IYレジスタ削って16bitのSUB命令入れろ。

146 ：

ALUが4bitなのに無理言うなよ。

147 ：

>>145
そんな事より、メモリアクセスを2クロックサイクルにして
M1サイクルと同じタイミングにすべきだった。

148 ：

>>132
派生CPUはともかくとして、主CPUにしても時期的なものは有るがCLOCKは色々ある。
63C09や、Z80もBやHもある。
6502は速いのあるの?

149 ：

Z80、今だに現行品なのでZilog公式のCMOS20MHz品(Z84C0020)も買えます。
HD64180ZのZilog版であるZ180も今だ健在です。こっちは33MHzが最高クロック品かな。
6502、B-CASカードにIPが使われている事で話題になりましたが、単体のチップとしてはWestern Design Center版の65C02や65C816は現行品です。
WDCの65C02なら、現行品の高クロック版は14MHz版ですかね。

150 ：

>>149
よく知ってるなぁ、感心するよ

151 ：

65C02っちゃ6502のバグ直したやつだから動かない場合あるよね

152 ：

複雑さにおいて桁外れのIntelの最新CPUが数年で消えてしまうのが何か虚しいですね

153 ：

>>15
8bitだって似たようなもんだろ。
Z80や6502は現行だが、6809はwwwww

154 ：

あれ?
直しとくぜ!
>>152
8bitだって似たようなもんだろ。
Z80や6502は現行だが、一番複雑な6809はwwwww

155 ：

6809って使われてるっしょ

156 ：

Z80はIX/IYが遅いのではなくて、(HL)関連が「相対的に速い」んだよね
LD (IX+d), r が6809や6502での5クロック相当の命令だとすると
LD (HL), r　 は6809や6502での2クロック相当の命令だからなぁ

157 ：

メモリアクセスが３クロックでOPコードが４クロックか８クロック使うんだから
ツボにはまった命令やINC rだけでやりくりできる特殊な状況でなければ３〜４倍ってのが妥当
ビッグエンディアンの6800は論外

158 ：

単純なプログラムだと6800>6809だよね

159 ：

6309E使えば解決。

160 ：

>>149
知ったか乙

161 ：

↑ジジイになるとそういうひねくれたレスしか出来なくなるんだね

162 ：

知ったか乙とか言っとけば気が済むんだから放置しろよ。
>>160 から見て >>149 が本当に知ったかなら、どこがどう知ったかなのか指摘するでしょ。

163 ：

>>149
>6502、B-CASカードにIPが使われている事で話題になりましたが、
6805でしょ。6502とは全然違うよ。

164 ：

>>151
>65C02っちゃ6502のバグ直したやつだから
違うよ

165 ：

直したよフラグを

166 ：

>>165
そだね。直したら文句言われたという　orz

167 ：

>>151
一口に65C02と言ってもWDCとRockwellとで別もんだよ。

168 ：

そこまで判ってるのに、>151 の意図も判らない？

169 ：

>>168
151「ぼくわバカですウヘヘあーRもれちゃったー」
こういうこと?

170 ：

使ったことないガキは黙ってろ

171 ：

>>167
どっちも6502のバグ修正済み

172 ：

バグ修正ではなく仕様変更

173 ：

167は何がいいたいの？

174 ：

理解できないバカがいます

175 ：

>>167
ﾊﾞｰｶ

176 ：

このごろあちこちで程度の低い奴がごろごろ出てきたな、しかも真っ昼間を中心に。
夏休みも仕方ないもんだ。

177 ：

>>176
ﾊﾞｰｶ

178 ：

バグじゃねーエラッタ

179 ：

バグって書いてあんじゃん

180 ：

>>179
どこに？

181 ：

そこに

182 ：

そこかよ

183 ：

大方、Wikipediaかなんかの記述をありがたがってる半可通だろう。

184 ：

>>167
www

185 ：

爽健美茶のシールの下四桁が6502だった〜

186 ：

最強じゃないか

187 ：

それはうpしないと価値が十分の一になる

188 ：

いらない

189 ：

おう、ジーサン共
暑さでくたばってるんじゃないか

190 ：

ガキが来るところじゃないよ

191 ：

cpuが熱暴走しない程度にエアコンつけとけよ
年寄りに熱中症は命取りだからな

192 ：

ガキが来るところじゃないよ

193 ：

逝ったらスレに訃報出すように遺言状に書いとけよ

194 ：

1D SEX

195 ：

もうだんだんNOPばっかになってきて最後にHALTするんでしょ

196 ：

Z80を超えられるものはでなかったな

197 ：

スレチかもしらんが、PPCのEIEIOも好き

198 ：

ゼロのページのアドレスに　今日も修飾吹き荒れる
リフレッシュ無用のザイログに　サイクルスチール見せてやれ

199 ：

闇に隠れて 生きる
俺達ゃ常駐ソフト なのさ
人にコードを 見せられぬ
獣のような この実装
（割り込みベクタを 奪い取れ〜！）
ティー！ エス！ アール！
常駐 ソフト

200 ：

TSRBIOS.SYSってなんぞや？

201 ：

「プログラムを終了させてシステムに制御を戻すが、そのプログラムはメモリに残しておく」
例：デバイスドライバ、DOSKEY
Terminate and Stay Resident (TSR) 常駐プログラム
Terminate and Stay Resident − Wikipedia

202 ：

同一クロックなら6800はZ80よりも処理が速いの？

203 ：

>>202
最短実行クロックが
6800 → 2
Z80 → 4
だから、同じクロックで同じような命令なら6800の方が速い。

204 ：

>>202
Z80よりも遅い

205 ：

>>204
なんで？

206 ：

>>203
なるほど

207 ：

6502>6809≧6800＞Z80＞8080

208 ：

>>207
同一クロックで？
>6502>6809≧6800＞Z80＞8080

209 ：

>>208
同一クロックでそれはおかしい

210 ：

扱うデータの量にも拠るな。6502は256バイト超えると途端に効率が落ちる。

211 ：

>>207
場合によっては8080＞Z80もありうる。

212 ：

>>207はニワカ

213 ：

こうか
6502>6809＞6800＞8080＞Z80

214 ：

>>213もニワカ

215 ：

6800…世界的にパソコンやゲーム機にあまり使われなかった。
　しかし16bit拡張の後継CPUが出ている(68HC12と68HC16)
6809…後継CPUの出なかった残念なCPU
仮に6809の16bit版があったなら、6800の16bit版とどっちが使いたい？

216 ：

6800 → 6809
　　　＼
　　　　　68HC11 → 68HC12
　　　　　　　　　　＼
　　　　　　　　　　　　68HC16

217 ：

>6800…世界的にパソコンやゲーム機にあまり使われなかった。
>　しかし16bit拡張の後継CPUが出ている(68HC12と68HC16)
ライバルだった筈の8080は64bit版が出てるってぇのにえらい差ぁついたなｗ

218 ：

>>216
6800系の場合、バイナリ上位互換じゃ無いので水平展開のように見えてしまう…
HC11 = 6800 + Yレジスタ
HC12 = 6809 - Uレジスタ （HC11にポストバイトを設けて命令形態を再設計した感じ）
HC16 = アドレス20bitの独自設計（オペコードマップも大きく異なる）
まあ、PDFでしか見たこと無いけど

219 ：

6800は16ビットのレジスタ持ってるくせにバカみたいに遅い命令しかなかったな
Z80でLD A,（HL)みたいなことができなくて常に３サイクル浪費しさせられた
子孫のＨＣＳ０８はACCBがなくなってIXが上位と下位に分轄されてマトモなCPUになったが
6809の頃にんな形にしとけばよかったのに

220 ：

6809もprefixバイトで拡張してるからなぁ、あれがなければもうちっと綺麗だったような。
または逆に大幅に拡張しとけ、って感じでもあったんだが当時はあのへんが色々妥協点だったんだろうね。
モトローラのバスは、設計は美しいような気がするが周辺デバイスとの親和性がいまいち(ファミリーなら問題ないが)
だったから最終的にコストがかかる感じだったんだよね。
そこらへんがメーカーが採用しぶった部分だと思う。
いまとなってはどの8bitCPUが優れてるとかそうじゃないとか、些末なことだな。
年寄りの昔は良かったに近い、思い出だけが増幅される。

221 ：

集積度か低かった時ならいざ知らず、今時レジスタ分割とか何言っちゃってるんだ？

222 ：

今時でもオペコードはバイト単位にまとなきゃならんし
割込み時には保存しなきゃならんし

223 ：

オペコードサイズとレジスタ分割に何の関係が？
割り込み時の保存はまあそうだが、集積度活かしてレジスタウィンドとか使えばいいだけでしょ。

224 ：

バイナリ互換ではないがアセンブリ言語レベルでは互換
8008 - 8080 - 8086
6800 - 6809

225 ：

8008 - 8080 - 8086 - (略) - 80386 - (略) - Sandy Bridge

226 ：

そこまで書くなら、4004 からにしてやりなよ。

227 ：

>>226
互換じゃないし

228 ：

>>226
4004のアーキテクチャ知ってて言ってる?
http://www.intel.com/Assets/PDF/DataSheet/4004_datasheet.pdf

229 ：

バイナリ互換以外は互換とは認めん

230 ：

古いバイナリなんて動いても価値無い

231 ：

んなこたーない

232 ：

>>231
4004のバイナリが今のPCで動いたとして、どういう価値があるのか詳しくPLZ

233 ：

I4004とI4040は互換性あったよな

234 ：

当時既にアドレスが16bitでは足りないのが判ってたんなら、MMUなんかにしないで24bitにすればよかったのに。
当然、インデックスレジスタ、スタックポインタは24bit、アキュムレーターは3個にして、三つ繋げて使えるとか。
駄目かな。

235 ：

3ていうのが2進数に収まり悪いし効率悪いだろ。

236 ：

i4004は12bitで4KB
i4004は13bitで8KB
典型的な8bitCPUは24bitで64KB
8086は20bitで1MB
典型的な16bitCPUは24bitで16MB
典型的な32bitCPUは32bitで4GB
典型的な64bitCPUは48bitで256TB

237 ：

i4004は12bitで4KB
i4004は13bitで8KB
典型的な8bitCPUは24bitで64KB
i8086は20bitで1MB
典型的な16bitCPUは24bitで16MB
典型的な32bitCPUは32bitで4GB
典型的な64bitCPUは48bitで256TB

238 ：

>>236
>i4004は12bitで4KB
>i4004は13bitで8KB
>典型的な8bitCPUは24bitで64KB
何言いたいのか分からん

239 ：

>>236
>典型的な16bitCPUは24bitで16MB
「典型的な16bitCPU」ってどんなんよ?

240 ：

i4004は12bitで4KB
i4004は13bitで8KB
典型的な8bitCPUは16bitで64KB
i8086は20bitで1MB
典型的な16bitCPUは24bitで16MB
典型的な32bitCPUは32bitで4GB
典型的な64bitCPUは48bitで256TB

241 ：

>>240
>i4004は12bitで4KB
>i4004は13bitで8KB
どっちが正しいの?

242 ：

典型的なﾊﾞｶ

243 ：

スパゲッティ絡まった

244 ：

i4004は12bitで4KB
i4040は13bitで8KB
典型的な8bitCPUは16bitで64KB
i8086は20bitで1MB
典型的な16bitCPUは24bitで16MB
典型的な32bitCPUは32bitで4GB
典型的な64bitCPUは48bitで256TB

245 ：

Rっこ

246 ：

>>244
>典型的な64bitCPUは48bitで256TB
典型的な64bitCPUってDECのAlphaだろ? そんなでかい物理アドレス持ったチップなんてあったかな?

247 ：

>>244
>典型的な16bitCPUは24bitで16MB
典型的な16bitCPUであるTMS9900はそんなにメモリ積めないゾｗ

248 ：

CPUの擬人化漫画はまだですか？

249 ：

結局>>244は何が言いたいのかわからない
究極の8ビット機スレによく沸いた
「メインCPUが8008でサブCPUがcore-2」
とかいう内容を延々書き込んでいたバカと同じ匂いがする

250 ：

>>248
CPUの創り方という本で

251 ：

>>250
名作だよね、一度作ってみたいけど
込み入ってくるとジャンパー飛ばすのがめんどくさそうで
部品集めしたけどまだ手を付けていないのが現実

252 ：

>>250
買った、読んだ、色々な意味で感動した
Verilog-HDL とやらで FPGA に移植を試みた
初っ端のクロック 1 Hz を作る段階で、虚しくなって頓挫 w

253 ：

本文: 渡波郁 (となみかおる)
イラスト: 須田都 (すだみやこ)
…ってペンネーム使い分けてるけど、実は同一人物?
ttp://homepage3.nifty.com/sudamiyako/

254 ：

仮に超高クロックの究極8bitCPUが有ったとしても
今時のソフトウェアはFloatだのDoubleだの16bit以上の演算ばかりなので
大したパフォーマンス出ないだろうな

255 ：

>>254
今だとCPUよりGPUの方が重視されそうだしな。

256 ：

FPUとGPU外付すれば。

257 ：

そもそもそんな高パフォーマンスが必要なのか？

258 ：

もちろんないよ

259 ：

>>254
8bitアドレスのCPU作るなら別だけど、8bitCPUだってアドレス演算は16bit以上だからね。

260 ：

>>253
http://homepage3.nifty.com/sudamiyako/zk/68/jisaku.html
結構アレゲ。

261 ：

>>254
昔のソフトを動かせば良い

262 ：

8bitCPUに追加するFPUなんてカシオの電卓で十分やで

263 ：

実際電卓用のLSIを繋げようとした試みはあった。

264 ：

そういや、外付け乗算器とかあったなぁ

265 ：

8bitようのマスコプロも色々出てたな

266 ：

トランスピュータとか？

267 ：

は？

268 ：

違ったね。失礼。

269 ：

そういやWikiのFP-1100の解説でサブCPUは電卓のだとかむちゃくちゃ書いてたな
今見たら差し障りのない解説でつまらん

270 ：

>>269
>そういやWikiのFP-1100の解説でサブCPUは電卓のだとかむちゃくちゃ書いてたな
どの版?
http://ja.wikipedia.org/w/index.php?title=FP-1000&action=history

271 ：

>2CPU構成(メイン Z80互換 4MHz、サブ 4bitマイコン)
これかな？
意味は違うけど

272 ：

>>269
なんだ嘘か。

273 ：

嘘にしちゃ意図わからんな。履歴見れるのも知らず、適当な伝聞に脚色したのかな
「wikiとはどっかのwikiであってwikipediaとは誰も言っていない」説に切り替えられると予想

274 ：

wwwなるほどwww

275 ：

Z80も言い方変えれば4bitなんだけどな。

276 ：

>Z80も言い方変えれば4bitなんだけどな。
↑バカ丸出しｗ

277 ：

>>275はALUかなんかのことと勘違いしてると見た

278 ：

>>275
kwsk

279 ：

まあ○ビットCPU なんて、メーカーが適当につけてるだけだからねぇ。
ちゃんとした定義があるわけでもないし。

280 ：

>>275に言わせるとドリームキャストは128bit

281 ：

>>279
Z80当時はデータバス幅の意味で各社例外なかったと思う

282 ：

インテルが8bit CPUとして販売していた8088を、IBMがPCに採用して16bit PCと言って売ったり、
ナショセミが外部16ビットのNS16032を32ビットアーキテクチャMPUとして売ったりした辺りから
崩れてきた気がする。

283 ：

8088のデータシート
http://pdf1.alldatasheet.com/datasheet-pdf/view/66063/INTEL/8088-2.html
> 8-BIT HMOS MICROPROCESSOR
16032のデータシート
http://i.ebayimg.com/t/National-Semi-NS16032-High-Performance-Microprocessor-/19/!B6rIZwgBWk~$(KGrHqV,!jcEybjnQ001BMyL3RY-6g~~_3.JPG
> 32-Bit Architechture and Implementation

284 ：

Z80も6809も6502も言い方変えれば16bitなんだけどな。

285 ：

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

286 ：

>>285
スレの流れ的に貼るのはこっちの方だろ。
http://ja.wikipedia.org/wiki/FM_TOWNS#cite_note-32
> 29. ^ X68000が搭載する68000（より厳密にはそのセカンドソース品の日立製作所HD68HC000）は
> 汎用レジスタが32ビット長であるが、アドレスバスは24ビット幅、データバスは16ビット幅となっており、
> 開発元であるモトローラの定義では16ビットCPUとなる。同社のライバルであったインテルの場合は
> CPU内部の汎用レジスタ長をもってCPUのビット数として取り扱ったが、モトローラではデータバス幅を
> もってCPUのビット数を表現した。このため、同じ16ビットパソコンと表記する場合でもインテル製CPU
> 搭載マシンとモトローラ製CPU搭載マシンではその意味合いが異なる場合がある。X68000の場合も
> インテル流に表記すれば全て32ビットパソコンということになり、データバス幅16ビットの386SXを搭載
> したFM TOWNSの廉価機はモトローラ流の表記に従えば16ビットパソコンとなる。ここでいう32ビット
> パソコンとは、データバス幅も32ビット化されたマシン、つまりMC68020やMC68030（およびその
> 派生モデル）を搭載したマシンを指す。

287 ：

>>286
> 開発元であるモトローラの定義では16ビットCPUとなる。同社のライバルであったインテルの場合は
> CPU内部の汎用レジスタ長をもってCPUのビット数として取り扱ったが、モトローラではデータバス幅を
> もってCPUのビット数を表現した。
8088は? 68008は?

288 ：

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

289 ：

Wikipediaの注釈書いた奴が発狂してるのか？ｗ

290 ：

マルチポストしてるアホにいちいちかまうなよ。

291 ：

じゃ元祖Pentiumは64bitになるじゃんか

292 ：

>>287
モトローラ流で言えばどちらも8bit

293 ：

>>292
8088のデータシート
http://pdf1.alldatasheet.com/datasheet-pdf/view/66063/INTEL/8088-2.html
> 8-BIT HMOS MICROPROCESSOR
インテルがモトローラ流(笑)の呼び方してる↑
68008のデータシート
http://pdf1.alldatasheet.com/datasheet-pdf/view/4141/MOTOROLA/MC68008.html
> MC68008 - 16-Bit Microprocessor With 8-Bit Data Bus - Motorola, Inc
モトローラがモトローラ流(笑)の呼び方してない↑

294 ：

Rっこ

295 ：

288や388は無いのか〜

296 ：

そういや、i80386sxも外部バスは16bit、アドレスバスは24bitだったけど、32ビットって言ってたもんなぁ

297 ：

16bitな486
IBM 486SLC、486SX(J) 、Cyrix Cx486SLC

298 ：

486はダイナミックバスサイジングができるから8bitも可

299 ：

>>296
ちゃんと32bit「内部」アーキテクチャだと明記している。
http://pdf1.alldatasheet.com/datasheet-pdf/view/226542/INTEL/INTEL386.html
> ■ Full 32-Bit Internal Architecture
286の基板に載せられる386ってコンセプトだから当たり前だが。

300 ：

>>298
NECがV30後継として8080/Z80互換機能搭載の486を作ってくれたら最強だったのにね。
別に他のメーカーが同様の発想で作っても良かった。

301 ：

68000搭載のメガドライブは32bitと言いたいところだが、
外部アドレスバス32bit無いから32bitゲーム機とは言いがたいかも

302 ：

>>301
68000自体は自称でも32bitCPUとは言ってないけどな。

303 ：

>>301
68000は内部16bitのプロセッサだよ。レジスタの幅が32bitあるというだけ。

304 ：

現在担当のフリースケールはローコスト32bitと言ってるけどな

305 ：

モトローラと違う会社なんだから流儀が違っても不思議はない＞フリースケール

306 ：

今の「このCPUはRISCかCISCか」みたいな論争と同様、
「このCPUは16bitか32bitか」なんてほとんど意味ないだろ
外部バス幅がどうとかレジスタ長がどうとかメーカーがこう言ってるとか・・・

307 ：

>>306
意味がないとかあるとか、そんな話誰もしてませんよ？

308 ：

>>306
>今の「このCPUはRISCかCISCか」みたいな論争と同様、
いまどきそんな論争しとるバカなんていないだろ。

309 ：

>>306
>「このCPUは16bitか32bitか」なんてほとんど意味ないだろ
68000や386が現役の頃やそれ以前はマーケティング的な意味があったよ。

310 ：

中はデュアルポート32ビットRAMと独立バスのROMだから128bitと呼んでもいいレベル
演算対象がメモリへでも１サイクルで終わるんだから68000の子孫も6809の子孫も大したもんだ

311 ：

>>310
誤爆? つーか電波?

312 ：

>>310
>中はデュアルポート32ビットRAMと独立バスのROMだから128bitと呼んでもいいレベル
せめて何について言及してるんだかくらい書いとけ。

313 ：

68000は32bit、メガドライブは32bit、X68000は32bit
、メガドライブにメガCDと32Xを装着すれば、
Z80(8bit)+68000(32bit)×2+SH2(32bit)×2だから
136ビット級だな。

314 ：

>>310
ColdFire+?

315 ：

自称16bitのテキサス・インスツルメンツ TMS9900やゼネラル・インスツルメンツ CP1600
、なんか8bitとあまり変わらないような希ガス。外部メモリーアドレス幅は16bit。
8086も64KB以上にアクセスするにはセグメント方式(バンク切り替え機能と言えるか)
でアクセスするから似たようなもんかな。

316 ：

8bit CPUよりも16bit CPUの方が意外と種類が少ない感じだね。32bit になると
RISC系が沢山出てくるし。純粋な16bit CPUってもの少数派の感じで、
よく使われている16bit CPUでは8-16bit系(8086、65816)と
16-32bit系(MC68000)って感じだな。

317 ：

いまDIPで入手可能な一番性能が良いCPUってどれよ

318 ：

>>316
16bitは中途半端だからな。
アドレス幅が16bitじゃさすがにアレだし24bitとか欲しくなるのが目に見えてるんだから
最初から32bitにしとけって事だ。
>>317
はいはいPIC、PIC
PIC32なら中身はMIPSだし性能的には問題無いだろ
最近、ARMコアのDIP品も出回ってるけどアレはM0だからな〜

319 ：

>>318
>PIC32なら中身はMIPSだし性能的には問題無いだろ
サンクス、これから資料集めて読みまくる

320 ：

MIPSってキャリーフラグとかローテートって機能がないんだな
C言語にまったく無い概念だからどうでもいいといえばどうでもいいんだが

321 ：

mipsなんて完全にオワコンのアーキテクチャだったけどな、ライセンスが安いとかあんのかな? いまだに生きてるのが信じられん。

322 ：

>>316
>8bit CPUよりも16bit CPUの方が意外と種類が少ない感じだね。
お前が知らないだけ。
組み込み用途には結構使われてるし種類も多い。最近32bitプロセッサに侵食されてきてはいるけどな。

323 ：

>68000 CPUは外部データバスが16bitであったため当時は16bit CPUとして分類される。
またぞろ誰かさんが書き換えてくれたわけですが（しかもID作った直後に。そして
現在に至るまでX68000以外の編集履歴もなしときているわけだなこれが）。
これってぶっちゃけ「外部データバス幅が16bitしか無い386SXが32bitCPUを名乗れ
るなら、68000も32bitを名乗れるはずだ」という、当時Oh!X誌あたりで気持ち悪い
信者と無知なライターが主張して気勢を上げていたネタですよねぇ？
結論から言えば、一般的には（もちろん異論もありますが）CPUのビット数ってのは
第一にALU（算術演算ユニット）のビット幅によって規定されるものであって、68000
はこのALUが16bitしか無いため純然たる16bitCPUであると（そして386SXが何故32bit
を名乗れるかといえば、386SXのALUは32bitあるからです）、こんなことはWikiの
MC68000の項目にもしっかり書かれている事実なわけですよ。
レジスタ幅が32bitだから32bitCPUだろうとか、後の68020や030などの純然たる
32bitCPUと同じ命令アーキテクチャを持っているから実質32bitだとか、中身は
最初から32bitだったのに外部データバス幅が16bitだったから不当に貶められたと
かは、まあ外野が噂話をする分には構わないしそういう（無知だからこそ）流布した
噂が当時存在していたことも事実ですが、百科事典に書いてしまったらまずい訳です
わ。そういう（恥ずかしい誤認による）主張があったという事実を記述したいので
あれば、無知なライターと阿呆なユーザーが一部でそう主張していたという事実を
きちんと書かなければならない。違いますか？

でも68kは置いとくとして、例えばオリジナルの8080やZ80なんかはALUは4bitで
実装されていて、2回回しで8bit演算を行ってたはずでは。論理的（もしくはISA的）
には8bitで、機能面の充実を優先するために実装上の等価回路として4bit2回回し
を選択した訳だし(電子情報通信学会より)。
そういう前例からも、ALUのbit幅は単なる実装上の数値でしかないんじゃないかな
ー。--125.28.0.232 2006年8月23日 (水) 17:20 (UTC)
ノート:X68000 - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%BC%E3%83%88:X68000

324 ：

なんだ8080とZ80は4ビットか

325 ：

ノート:CPU - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%BC%E3%83%88:CPU
> bit数
> CPUのビット幅がALU幅である旨の要出典。反例として8080やZ80はALU4bit構成(2回廻し)で
> あるが矛盾する。従って信頼性の高い出典なければ独自研究と判断) (取り消し)
> ちぇすさん、取り消しは？ CPUのビット幅の定義、または説明は必要でしょう。 この件は
> 各メーカーの定義、或いは共通の認識で決まると思います。 bit数は必要な説明ではない
> ですか？ 削除ではなく×bitCPUに対して、その定義、或いは説明を考えませんか？
> > CPUのビット幅がALU幅である旨の要出典。 との事ですが >反例として8080やZ80は
> > ALU4bit構成(2回廻し)である
> のソースを教えていただけないでしょうか。
> ちなみにWikipedia初心者で使い方がイマイチ解っていません。 何となく変な事をしている気が
> します。 ご指摘を頂けると幸いです。Shisan 2007年10月19日 (金) 16:25 (UTC)

326 ：

8080Aのデータシートのブロック図見るとALUは8ビットっぽいけどね。
http://www.classiccmp.org/dunfield/r/8080.pdf

327 ：

見やすくするために、4bit ALUの2回回しは省いたんチャウチャウかわいいよね

328 ：

Z80は4bitALU。
設計者の嶋氏の著書マイクロコンピュータの誕生p144で「8ビット構成のALUを4ビットに変更した事によって〜」と触れられている。

329 ：

嶋氏の著書で8080の演算回路についても書かれているが、キャリールックアヘッドってか
プロセス違いによる回路設計上の問題点が主題になってる。
Z80ALU回路について触れられる文章において
「8080Aでは〜かなりの面積を無駄にした。こんどは内部〜、先に述べた8ビット構成のALUを4ビットに〜」と書かれているので
8080Aでは8bitALUである事が推測されるが。
実際の8080チップ写真に置いてもALU部分が8bit処理である事は見て取れるが。

330 ：

>>323
>こんなことはWikiの
>MC68000の項目にもしっかり書かれている事実なわけですよ。
オモロイｗ

331 ：

1D SEX

332 ：

MC68000はあの巨大なDIPパッケージで他を圧倒するだろ
MC68000と同じ基板に並べたら8086なんてただのICにしか見えん
あのでかさは32bit級と言っても過言ではない

333 ：

32bitだからでかいってこと別にないけどな
http://akizukidenshi.com/catalog/g/gI-05852/
http://akizukidenshi.com/catalog/g/gI-06071/

334 ：

組込系だ制御系だといいつつプログラムしかしなかったからプロセッサが8ビットだとか16ビットだとか32ビットだとか気にしなかったな。
データやロジックが実装されているストレージに収まるかどうか、処理が時間道理に完了するかどうかのほうが重要だったから。
「おい、処理をあとｎクロック短くしてくれ」だけなら意外に簡単。
『処理をｎクロック短く、かつ、データをｍバイト以下に抑えてスタック消費をｐバイト以下にしろ』とかの複合攻撃だったからなぁ・・・

335 ：

>>334
>組込系だ制御系だといいつつプログラムしかしなかったからプロセッサが8ビットだとか16ビットだとか32ビットだとか気にしなかったな。
アセンブリで組んでなかったんじゃね?

336 ：

>>334
8ビットと32ビットじゃプログラムのチューニングの仕方も結構違うと思うけど、気にしないで
やってけるもんなのか？

337 ：

最近スレ違いが度を越しているな
誰も8086,Z80,6809,6502の話してないじゃん
組み込みがどうのこうの、なんて話は電気電子板でやれよ。

338 ：

組み込みって言っても範囲広いからなあ。
ＵＩ 周りとかだと、あまりビット数なんて意識しないけど、8bit でリッチな UI と言うのは
あまりないだろうね。
そもそもクロック気にするような状況だと、ビット数というよりプロセサの種別の方が気
になると思うから、>>334 はどう見ても聞きかじりの知ったか君にしか見えない。

339 ：

Z80に32bit演算の出来るFPUを繋げたら
究極の8bitCPUになれる

340 ：

>>334
プロセッサのアーキテクチャも意識しないでプログラムの最適化なんて大したことできないと思うんだけど、現実の話ですか？

341 ：

>>334
>「おい、処理をあとｎクロック短くしてくれ」だけなら意外に簡単。
>『処理をｎクロック短く、かつ、データをｍバイト以下に抑えてスタック消費をｐバイト以下にしろ』とかの複合攻撃だったからなぁ・・・
ヌルいプログラム書いてっただけの話だろ。

342 ：

>>339
つ Z380

343 ：

>>342
http://www.zilog.com/docs/serial/z380.pdf
> 32-Bit Internal Data Paths and ALU
なんて書いてあるし、8bitCPUじゃねぇだろ。浮動小数点演算も機能としてないみたいだし。

344 ：

Z800･Z280 24ビットリニアアドレッシング
Z380 24ビットリニアアドレッシング/32ビットリニアアドレッシング
eZ80 24ビットリニアアドレッシング
いずれもZ80上位互換だが、拡張部分はそれぞれ非互換である

345 ：

>>344
>Z800
Z800って実在しないだろ

346 ：

Z800･Z280 24ビットリニアアドレッシング
Z380 24ビットリニアアドレッシング/32ビットリニアアドレッシング
eZ80 24ビットリニアアドレッシング
R800 24ビットリニアアドレッシング
eZ80はR800の技術を使用しているとか

347 ：

>>343
せやな

348 ：

>>346
>R800 24ビットリニアアドレッシング
MMUで物理アドレス空間が24ビットまで使えるってだけじゃん

349 ：

>>346は「リニアアドレッシング」の意味を理解してない

350 ：

Z280 20886的拡張で使い難い。遅い。
Z380 32bit扱うにはショボイ。
R800 速い。
eZ80 速い。仮想80モードも搭載。
Z380とR800とeZ80は似ているらしい

351 ：

>>350
>20886的拡張
意味分からん

352 ：

内容が不確かと評判のWikipediaに
HD64180 - Wikipedia
http://ja.wikipedia.org/wiki/HD64180
> 除算命令を備えている。
と書かれていた。評判通りだな。

353 ：

>>334
>『処理をｎクロック短く、かつ、データをｍバイト以下に抑えてスタック消費をｐバイト以下にしろ』とかの複合攻撃だったからなぁ・・・
コンパイラの出力眺めながら最適なコードを吐くようソースを修正したり、場合によっては
アセンブラで関数書いたりって作業になると思うけど、「プロセッサが8ビットだとか
16ビットだとか32ビットだとか」気にしないでどうやるんだ??
アセンブリレベルの最適化しないにしても、プロセッサによって効率のいい変数のサイズも
違ったりすんのに。

354 ：

>>350
>Z280 20886的拡張で使い難い。遅い。
286的って事?例えが変だろう。
パソコン向けの拡張と言うべき。
速度が期待外れ的に遅いってのがZ280の問題点だが
もし速度が速かったら、今度は16bitアドレスが枷になって、Z80互換CPUの限界を露呈しただろう。
命令セット互換の辛さだな…

355 ：

インテルは8080用のソースプログラムを8086や80386、現在のSandy Bridgeに至るまで
簡単なコンバータで変換できる機構を用意できてんのにザイログは何馬鹿なことやってんだ?
バイナリ互換なんてパソコンでもない限り必要ないのにな。

356 ：

アセンブラとかバイナリ直うちとか、原始時代のお猿さんたちかよｗ

357 ：

>>355
パソコンこそ必要ないだろ

358 ：

ああごめ。
パソコンこそ必要だったわ
素で間違った

359 ：

mipsまだ生きてるみたいじゃんスマホ・タブレット向けにやってる。javaにopengl、mipsと
くればワークステーションの怨念の塊よね、ARMだといまいち怨念が足りない。

360 ：

>>356
うるせー馬鹿

361 ：

メガドライブが32ビットになるのさ
メガドライブ スーパー32X　CM
http://www.nicovideo.jp/watch/sm717736

362 ：

ARMってどうにもマイコンって気がするんだよな。
先入観的に。

363 ：

組込みなんて動いてナンボな世界だろ。
コロコロ石かえたりすんの？
リスキー過ぎるな

364 ：

コロコロ石変えるなんて誰か言ってる?

365 ：

誰も言ってないと思う。
ただ、例の震災で石変える羽目になったとかで、いくらか受注案件が増えたよ (w

366 ：

色々な石を経験してるとしか思えない書き込みがちらほらあるから。
今の現場はプログラミングリレーからＰＣボードで窓組込７になったんだ。

367 ：

> 色々な石を経験してるとしか思えない書き込みがちらほらあるから。
この板ジジイばっかだから、何十年もやってりゃそりゃ色々経験すんだろ。

368 ：

同じ世代の複数機種を経験するって…

369 ：

別に普通にあると思うが。

370 ：

>>368
外注でソフト開発する会社なんかだとふつー。
元請けレベルのデカい機器メーカーだと、そうでもないのだろうけど。

371 ：

>同じ世代の複数機種を経験するって…
普通じゃね? つーかそれぐらい対応できんとその道でメシ食えないだろ。

372 ：

柔軟に他機種でアセンブルプログラミングできないとね。

373 ：

まあ組み込み系だと珍しくないわな。
業務系だと、それこそ 30年間 COBOL 一筋の COBOLER とか VB しかやったことない
VBer とかがいたりしたけど。

374 ：

>>368
いままでどういうのやってきたかちょろっと書いてみ?

375 ：

釣れますか？　>>368

376 ：

PCやゲーム機が8bitだった時代はどうやってソフト開発したんだ
ROM BASIC使わずマシン語で高速に実行したい場合
FORTRANやC言語などのコンパイラとかあったの？
それとも全部人間がアセンブリ言語で作っていたのか

377 ：

>>376
>FORTRANやC言語などのコンパイラとかあったの？
あった。
>それとも全部人間がアセンブリ言語で作っていたのか
こっちの方が主流。

378 ：

↑釣られるなよ

379 ：

>↑釣られるなよ
意味分からん。当たり前の事実しか書かれていないが？

380 ：

まあこんな閑静なスレだから、釣り宣言も釣られたレスも枯れ木の賑わいだろ

381 ：

ITどかた上がりのじい様たちが集う枯れ木山だね。

382 ：

>>376
今は効率的なコンパイラとコンパイラに合わせたcpuがあるけど、当時は下手にコンパイルするより
人間が組んだ方が速かったもんなぁ。
そのノウハウがいまのコンパイラに注ぎ込まれてるから、今は下手にニーモック書くよりコンパイラ通した方が速いし。

383 ：

>>382
>今は下手にニーモック書くよりコンパイラ通した方が速いし。
ホントに下手糞が書いた場合よりはな。

384 ：

BDS Cはなかなか速かった。
Lattice C 1.xは糞だった

385 ：

>>384
>Lattice C 1.xは糞だった
クロスコンパイラじゃね?
http://web.archive.org/web/20090424005739/http://www.lattice.com/otherz80.htm
> Z80 C DEVELOPMENT SYSTEM
> Requirements
> CPU ― 8088, 8086, 80186, 80286
> Operating System ― MS-DOS, PC-DOS or equivalent
> Memory ― DOS: 128 KB minimum
> Hard disk recommended

386 ：

>>382
> 今は下手にニーモック書くよりコンパイラ通した方が速いし。
いまでもちゃんと効率考えて組めばコンパイラの吐いたコードなんかよか早いもん組めるよ。
いまどきのプロセッサで極限まで高速化するにはキャッシュやパイプラインやストールの
原因なんかを意識しないといけないんでけっこうしんどいけど。

387 ：

>今は下手にニーモック書くよりコンパイラ通した方が速いし。
↑こーゆーこと訳知り顔で語る奴は大抵の場合分かってない

388 ：

95年ぐらいまでのコンパイラが吐くより効率の良いコード書けるが21世紀になってからのは太刀打ちできねーな。
元より今時のプロセッサ相手にアセンブラとか無駄なことはしないけど。

389 ：

>>387はAVRとかPICとかのセルフコンパイラーとアセンブラ比べたりしてんのかな？

390 ：

まあ1バイト単位でｶﾞﾘｶﾞﾘ削ったりしないしな。
当然速度も十分速いし。

391 ：

>>389
>>>387はAVRとかPICとかのセルフコンパイラーとアセンブラ比べたりしてんのかな？
AVRやPICにセルフコンパイラなんてある? ちょっと想像できん。

392 ：

言葉の意味分かってないんじゃないかな。

393 ：

仕事なら１バイト削らなきゃ仕様を満たさないとなれば削るが、んな馬鹿馬鹿しいことはやらないし。
ページャーぐらいしかンな経験ないな。

394 ：

月間マイコン1986/05のT-TIMEインタビュー記事で
デーモンクリスタルってゲームを作ったプログラマーの人が
「MZ-1500でコンパイラ使ってる」って書いてたな。
GAMEか何かだとは思うけど、まぁアセンブラ絶対主義ってのもな…

395 ：

>まぁアセンブラ絶対主義ってのもな…
誤爆？

396 ：

>>394
>まぁアセンブラ絶対主義ってのもな…
何関係ない話してんの？

397 ：

>>394
当時の市販ソフトで、BASICで組まれたのやなんらかのコンパイラ使用を謳ったソフトなんて珍しくなかったけど、知らんの？
つーか何言いたいのか解らん。

398 ：

最適化の話をしてる人を見るとアセンブラ絶対主義者に見える病気の人では？
要求される条件に従い実行効率や開発効率を考慮してアセンブラでもコンパイラでもインタプリタでも使い分けれればいいってだけの話だけどね、頭悪い人なんだろうな。

399 ：

まあ極限の世界で闘えるのはアセンブラだけやな

400 ：

そんなことはない

401 ：

>極限の世界で闘えるのはアセンブラだけ
↑こーゆーこと訳知り顔で語る奴は大抵の場合分かってない

402 ：

使えないヤツの書くコードはムダだらけ

403 ：

今どきアセンブラにこだわる奴が使える奴とは思えないわな〜
おまけにアセンブラーが威力発揮せるようなプアな環境なんて使い物にならんし。
30年前はともかくｗ

404 ：

ゲームやら組み込みやら、動作環境のパフォーマンス引き出さな商売ならんこともあるの知らんのね。

405 ：

>今どきアセンブラにこだわる奴が使える奴とは思えないわな〜
>おまけにアセンブラーが威力発揮せるようなプアな環境なんて使い物にならんし。
いまだに使われてるちっこい組み込み用のマイコンとか想像もつかんのだろうな

406 ：

>今どきアセンブラにこだわる奴が使える奴とは思えないわな〜
>おまけにアセンブラーが威力発揮せるようなプアな環境なんて使い物にならんし。
>30年前はともかくｗ
JavaかVBしか知らんようなニワカが言いそうなセリフだなｗ　釣りとしてはよく出来てる。

407 ：

最初は30年前のこと言っていて、途中から現代の話かよ
年寄りってのは話がむちゃくちゃで、憑いていくのが大変だな

408 ：

アセンブラなんて選択肢のひとつでしかないのに、端っから否定するような奴にできる仕事なんてたかが知れてるだろ。

409 ：

組み込みだってずいぶん前からクロス開発当たり前だし、アセンブラー使わなきゃならないなんて案件は絶無だけどね。
たいていは言語仕様的に書けないような部分をインラインアセンブラで書くぐらいだな。

隠居爺の脳内歴史じゃ違うのかもしれんが。

410 ：

>組み込みだってずいぶん前からクロス開発当たり前だし、
それ以前はセルフ開発が当たり前だったみたいな言い方だなｗ

411 ：

AMD64でアセンブル、やる気の起こるハードが無い

412 ：

アセンブリ使わなければ要求する性能を達成できないというなら
コンパイラで書いても十分な性能を達成できるハードウェアに変更するし
コンパイラで書いて十分な性能が出ているものを、さらに効率化するため
とか言ってアセンブリで書こうとするような奴はプロジェクトから叩き出すし
大昔の、しょぼいプロセッサに狭いメモリしか無かった時代に
それ以上のものを求めても手に入らなかったから仕方なく書いていたならともかく、
デバイスドライバや割り込み・メモリマネージャまでCで書く時代が
いったい何十年続いてると思ってるんだか、あるいはそれを知らないのかしらんが、
21世紀の今頃になってアセンブリ最強とか言ってる奴は頭どうかしてる

413 ：

えらそうに「コンパイラが吐くコードを意識しながらコーディングするんだ」とか言ってた奴らも、
実際はそんなことできていなかった。
口プロレスでこういう事ほざく奴に限って、能力はたいした事のない口だけ野郎だったしなー

414 ：

使わないと使えないの区別ができないバカ

415 ：

>>413
職場のレベルの低さを自慢してどうすんの?

416 ：

>>412
>アセンブリ使わなければ要求する性能を達成できないというなら
>コンパイラで書いても十分な性能を達成できるハードウェアに変更するし
家庭用ゲームとかでも同じことできる？
>コンパイラで書いて十分な性能が出ているものを、さらに効率化するため
>とか言ってアセンブリで書こうとするような奴
なんでプロジェクトに基地外がいるの？

417 ：

C++のコードをアセンブラレベルで効率的に書き直せるのかな？

418 ：

>>417
ループの内っ側や末端の関数なら大した手間ではないし効果も期待できることもある

419 ：

アセンブラ最高
アセンブラは大人のたしなみ

420 ：

小生も最近物忘れが目立ってきたのでボケ防止のためにアセンブリ

421 ：

>>418
万とか億とかの単位で単純ループするとか？
もしそんな事があるなら、言語以前の問題でわないかと…

422 ：

アセンブラ
アセンブリ
アセンブル
アセンブレ
アセンブロ

423 ：

昔のPC板で「21世紀」とか何を言っているんだか。
21世紀とは永遠に訪れない夢のような未来。

424 ：

>家庭用ゲームとかでも同じことできる？
家庭用ゲームのプログラマーなんて、底辺中の底辺じゃねーか
しかも今はメーカー・ミドルウェア開発（こっちはエリート）と
アプリケーション（消費者向け製品）のプログラマは完全に階層が別れてる

425 ：

>>421
>万とか億とかの単位で単純ループするとか？
1万回ループするなんて全然珍しい話ではないけど何言ってんの???

426 ：

わずかROM 3Kバイト，RAM 24バイトで動くリアルタイムOS「TOPPERS/SSP」誕生!
第1回　カーネルの機能と構造
ttp://www.kumikomi.net/interface/sample/201211/if11_122.pdf
TOPPERS/SSPカーネル
ttp://www.toppers.jp/ssp-kernel.html

427 ：

ループ内処理をアセンブリにして小手先で効率化するくらいなら
ループ展開しちゃった方がたぶんずっと楽になるよね（メモリは喰うけど）

428 ：

>>424
>しかも今はメーカー・ミドルウェア開発（こっちはエリート）と
>アプリケーション（消費者向け製品）のプログラマは完全に階層が別れてる
実際そんなにミドルウェア製品なんて使われないぞ? ゲーム関係で仕事したことあんの??

429 ：

>>427
いまどきのプロセッサはループ展開すると速くなるって単純なもんでもなかったりするよ

430 ：

プレステ3のようにハードウェア設計者側のRーで扱いにくい構成にしてしまった結果
効率的なミドルウェアの開発に失敗して、アセンブリ使わないと性能を発揮できない糞ハードが
なぜか21世紀の10年期をまたいで存在してしまっているけど、そのくらいへぼい、最低の環境でもないと
いまどき「家庭用ゲームのプログラマー」はアセンブリなんか使わないよ
10年くらい前なら、CPU側でSIMD命令を使った処理を書くのにアセンブリしか無かった
みたいな事情はあったけど、それも今ではGPUに丸投げする時代だしねえ
モダンなGPUでは命令は中間コードで持っていて（これ自体をコンパイラが吐くわけだけど）、
それをデバイスドライバ内に持ったJITコンパイラでさらに機械語に変換して食わせてるわけで。
最も処理の効率化が求められ、その見返りも大きなGPU内の処理でさえ、こんな有り様なんだよね。
MS-DOSで頭が止まっているような怠惰なオッサン連中には、想像もつかない世界だったかもしれないね。
ちょっと残酷なことをした。

431 ：

>>427
ループ内処理をアセンブリ化するのと、ループ展開は全然別の話じゃん。
それに、ループ展開で効率化すんならアセンブリ化の際に当たり前にやってるだろ。

432 ：

>いまどきのプロセッサはループ展開すると速くなるって単純なもんでもなかったりするよ
キャッシュを無駄に食いつぶしちゃうからね。
それに、いまどきループ処理で無駄なコードを吐くようなコンパイラも、ごみだ。

433 ：

>実際そんなにミドルウェア製品なんて使われないぞ? ゲーム関係で仕事したことあんの??
いまどき碌なミドルウェアもないゲーム機なんて、SONYの据え置き機くらいしかないぞ？
ゲーム関係で仕事したこと、ないよね？

434 ：

>>430
>プレステ3のようにハードウェア設計者側のRーで扱いにくい構成にしてしまった結果
>効率的なミドルウェアの開発に失敗して、アセンブリ使わないと性能を発揮できない糞ハードが
>なぜか21世紀の10年期をまたいで存在してしまっているけど、そのくらいへぼい、最低の環境でもないと
>いまどき「家庭用ゲームのプログラマー」はアセンブリなんか使わないよ
なんだ現代の話じゃん。何必死に否定してんの？

435 ：

最低の例外くらいしか存在しない、って話してやってるのに、なにを一般化して語ってんの？
それにゲーム本体のプログラマはアセンブリなんか書かないし、書けないよ。

436 ：

じゃあなんだ、アセンブラ使ってると思ってる連中は、いまだにゲームのプログラムではアセンブラで直接ハードウェアを叩いてると思っているわけかｗ

437 ：

>>433
>いまどき碌なミドルウェアもないゲーム機なんて、SONYの据え置き機くらいしかないぞ？
任店のはライブラリってレベル

438 ：

>>436
必要があればアセンブラも使うけど何か？

439 ：

素人でも分かりやすい例だと8bitのPICなんかだとコンパイラで組んだ場合とアセンブラでの場合とで速度やサイズが段違いだから今でも全然アセンブラ有利だけどな。
まあ、ここ数年でPICの上位シリーズが随分伸びてるんで8bitにこだわる理由もなくなっては来てるが。

440 ：

>>421
億は兎も角、万ならそんな驚く話ではないな。

441 ：

いまだに8bitなんか使ってるような底辺・小規模の組み込み系くらいだろ
それもブートストラップの一部だけどうしても（CPUがマイナーすぎてコンパイラが対応してないから）アセンブリで書かないと通らない
みたいなニッチな事情で。

442 ：

>>435
>それにゲーム本体のプログラマはアセンブリなんか書かないし、書けないよ。
ゲーム本体のプログラムが全てとでも言いたげだなﾜﾛﾀｗ

443 ：

>>441
>いまだに8bitなんか使ってるような底辺・小規模の組み込み系くらいだろ
いまだに数が一番多い分野じゃん。馬鹿なの？

444 ：

ファミコンのゲームソフトも職人がコード書いてハードの限界を追求したんだろうな

445 ：

6502の職人で有名どころだと岩田とかナーシャジベリとかか
まあ岩田が限界に挑戦したって言ってるところ話は想像つかんけど

446 ：

いまでもパR/パチスロの当たり制御は保通協の関係でアセンブラなんじゃないかな。

447 ：

>>413
コンパイラの出力見てソースの書き方考えるって普通のことじゃん。

448 ：

>>409
>組み込みだってずいぶん前からクロス開発当たり前だし、アセンブラー使わなきゃならないなんて案件は絶無だけどね。
「求人 組込み アセンブラ」でぐぐるだけで「絶無」なんて状況じゃないことは判るが。
https://www.google.co.jp/search?q=%E6%B1%82%E4%BA%BA+%E7%B5%84%E8%BE%BC%E3%81%BF+%E3%82%A2%E3%82%BB%E3%83%B3%E3%83%96%E3%83%A9&ie=UTF-8
# つーか「クロス開発」って意味解って言ってんのかな?
# 組込みでセルフ開発なんて時代あったか?? FORTHでも使うのかな?

449 ：

>>413
>えらそうに「コンパイラが吐くコードを意識しながらコーディングするんだ」とか言ってた奴らも、
>実際はそんなことできていなかった。
>口プロレスでこういう事ほざく奴に限って、能力はたいした事のない口だけ野郎だったしなー
じっさいそういう必要があるからVTuneみたいなツールも存在するわけだが。

450 ：

>>427
ループ展開するとキャッシュヒットが減ることがあるのであんまし薦められない
キャッシュに入れば爆速に出来るが外れると速度が落ちる
後、分岐予測でミスが出にくくなる必要もあるだろう
ある程度短くブロック分けして、サブルーチンにする所とただのループとベタ展開を使い分ける事が大事じゃないかな

451 ：

塵も積もれば山となる
標準関数なんか激遅だから気をつけろよ

452 ：

>>430
>いまどき「家庭用ゲームのプログラマー」はアセンブリなんか使わないよ
2008年の新世代株式会社のプログラマの求人でアセンブラだってよ。Cより優先だったみたいよ。
http://web.archive.org/web/20081024194102/http://www.shinsedai.co.jp/ex_programmer.html
> 応募条件 アセンブラー、C言語プログラム経験者
あとぐぐるとトーセは出てくるな。まあ色々やってるしな。
http://www.tose.co.jp/jp/recruit/recruit01_2_2.html
> C、C++言語又はアセンブラを使用できる方。
ほか探せばいくらも出てくんじゃねぇの？これはトライエースか。
https://ecareerjs.jp/positions/66446
> 求める人物像
> また、エンジン製作経験、アセンブラ、シェーダ、DCCツールプラグイン作成経験、オフライン
> レンダラー作成経験者、ダイナミクスプログラム作成経験者などゲームエンジン製作に必要な
> 特定の分野の知識などがあると優遇されます。

453 ：

( ´−｀) .｡oO（なんでみんなそんなに必死なんだろう・・）

454 ：

分からないものを無理に理解しようとしなくていいし、知らないものを必死に否定しなくとも良い。

455 ：

>標準関数なんか激遅
場合に拠る

456 ：

OSやデバドラでなきゃアセンブラ使わないのは何年も前からの常識だよ。
そういう極一部のニーズが全てにあてはまるとか思うのは勝手だけど、世間の非常識だって理解しような。

457 ：

自分の知らん世界のことは非常識と思える頭は幸せだヌーン

458 ：

>そういう極一部のニーズが全てにあてはまるとか思うのは勝手だけど、
誰も言ってもいないことを喚き始めたかｗ

459 ：

>OSやデバドラでなきゃアセンブラ使わないのは何年も前からの常識だよ。
>そういう極一部のニーズが全てにあてはまるとか思うのは勝手だけど、世間の非常識だって理解しような。
十年前、二十年前に作られていまだに稼動してるシステムなんてゴマンとあんのに、
プログラムの保守とか想像したこともないんだろうなあ。

460 ：

Visual Studioにアセンブラが入ってるのも非常識とか言いそう

461 ：

コンパイラの出力コードを手直しすればいいだけなのでコンパイラに負ける事はほぼ有り得ない
想定と実環境が大きく異なったときにたまたま負ける可能性はある

462 ：

プレイステーション系のゲーム機はアセンブリでガリガリ書かないと
パフォーマンスを発揮しない。

463 ：

プレステ２でゴリゴリ書いてみたい^^

464 ：

64bitOS開発やったときはアセンブラの読解力は必須だったよ。
ソースはメモリーコピー部分以外Cだったけど。

465 ：

高級言語を扱う場合でも
パッケージに入ってるDLLがｸｿな場合、
機械語を見てバグの当たりをつけて
メーカーにねじ込む目的でVSのアセンブラは使うけどな。
まあ、書いたりはしない。

466 ：

知って損は無い言語。

467 ：

損はしないが役に立つこともあまりないな。

468 ：

ここ昔のPC板だぜ？
アセンブラを語るんなら、今現在アセンブラが役立つか、じゃなくて
8bit機や、ごく初期の16bit機でのアセンブラの意義を語るべきだと思うんだが。
今のこのスレには当時のアセンブラ経験者なんて居なさそうだな。

469 ：

>>468
いるよﾉｼ

470 ：

当時のアセンブラは経験ないな。
なんせアセンブラがなかったからな。
ハンドアセンブル。
(なかった=一般人は入手困難って意味)

471 ：

8-bit CPUでC言語を使う会

472 ：

ベーマガだかザベだかに自作アセンブラを投稿してた人もいたよな。
DOSのTASMとかならそれなりに経験者いるんでないかい。
俺はCP/MのASM使ってたけど。

473 ：

レジスタやアドレスを意識しなくていいIntrinsicsだけどSSEやAVX使うならアセンブラ必須
欲しい命令があちこちで抜けてるIntelのバカアーキテクチャは最低だぜ

474 ：

>>471
MSX-DOSの？

475 ：

>>471
BDS-Cはまあまあ使えた。
当時としてはコンパイルが軽かったのと、実行効率が低すぎてはなかったギリギリのバランスだった。

476 ：

FMのDOH-CやDraco-Cを使ってた人の感想が聞きたい

477 ：

>467
役に立たせるだけの知能がないだけだろ。

478 ：

自分がそうだから他人も含めて世の中世間の全てはそうだと思ってるおめでたい頭の奴に何か言ったところで無駄

479 ：

下駄

480 ：

6809と6502ってどう違うの？
両方ともよく知らないもので

481 ：

6809は6502に比べて307大きい

482 ：

307命令追加されているって事でイイの？

483 ：

そういや、CPUの特性にあわせたアルゴリズムで最大性能ひきだせるとか言ってたバカが居たな。
CPUの特性にあわせた実装するとかならわかるが。

484 ：

組込みの仕事の何パーセントがアセンブラー必須なんだ？
100？
99？
アセンブラ使わないのは組込みでわありませんw
朦朧爺の妄想垂れ流しww

485 ：

>組込みの仕事の何パーセントがアセンブラー必須なんだ？
>100？
>99？
>アセンブラ使わないのは組込みでわありませんw
>
>朦朧爺の妄想垂れ流しww
↑ちょっと何いいたいのか分からん

486 ：

> 組込みの仕事の何パーセントがアセンブラー必須なんだ？
> 100？
> 99？
> アセンブラ使わないのは組込みでわありませんw
これは>>484の主張? それとも朦朧爺の妄想?
解釈次第で主張が180度変わる投稿を平気でする>>484は馬鹿だと思う。

487 ：

>>483
乗除算の機能のないCPUで、乗除算を使わないアルゴリズム(実装でなく)を使用した経験ならあるが?

488 ：

>>483
前スレの>>474-561みてみれ

489 ：

>>483
>そういや、CPUの特性にあわせたアルゴリズムで最大性能ひきだせるとか言ってたバカが居たな。
>CPUの特性にあわせた実装するとかならわかるが。
バカはお前じゃね？

490 ：

バカども同士、仲良くね

491 ：

>>483
>>484
同じ奴？

492 ：

>>483
Z80と6809で、特性にあわせたアルゴリズムで最大性能をひきだそうとした例
8086 vs. Z80 vs. 6809 vs. 6502　その7
http://logsoku.com/thread/ikura.2ch.net/i4004/1319314159/474-561n

493 ：

>>483
> そういや、CPUの特性にあわせたアルゴリズムで最大性能ひきだせるとか言ってたバカが居たな。
> CPUの特性にあわせた実装するとかならわかるが。
DDAとか知らない世代かしら?

494 ：

LZH圧縮をCPUにあわせたアルゴリズムで〜と言ってた奴。
LZH圧縮てか、ハフマン符号化とかスライド辞書とかのアルゴリズムはCPU関係ないしょ？
DDA？

495 ：

>>494
> LZH圧縮てか、ハフマン符号化とかスライド辞書とかのアルゴリズムはCPU関係ないしょ？
V30みたいなビットフィールド操作命令が使えるCPUだと便利かもね。

496 ：

>>494
>LZH圧縮てか、ハフマン符号化とかスライド辞書とかのアルゴリズムはCPU関係ないしょ？
ハフマン木やLZSSの辞書の表現はCPUの特性を考慮すべきだな。

497 ：

>>483
>そういや、CPUの特性にあわせたアルゴリズムで最大性能ひきだせるとか言ってたバカが居たな。
仮にLZHのことだとして、
・圧縮率
・圧縮速度
・圧縮時のメモリ使用量
・展開速度
・展開時のメモリ使用量
性能って上の5つぐらいで評価できると思うけど、そりゃCPUの特性に合わせて何を重視するかで
アルゴリズムなんて当たり前に変わってくるだろ。確かDOS版のLhaでも何種類かの圧縮形式
サポートしてたぞ。

498 ：

>>494
>LZH圧縮てか、ハフマン符号化とかスライド辞書とかのアルゴリズムはCPU関係ないしょ？
LZH自体、当時の16ビットプロセッサ用に最適化された実装だと思うけどね。

499 ：

訂正
実装→仕様

500 ：

>>494
>LZH圧縮てか、ハフマン符号化とかスライド辞書とかのアルゴリズムはCPU関係ないしょ？
どうだろ？
Lha当時のPCといまどきのPC比べても、いまどきのPCはCPUが速くなった程度には
メモリの方は速くなってないから、「最大性能」目指すなら、アルゴリズムがいくらか
複雑になってもメモリアクセス減らす工夫したりすんのは有効だったりすんじゃないの。

501 ：

アルゴリズムはCPUのアーキテクチャに左右されると思うぞ。
たとえばZ80のパソコンが全盛期だった頃、
乗除算命令が当たり前のように実装されていたら
画面に斜めの直線引くのにBresenhamのアルゴリズムなんか使わずに
乗除算命令を使う奴が大多数を占めていたと思う

502 ：

メモリアクセス減らすって、レジスタだけで圧縮演算するんすか！？

503 ：

一旦ハッシュ値計算しておいて辞書の検索に使ったりすんのは有効かもね。

504 ：

>>494
>DDA？
http://en.wikipedia.org/wiki/Digital_differential_Ryzer_(graphics_algorithm)

505 ：

>>501
どうせ除算は遅いから、ブレゼンハムおいしいです＾ｑ＾になる
ふつーの人は速いのを呼ぶだけ

506 ：

>どうせ除算は遅いから、ブレゼンハムおいしいです＾ｑ＾になる
最初に一回やるだけの除算がそんな問題になるかな?

507 ：

> そういや、CPUの特性にあわせたアルゴリズムで最大性能ひきだせるとか言ってたバカが居たな。
> CPUの特性にあわせた実装するとかならわかるが。
> LZH圧縮をCPUにあわせたアルゴリズムで〜と言ってた奴。
> LZH圧縮てか、ハフマン符号化とかスライド辞書とかのアルゴリズムはCPU関係ないしょ？
なんかマヌケなこと書いて引っ込みが付かなくなって、必死に考えた言い訳がLZHかｗ　笑えるｗｗ

508 ：

Z80の時はアルゴリズム2、3個考えてどれが速いか比較してプログラム書いてた。
32bitCPUあたりからは命令数減らすようには考えるけど、アルゴリズムまではそんなにこだわらなくなった。

509 ：

>>506
整数演算で直線の方程式を使うのを想定していたから、ソレは無理。

510 ：

6809 ビッグエンディアン
6502 リトルエンディアン

511 ：

>どうせ除算は遅いから、ブレゼンハムおいしいです＾ｑ＾になる
それは、当時の「除算は加減算より遅い」というアーキテクチャに依存する発言だな。
今のLSI技術なら整数の除算なんて1クロックで終わる。
当時そういうアーキテクチャがなかったからからこそBresenhamが重視された。

512 ：

>>506
最初に割り算使うやり方だと小数計算使うから途中の計算も重くなるよ

513 ：

>>512
>最初に割り算使うやり方だと小数計算使うから途中の計算も重くなるよ
横640ドットとかだったら、小数点以下10ビットの固定小数点で精度は十分だよ。

514 ：

>>509
>整数演算で直線の方程式を使うのを想定していたから
意味分からん

515 ：

>>511
>それは、当時の「除算は加減算より遅い」というアーキテクチャに依存する発言だな。
割り算は最初に一回だけやればいいので、加算と単純に較べられない

516 ：

>今のLSI技術なら整数の除算なんて1クロックで終わる。
そんなわけはない。
除算は原理的に並列化できないから整数除算はビット数分だけ時間がかかる。
浮動小数点除算なら、表引き＋ニュートン法で逆数＋乗算で加速できるけど、
どんなに頑張っても２〜３クロックは必要（普通はもっと遅い）
例えばほら。
http://sonnyclark.seesaa.net/article/151202289.html
今でもこの手の問題（有理数倍のリサンプリングとか）には DDA 使ってるけどな。
だいたい DDA も固定小数点の積算も本質的に同じだろ。
最初の除算が無駄なだけ。

517 ：

>>513
640*480の頃のVRAMはピクセルとビットが対応してたからそんな実装非効率すぎる
画面のXY座標からアドレスとビットパターンをもう一回計算するのかい

518 ：

>>516
>>今のLSI技術なら整数の除算なんて1クロックで終わる。
>そんなわけはない。
10bit ÷ 10bit 程度なら、表から引けばいいだけだろ。

519 ：

>>516
>だいたい DDA も固定小数点の積算も本質的に同じだろ。
>最初の除算が無駄なだけ。
加算一回してキャリー見るだけの積算とDDAが同じなわけないじゃん

520 ：

>>517
>640*480の頃のVRAMはピクセルとビットが対応してたからそんな実装非効率すぎる
>画面のXY座標からアドレスとビットパターンをもう一回計算するのかい
お前にコーディング能力がないことは解った

521 ：

昔のハードを前提に語ってるのなら除算テーブルなんかに貴重なメモリを消費する訳にいかないだろ

522 ：

>>516
>例えばほら。
>http://sonnyclark.seesaa.net/article/151202289.html
「加減乗除それぞれループに要する時間を差し引いた10億回の
計算時間が測定ができるよう工夫をした。かなりの試行錯誤の
末、最適化なしコンパイルとシングルユーザモードでの実行に
よりミリ秒レベルまで再現性のあるデータがとれるようになっ
た。」
って、こういうことするときって最低でもコンパイラの出力提示するし、
普通はアセンブリで組むよね。
何？このテスト。バカじゃないかしら。

523 ：

>>521
>昔のハードを前提に語ってるのなら
「今のLSI技術なら〜」が読めないんですね分かります

524 ：

>>521
> >今のLSI技術なら整数の除算なんて1クロックで終わる。
>
> そんなわけはない。

525 ：

>>521
PC-8001用のフライトシミュレータ(と言う名のワイヤーフレームデモ)で除算テーブルにごっそりメモリ割いてたの見たことあるけどな?

526 ：

RAMの節約の為に640x400か512x480にしてください。

527 ：

というか、8ビット時代の実際のコーディングの話なら
高速化重視のときラインルーチンはBresenhamをやめて最初に除算で差分を求めるのが定石だったけどな
nドット連続で書き込むことが先に確定しているほうがループ展開や場合分けで高速化できるから
除算のコストを払っても短い線でなければずっと速い

528 ：

>>521 読んで、突っ込もうと思ったら既にボッコ状態だった (w

529 ：

>>527
>除算のコストを払っても短い線でなければずっと速い
ラインの長さで場合分けをするのが正しい

530 ：

何を持って正しいかも定義しないで、「正しい」とか言い切る奴って…

531 ：

正しいは正義

532 ：

>>516
>>今のLSI技術なら整数の除算なんて1クロックで終わる。
>そんなわけはない。
できるよ。VHDLで大雑把に書くと下のような感じ。
ビット数が多くなるほどにディレーが多くなるからこれを何百MHzで動かすのは無理だろうけど当時の8BitCPUみたいな一桁MHzなら余裕。
signal y:std_logic_vector(7 downto 0);
process div(a,b)
variable t:std_logic_vector(7 downto 0);
begin
　　if(a > b) then
　　　　t := a-b;
　　　　y(7) <= '1';
　　else
　　　　t := a;
　　　　y(7) <= '0';
　　end if;
　　if(t > b) then
　　　　t := t-b;
　　　　y(6) <= '1';
　　else
　　　　t := t;
　　　　y(6) <= '0';
　　end if;
　　　　：
　　（ビット5〜0も同様に）
　　　　：
end process;

533 ：

>>532
t への代入を繰り返してるけど、展開して１クロックで終わるようにしてくれるの？

534 ：

>>533
VHDLだとこの8個の引き算は並列に動く減算器8個にしてくれるよ。
ついでに、いまちょっと間違いに気づいた。bをシフトしてなかった。
２回目（ビット6）の処理はこうなる。
　　if(t > b(7 downto 1)) then
　　　　t := t-b(7 downto 1);
　　　　y(6) <= '1';
　　else
　　　　t := t;
　　　　y(6) <= '0';
　　end if;
ビット5〜0も同様に１ビットずつ右にシフトした値を比較・減算する。

535 ：

>>527
今でもDDAだぜ
WindowsのGDI関数はおバカだから対象がメモリ上の仮想スクリーンでも
自分で描かないと遅くて使い物にならん
>>519
8bitや16bitCPUなら分数を分数のまま扱うから余分な精度確保と整数部分の取出しがない分
キャリー発生時に減算が一個入るだけのDDAの方が速いよ

536 ：

>>530
>何を持って正しいかも定義しないで、「正しい」とか言い切る奴って…
「何を持って正しいかも定義しないで、「正しい」とか言い切る」ことが正しいのか誤っているのかまず定義すれ。

537 ：

>>535
>8bitや16bitCPUなら分数を分数のまま扱うから余分な精度確保と整数部分の取出しがない分
お前にコーディング能力がないことは十二分にわかった

538 ：

>>535
>8bitや16bitCPUなら分数を分数のまま扱うから余分な精度確保と整数部分の取出しがない分
まっさか座標を小数点以下まで持って計算するとでも思ってるのかな?

539 ：

>>535
> 8bitや16bitCPUなら分数を分数のまま扱うから余分な精度確保と整数部分の取出しがない分
> キャリー発生時に減算が一個入るだけのDDAの方が速いよ
馬鹿がいる

540 ：

ピクセル座標で演算するなら隣のピクセルにドット打ったりしなきゃいいだけのはずだから、小数点以下10ビットは取りすぎだと、素人は思う。
点が抜けたり余分に打ったりしないていど、がどのぐらいの精度になるか分からないだけだが小数点以下2ビット以上あればよさげな気がする。
垂直水平と斜め線と円弧でロジック違うのは判るけど線の長さでも変えるもんなの？

541 ：

傾きがちょうど1.0の時も場合わけがいるな
線分発生なんてボトルネックでも何でもないのにアホくせ

542 ：

>>540
>ピクセル座標で演算するなら隣のピクセルにドット打ったりしなきゃいいだけのはずだから、小数点以下10ビットは取りすぎだと、素人は思う。
横640ドット移動する間に縦1ドット移動する程度の傾きのラインを描画するとした場合、
1/640ドットの精度が必要となる。 →10bitの精度が必要ということ

543 ：

>>540
>垂直水平と斜め線と円弧でロジック違うのは判るけど線の長さでも変えるもんなの？
高速化を考えるなら有効。
ただし、場合分けにも処理やコード量が嵩むから、そのへんはトレードオフを考慮しなければいけない。

544 ：

精度は画面幅に依存ってことね。
10ビット要るのは納得。
直線ひくだけなら単純な等差数列だからわり算一度きりでいいはずだよね？
しかし0度〜45度と45度〜90度と45度ドンピシャとでロジック変えないとドットが縦か横にズレるとか、意外だった。
8ビットCPUじゃ面倒そうだっのが正直な感想。
ググる先生大活躍したけど日本語の画像座標のこと書いてるサイトがあんまり見つからなかった。
コンピュータ系の専門学校とかで扱わないのかな。

545 ：

普通のLINE
●●●●●□□□□□
□□□□□●●●●●
N-BASICのLINE
●●●●●●●●●□
□□□□□□□□□●

546 ：

>>516
>例えばほら。
>http://sonnyclark.seesaa.net/article/151202289.html
> 　私のCPU　Athlon64 X2 3600+では、
> 　加算　0.501秒／10億回
> 　減算　0.501秒／10億回
> 　乗算　0.501秒／10億回
> 　除算　35.57秒／10億回
> という結果であった。
> つまり除算の速度は他の演算の71倍という想像以上に大きな
> 数値がでた。また乗算は加減算より手間がかかりそうなのだ
> が同速度というのも意外な結果だった。もちろんCPUによっ
> て結果は変わるのだが。
とあるが、これ正しいのか? ちょっと除算が遅すぎる気がする。

547 ：

----------------------------------------------------------------
試しに今使ってる core2duo 2.67GHz の PC の Cygwin 環境で
1: int main()
2: {
3: 　　asm volatile(
4: 　　　　"\tmov $1000*1000, %ecx\n"
5: 　　　　"1:\n"
6: 　　　　"\t.rept 1000\n"
7: 　　　　"\tmov $0xfffffffe, %edx\n"
8: 　　　　"\tmov $0xffffffff, %eax\n"
9: 　　　　"\tmov $0xffffffff, %ebx\n"
10: 　　　　"divl %ebx\n"
11: 　　　　"\t.endr\n"
12: 　　　　"\tdec %ecx\n"
13: 　　　　"\tjnz 1b\n"
14: 　　);
15: 　　return 0;
16: }
↑のプログラムを gcc でコンパイル、time ./a で実行したら
> real 0m5.113s
> user 0m4.741s
> sys 0m0.031s
だった。

548 ：

7〜9行を
7: 　　　　"\tmov $0, %edx\n"
8: 　　　　"\tmov $0, %eax\n"
9: 　　　　"\tmov $1, %ebx\n"
に変えると
> real 0m1.947s
> user 0m1.684s
> sys 0m0.015s
となったので、値にも拠るようだ。
Athlon64 X2 3600+ と core2duo でそれほど世代が違うとも思わないので、全体としてそれほどパフォーマンスに大きな差はないと思う。実際、7〜10行を
7: 　　　　"\tadd %eax, %eax\n"

に変えて加算のみの数値を測ってみると、
> real 0m0.437s
> user 0m0.405s
> sys 0m0.015s
となったので、加算についてはそれほど差はないようだ。
ブログ主も書いてるが、CPUによって結果が異なるのは事実だと思うが、除算のような基本的な命令でこれほど大きな差が出るのだろうか? 俄かには信じ難い。

549 ：

>>548
ソースコード出てこないと何とも言えないですよね。

550 ：

考え直してみると、ブログ主は64bit-ubuntu上で確認を行ったということなので、128bit÷64bit の命令を試したということだろうか?
それなら倍かそれ以上は遅くなって当たり前だな。

551 ：

割り算が遅いって思ってるから/3するより.33…掛けた方がいいかなと思ってる、最近のマシン速いし
意味無さそうだけど。識者の方は如何してますか。

552 ：

8bit CPUの頃に約1/3の計算をしたくて、8bitの値を85倍して16bitの値にし、インクリメントして上位8bitを使ったような記憶ならある。
同様に、22倍して7で割って 直径→円周 ということにしたこともあった。

553 ：

>>551
Cray-1 には、除算命令がなく逆数を掛けることで処理していたのは結構有名な話

554 ：

>>545
座標の基準がドットの左上か中心かで変わるみたいだね。

555 ：

>>554
DDAの積和のところで初期値が適正でないだけな気がする。

556 ：

>>555
不慣れな英語を流し読みしただけだから勘違いかもしれないけど
CGと学術系(サイエンティフィ？)なグラフでは使い分けられてる、見たいなことが書かれてたよ。
初期値を0.5変えるだけだろうけど。
ブクマしときゃよかったorz。
ガラケだから検索辛いんだ。

557 ：

>>556
数学的には(0,0)-(1,1)にプロットしたとして2ドット描かれるのはおかしいと気付け

558 ：

別におかしくないよ。
(0,0)と(0,0.5)が同じ位置にドットが打たれるかそうじゃないかだから。
ピクセルの中心が基準なら違う位置に、左上基準なら同じ位置にドットが打たれるってだけだから。

559 ：

>>558
座標(0,0)から(1,0)を結ぶ線分の長さは1だが、画面には長さ2のラインが描かれる。
↑説明してみ?

560 ：

(0,0)-(1,1)で2つ打つのは正しい。
(0,0)-(0.9,0.9)なら１つだけになる左上基準と２つになる中心基準で違いがでてくる。

561 ：

画面上の座標1,1の守備範囲は1.0≦x＜2.0、yも同じ。
終点座標は始点と異なるピクセルを示してる。
こんなんで良い？

562 ：

>>561
長さの話ですよ

563 ：

中心基準なら 0.5≦x＜1.5 以下略。
線分の縦横どちらかの長さが≧1.0の時点で2個以上のドットが打たれるんだよ。
中心基準も左上基準もどちらもね。

564 ：

長さ1の線分を描画すると長さ2のラインが描画されるということは、ドットの中心に座標があるということ。
そう考えると、N-BASICのラインの描画は正しくないという結論になる。

565 ：

モダンなハードだと、座標はドットの角にあるのでひとつの辺を共有するポリゴンを2個描画したとしても共有する辺は二度描きされない。

566 ：

条件書き出してみればかんたんだよ。
左上基準なら
0≦x＜1なら一番左、
1≦x＜2なら２番目
だから。
0,0-1,0は隣接する２つのピクセルにドットか打たれるって一目瞭然でしょ？

567 ：

面倒なのは画面内の線分だけ切り出すクリッピングなんだよな
まじめにやると乗除算を使うからZ80には重荷

568 ：

>>567
昔やってたときはバイナリーサーチみたいなアルゴリズムで乗除算は使わなかったような記憶があるなあ。

569 ：

>>566
「線分の長さ」の意味が理解できないバカは引っ込んでてね

570 ：

イタタタ。
論理座標とディスプレイ上の描画が頭のなかでリンクしてないバカにバカとか言われたよ。
どんなコンピュータでも最後はハードウェアに依存するって当たり前すぎる認識がない奴がこのスレに居るんだな。

571 ：

ドットの中心に座標があることが理解できないバカは滑稽ｗ

572 ：

>>516
>除算は原理的に並列化できないから整数除算はビット数分だけ時間がかかる。
例えば、除数を 0倍〜15倍した値を予め求めておいて(16個)、被除数の上の桁から
引けるかどうかの判定を16個同時に並列してやって、引けた数字の一番大きいやつ
採用すれば一度に4ビット分計算できんじゃないの?

573 ：

>>542
固定小数点で小数点以下を精度良く計算、は正攻法だけど、除算を整数部までの計算で済ませる方法もある。
例として(x1,y1)-(x2,y2)にラインを引くとする。
話を簡単にするためsx=x2-x1>2 sy=y2-y1>1 sx>sy だとしよう。
このとき、(sx+1)/syの除算をするのだが、(sx+1)÷sy=d あまり r 、と整数のdとrまで求める。小数点以下は計算しない。
高速化に寄与が大きいのは「dドット連続して描いてよい」という情報だからこれで十分。
あとは描画でx方向に連続するdドットの横線を描いていくときに
「y方向の(sy+1)ラインのうち(d+1)ドットのラインをr本だけバランスよくはさむ」と考えればいい。
具体的にはカウンタfを用意して、
・ y方向に移動するとき f+=r する。
・ f>=sy になったらそのラインはd+1ドットにして f-=sy。
をsy回繰り返す。
実は割り算の続きをしてるみたいなものだが、整数演算と分岐なのでオーバーヘッドはほとんどないし
小数計算だと精度が足りないと終点まで届かなかったり、はみ出したりする可能性があるが
この方法だと始点から終点までピッタリ確実につながる。
fの初期値は sy/2 にしておくとそれっぽい線になる。

574 ：

>>573
よくわからんから図を書いて説明してくれ

575 ：

DDAループ内で2分の１の確率で発生するレジスタ加算の１命令４クロックを節約するために
長さチェックして頭で割り算やって45度専用ルーチン用意するなんて実装本当にやった人いるの？
オレならそんな長い線分来たらゴメンナサイで済ますぞ。どうせフレームレートは変わらんし

576 ：

>>573
まともに読んでないけど言ってることはDDAじゃね?

577 ：

>>575
>DDAループ内で2分の１の確率で発生するレジスタ加算の１命令４クロックを節約するために
>長さチェックして頭で割り算やって45度専用ルーチン用意するなんて実装本当にやった人いるの？
DDAも45度専用ルーチンも理解してないなｗ

578 ：

そういや昔、初代Pentiumの中にある除算表の一部がバグって
誤った計算結果が出てリコールするかしないかの騒動があったな

579 ：

>>578
あれは浮動小数点の割り算だから関係ない話

580 ：

アレは今でもIntelにお願いすれば交換してくれる

581 ：

6809ならやる価値あるか
個々の命令がクソ遅いから節約効果は大きいし
逆数表と得意の乗算使えば損益分岐点はかなり短い

582 ：

この時代のCPUって除算が1クロックで終わらせられるほどIPC高いの？

583 ：

バカは放置で

584 ：

Bresenhamはテクスチャマッピングをするまで

585 ：

>>573
傾きが3/7の線なら途中の横並び数は2-2-3-2-2-3だから意味無いよね
傾きが水平に近くて長い線分専用にするしかないけど普通はやらないわ

586 ：

http://www.youtube.com/watch?v=eADSS9FgNxA&feature=relmfu
本編は平面シューティングでｶﾞｯｶﾘしたが１ページ３プレーンのVRAMで２色のワイヤーフレーム
Z80とは思えないデモだった

587 ：

シルフィードは偉大だよ。

588 ：

>PC-8001用のフライトシミュレータ(と言う名のワイヤーフレームデモ)で除算テーブルにごっそりメモリ割いてたの見たことあるけどな?
サインテーブルとか68k使ってた頃でもインチキして

589 ：

インチキして360度は4096分割(1象限1024度)なスチャラカプログラム作ってたな
Z80でやってた頃は1象限256分割で、360度が1024分割というアバウトさ
640x400だとさすがに襤褸が出るが、320x200や256x256ならいける

590 ：

>>586
>１ページ３プレーンのVRAMで２色のワイヤーフレーム
解析してないから断言できんけど、描画と表示を別プレーンに割り当てて、パレット切り替えでページフリップしてると思う。こんな感じで。
発進のシーン
Bプレーン描画　Rプレーン表示　Gプレーン表示
↓
Bプレーン表示　Rプレーン描画　Gプレーン表示
↓
Bプレーン表示　Rプレーン表示　Gプレーン描画
機体のスペック表示のシーン
Bプレーン描画　Rプレーン表示　Gプレーン表示
↓
Bプレーン表示　Rプレーン描画　Gプレーン表示

591 ：

シルフィードは母艦と戦闘機で色が違うから、明らかに2プレーン使ってるよ
OP後半の諸元表示のところは1色だけどな
ゲーム本編でも2プレーン3色(赤青白+黒)だし
移植されたPCDOS版のOPは、全編通して320x200ドット単プレーン表示へ退行
（その甲斐あって、フレームレートは向上したが）

592 ：

>>591
>シルフィードは母艦と戦闘機で色が違うから、明らかに2プレーン使ってるよ
同時に更新する必要はないと思うから描画中に隠すプレーンは1枚でいいと思うよ。

593 ：

>>591
>ゲーム本編でも2プレーン3色(赤青白+黒)だし
目ぇ大丈夫?
http://www.youtube.com/watch?v=8hVwAfy88NE

594 ：

FM77版もあったよな？

595 ：

>>550で言いっ放しはどうかと思ったので、64bitも確認してみた。
1: int main()
2: {
3: 　　asm volatile(
4: 　　　　"\tmov $1000*1000, %rcx\n"
5: 　　　　"1:\n"
6: 　　　　"\t.rept 1000\n"
7: 　　　　"\tmov $0xfffffffffffffffe, %rdx\n"
8: 　　　　"\tmov $0xffffffffffffffff, %rax\n"
9: 　　　　"\tmov $0xffffffffffffffff, %rbx\n"
10: 　　　　"divq %rbx\n"
11: 　　　　"\t.endr\n"
12: 　　　　"\tdec %rcx\n"
13: 　　　　"\tjnz 1b\n"
14: 　　);
15: 　　return 0;
16: }
↑のプログラムをCygwin上のx86_64-w64-mingw32-gcc でコンパイル、time ./a で実行したところ
> real 0m20.898s
> user 0m0.000s
> sys 0m0.031s
4倍程遅くなった。2倍かそこらを予想していたが、4倍は予想外だったな。加減算は変わらなかったのだが。

596 ：

>>ゲーム本編でも2プレーン3色(赤青白+黒)だし
>
>目ぇ大丈夫?
>http://www.youtube.com/watch?v=8hVwAfy88NE
何に文句をつけているのか理解できない

597 ：

>何に文句をつけているのか理解できない
目も頭も悪いんだなｗ

598 ：

>>596
>>>ゲーム本編でも2プレーン3色(赤青白+黒)だし
>>目ぇ大丈夫?
>何に文句をつけているのか理解できない
緑やらシアンやら使った敵出てるじゃん
分かりやすいのはこの辺
http://www.youtube.com/watch?v=8hVwAfy88NE&t=190

599 ：

>分かりやすいのはこの辺
一部のボス以外は2プレーン描画だよ
3プレーン目はステージやシーンによって背景に使ったり
ボスに使うなど使い分けているが、
自機や弾やザコ敵は3プレーン目は使わない
自機も地形も2プレーン描画で、
レーザーと爆炎を3プレーン目に持って行ったテグザーや
キャラは2プレーンで地形を1プレーン描画した
ドラスレ/ザナドゥと同じ考え方だ

600 ：

>>599
>一部のボス以外は2プレーン描画だよ
>
>3プレーン目はステージやシーンによって背景に使ったり
>ボスに使うなど使い分けているが、
>自機や弾やザコ敵は3プレーン目は使わない
ザコ敵に緑やシアンや黄色も使ってるみたいだけど?
http://www.youtube.com/watch?v=8hVwAfy88NE&t=21
http://www.youtube.com/watch?v=8hVwAfy88NE&t=28

601 ：

テクスチャー入ってもいないんだし、88SRのALU使って描画してるだろうから、
重ね合わせとかしない限りはプレーン数減らしても描画の速度は変わらん筈。

602 ：

>>591
>ゲーム本編でも2プレーン3色(赤青白+黒)だし
なんだ嘘か

603 ：

あれって頂点データ垂れ流し方式なのかな

604 ：

>>585
あの時代のライン描画の高速化はVRAMの読み書き回数をいか減らすか、がポイントで
特に水平に近い長い線を描くときそれが効いてくるからそれでいいんだよ。
1点を描くのに、まともに3プレーンアクセスが必要な機種はVRAM3枚分の読み込み・合成・書き込みが必要になるが、
横8ドット＝1バイトが線で埋まることがあらかじめわかっていれば書き込み以外をまるまる省くことができる。
VRAMアクセス減らすのにBresenhamで空ループさせる手もあるけど、なら割り算したほうが結局は速い。
逆に短い線や縦に伸びる線はどの方法を使ってもVRAMアクセス回数は大して変わらないから
それなら横長の線が劇的に速くなるほうがいい。実際やってみるとかなり効果あったよ。

605 ：

>>604
そのテストプログラムを公開してくれよ

606 ：

>>605
おそらく予期した返答だと思うけど、現存してない。
公開するには思い出しながら一から作り直すことになるが、完成させる自信はないなｗ。

607 ：

Coreアーキテクチャ以降は倍精度実数でも除算が６クロックなんだよな
逆数テーブル引くのが空しくなるぜ

608 ：

>>596
>何に文句をつけているのか理解できない
りかいできまちたか？

609 ：

盛り上がってるな

610 ：

>>607
fdivかよー／(^o^)＼

611 ：

ここはレベルの低い話しかしてないんだねー
もっと深い話題があると思ったんだが

612 ：

そのレベルの低い話もできないのがお前。

613 ：

語りたい深い話題があるなら自分から話を振るべき

614 ：

>ここはレベルの低い話しかしてないんだねー
>もっと深い話題があると思ったんだが
そりゃ8bit全盛期の、いまから見たらクソみたいなCPUを語る場だからな。
最新のCPUの高度な話題を求めてるんなら、こんなスレに来たお前が情弱。

615 ：

Z80全盛時でもロクな乗算除算ルーチンが公表されていなかったよな
平方テーブル方式や16bit加算を使わない8x8乗算が一般化してりゃもう少し文化が育っていたかもしれん

616 ：

オープンソースという概念やネットワークがなかった技術的に発展途上だったなどとなんとなく想像

617 ：

>>615
出来が良い乗除算ルーチンはなくてもコプロつかえばOKでしょ

618 ：

ニューメリカルレシピとかをどれだけのプログラマーが読んだんだろ。

619 ：

>>617
Z80にコプロは付かない

620 ：

Z80用はなかったけど、8bit一般用のはあったろ

621 ：

雑誌ならインターフェースやbit、ときどき数学セミナー、無理して書泉グランデでDDJ
最新知りたきゃACMの論文見ろな時代だった。

622 ：

>>620
数値演算プロセッサとコプロの区別がつかない人？

623 ：

うん区別が付かない
何が違ってどう使い分けるか教えていただけると助かる

624 ：

CPUの機能が拡張されて見えるのがコプロセッサ
数値を演算するのが数値演算プロセッサ

625 ：

CPUガワにもコプロと結託する機能が必要って事？

626 ：

コプロに完全に乗っ取られるものもありました。はい。

627 ：

8087は8086の命令読み込みを監視しながらESC命令を見つけたら乗っ取る。
んで処理したら8086へ主導権を返す。
487SXは486SXを止めて乗っ取る。
ぐらいしか乗っ取り型のコプロセッサは知らない。

628 ：

487SXは486SXを止めっぱなしになるのでコプロではないと思う。

629 ：

80287からI/Oポートを使うようになったでしょ
だれかこの事を簡単に説明してくれませんか

630 ：

>>565
旧MacOSのQuickDrawはそういう環境だった。もう25年は前の話なんだな。

631 ：

簡単に平方根を求める方法を教えてください！
符号なし、小数切り捨てで構いません

632 ：

sqrt()

633 ：

>簡単に平方根を求める方法を教えてください！
>>488

634 ：

Am9511,CDP1855,74LS384
Z80にわざわざこんなの付けて自分で専用プログラム作る必要あるなら16bitマシン調達するのが正解
ROMカートリッジのソフトならありだけどゲーム機で高速CPU載せたのが少し出ただけだったな

635 ：

>>634
TurboPascalでAm9511サポートされてたり…
ポートアドレス書いてライブラリ再構築で使える。
向こうはS100バス機普及もあって使える機械が多かったって事だろう。
74LS384に関してはI/Oか日経バイトかなんかに8801向けカードの製作記事が載った事があったかな。

636 ：

>りかいできまちたか？
わからんね。自キャラ・雑魚キャラ・弾は2プレーン描画、地形と爆炎が別プレーン
ボス級キャラのみ3プレーン使う「場合もある」ようにしか見えないが。
（自機・雑魚と重複するのは1プレーンのみで、ボス・地形も2プレーン描画かもしれない）

637 ：

赤緑のアレだろう

638 ：

>>636
>自キャラ・雑魚キャラ・弾は2プレーン描画、地形と爆炎が別プレーン
>ボス級キャラのみ3プレーン使う「場合もある」ようにしか見えないが。
「ゲーム本編でも2プレーン3色(赤青白+黒)だし」という主張だった筈だが？ｗ
雑魚キャラ・ボスキャラが「3色(赤青白+黒)」以外使ってる時点で主張はボロボロなんだがなあ？ｗｗ

639 ：

全然スレチ。

640 ：

>>599
>レーザーと爆炎を3プレーン目に持って行ったテグザーや
>キャラは2プレーンで地形を1プレーン描画した
>ドラスレ/ザナドゥと同じ考え方だ
要するにお前の頭がそれ以上ついていってないってことだよ

641 ：

憶測でなく、実機でN-BASICリセットでVRAM吸い出して確認してみたら？

642 ：

>>591
>ゲーム本編でも2プレーン3色(赤青白+黒)だし
地形が表示されるシーンや敵艦体内部に限ってはザコ敵中ボス含めてその色使いだが
http://www.youtube.com/watch?v=8hVwAfy88NE&t=272
http://www.youtube.com/watch?v=8hVwAfy88NE&t=421
それ以外のシーンでは黄色だの緑だの色使ってるぞ。

643 ：

OPのワイヤーフレーム、変わった処理してるね。
プレーン1を縦縞で固定。
プレーン2と3を切り替えながら描画して
偶数ラインONなら青、奇数ラインONなら黄色を表示。
プレーン1 　　： 01010101 固定
プレーン2/3　： 00000000 黒+黒
プレーン2/3　： 10101010 青+黒（母艦描画に使用）
プレーン2/3　： 01010101 黒+黄（星描画に使用）
プレーン2/3　： 11111111 青+黄（時機描画に使用）
これで１プレーン書き換えだけで４色表示させてる。

644 ：

>>643
面白いな

645 ：

ttp://ichigo-up.com/cgi/up/qqq/nm57148.bmp
自キャラ 白、赤、青
ボス　　　 白、赤、緑、水色、黄色
黒含めて7色。
自機といっぱい出てくる雑魚キャラは2プレーン描画で
１体だけのボスは3プレーンかな？
あと１色は爆発用とか。

646 ：

随分暗い白だな

647 ：

ゲームアーツのことだから、面の途中で描画プログラム変えるぐらいはやりそう。

648 ：

>>645
>自機といっぱい出てくる雑魚キャラは2プレーン描画で
>>600見れ

649 ：

M88の画面キャプチャBMPのカラーパレットが実際のパレットと一致してるかわからんが
000:黒
001:白
010:グレー？
011:赤
100:青
101:緑
110:水色
111:黄色
さて、ゲームアーツが何も考えずにこんな配色にするとは思えないんだが…。

650 ：

>>649
同じステージでも、背景に地上が表示されているときと表示されなくなったときで
爆発パターンの色が違うからパレットも固定ではないと思う。
ダメージ食らったときに画面が赤くなるのもパレットチェンジだろうし。

651 ：

ゲームアーツだしな。
何やらかしてても納得するよ。
だってゲームアーツなんだもん。

652 ：

4096色中同時発色16色が使えるとかあったけれど絵とか表現する時どう？

653 ：

PC-98のことか？
某漫画家がエロゲの画像描いてた時は「64色あればなんでも描けるのに」って愚痴ってたらしい。

654 ：

>>631
敵キャラとの距離か?
テーブル用意したら?

655 ：

走査線ごとに切り替えて32色出す

656 ：

8801SRに320＊200のモードがあればもっと色々なことができたのに残念
PC6000シリーズに遠慮したとしても不要と判断したにしても大きな誤り

657 ：

この話題は、そろそろこっちに移動したほうが良くないか？
【8bit機】CRTC,VDP,ALU,メモリマップ,MMU 専スレ
http://ikura.2ch.net/test/read.cgi/i4004/1221375066/

658 ：

>>545
富士通の場合 (F-BASIC v1.0〜v3.0)
階段部分が太い特殊なLINE
●●●●●□□□□□
□□□□●●●●●●

659 ：

これは酷いなぁ
階段部分が目立って目について仕方なさそう

660 ：

円も32角形とかそんなんだった気がする >FM

661 ：

モンテカルロなやり方と誤差でかそうなだな>>FM

662 ：

最近自作したMC680ボードでtiny basicを動かそうとした。
OS-9の会社のアセンブラソースが入手できたので走らせようとしたが動かん。
解読したところ自分自身のコードを動的に書き換えて動作してる部分を発見。
それをフラッシュROMに焼いて動かそうとしたのがダメだった。富士通がイン
デックス関係の演算追加したくなった意味が理解できた。6502も改良方向の
１つはそれなのだろう。そういう不足アドレシングモードを自己書き換えで
補って使ってたのだろう。自己書き換え部分修正して動かす予定。

663 ：

>>662 MC680でなくMC6800

664 ：

自作といえばラッピングワイヤーと電動ラップツールの存在は知っていたけどハンドラップツール
の存在を最近知った。もっと前から知ってれば電子工作で色々作れたな。最近だと秋葉の大きな
工具屋にも殆ど置いてないし。電子立国日本の終焉か。

665 ：

>もっと前から知ってれば電子工作で色々作れたな。
やる気さえあれば、方法なんて二の次でハンダ付けでも電動工具使ってでも電子工作やってただろ。

666 ：

簡単な工作ならそれでいいけど。ハンドラップツール無しでハンドラップしてみなw

667 ：

>ハンドラップツール無しでハンドラップしてみなw
なんで?

668 ：

ラッピングした事無いような素人はほっとき

669 ：

>>668
「自作といえばラッピングワイヤーと電動ラップツールの存在は知っていた」ってんだから、
「ラッピングした事無いような」じゃなくて実際無いんだろ。

670 ：

>>664
>最近だと秋葉の大きな
>工具屋にも殆ど置いてないし。電子立国日本の終焉か。
今どきラッピングで工作できる部品なんてほとんど使わんだろ。
アマチュアがFPGA使って個人で業者に基板発注する時代なの理解してっか？

671 ：

なんでわざわざ発注すんだよ秋月あたりで出来合いの基盤買ってデータ焼いてコネクタ挿して
動かしてそれを自作でございとやりゃいいだろ。

672 ：

趣味なんだから、人それぞれの方法でやればいいだけだろ。
まあ、ラッピングしたことあるとかぐらいしか自慢のネタがないなら
しょうがないけど。

673 ：

FPGA評価ボードとかは使った事ある人なら判るかも知れないが
特に半導体ベンダ提供の物はFPGA機能を試す為に作られている物が多く
大抵のGPIOが配線済みになってたりするので、使う用途によっては、とても使いにくいものだったりする。
ttp://akizukidenshi.com/catalog/g/gM-05113/
これなんか、FPGAの評価用というより、ソフトプロセッサIPであるMicroBlazeを評価する為の物だったりするので、I/Oはほぼ使えなかったり。
秋月ではFPGAやCPLDの扱いって昔から弱いからな。
秋葉の店頭小売なら千石やマルツの方がまだ強い。
それはともかく、アマチュアなら、今はラッピング線よりもUEW使って配線してる人が多いのでは無いかな。
ラッピング線、専用工具無しだと剥きづらいし、実際にラッピングで作るには専用ICソケットとか使わなきゃいけないしな〜

674 ：

>>673
この間転職したソフト屋だけど、プロの人も試作とかではUEW使ってるね。
治具とかつくるのにハンダやらされるんだが、実装の話なんてそれこそ
ラッピングの時代までの知識しかなくてUEWなんて知らなかったから、導通しなくて頭抱えたわ。

675 ：

１プレーンのVRAMへの16bitDDAライン処理を書いてみたら
Z80が71〜104クロック/dot
6809が39〜66クロック/dotくらいになった
FMもSRも長さ50の線を１秒間に1000本くらいは描けるがいろんな意味でどっちもダメダメなことに違いは無い

676 ：

スタックポインタをVRAM上に設定して
PUSH
PUSH
PUSH
PUSH
PUSH
...

677 ：

>>662
OS-9は6809からだと思ったが?

678 ：

>１プレーンのVRAMへの16bitDDAライン処理を書いてみたら
>Z80が71〜104クロック/dot
>6809が39〜66クロック/dotくらいになった
遅杉じゃね？

679 ：

8bitにしてALUと自己書き換え使えば8801SR専用の方は50〜80ck/dotまで縮むけど
大勢に影響はない

680 ：

>>679
>8bitにしてALUと自己書き換え使えば8801SR専用の方は50〜80ck/dotまで縮むけど
遅すぎじゃね?

681 ：

>>675
>>679
そのコードを披露せんことには評価されんだろう

682 ：

>>679
>8bitにしてALUと自己書き換え使えば8801SR専用の方は50〜80ck/dotまで縮むけど
なんでそんなに掛かるのか理解できん。つかそれを自慢げに語るのが更に理解できんわ。

683 ：

「性能の限界で〜」とか軽々しく口にする奴のコードは大抵の場合限界には達していない
…ことが多かった希ガス

684 ：

>>683
そんな事言ったら披露しにくくなっちゃうだろ
ここはまずおだてておいてだな・・・

685 ：

>>675
>１プレーンのVRAMへの16bitDDAライン処理を書いてみたら
>Z80が71〜104クロック/dot
>6809が39〜66クロック/dotくらいになった
すごーい！見して見して！！

686 ：

>>679
>8bitにしてALUと自己書き換え使えば8801SR専用の方は50〜80ck/dotまで縮む
凄いテクニックですね！
ゼヒ参考にして勉強させていただきたいと思いますで、公開してはいただけないでしょうか？

687 ：

ドットあたり何クロックが妥当で、どんぐらいなら速いの？

688 ：

>Z80が71〜104クロック/dot
>6809が39〜66クロック/dotくらいになった
恐らくは↑が最速。神の領域に達していると言っても過言ではない。

689 ：

ADD HL,DEとLD (HL),CとDJNEだけで３１クロックだから
46〜64ｃｋ/dotじゃとてもお見せできません

690 ：

>>679をヒントにして dy>dx : 45 〜 69 clock/dot
; 前略
DY_LOOP:
　ld (hl), c
　sub a, $dx
　jr c, DY_SLIDE
　add hl, de
　djnz DY_LOOP
　; 後略
DY_SLIDE:
　add a, $dy
　rlc c
　adc hl, de
　djnz DY_LOOP
　; 後略
こんな感じかいな？あとは頼んだｗ

691 ：

>>690
とりあえず3クロック高速化した。
DY_LOOP:
　ld (hl), c
　sub d
　jr c, DY_SLIDE
　add hl, sp
　djnz DY_LOOP
　; 後略
DY_SLIDE:
　add a, e
　rlc c
　adc hl, sp
　djnz DY_LOOP
　; 後略

692 ：

なんかもりあがっとるなあ

693 ：

これで36〜48clock/dot?
　rept 640
　　ld (hl), c
　　sub d
　　jp nc, *+6
　　add a, e
　　rlc c
　　adc hl, sp
　endm
　; 後略

694 ：

訂正
　rept 640
　↓
　rept 200

695 ：

さすがに全てのアンロールは…
アンロールは2回分にしてdyの偶数奇数で、というのはどう？

696 ：

>さすがに全てのアンロールは…
何の問題が?

697 ：

>>695
コード書いてみ?

698 ：

>>697
未成立分岐7clockが効率よく使えなくなり、
煩雑コード & 効果薄だったのでスマンが取り下げる

699 ：

ループ処理はとりあえずは考えなくていんじゃね？
>>675 >>679で言ってるのがループ処理を含んだ話なのか分からんし。

700 ：

ld (hl), cでいいの？
or使わないと他の点消えない？

701 ：

ALUでORしてんだろ

702 ：

>>700
88SRのALU機能が前提らしいので
事前に（この場合Cレジスタの）ビットを書くか消すかを設定しておけばいいらしい

703 ：

ALUのおかげでギリギリ表レジスタに収まってるから
OR使うとEX AF,AFも加わって一気にスピードダウン
これにOUT命令のプレーン切り替えとANDクリアも加わったら絶望的
さらに垂直ブランク期間中しかVRAMにアクセスできないマシンとか何考えているんだか

704 ：

>>703
>ALUのおかげでギリギリ表レジスタに収まってるから
>OR使うとEX AF,AFも加わって一気にスピードダウン
SET n,(hl) 使えばいいじゃん

705 ：

>>703
SRのALU使う前提のプログラムに何言ってんの?

706 ：

>>704
８パターン分アンロールか、その発想は無かったわ

707 ：

ALU使用って、6809版もそうなのけ？

708 ：

>sub d
>add e
をイミディエイトにして、自己書き換えでdeレジスタ空けるってどうよ？

709 ：

>>708
遅くなるし空けてどうすんの?

710 ：

スタックをそのままにしておけばret cc(5/11ck)が使える

711 ：

使わなくていいじゃん

712 ：

>>708
コード書いてみ

713 ：

16bitDDAで書いてみた。
z80のアセンブラ忘れている。#はイミディエイトだと思ってくれ。$は16進だと思ってくれ
ix,iy使ってすR。つか256dotしか描けない（泣
ld ix,固定小数点
ld @1+1,ix ; 書き換える
ld iy,#$8000 ; 初期値
xor a,a
loop:
ld (hl),c
@1:
ld de,#1234 ; 自己書き換えられる
adc iy,de
;キャリーが立ったらCをローテートして、はみ出たらまたキャリーを立てる
sbc a,a
and a,c
add a,c
adc a,#0
cp a,c
ld c,a
;縦に移動
ld de,#80
adc hl,de
djnz loop
クロック数の計算のしかた忘れた。

714 ：

DDAじゃないだろ

715 ：

>DDAじゃないだろ
むう、abs(dx)/abs(dy)の小数点部を16bitにしたときの値をixに入れたとして
(iyの$8000は、0.5を表している)
DDAしたつもりなのだが(´・ω・`)

716 ：

メモリのスピードが同じなら6809はZ80の1/2.5〜1/3のサイクルで終わって欲しいけど
　　6809　　　　　　Z80
STA　,X 4ｃｋ　　LD (HL),A ７ｃｋ　
LEA　1,X 5ck　　INC L　4ck
LEA 80,X 5ck　　ADD HL,80できないが実質11ck
RLC Bできないし意味無い　RLC C 8ck
尾を引く敵弾を１０００個くらい画面にバラまいたら速いんだろうけど単純な処理には向かないな
OPコードが大きいのと空きサイクルが痛かった、6309作りたくなるのも無理はない

717 ：

昔、PC88の高速ライン描画ルーチンとかで雑誌に載ってなかったっけ？

718 ：

PC-8801/mkIIのCLS 3遅すぎ。

719 ：

roll命令使え

720 ：

>>717
Oh!XのMAGICとか
ことりちゃんの男前な奴が載っていたような

721 ：

ことりちゃん、あの時のままならまだよかったのに、今や(;_;)

722 ：

この人か。
http://ja.wikipedia.org/wiki/%E5%90%89%E6%9D%91%E5%8A%9F%E6%88%90
http://dic.nicovideo.jp/a/%E5%90%89%E6%9D%91%E5%8A%9F%E6%88%90

723 ：

これって本人が書いてるの？
http://news.hareplace.com/2nn/127/1278506390.html#213

724 ：

ことりさーん、プラズマラインをdirectxでつくってよ
いや、ことりさんじゃなくても良いんだけどさ

725 ：

自分で作りゃいいじゃん

726 ：

よし、いっちょやったるか

727 ：

お前ら初めてかZ80は？ 力抜けよ

728 ：

directxを良くactivexと間違える…

729 ：

directR

730 ：

actiR

731 ：

>>728
さすがにこの業界向いてないから、辞めたほうがいいんじゃね。
リタイヤした爺なら、もうそういう単語には忘れてもいいと思う、お疲れ様でした。

732 ：

　　　　　　　　　,___
　　　 　　　o'⌒)　 `ヽ
　　　　　　　　(i:i:i:i:i:☆i:i)　Z80に追加して欲しい命令を3つ言え
　　　　　　 　　(　´･ω･)　
　　　　　　　　　(　　∽)　　　　　　　　 (~)
　　　　　　　　 　 )　ノ　　　　　　　 γ´⌒｀ヽ　
　　　　　　　　　　（_　　　　　　　　　{i:i:i:i:i:i:i:i:}
　　　　　　　　　 [il=li]　　　　　　　　(ω・`　 )　3つだけか・・・
　　　　　　　　　　)=(_　　　　　　　　（::：::::∪)
　　　　　　　　　(-==-)　　　　　　　 　し─Ｊ
　　　　　　　　　 `ｰ‐''　　

733 ：

リフレッシュのタイミングを変更、あるいは止める命令は欲しい。

734 ：

>>732
EnterARMMode ... 以降 ARM Cortex-A15 相当になる。
あと２つは、64bit 版と予備に取っとく。

735 ：

64180のMLT ssは欲しい
あと2つ…どうせ2バイト命令だしなあと思うと難しい…

736 ：

LD A,A とか無くてもいい命令潰していいじゃん

737 ：

NOPもいらない

738 ：

NOPは結構使われてるから必要

739 ：

Z80に欲しい命令…
命令っつーかアドレッシングモードは欲しかったな、
レジスタ潰さずにオフセットアドレス使えるとかLD B,(A+HL)みたいな。

740 ：

>>738
XORでいいじゃん

741 ：

フラグやレジスタに影響する命令がNOPの代わりになるわけないべや

742 ：

LD HL,(HL)
LD BC,(HL)
LD DE,(HL)

743 ：

IX,IYとかもあったな、そいえば(すっかり忘れてたが…)

744 ：

AFもSPもPCもあったよ。

745 ：

アドレッシングモード、A〜HLまでの全てのレジスタをアキュムレータと同等に扱える命令形態
って考えるともうZ80じゃないんだよな…

746 ：

rが8bit欲しいのは俺だけか。

747 ：

Rは8bitあるからな。7bitなのはカウンタ。

748 ：

LD r8,(SP + imm8)
LD (SP + imm8),r8
LDA r16,(SP + imm8)

749 ：

SP相対にするとPUSH/POPするだけでオブジェクトを指すオフセットの値変わるし使い辛そう

750 ：

>>747
そういやそうだ。

751 ：

FADD
FSUB
FMUL
FDIV

752 ：

命令はどうてもいいがリフレッシュを8bitでやってほしかったな」

753 ：

LD r16,(HL)ってなかったっけ？

754 ：

ない

755 ：

>>753
Z280なら
LDWHL,(HL)ed28
LDWBC,(HL)ed06
LDWDE,(HL)ed16

756 ：

おおぅ。
×LDW HL,(HL) ed28
○ LDW HL,(HL) ed26
ついでに
LDW HL,(SP+im16) ed04,im16
とか色々…

757 ：

裏レジスタ使用
EXX
裏裏レジスタ使用
EXXX
裏裏裏レジスタ使用
EXXXX
裏裏裏裏レジスタ使用
EXXXXX

758 ：

レジスタバンクでいいだろ

759 ：

jr a,...
jr na,...

760 ：

Z80をどう弄ってもどうにかなる問題でもないしな…
選択肢が他にあまりない当時とか、ソフトの互換性問題とかそういうのじゃなければ
オリジナルCPUを趣味で自作する程度のお遊びか学習目的くらいだからなぁ。

761 ：

6800・6502のゼロページは実質256個のレジスタとして使えたなあ。
6809は半端にそれを引き継いだので、アキュムレータ潰してTFRでDPRへ上位8bit転送しないといけなかったっけな。DPRってリセット時の値って保証されてたっけ？

762 ：

ゼロにはなるが命令短縮以外になんのメリットも無いバカCPUだったな
エクステンドの方も１サイクル余分に食うから6809の中じゃ意味があったんだが
6502はともかく6800より遅いなんてバカ過ぎる

763 ：

>命令短縮以外になんのメリットも無い
命令短縮ってあの当時としてはすげえメリットだろ。

764 ：

>>762
>6502はともかく6800より遅いなんて
同じじゃん
6502:
LDA ZEROPAGE 3cycles
LDA ABSOLUTE 4cycles
6800:
LDAA DIRECT 3cycles
LDAA EXTENDED 4cycles

765 ：

>>764
普通に考えて
[ 6809 は ] 6502はともかく6800より遅いなんてバカ過ぎる
だと思うが…
6809:
LDA Direct 4 cycles
LDA Extended 5 cycles

766 ：

>>765
6502も6800も同じなのに「6502はともかく6800より遅いなんて」て言ってるのがバカだろ

767 ：

> 6502はともかく6800より遅いなんて
6502信者ｗ

768 ：

>>103の引用先のお仲間かｗ

769 ：

>>766
日本語大丈夫か？
とも‐かく
２ （「…はともかく」の形で）…は別として。…はさておき。「交通の便は―、閑静でいい」
http://dictionary.goo.ne.jp/leaf/jn2/160357/m0u/
つまり、「6502はともかく」と書いてある時点で、6502 はどうでもいい存在なんだよ。

770 ：

http://kotobank.jp/word/%E5%85%8E%E3%82%82%E8%A7%92%E3%83%BB%E5%85%94%E3%82%82%E8%A7%92
> 大辞林 第三版の解説
> ともかく【兎も角・兔も角】
>
> （ 副 ）
> �@不確かな点はさておいて，まずは実行したり判断したりするさま。とにかく。
> 　ともかくも。 「留守かもしれないが，−行ってみよう」
> �A（「…はともかく」の形で）それは問題外として。 「夏は−，冬がつらい」

771 ：

>>769
>つまり、「6502はともかく」と書いてある時点で、6502 はどうでもいい存在なんだよ。
どうでもいい存在の6502の名をわざわざ挙げている>>762は頭がおかしいと?

772 ：

>>769
>つまり、「6502はともかく」と書いてある時点で、6502 はどうでもいい存在なんだよ。
6502は別格ってことだよ。

773 ：

>>771
わざわざ「交通の便は―、閑静でいい」と言うような用例まで書いてあるんだから、
理解しようよ。
色々犠牲にしている 6502 にスピードで負けるのは別にいいけど、前身の 6800 に
負けるのは許せないってことだろ JK
書いてる内容の是非はともかく、内容ぐらい理解できるようになろうね (w
　　　　　　　　　　　　　~~~~~~~~~~~

774 ：

>>773
> 色々犠牲にしている 6502 にスピードで負けるのは別にいいけど、前身の 6800 に
> 負けるのは許せないってことだろ JK
色々犠牲にしているという6502も、6800と速度は変わらんて話だが、理解できてる?

775 ：

>>773
>わざわざ「交通の便は―、閑静でいい」と言うような用例まで書いてあるんだから、
この場合の用法は、交通の便については否定的なニュアンスが含まれるぞ。

776 ：

>>774
> 色々犠牲にしているという6502も、6800と速度は変わらんて話だが、理解できてる?
そんな話しでないことも理解できてないのかよ…
>>775
「否定的な」とは？
ニュアンスとして「どうでもいい」あたりまでは含まれることもあるけど、普通は
A) 交通の便よし、でも騒がしい
B) 交通の便悪い、でも閑静
の２物件があったら、Ｂ を選ぶってことだろ。
もちろん、
C) 交通の便よし、でも閑静
があったら、C を選ぶ。
※ もちろん、他の条件が同じ場合ね。

777 ：

>>776
> > 色々犠牲にしているという6502も、6800と速度は変わらんて話だが、理解できてる?
>
> そんな話しでないことも理解できてないのかよ…
>>764読んでないの？見ても理解できないのかな？？

778 ：

age

779 ：

逝去をねがってage

780 ：

１９７６年に「今の知識でチートして」新しいCPU作るとどうなるんだろうね。
Z80を市場から駆逐できるだろうか？

781 ：

>>777
>>764 自体がおかしいと指摘されてることすら理解してないのか…
まあ、>>769 見て理解できないならどうしようもないけど、少なくとも
理解度が世間と違うことぐらいは覚えておいた方がいい。
>>780
半導体技術 (集積度とか) は、当時を想定するの？
そうであれば、Z80 を駆逐するのはちょっと難しいかも。

782 ：

>>769
>つまり、「6502はともかく」と書いてある時点で、6502 はどうでもいい存在なんだよ。
「>>769が真性Rなのはともかく6800より遅いなんてバカ過ぎる」ぐらいどうでもいい存在の話
してるってこと？
頭おかしいね。

783 ：

>>780
当時の半導体技術で実現可能なことは実際に当時に行われてるんじゃないかな。

784 ：

久しぶりに見に来たらガイキチが暴れているようですな

785 ：

と気違いが申しております。

786 ：

ここID出るようにしてほしいな

787 ：

>>782
悔しいね (w

788 ：

>>786
自治スレで叫ぶか？

789 ：

IDなんかいらないよ
俺と俺以外、それがわかれば十分

790 ：

いえ、おたくの都合なぞ知りませんよ

791 ：

真性R

792 ：

>>762
DP レジスタが 16 bit だったらもっと使いでがあったかもしれない。

793 ：

それってアドレスを20ビットにするってこと？

794 ：

それって 16+8=20 ってこと？

795 ：

そうじゃなくて、 256 Byte 飛びじゃなく任意のアドレスから
256 Byte 使えるということ。

796 ：

それじゃインデクスレジスタがもいｌっこ増えるのとあんま変わらんな

797 ：

しかもモトローラの技術じゃ実行に５サイクルかかる
耐え切れずに日立が３サイクルに改造しても因縁付けられて封印されると

798 ：

>>797
つかCPUエミュだったからな

799 ：

>>798
どゆこと? 日立が勝手にマイクロコードいじったとかの話じゃないの?

800 ：

6809はマシンサイクル短いけれどCISCなんですか？

801 ：

うわ、バカがいる！

802 ：

RISCの原型どす

803 ：

比較的速い命令も、遅い命令もある6809がRISCなわけねーべや

804 ：

じゃあZ80はRISC?

805 ：

比較的速い命令も、遅い命令もあるZ80がRISCなわけねーべや

806 ：

べや

807 ：

とにかく演算器を休ませない為、どうデータを流し込んで逝くかって設計思想になる前のモノだからな〜

808 ：

6502とR800はRISC

809 ：

比較的速い命令も、遅い命令もある6502やR800がRISCなわけねーべや

810 ：

内部でパイプライン動作してるプロセッサをRISCとか言うのバカ丸出しだからやめて

811 ：

R800の頃はRISCという言葉が流行りだったから仕方ない

812 ：

ペンティアムやコールドファイヤはRISC

813 ：

なわけねーべやべやべや

814 ：

老いぼれどもage

815 ：

先月号の月刊インターフェース(Rhapsberry PiとARM特集)の冒頭なんだが
http://www.kumikomi.net/interface/sample/201212/if12_036.pdf
最初のイラストで、マイコンホビーの歴史が、8080から始まるのはいいとして
なぜ Z80 を飛ばしてるんだろう? 納得がいかん

816 ：

>なぜ Z80 を飛ばしてるんだろう? 納得がいかん
「今までのインテル系CPUの場合…」ってあるからだろ。

817 ：

AMD64はインテル系CPUでは無い！

818 ：

AMD64? 何の話?

819 ：

どうしよう、ゼルビーノがお肉盗んじゃったよ
お金なんてボクもってないしどうしよう

820 ：

むしろ8085を入れるべきだろ

821 ：

8085本流から外れた枝葉のチップだし必要ないだろ

822 ：

>>820
ホビーで 8085 なんて、使ってた奴なんて見たことないぞ。

823 ：

>>822
http://www.kumikomi.net/interface/sample/201212/if12_036.pdf
↑の最初のイラストでホビーって??

824 ：

PC-8201やTK-85なんかをホビー用途に使ってた人も多いことだろう

825 ：

>>823
>↑の最初のイラストでホビーって??
俺に言わずに >>815 に言ってくれ。
>>824
TK-85 を使ってる奴はいないとは言わないけど、俺は見たことない。
PC-8201 の CPU が 8085 とは知らんかった、PC-8201 は使ってた奴見たことあるから、
>>822 は撤回するわ。

826 ：

カシオのFP-200も8085だと思ったが、この頃のハンドヘルド機に8085の採用が多く見られるのは
C-MOS版があったからかしら?

827 ：

>>826
そう。8085のCMOS版は、沖がかなり早い時期に出した。
そういう用途だとメモリーもCMOSのSRAMを使うから、リフレッシュ機能がないことはデメリットにならない。

828 ：

AVRって76年に投入は無理かな？

829 ：

HC-20は6301という珍しいCPU使ってたな
6800とバイナリ互換のくせにASLDとかABXが１サイクルで終わる優れものだった
6809と違って内部はちゃんと16bitになってたのに惜しかった

830 ：

Canonが確かZ80のHHC出してたよなぁ、あれどっかで修理してるブログとか見たような。

831 ：

>>833
X-07?
NSC800でソフトはZ80、バスは8085コンパチって言う変な奴だったね。
(サブにCUSTUM8BitCPU)
小型でいろんな拡張機器が有ってなかなか意欲的とは思ったが、拡張機器付けたら動かせなくなるから?と思った。

832 ：

i8085はもっと評価されてもいいと思うんだけどなぁ
バス系はi8086に繋がっていくし

833 ：

呼んだ？

834 ：

組み込み用だし後が続かなかったからなあ。 ＞8085
8086のフラグとか見ても8080の仕様引き継いでて、8085は無視されてるもんなあ。

835 ：

8085は、8085の後継機にしてはショボかったからな。
8224と8228を一体化しましたとか言っても
Z80と比べるとアドレスラッチがいる分ダサいし
命令の拡張もイマイチ
「シリアル入出力命令追加」とか言ってるけど
それ単なる1ビットI/Oポートだろ、みたいな。

836 ：

すまん、入力ミス
8085は、8085の後継機にしてはショボかったからな。
↓
8085は、8080の後継機にしてはショボかったからな。

837 ：

オーバーフローフラグが増設されたのに隠し仕様だったし8086に引き継がれなかったしなあ。
つーかZ80でパリティフラグとオーバフローを同居させたのは見識を疑う。

838 ：

8051は組み込み用やらコントローラ用やらで、生き残ってるね

839 ：

8085の条件ジャンプは飛ばない時は命令の３バイト目を読まずに次の命令を読みに行くのか
これはZ80でもやって欲しかった

840 ：

割り込みのピンが40本中5本(RESETも含めれば6本)と豊富なところがカッコイイ

841 ：

NECはTK-80の後継機に8085を採用したのはなぜだろう? uPD8085よか、uPD780のほうが
よっぽど売れ筋だったと思うのだが。
8085を組み込み用と位置づけた上で、組み込みを勉強するための教材として企画された
製品ということだろうか?
8085の組み込みに便利な特徴としては、
・少ないチップ数で構成可能
・豊富な割り込みピン
・1ビットづつある入力/出力ポート
こんなところがあると思うのだが、TK-85で活かされてたのは一番下のみだな。

842 ：

>>835
アドレスラッチを使うと数ピン別目的で使う事が可能になる訳だけど
その別目的にしたピンの用途ってのが微妙だとね。
ついでに。
アドレス下位をデータバス共用にするよりも
アドレス上位をデータバス共用としてラッチする形にしておけば
DRAM使用前提のバス構造として使いやすくなったんじゃないか?とも思う。
DRAM用信号をCPU側で作ってくれたならば、だけど。
特にアドレスマルチプレクサの切り替え信号。

843 ：2012/12/05

>>838
Zilogの対抗品なSuper8もそうだけど
後発だけあって、バイト操作に特化した命令セットで、コントローラ用途だと扱い易いからね。
乗算／除算命令だってあるし。
その代わり、16bit演算&操作は80系より弱いがww