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

1 + 1：ナイコンさん[sage] 2012/04/09(月) 18:54:57.87: 8086(8088)・Z80・6809・6502のうち、どのCPU(MPU)が優れているか議論するスレッドです。
CPU(MPU)アーキテクチャや周辺デバイス制御など
基本的に「石」に関連する議論なら、ほぼ何でもアリです。

■過去スレ
8086 vs. Z80 vs. 6809 vs. 6502　その7
http://read2ch.com/r/i4004/1319314159/
8086 vs. Z80 vs. 6809 vs. 6502　その6
http://read2ch.com/r/i4004/1286766300/
8086 vs. Z80 vs. 6809 vs. 6502　その5
http://read2ch.com/r/i4004/1280380374/
8086 vs. Z80 vs. 6809 vs. 6502　その4
http://read2ch.com/r/i4004/1252639237/
8086 vs. Z80 vs. 6809 vs. 6502　その3
http://read2ch.com/r/i4004/1235851359/
8086 vs. Z80 vs. 6809 vs. 6502　その2
http://read2ch.com/r/i4004/1213527504/
8086 vs. Z80 vs. 6809 vs. 6502
http://read2ch.com/r/i4004/1165801265/
6809とZ80 part 2
http://read2ch.com/r/i4004/1093190685/
6809とZ80
http://read2ch.com/r/i4004/1008496410/

■関連スレやサイトなど　※補足などあれば>>2-9あたりで
68K v.s. x86
http://read2ch.com/r/i4004/1220728356/

半導体コレクション展示会場
http://www.st.rim.or.jp/~nkomatsu/ICcollection.html

2：ナイコンさん[sage] 2012/04/09(月) 21:05:54.45: おつ！
3：ナイコンさん[sage] 2012/04/09(月) 23:13:10.45: >>1　乙です

小松さんのコレクションのサイトを閲覧してて、初めて知ったんだけど
AMDの石のセカンドソースを、Intelが出すような例が昔はあったんだね

AMDの数値演算プロセッサ Am9511　→　セカンドソース Intel 8231
ttp://www.st.rim.or.jp/~nkomatsu/peripheral/Am9511.html
4：ナイコンさん[sage] 2012/04/10(火) 09:48:27.12: ああ、am9511は超有名だったからな。

そしていちょつ。
5 + 1：ナイコンさん[sage] 2012/04/10(火) 12:42:52.15: Zilog Z180(HD64180)やIntel 8231/8257 (Am9511/9517のセカンドソース) への
柔軟な対応と、HD63C09へのどうしようもない対応が歴史を決定した。

オリジナルの6809のアーキテクチャに最大限の敬意を払って拡張され、
高速化され、CMOS化された優秀なセカンドソーサのチップを潰したMotrora。

MC68040、MC68060、PowerPC620、PowerPC G4と複雑化→開発遅れを
何度も何度も何度も同じ轍を踏んで、半導体事業撤退に至る。
6：ナイコンさん[sage] 2012/04/10(火) 13:24:33.84: >>5
>高速化され、CMOS化された優秀なセカンドソーサのチップを潰したMotrora。

潰してないでしょ
7 + 1：ナイコンさん[sage] 2012/04/10(火) 14:56:30.86: 6309の独自拡張がモトローラと日立の紛争の原因とはなったようだが。

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

日立が勝手に拡張した内容をデータシートに載っけてモトローラに怒られただけ。
データシートの該当部分は削除になったけどチップの販売は普通に継続された。
9 + 1：ナイコンさん[sage] 2012/04/10(火) 15:29:30.49: 拡張仕様がリファレンスやデータシートに載ってない6309など、互換チップ以外に存在意義はないな。
実質的な圧力だろう。当時貿易摩擦もあったろうし東海岸の企業らしい。

モバイル部門がグーグルに買収されたら終了だろうかね。
モトローラという企業は、ビジネス的にチップだけでなく企業としてもイマイチだったのだろう。
そんな企業の作るチップを信じてしまった昔のPC板住人氏は残念でならない。
10 + 1：ナイコンさん[sage] 2012/04/10(火) 16:09:43.49: >>9
>拡張仕様がリファレンスやデータシートに載ってない6309など、互換チップ以外に存在意義はないな。

CMOSだし、3MHz動作版もあったし、そんなことないでしょ。あんたバカじゃね？
11：ナイコンさん[sage] 2012/04/10(火) 22:45:18.61: ロストテクノロジーで盛り上がってるな
12：ナイコンさん[sage] 2012/04/11(水) 09:52:23.76: そもそもデータシートが外部非公開のエンジン制御用6301とかもっと魔改造されてるじゃん
13 + 2：ナイコンさん[sage] 2012/04/20(金) 00:21:05.95: >>10
FM7系だと結構載せ替え流行ってたよ。
14 + 1：ナイコンさん[sage] 2012/04/20(金) 00:25:11.85: >>13
マニアがどうこうした数なんて全体の生産量からすれば屁みたいなもんだろ。
15 + 1：ナイコンさん[sage] 2012/04/20(金) 18:32:04.57: 臭いって事？
16：ナイコンさん[sage] 2012/04/20(金) 23:12:51.69: >>13
ないな。
ゲームが動かなくなるから。
あとFM77AV系はCPUが直付けだから、載せ換えはさらにハードル高い。
17：ナイコンさん[sage] 2012/04/21(土) 00:23:48.02: >あとFM77AV系はCPUが直付けだから、載せ換えはさらにハードル高い。

DIPだし大したことない
18：ナイコンさん[sage] 2012/04/22(日) 23:58:31.74: >>14
数が少ないからステータスになるのさ。
もちろんコテ持てない奴等はよだれ流してるだけ。
19 + 1：ナイコンさん[sage] 2012/04/23(月) 07:10:13.84: いい加減な改造して不安定になるよりも
遅くてもノーマルで安定している方が良い

まして改造がステータスだなんて思っているヤツはアホゥ
20：ナイコンさん[sage] 2012/04/24(火) 00:07:02.94: >>19
いいかげんな改造しか出来ない奴のいいわけだな。
21：ナイコンさん[sage] 2012/04/24(火) 04:00:48.74: いい湯加減だよ
22：ナイコンさん[sage] 2012/05/24(木) 02:20:35.52: 6309はTFR,EXGの非互換さえなけりゃ神CPUだったのに。
惜しい、とても惜しい。
23：ナイコンさん[sage] 2012/05/24(木) 02:55:48.77: この辺の話かいな?

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：ナイコンさん[sage] 2012/05/24(木) 03:01:37.14: データシート上は互換だったのに、
未定義動作の互換性までは考えていなかったというオチ。
25：ナイコンさん[sage] 2012/05/24(木) 03:07:10.31: まあ、8080→Z80でもけっこう非互換部分あるけど、あんまし文句言ってる人見たことないし、いいんでないの?

26：sage[] 2012/05/24(木) 10:19:09.57: オーソドックスに組まれてないだろそれ。
素人ならともかく、プロが未定義使うってどうなの。
27：ナイコンさん[sage] 2012/05/24(木) 12:01:08.05: エラーにしないアセンブラが悪い希ガス
28 + 1：ナイコンさん[sage] 2012/05/25(金) 18:55:00.99: 使うヤツが悪いに決まっているだろ
アセンブラ、コンパイラのエラー報告は忠告程度
エラーがなくても疑うのがプロ
29：ナイコンさん[sage] 2012/05/25(金) 19:11:53.09: >>28
アセンブルのたび、リンクのたびに出力されたコードをプログラマが精査ですか? プロって大変なんですね。
30 + 1：ナイコンさん[sage] 2012/05/25(金) 19:56:27.27: 全てやる訳無いだろ、バカかオメーはよ
アグレッシブなコードだけ精査するに決まってんだろ
とろい突っ込み入れてんジャネーヨボケが
31：ナイコンさん[sage] 2012/05/25(金) 20:16:52.41: >>30
え、それじゃあ「エラーがなくても疑うのがプロ」てのは嘘なの?
32 + 1：ナイコンさん[sage] 2012/05/26(土) 01:05:06.91: なんだ、テスト中は全然こなかったのに、テスト終わるとさっそくやって来たな。
33 + 1：ナイコンさん[sage] 2012/05/26(土) 01:16:34.31: >>32
キミの頭の中はまだ学生気分なの?
34：ナイコンさん[sage] 2012/05/26(土) 18:32:14.09: ていうか、意識して未定義使うとかの話じゃなくて、
意図せずにないsrc/dstの組み合わせをしてしまったとかの話なの？
35 + 1：ナイコンさん[sage] 2012/05/26(土) 18:37:34.16: アマチュア製アセンブラやコンパイラが普通に使われていた時代
アマチュアとプロの境界線も曖昧だった時代

未定義動作の記述ハジくとか石の製造メーカーが作ったアセンブラぐらいしかなさそうな気が
36 + 1：ナイコンさん[sage] 2012/05/26(土) 18:42:02.19: >>35
> アマチュア製アセンブラやコンパイラが普通に使われていた時代

そんな時代あったか？

俺は使ったことない。
37：ナイコンさん[sage] 2012/05/26(土) 18:47:44.08: なんか、マシン語とか言いながらバイナリダンプを指すような人達の会話に見えてるな…
38 + 1：ナイコンさん[sage] 2012/05/26(土) 20:16:06.42: >>36
お仕事でCP/Mとか使っていたヒトは知らないかもしれんけど
アマチュアホビーストはそんな高いモノ普通は手が出なかったから
ホビーストお手製のシステムプログラムでお茶を濁していたのだ
39：ナイコンさん[sage] 2012/05/26(土) 20:18:44.23: この場合は6309だからCP/MじゃなくてOS-9とかだな。
40：ナイコンさん[sage] 2012/05/26(土) 20:22:44.85: パソコン一台買って小遣いが干上がった子供はソフトは自作か雑誌で手入力
41：ナイコンさん[sage] 2012/05/26(土) 21:09:35.67: >>38
お仕事の話じゃないのか…
42 + 1：ナイコンさん[sage] 2012/05/27(日) 00:36:45.64: >>33
ならいいな、そろそろ赤いちゃんちゃんこに手が届きそうなんだよ。
43：ナイコンさん[sage] 2012/05/27(日) 02:50:36.30: >>42
頭の中が学生気分であるか否かと、年齢ってあんま関係ないんじゃない?
44：ナイコンさん[sage] 2012/05/30(水) 12:46:27.02: 1D SEX
45：ナイコンさん[sage] 2012/05/31(木) 00:50:09.24: 符号拡張命令はホントに人気だねぇ
46：ナイコンさん[sage] 2012/05/31(木) 08:58:06.67: CBWすげぇ
47：ナイコンさん[sage] 2012/06/02(土) 20:02:07.37: 別人の横レスですが、たとえば 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 + 1：ナイコンさん[sage] 2012/06/03(日) 11:57:12.93: だから、未定義命令を仕事で使っちゃだめだろ
純正品だってrevisionが変わったら動かなくなるかもしれん
49：ナイコンさん[sage] 2012/06/04(月) 00:15:38.62: >動かなくなるかもしれん
その修正を有料で受けることを考慮した仕事を(ry
50：ナイコンさん[sage] 2012/06/05(火) 13:09:06.34: TB級のHDDをカセットレコーダーエミュレーションさせて8bit機に活用出来ませんかね
51：ナイコンさん[sage] 2012/06/05(火) 14:10:01.28: ICレコーダーでいいだろ
52：ナイコンさん[sage] 2012/06/06(水) 08:14:47.88: 999GBまど読んでエラーにする機能も実装
53 + 1：ナイコンさん[sage] 2012/06/06(水) 17:49:06.96: >>48
ゲームとかでは使われている事が多々あって、実際MSXではHD64180機で動かないソフトが(ry

規格なんて、大手だって無視するんだぜwwww
iPadのUSB充電とか有名でしょw
54：ナイコンさん[sage] 2012/06/06(水) 18:33:44.32: >>53
>MSXではHD64180機で動かないソフトが(ry

MSXでは64180の方が規格違反だろ。日立も64180のことをZ80コンパチとか謳ってないし。
55 + 1：ナイコンさん[sage] 2012/06/07(木) 09:18:32.05: 64180搭載機はZ80と切り替えられるから規格違反ではない
56 + 1：ナイコンさん[sage] 2012/06/08(金) 06:17:37.93: >>55
動かないんだからどっか違反してんだろうな
57：ナイコンさん[sage] 2012/06/08(金) 07:46:24.55: >>56
HD64180とかZ180とかZ380では
Z80のインデックスレジスタ関連の未定義命令が排除されてるってだけの事だな。

Zilog的には公式には存在しない命令なんだから
排除も何もない訳だがwww
58：ナイコンさん[sage] 2012/06/08(金) 11:09:32.62: Z80も各命令の挙動についてマニュアルに全て書かれてる訳じゃないしな
59：ナイコンさん[sage] 2012/06/08(金) 18:47:20.76: 裏挙動があるのかー
60：ナイコンさん[sage] 2012/06/14(木) 00:40:08.07: 裏命令を使うとか今の基準で考えるとありえない事やってたんだな
61：ナイコンさん[sage] 2012/06/14(木) 16:17:40.20: 今は例外割り込みとかあるからな、普通に使えない。
(まぁまだCPUにもよるが…)

当時は速度が必要十分じゃなかったことと、メモリが高すぎたからな。
１バイト節約のためにトリッキーなことをするのも、たしなみみたいな意識もあったし。
(それはそれで色々問題あるが)
62 + 1：ナイコンさん[sage] 2012/06/15(金) 00:03:34.84: ホントにメモリが逼迫していたり処理を速くしたくて
裏技を使うのは仕方が無いと思うけど
知っている事を自慢したくてとか、興味本位で使うヤツはギルティーだな
63：ナイコンさん[sage] 2012/06/15(金) 02:35:14.21: 64180とZ80じゃDAAしたときの挙動が違ってた気がする
64：ナイコンさん[sage] 2012/06/15(金) 03:02:37.90: DAA命令って、8080でも、Z80でも、64180でも、マニュアルでちゃんとした動作の定義なかった気がする
65 + 2：ナイコンさん[sage] 2012/06/15(金) 14:12:42.58: >>62
ある意味IOポート命令でVRAM(16bitアドレス指定アクセス)をするのもそうだな。
確か当初はOUT(C),Aとか上位バスにBレジの内容が出るとかいうのは、正式にはなかったはずだし。

DAAは8080A以降の命令じゃなかったかな、Aなしはなかったと思う。
それ以前に積極的に使う場所が限られてたような。
66：ナイコンさん[sage] 2012/06/15(金) 14:18:08.23: >>65
>ある意味IOポート命令でVRAM(16bitアドレス指定アクセス)をするのもそうだな。
>確か当初はOUT(C),Aとか上位バスにBレジの内容が出るとかいうのは、正式にはなかったはずだし。

少なくともシャープのマニュアルには書いてあったぞ。

>DAAは8080A以降の命令じゃなかったかな、Aなしはなかったと思う。

Aなし→Aありは電気的に改良されただけ。
67：ナイコンさん[sage] 2012/06/15(金) 15:19:59.59: あ、そうだNECの偽物の話とごっちゃになってた。ぐぐって確認。

シャープのZ80だってところがミソってことだったんだろうなｗ
68：ナイコンさん[sage] 2012/06/15(金) 15:42:56.83: Z80ってバグあったよね
69：ナイコンさん[sage] 2012/06/16(土) 02:06:25.64: Zilogのマニュアルにも書いてあるがな
70 + 2：ナイコンさん[sage] 2012/06/16(土) 02:27:10.74: >>65
>ある意味IOポート命令でVRAM(16bitアドレス指定アクセス)をするのもそうだな。
>確か当初はOUT(C),Aとか上位バスにBレジの内容が出るとかいうのは、正式にはなかったはずだし。

↓の269頁とか見れ
http://www.z80.info/zip/z80cpu_um.pdf
71：ナイコンさん[sage] 2012/06/17(日) 03:06:15.27: 288ページしかないんだが
72 + 1：ナイコンさん[sage] 2012/06/17(日) 03:20:16.10: 288ページもあれば、充分だと思うが。

まあ、out (c),a というニーモニックだし、"select the I/O device at one of 256 possible ports"
なんて書いてるから、たまたま A8-A15 に Bレジスタの内容がでるような設計になってて、
便利そうだということで仕様になったんだろうね。
73 + 1：ナイコンさん[sage] 2012/06/17(日) 03:21:52.78: >>70
それ新しい版だから
74：ナイコンさん[sage] 2012/06/17(日) 04:02:13.85: >>73
古い版のにはなかったとか言いたいならお前がそれ提示すればいいと思うよ
75：ナイコンさん[sage] 2012/06/17(日) 06:09:05.91: ドヤ顔(笑)
76 + 2：ナイコンさん[sage] 2012/06/17(日) 06:26:36.29: >>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 + 1：ナイコンさん[sage] 2012/06/17(日) 08:10:51.72: >>76
Bレジスタがアドレスの上半分に出てくるなんて書いてないだろ
78：ナイコンさん[sage] 2012/06/17(日) 08:41:38.87: >>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 + 1：ナイコンさん[sage] 2012/06/17(日) 08:44:04.33: 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 + 1：ナイコンさん[sage] 2012/06/17(日) 11:07:27.07: ザイログ発行の資料にBレジスタの事が謳われていないんだから
それを見込んだプログラミングはトリッキーと言われても仕方が無いね
シャープについてはもう言う事無い、ただ異常としか
これからは使わないようにしようね
81 + 1：ナイコンさん[sage] 2012/06/17(日) 11:17:35.15: >>80
>>79はZiLog発行資料な
82：ナイコンさん[sage] 2012/06/17(日) 11:41:08.73: >これからは使わないようにしようね

そもそも、今後Z80のプログラムを組む可能性のある人は
ほとんど居ないんじゃなかろうか。
83 + 1：ナイコンさん[sage] 2012/06/17(日) 11:58:53.22: >>81
だからそれのどこにもそんなこと書いてないじゃん
ザイログの資料にないことは全部裏技
裏技使えばどこかで問題が出る可能性が残る
だから使わないようにしようね
正統派のプログラマーは
84：ナイコンさん[sage] 2012/06/17(日) 12:03:36.89: >だからそれのどこにもそんなこと書いてないじゃん

???
85：ナイコンさん[sage] 2012/06/17(日) 12:09:12.63: >>83
>だからそれのどこにもそんなこと書いてないじゃん
>ザイログの資料にないことは全部裏技

http://www.zilog.com/docs/z80/um0080.pdf の15ページ、'Figure 7. Input or Output Cycles' に
A15-A0 のタイミングまで書いてあんのに?
86：ナイコンさん[sage] 2012/06/17(日) 12:09:58.04: 都合の悪いことは見えなくなる人かな？
87：ナイコンさん[sage] 2012/06/17(日) 12:16:24.77: 古いのもってこいよ
88：ナイコンさん[] 2012/06/17(日) 12:31:27.41: レジスタBの値がアドレスバスの上位に出るから積極的に使ってネ
VRAMなんかI/Oアドレスに繋いでアクセするすると良いよ
とでも書いてあると思っているのか

マニュアルは事実だけしか書かれていない
それをどう使うかはユーザー次第
トリッキーなコード書くのもユーザー次第
ﾒﾝﾃﾅﾝｽが出来るならどんなコードでも良いんだよ
89：ナイコンさん[sage] 2012/06/17(日) 13:56:52.30: >>70
それさところどころ間違ってるとこあるよね。
IN A(C)はED 7BじゃなくてED 78だよね。
ED 7B xx xx は LD SP,(nn)だよね。
90 + 3：ナイコンさん[sage] 2012/06/17(日) 14:05:46.88: Z80の売りの一つなブロック入出力命令だと実質使えないんだから
積極的に16bitI/Oアドレス使ってねとは書けないよなwww
91：ナイコンさん[sage] 2012/06/17(日) 15:23:39.19: >>90
Z80の売りの一つはDRAMのリフレッシュ機能だからDRAM以外は繋いじゃダメ、くらいナンセンスな話だな。
92：ナイコンさん[sage] 2012/06/17(日) 16:07:07.59: >>90

Bレジスタがアドレスバスに出るから、OTIRとかINIRとかで
「あと何回で転送が終わるか」がCPUの外からも見えて便利なわけだなwww
93：ナイコンさん[sage] 2012/06/18(月) 22:50:44.03: >>90
大活躍の間違いじゃないか
94 + 1：ナイコンさん[sage] 2012/06/19(火) 02:13:47.11: I/OはA0-A7とA8-A15を入れかえて配線すると便利ですよ
とマニュアルに書いてて欲しかった
そうすれば公知の事実になったのに
95：ナイコンさん[sage] 2012/06/19(火) 02:21:36.04: >>94
SONYのSMCﾅﾝﾄｶはそんな感じのI/Oマップだったらしいけど、なんか便利だった?
VRAMの並びがリニアでない時点でダメダメな気がするけど。
96：ナイコンさん[sage] 2012/06/19(火) 02:29:12.84: なんでリニアでないとダメダメなの？
97 + 1：ナイコンさん[sage] 2012/06/19(火) 02:31:36.85: 16ビットでアドレス計算したあとペアレジスタの上下入れ替えるなんてしたくないよね
98：ナイコンさん[sage] 2012/06/19(火) 02:37:08.78: I/Oのアドレス上下入れ替えて、VRAMはI/Oにぶら下げられるわ、1命令でI/Oは
アクセスできるわって話なら、I/Oのアドレス入れ替えるの止めてメモリの64KBの内
256バイト潰してメモリマップドI/Oにするのも考慮していいと思う。
99：ナイコンさん[sage] 2012/06/19(火) 18:08:09.09: >>97
入れ替える必要ないんでないの？
100：ナイコンさん[sage] 2012/06/19(火) 18:30:39.11: たとえば 320x200 の解像度で1ドット1バイトのビットマップを実現したとして、
アドレスがリニアなら 0000～F9FF になるとこをアドレスの上下入れ替えて
0000～FFF9(XXFA～XXFF は非使用)に割り当てる。
そうすると VRAM を I/O 領域にマッピングできるし、XXFA～XXFF の非使用
領域はアドレスの下位のみデコードして他のペリフェラルを繋げられ、アクセスも
OUT(n),A の1命令でアクセスできるってことだろ。
VRAMのアクセスは上下入れ替えが生じてる分面倒くさくなる。
101：ナイコンさん[sage] 2012/06/19(火) 19:09:34.91: OUTI命令並べられるし16ビット計算は元々遅いから使ってないし
102：ナイコンさん[sage] 2012/06/19(火) 19:28:58.60: SMCっリニアに見せ掛けてんじゃないの？
103：ナイコンさん[sage] 2012/07/02(月) 00:44:15.63: 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：ナイコンさん[sage] 2012/07/02(月) 04:43:45.89: 元プロが「hz」とか。
大丈夫か？
おめでたいな。
105：ナイコンさん[sage] 2012/07/02(月) 11:03:45.37: >割り込みが実質256使えるために

どういう意味だろ?

割り込みの数を比べるならZ80の割り込みモード0に勝てるわけないと思うが。
106 + 1：ナイコンさん[sage] 2012/07/02(月) 20:41:14.77: ↓どう見ても割り込みが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：ナイコンさん[sage] 2012/07/02(月) 21:09:24.02: >それどころか6800で言うところのSWI(Soft Ware Interrupt)すら無さそうだね。

http://www.6502.buss.hk/6502-instruction-set/brk
108：ナイコンさん[sage] 2012/07/02(月) 21:18:41.47: 106みたいなバカが相手なら「いい加減に知ったかやめてマジでw」というセリフが出るのも仕方ないかな。
109：ナイコンさん[sage] 2012/07/03(火) 03:43:38.64: >>106
知らないくせに話題に参加しようという姿勢は評価する
110 + 1：ナイコンさん[sage] 2012/07/03(火) 18:38:00.11: 6502の1MhzはZ80の4Mhz相当ってのは正しいな
111：ナイコンさん[sage] 2012/07/03(火) 18:40:58.03: >6502の1MhzはZ80の4Mhz相当の処理能力

知ってたらこんなバカなこと書けない
112：ナイコンさん[sage] 2012/07/03(火) 19:37:15.57: >6502の1MhzはZ80の4Mhz相当の処理能力

何倍相当かなんて何やらすかにも拠るけど、6502で4倍のクロックのZ80相当に働かせるって
なかなかそんな処理ないだろ。
113：ナイコンさん[sage] 2012/07/03(火) 23:08:14.73: >>110
その話は前スレでなぁなぁになったでしょ、お爺ちゃん
114：ナイコンさん[sage] 2012/07/03(火) 23:32:59.26: ここには6500系がまともに使える奴は絶対にいないな
何せまともな話が出てこないものな
115：ナイコンさん[sage] 2012/07/03(火) 23:50:50.00: 何を持ってまともに使えると言ってるのか知らんけど、
普通に使ってた奴はいくらでもいると思う。

て言うか、そういう奴しか見てないだろ、この板。
116：ナイコンさん[sage] 2012/07/04(水) 02:18:04.15: >ここには6500系がまともに使える奴は絶対にいないな

という奴がアセンブリ言語の話題を絶対に振らないという不思議Ｗ
117：ナイコンさん[sage] 2012/07/04(水) 08:59:41.53: インストラクションの実行を考えないクロックの比較の無意味さとか、過去にやってたよな？
118：ナイコンさん[sage] 2012/07/05(木) 22:05:50.84: コピペ連呼君は芸が無いからな…

今だったら、B-CASカードにも内蔵されてる6502最強!とか書くべきなのにww
119：ナイコンさん[sage] 2012/07/05(木) 22:18:08.29: >B-CASカードにも内蔵されてる6502

芸がある人は流石だと思う。
120：ナイコンさん[sage] 2012/07/06(金) 11:30:56.51: ARM使えりゃ十分だろ
121：ナイコンさん[sage] 2012/07/06(金) 14:35:13.83: ARMだけだと消費電力に制限ある場合とか困る。
ついでにARM用語に慣れすぎてると、他のCPU使う時にまごつく。MPUとかw
122：ナイコンさん[sage] 2012/07/06(金) 14:47:16.33: >ついでにARM用語に慣れすぎてると、他のCPU使う時にまごつく。MPUとかw

ARMしか知らんとこういう勘違い平気で口にできたりすんのか。
123：ナイコンさん[sage] 2012/07/06(金) 17:16:35.24: ARM用語でのMPUはMemory Protection Unitの略で
コントローラー向けに使われる簡易版MMUの事。

他にもARM独自略語がふつ～にあるので英文マニュアルを読む時は注意が必要。
日本語訳本も略語等の意味が間違ってる物があるのでマジヤバイ。
124：ナイコンさん[sage] 2012/07/06(金) 17:21:08.39: ARM開発での会話だと「MPUって滅多に叩かなくね?」とか普通に言ってるwww
125 + 1：ナイコンさん[sage] 2012/07/06(金) 18:54:49.55: АРМ
126 + 1：ナイコンさん[sage] 2012/07/06(金) 20:59:48.96: 別にARM用語じゃねぇだろ。
http://www.altera.co.jp/support/examples/nios2/exm-niosii-mpu.html
127：ナイコンさん[sage] 2012/07/06(金) 21:05:47.93: http://japan.renesas.com/products/tools/os/itron/ri600_px/index.jsp
>対応MPU
>MPU(Memory Protection Unit)を搭載したRXファミリ RX600シリーズ

「MPUを搭載したMPU」みたいな会話はしたくないなー。
128：ナイコンさん[sage] 2012/07/06(金) 21:24:27.74: まあ、略語なんてどんなプロセッサにも付きもんだし、
どうと言うこともないと思うが。
129：ナイコンさん[sage] 2012/07/06(金) 21:49:04.64: >>126
最初、ARMが使っちゃったんだと思
その後、ARMコア対抗の奴が皆使い出したwwww

ふつう～避けるでしょ～MPUなんてのはwww
130：ナイコンさん[sage] 2012/07/07(土) 09:50:20.40: >>125
ARM Partner's Meeting
131：ナイコンさん[sage] 2012/07/11(水) 19:48:36.07: МПЮ
132 + 2：ナイコンさん[] 2012/07/19(木) 16:04:47.79: 6502-1MHz=Z80A-4MHz=6809-2MHz
つまり6502は8bit最強ってことだな
133：ナイコンさん[sage] 2012/07/19(木) 16:49:07.43: >>132
6502って実際そんなに速くない。
命令レベルで見ても、同クロックのZ80の4倍に相当する速さの命令なんてほとんどないし、
256バイト超えるテーブル操作とかガクッと効率落ちる。
134 + 2：ナイコンさん[sage] 2012/07/19(木) 17:18:20.64: インデクスレジスタ２本のおかげでシューティングゲームの当たり判定や弾移動は効率よく書けたな
Z80のLD r,(IX+d)は１９クロックだから6502のABS,Xの４クロックはムダがなくて気持ちよかった
135：ナイコンさん[sage] 2012/07/19(木) 17:43:36.51: >6502のABS,Xの４クロックはムダがなくて気持ちよかった

ページ境界超えると+1クロック
136：ナイコンさん[sage] 2012/07/19(木) 17:46:27.61: >>134
ADD命令すらないプロセッサで効率よく書けたもないもんだわ
137：ナイコンさん[sage] 2012/07/19(木) 17:49:40.81: >>134
Z80慣れてるプログラマは、LD r,(IX+d)みたいな遅い命令は積極的には使わない。
138：ナイコンさん[sage] 2012/07/19(木) 19:19:29.47: IX,IYレジスタ使うぐらいならメモリに退避させるわ。
139：ナイコンさん[sage] 2012/07/19(木) 19:22:37.06: レジスタ使えよ
140：ナイコンさん[sage] 2012/07/19(木) 22:21:31.36: インデックスアドレスもどきするためにRAM上にコード置いてjmpしてたな、昔は
141：ナイコンさん[sage] 2012/07/19(木) 23:04:55.25: IX,IYレジスタ使うのと、それ以外のレジスタとメモリ駆使して処理するのとが
メモリ量的にも速度的にも変わらないからな。
142：ナイコンさん[sage] 2012/07/20(金) 00:23:43.22: やっぱ6502信者って底が浅いな
143：ナイコンさん[sage] 2012/07/20(金) 09:44:59.15: ゼロページが足りてる間だけは結構効率が良いと思う
144：ナイコンさん[sage] 2012/07/20(金) 18:57:35.14: IX,IYは無いものと思っている
145 + 1：ナイコンさん[sage] 2012/07/20(金) 19:52:12.10: Z80はIX,IYレジスタ削って16bitのSUB命令入れろ。
146：ナイコンさん[sage] 2012/07/20(金) 21:11:56.77: ALUが4bitなのに無理言うなよ。
147：ナイコンさん[sage] 2012/07/20(金) 22:01:55.67: >>145
そんな事より、メモリアクセスを2クロックサイクルにして
M1サイクルと同じタイミングにすべきだった。
148：ナイコンさん[sage] 2012/07/20(金) 22:26:11.11: >>132
派生CPUはともかくとして、主CPUにしても時期的なものは有るがCLOCKは色々ある。
63C09や、Z80もBやHもある。
6502は速いのあるの?
149 + 4：ナイコンさん[sage] 2012/07/20(金) 23:39:01.26: Z80、今だに現行品なのでZilog公式のCMOS20MHz品(Z84C0020)も買えます。
HD64180ZのZilog版であるZ180も今だ健在です。こっちは33MHzが最高クロック品かな。

6502、B-CASカードにIPが使われている事で話題になりましたが、単体のチップとしてはWestern Design Center版の65C02や65C816は現行品です。
WDCの65C02なら、現行品の高クロック版は14MHz版ですかね。
150：ナイコンさん[sage] 2012/07/20(金) 23:54:09.45: >>149
よく知ってるなぁ、感心するよ
151 + 2：ナイコンさん[sage] 2012/07/21(土) 00:43:23.36: 65C02っちゃ6502のバグ直したやつだから動かない場合あるよね
152 + 1：ナイコンさん[sage] 2012/07/21(土) 13:03:56.82: 複雑さにおいて桁外れのIntelの最新CPUが数年で消えてしまうのが何か虚しいですね
153：ナイコンさん[sage] 2012/07/21(土) 13:47:27.34: >>15
8bitだって似たようなもんだろ。

Z80や6502は現行だが、6809はwwwww
154：153[sage] 2012/07/21(土) 13:55:50.25: あれ?
直しとくぜ!

>>152
8bitだって似たようなもんだろ。

Z80や6502は現行だが、一番複雑な6809はwwwww
155：ナイコンさん[] 2012/07/21(土) 14:03:08.38: 6809って使われてるっしょ
156：ナイコンさん[sage] 2012/07/21(土) 14:13:38.37: Z80はIX/IYが遅いのではなくて、(HL)関連が「相対的に速い」んだよね

LD (IX+d), r が6809や6502での5クロック相当の命令だとすると
LD (HL), r　は6809や6502での2クロック相当の命令だからなぁ
157：ナイコンさん[sage] 2012/07/21(土) 14:23:42.19: メモリアクセスが３クロックでOPコードが４クロックか８クロック使うんだから
ツボにはまった命令やINC rだけでやりくりできる特殊な状況でなければ３～４倍ってのが妥当
ビッグエンディアンの6800は論外
158：ナイコンさん[sage] 2012/07/21(土) 14:43:20.58: 単純なプログラムだと6800>6809だよね
159：ナイコンさん[sage] 2012/07/21(土) 21:27:23.67: 6309E使えば解決。
160 + 1：ナイコンさん[sage] 2012/07/22(日) 06:40:17.19: >>149
知ったか乙
161：ナイコンさん[sage] 2012/07/22(日) 22:57:19.82: ↑ジジイになるとそういうひねくれたレスしか出来なくなるんだね
162：ナイコンさん[sage] 2012/07/22(日) 23:06:59.22: 知ったか乙とか言っとけば気が済むんだから放置しろよ。

>>160 から見て >>149 が本当に知ったかなら、どこがどう知ったかなのか指摘するでしょ。
163：ナイコンさん[sage] 2012/07/23(月) 00:00:24.26: >>149
>6502、B-CASカードにIPが使われている事で話題になりましたが、

6805でしょ。6502とは全然違うよ。
164：ナイコンさん[sage] 2012/07/23(月) 01:24:38.39: >>151
>65C02っちゃ6502のバグ直したやつだから

違うよ
165 + 1：ナイコンさん[sage] 2012/07/23(月) 01:34:13.79: 直したよフラグを
166：ナイコンさん[sage] 2012/07/23(月) 02:15:24.17: >>165
そだね。直したら文句言われたという　orz
167 + 3：ナイコンさん[sage] 2012/07/23(月) 03:58:00.87: >>151
一口に65C02と言ってもWDCとRockwellとで別もんだよ。
168 + 1：ナイコンさん[sage] 2012/07/24(火) 02:20:47.92: そこまで判ってるのに、>151 の意図も判らない？
169：ナイコンさん[sage] 2012/07/24(火) 02:52:47.79: >>168
151「ぼくわバカですウヘヘあーウンコもれちゃったー」

こういうこと?
170：ナイコンさん[sage] 2012/07/24(火) 12:19:27.97: 使ったことないガキは黙ってろ
171：ナイコンさん[sage] 2012/07/24(火) 12:22:31.82: >>167
どっちも6502のバグ修正済み
172：ナイコンさん[sage] 2012/07/24(火) 12:28:49.24: バグ修正ではなく仕様変更
173：ナイコンさん[sage] 2012/07/24(火) 13:07:12.56: 167は何がいいたいの？
174：ナイコンさん[sage] 2012/07/24(火) 13:35:34.16: 理解できないバカがいます
175：ナイコンさん[sage] 2012/07/24(火) 13:40:23.17: >>167
ﾊﾞｰｶ
176 + 1：ナイコンさん[sage] 2012/07/24(火) 23:58:29.91: このごろあちこちで程度の低い奴がごろごろ出てきたな、しかも真っ昼間を中心に。
夏休みも仕方ないもんだ。
177：ナイコンさん[sage] 2012/07/25(水) 00:21:21.92: >>176
ﾊﾞｰｶ
178：ナイコンさん[sage] 2012/07/26(木) 01:31:55.48: バグじゃねーエラッタ
179 + 1：ナイコンさん[sage] 2012/07/26(木) 14:23:13.97: バグって書いてあんじゃん
180：ナイコンさん[sage] 2012/07/26(木) 15:34:03.94: >>179
どこに？
181：ナイコンさん[sage] 2012/07/26(木) 18:41:27.14: そこに
182：ナイコンさん[sage] 2012/07/26(木) 18:44:44.45: そこかよ
183：ナイコンさん[sage] 2012/07/26(木) 19:32:16.51: 大方、Wikipediaかなんかの記述をありがたがってる半可通だろう。
184：ナイコンさん[sage] 2012/07/26(木) 20:16:30.23: >>167
www
185：ナイコンさん[sage] 2012/07/28(土) 11:27:17.25: 爽健美茶のシールの下四桁が6502だった～
186：ナイコンさん[sage] 2012/07/28(土) 12:44:56.45: 最強じゃないか
187：ナイコンさん[sage] 2012/07/28(土) 22:46:26.92: それはうpしないと価値が十分の一になる
188：ナイコンさん[sage] 2012/07/29(日) 06:33:46.49: いらない
189：ナイコンさん[sage] 2012/08/03(金) 22:45:00.92: おう、ジーサン共
暑さでくたばってるんじゃないか
190：ナイコンさん[sage] 2012/08/04(土) 11:45:20.80: ガキが来るところじゃないよ
191：ナイコンさん[sage] 2012/08/04(土) 22:28:35.05: cpuが熱暴走しない程度にエアコンつけとけよ
年寄りに熱中症は命取りだからな
192：ナイコンさん[sage] 2012/08/05(日) 17:48:51.25: ガキが来るところじゃないよ
193：ナイコンさん[sage] 2012/08/08(水) 23:15:35.18: 逝ったらスレに訃報出すように遺言状に書いとけよ
194：ナイコンさん[sage] 2012/08/12(日) 21:47:16.71: 1D SEX
195：ナイコンさん[sage] 2012/08/15(水) 12:43:32.01: もうだんだんNOPばっかになってきて最後にHALTするんでしょ
196：ナイコンさん[sage] 2012/08/19(日) 19:25:38.23: Z80を超えられるものはでなかったな
197：ナイコンさん[sage] 2012/08/21(火) 01:43:18.01: スレチかもしらんが、PPCのEIEIOも好き
198：ナイコンさん[sage] 2012/08/27(月) 01:35:10.11: ゼロのページのアドレスに　今日も修飾吹き荒れる
リフレッシュ無用のザイログに　サイクルスチール見せてやれ
199：ナイコンさん[sage] 2012/08/28(火) 04:58:51.95: 闇に隠れて生きる

俺達ゃ常駐ソフトなのさ

人にコードを見せられぬ

獣のようなこの実装

（割り込みベクタを奪い取れ～！）

ティー！エス！アール！

常駐ソフト
200：ナイコンさん[] 2012/09/17(月) 20:17:13.47: TSRBIOS.SYSってなんぞや？
201：ナイコンさん[sage] 2012/09/18(火) 14:19:17.19: 「プログラムを終了させてシステムに制御を戻すが、そのプログラムはメモリに残しておく」
例：デバイスドライバ、DOSKEY
Terminate and Stay Resident (TSR) 常駐プログラム
Terminate and Stay Resident － Wikipedia
202 + 2：ナイコンさん[] 2012/09/21(金) 00:56:37.48: 同一クロックなら6800はZ80よりも処理が速いの？
203 + 1：ナイコンさん[sage] 2012/09/21(金) 01:06:54.93: >>202
最短実行クロックが

6800 → 2
Z80 → 4

だから、同じクロックで同じような命令なら6800の方が速い。
204 + 1：ナイコンさん[sage] 2012/09/21(金) 01:13:13.90: >>202
Z80よりも遅い
205：ナイコンさん[sage] 2012/09/21(金) 01:14:07.41: >>204
なんで？
206：ナイコンさん[sage] 2012/09/21(金) 01:14:52.79: >>203
なるほど
207 + 3：ナイコンさん[sage] 2012/09/21(金) 01:17:45.28: 6502>6809≧6800＞Z80＞8080
208 + 1：ナイコンさん[sage] 2012/09/21(金) 01:19:07.03: >>207
同一クロックで？
>6502>6809≧6800＞Z80＞8080
209：ナイコンさん[sage] 2012/09/21(金) 01:19:40.55: >>208
同一クロックでそれはおかしい
210：ナイコンさん[sage] 2012/09/21(金) 01:22:04.50: 扱うデータの量にも拠るな。6502は256バイト超えると途端に効率が落ちる。
211：ナイコンさん[sage] 2012/09/21(金) 01:23:43.04: >>207
場合によっては8080＞Z80もありうる。
212：ナイコンさん[sage] 2012/09/21(金) 01:24:22.84: >>207はニワカ
213 + 1：ナイコンさん[sage] 2012/09/21(金) 01:48:30.79: こうか
6502>6809＞6800＞8080＞Z80
214：ナイコンさん[sage] 2012/09/21(金) 01:49:17.81: >>213もニワカ
215：ナイコンさん[sage] 2012/09/21(金) 04:26:44.12: 6800…世界的にパソコンやゲーム機にあまり使われなかった。
　しかし16bit拡張の後継CPUが出ている(68HC12と68HC16)
6809…後継CPUの出なかった残念なCPU

仮に6809の16bit版があったなら、6800の16bit版とどっちが使いたい？
216 + 1：ナイコンさん[sage] 2012/09/21(金) 04:38:28.44: 6800 → 6809
　　　＼
　　　　　68HC11 → 68HC12
　　　　　　　　　　＼
　　　　　　　　　　　　68HC16
217：ナイコンさん[sage] 2012/09/21(金) 04:48:53.64: >6800…世界的にパソコンやゲーム機にあまり使われなかった。
>　しかし16bit拡張の後継CPUが出ている(68HC12と68HC16)

ライバルだった筈の8080は64bit版が出てるってぇのにえらい差ぁついたなｗ
218：ナイコンさん[sage] 2012/09/21(金) 08:25:29.47: >>216
6800系の場合、バイナリ上位互換じゃ無いので水平展開のように見えてしまう…
HC11 = 6800 + Yレジスタ
HC12 = 6809 - Uレジスタ（HC11にポストバイトを設けて命令形態を再設計した感じ）
HC16 = アドレス20bitの独自設計（オペコードマップも大きく異なる）
まあ、PDFでしか見たこと無いけど
219：ナイコンさん[sage] 2012/09/21(金) 11:44:57.84: 6800は16ビットのレジスタ持ってるくせにバカみたいに遅い命令しかなかったな
Z80でLD A,（HL)みたいなことができなくて常に３サイクル浪費しさせられた
子孫のＨＣＳ０８はACCBがなくなってIXが上位と下位に分轄されてマトモなCPUになったが
6809の頃にんな形にしとけばよかったのに
220：ナイコンさん[sage] 2012/09/21(金) 12:23:51.69: 6809もprefixバイトで拡張してるからなぁ、あれがなければもうちっと綺麗だったような。
または逆に大幅に拡張しとけ、って感じでもあったんだが当時はあのへんが色々妥協点だったんだろうね。

モトローラのバスは、設計は美しいような気がするが周辺デバイスとの親和性がいまいち(ファミリーなら問題ないが)
だったから最終的にコストがかかる感じだったんだよね。
そこらへんがメーカーが採用しぶった部分だと思う。

いまとなってはどの8bitCPUが優れてるとかそうじゃないとか、些末なことだな。
年寄りの昔は良かったに近い、思い出だけが増幅される。
221：ナイコンさん[sage] 2012/09/21(金) 12:27:46.36: 集積度か低かった時ならいざ知らず、今時レジスタ分割とか何言っちゃってるんだ？
222：ナイコンさん[sage] 2012/09/21(金) 12:43:13.62: 今時でもオペコードはバイト単位にまとなきゃならんし
割込み時には保存しなきゃならんし
223：ナイコンさん[sage] 2012/09/21(金) 13:22:51.15: オペコードサイズとレジスタ分割に何の関係が？
割り込み時の保存はまあそうだが、集積度活かしてレジスタウィンドとか使えばいいだけでしょ。
224：ナイコンさん[sage] 2012/09/21(金) 17:07:45.96: バイナリ互換ではないがアセンブリ言語レベルでは互換
8008 - 8080 - 8086
6800 - 6809
225：ナイコンさん[sage] 2012/09/21(金) 18:08:43.97: 8008 - 8080 - 8086 - (略) - 80386 - (略) - Sandy Bridge
226 + 2：ナイコンさん[sage] 2012/09/21(金) 18:18:20.43: そこまで書くなら、4004 からにしてやりなよ。
227：ナイコンさん[sage] 2012/09/21(金) 18:20:01.89: >>226
互換じゃないし
228：ナイコンさん[sage] 2012/09/21(金) 18:23:56.07: >>226
4004のアーキテクチャ知ってて言ってる?
http://www.intel.com/Assets/PDF/DataSheet/4004_datasheet.pdf
229：ナイコンさん[sage] 2012/09/21(金) 20:56:10.88: バイナリ互換以外は互換とは認めん
230：ナイコンさん[sage] 2012/09/21(金) 20:58:21.18: 古いバイナリなんて動いても価値無い
231 + 1：ナイコンさん[sage] 2012/09/21(金) 22:46:46.63: んなこたーない
232：ナイコンさん[sage] 2012/09/21(金) 22:48:33.31: >>231
4004のバイナリが今のPCで動いたとして、どういう価値があるのか詳しくPLZ
233：ナイコンさん[] 2012/09/22(土) 01:21:20.42: I4004とI4040は互換性あったよな
234：ナイコンさん[sage] 2012/09/22(土) 02:09:07.39: 当時既にアドレスが16bitでは足りないのが判ってたんなら、MMUなんかにしないで24bitにすればよかったのに。
当然、インデックスレジスタ、スタックポインタは24bit、アキュムレーターは3個にして、三つ繋げて使えるとか。

駄目かな。
235：ナイコンさん[sage] 2012/09/22(土) 02:13:05.24: 3ていうのが2進数に収まり悪いし効率悪いだろ。
236 + 2：ナイコンさん[] 2012/09/22(土) 02:48:56.96: i4004は12bitで4KB
i4004は13bitで8KB
典型的な8bitCPUは24bitで64KB
8086は20bitで1MB
典型的な16bitCPUは24bitで16MB
典型的な32bitCPUは32bitで4GB
典型的な64bitCPUは48bitで256TB
237：ナイコンさん[sage] 2012/09/22(土) 02:49:45.11: i4004は12bitで4KB
i4004は13bitで8KB
典型的な8bitCPUは24bitで64KB
i8086は20bitで1MB
典型的な16bitCPUは24bitで16MB
典型的な32bitCPUは32bitで4GB
典型的な64bitCPUは48bitで256TB
238：ナイコンさん[sage] 2012/09/22(土) 03:51:54.59: >>236
>i4004は12bitで4KB
>i4004は13bitで8KB
>典型的な8bitCPUは24bitで64KB

何言いたいのか分からん
239：ナイコンさん[sage] 2012/09/22(土) 03:53:06.30: >>236
>典型的な16bitCPUは24bitで16MB

「典型的な16bitCPU」ってどんなんよ?
240 + 1：ナイコンさん[sage] 2012/09/22(土) 05:17:19.34: i4004は12bitで4KB
i4004は13bitで8KB
典型的な8bitCPUは16bitで64KB
i8086は20bitで1MB
典型的な16bitCPUは24bitで16MB
典型的な32bitCPUは32bitで4GB
典型的な64bitCPUは48bitで256TB
241：ナイコンさん[sage] 2012/09/22(土) 05:19:49.39: >>240
>i4004は12bitで4KB
>i4004は13bitで8KB

どっちが正しいの?
242：ナイコンさん[sage] 2012/09/22(土) 08:21:19.81: 典型的なﾊﾞｶ
243：ナイコンさん[sage] 2012/09/22(土) 10:21:01.77: スパゲッティ絡まった
244 + 3：ナイコンさん[] 2012/09/22(土) 17:05:07.88: i4004は12bitで4KB
i4040は13bitで8KB
典型的な8bitCPUは16bitで64KB
i8086は20bitで1MB
典型的な16bitCPUは24bitで16MB
典型的な32bitCPUは32bitで4GB
典型的な64bitCPUは48bitで256TB
245：ナイコンさん[sage] 2012/09/22(土) 17:08:07.60: うんこっこ
246：ナイコンさん[sage] 2012/09/22(土) 17:31:12.51: >>244
>典型的な64bitCPUは48bitで256TB

典型的な64bitCPUってDECのAlphaだろ? そんなでかい物理アドレス持ったチップなんてあったかな?
247：ナイコンさん[sage] 2012/09/22(土) 17:33:00.55: >>244
>典型的な16bitCPUは24bitで16MB

典型的な16bitCPUであるTMS9900はそんなにメモリ積めないゾｗ
248 + 1：ナイコンさん[sage] 2012/09/22(土) 21:01:15.78: CPUの擬人化漫画はまだですか？
249：ナイコンさん[sage] 2012/09/22(土) 21:10:55.97: 結局>>244は何が言いたいのかわからない

究極の8ビット機スレによく沸いた
「メインCPUが8008でサブCPUがcore-2」
とかいう内容を延々書き込んでいたバカと同じ匂いがする
250 + 2：ナイコンさん[sage] 2012/09/22(土) 23:19:31.32: >>248
CPUの創り方という本で
251：ナイコンさん[sage] 2012/09/23(日) 08:18:49.51: >>250
名作だよね、一度作ってみたいけど
込み入ってくるとジャンパー飛ばすのがめんどくさそうで
部品集めしたけどまだ手を付けていないのが現実
252：ナイコンさん[] 2012/09/23(日) 10:52:51.21: >>250
買った、読んだ、色々な意味で感動した
Verilog-HDL とやらで FPGA に移植を試みた

初っ端のクロック 1 Hz を作る段階で、虚しくなって頓挫 w
253 + 1：ナイコンさん[sage] 2012/09/23(日) 11:59:53.97: 本文: 渡波郁 (となみかおる)
イラスト: 須田都 (すだみやこ)
…ってペンネーム使い分けてるけど、実は同一人物?

ttp://homepage3.nifty.com/sudamiyako/
254 + 3：ナイコンさん[sage] 2012/09/23(日) 12:23:06.75: 仮に超高クロックの究極8bitCPUが有ったとしても
今時のソフトウェアはFloatだのDoubleだの16bit以上の演算ばかりなので
大したパフォーマンス出ないだろうな
255：ナイコンさん[sage] 2012/09/23(日) 12:32:00.35: >>254
今だとCPUよりGPUの方が重視されそうだしな。
256：ナイコンさん[sage] 2012/09/23(日) 13:21:43.96: FPUとGPU外付すれば。
257：ナイコンさん[sage] 2012/09/23(日) 13:39:57.54: そもそもそんな高パフォーマンスが必要なのか？
258：ナイコンさん[sage] 2012/09/23(日) 13:46:19.99: もちろんないよ
259：ナイコンさん[sage] 2012/09/23(日) 15:07:55.51: >>254
8bitアドレスのCPU作るなら別だけど、8bitCPUだってアドレス演算は16bit以上だからね。
260： ◆0uxK91AxII [sage] 2012/09/23(日) 16:11:38.11: >>253
http://homepage3.nifty.com/sudamiyako/zk/68/jisaku.html
結構アレゲ。
261：ナイコンさん[sage] 2012/09/23(日) 16:17:40.33: >>254
昔のソフトを動かせば良い
262：ナイコンさん[sage] 2012/09/26(水) 20:57:23.10: 8bitCPUに追加するFPUなんてカシオの電卓で十分やで
263：ナイコンさん[sage] 2012/09/26(水) 23:14:29.47: 実際電卓用のLSIを繋げようとした試みはあった。
264：ナイコンさん[sage] 2012/09/27(木) 01:04:19.12: そういや、外付け乗算器とかあったなぁ
265：ナイコンさん[sage] 2012/09/27(木) 02:10:07.58: 8bitようのマスコプロも色々出てたな
266：ナイコンさん[sage] 2012/09/27(木) 17:19:51.64: トランスピュータとか？
267：ナイコンさん[sage] 2012/09/27(木) 23:10:34.06: は？
268：ナイコンさん[sage] 2012/09/28(金) 07:46:06.90: 違ったね。失礼。
269 + 2：ナイコンさん[sage] 2012/09/29(土) 17:37:04.12: そういやWikiのFP-1100の解説でサブCPUは電卓のだとかむちゃくちゃ書いてたな
今見たら差し障りのない解説でつまらん
270：ナイコンさん[sage] 2012/09/29(土) 18:18:38.18: >>269
>そういやWikiのFP-1100の解説でサブCPUは電卓のだとかむちゃくちゃ書いてたな

どの版?
http://ja.wikipedia.org/w/index.php?title=FP-1000&action=history
271：ナイコンさん[sage] 2012/09/30(日) 00:31:23.09: >2CPU構成(メイン Z80互換 4MHz、サブ 4bitマイコン)
これかな？
意味は違うけど
272：ナイコンさん[sage] 2012/09/30(日) 00:35:47.73: >>269
なんだ嘘か。
273：ナイコンさん[sage] 2012/09/30(日) 02:49:52.42: 嘘にしちゃ意図わからんな。履歴見れるのも知らず、適当な伝聞に脚色したのかな

「wikiとはどっかのwikiであってwikipediaとは誰も言っていない」説に切り替えられると予想
274：ナイコンさん[sage] 2012/09/30(日) 06:54:23.03: wwwなるほどwww
275 + 3：ナイコンさん[sage] 2012/09/30(日) 09:04:55.34: Z80も言い方変えれば4bitなんだけどな。
276：ナイコンさん[sage] 2012/09/30(日) 09:11:26.77: >Z80も言い方変えれば4bitなんだけどな。

↑バカ丸出しｗ
277：ナイコンさん[sage] 2012/09/30(日) 09:12:20.46: >>275はALUかなんかのことと勘違いしてると見た
278：ナイコンさん[sage] 2012/09/30(日) 09:15:02.12: >>275
kwsk
279 + 1：ナイコンさん[sage] 2012/09/30(日) 09:19:13.81: まあ○ビットCPU なんて、メーカーが適当につけてるだけだからねぇ。
ちゃんとした定義があるわけでもないし。
280：ナイコンさん[sage] 2012/09/30(日) 09:19:15.15: >>275に言わせるとドリームキャストは128bit
281：ナイコンさん[sage] 2012/09/30(日) 09:20:27.24: >>279
Z80当時はデータバス幅の意味で各社例外なかったと思う
282：ナイコンさん[sage] 2012/09/30(日) 09:29:50.64: インテルが8bit CPUとして販売していた8088を、IBMがPCに採用して16bit PCと言って売ったり、
ナショセミが外部16ビットのNS16032を32ビットアーキテクチャMPUとして売ったりした辺りから
崩れてきた気がする。
283：ナイコンさん[sage] 2012/09/30(日) 10:38:43.99: 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：ナイコンさん[] 2012/09/30(日) 13:34:27.87: Z80も6809も6502も言い方変えれば16bitなんだけどな。
285 + 1：ナイコンさん[] 2012/09/30(日) 16:46:45.64: Wikipediaでこんなん見つけたｗ

FM TOWNS - Wikipedia
http://ja.wikipedia.org/wiki/FM_TOWNS#cite_note-31
> 28. ^ 富士通はかつて8ビットパソコンの時代にもFMシリーズで6800系パソコンの老舗で
> あった日立の独自アーキテクチャのパソコンを消滅に追い込んだ過去を持つ。
286 + 1：ナイコンさん[sage] 2012/09/30(日) 17:07:58.61: >>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 + 1：ナイコンさん[sage] 2012/09/30(日) 17:14:48.86: >>286
> 開発元であるモトローラの定義では16ビットCPUとなる。同社のライバルであったインテルの場合は
> CPU内部の汎用レジスタ長をもってCPUのビット数として取り扱ったが、モトローラではデータバス幅を
> もってCPUのビット数を表現した。

8088は? 68008は?
288：ナイコンさん[] 2012/09/30(日) 17:14:55.76: Wikipediaでこんなん見つけたｗ

FM TOWNS - Wikipedia
http://ja.wikipedia.org/wiki/FM_TOWNS#cite_note-31
> 28. ^ 富士通はかつて8ビットパソコンの時代にもFMシリーズで6800系パソコンの老舗で
> あった日立の独自アーキテクチャのパソコンを消滅に追い込んだ過去を持つ。
289：ナイコンさん[sage] 2012/09/30(日) 17:18:04.42: Wikipediaの注釈書いた奴が発狂してるのか？ｗ
290：ナイコンさん[sage] 2012/09/30(日) 17:50:26.68: マルチポストしてるアホにいちいちかまうなよ。
291：ナイコンさん[sage] 2012/09/30(日) 18:20:11.80: じゃ元祖Pentiumは64bitになるじゃんか
292 + 1：ナイコンさん[] 2012/09/30(日) 20:32:08.06: >>287
モトローラ流で言えばどちらも8bit
293：ナイコンさん[sage] 2012/09/30(日) 20:38:07.80: >>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：ナイコンさん[] 2012/09/30(日) 23:10:18.58: うんこっこ
295：ナイコンさん[] 2012/10/01(月) 21:12:03.87: 288や388は無いのか～
296 + 1：ナイコンさん[sage] 2012/10/01(月) 23:39:29.68: そういや、i80386sxも外部バスは16bit、アドレスバスは24bitだったけど、32ビットって言ってたもんなぁ
297：ナイコンさん[] 2012/10/02(火) 00:28:32.09: 16bitな486

IBM 486SLC、486SX(J) 、Cyrix Cx486SLC
298 + 1：ナイコンさん[sage] 2012/10/02(火) 01:29:34.68: 486はダイナミックバスサイジングができるから8bitも可
299：ナイコンさん[sage] 2012/10/02(火) 01:35:23.60: >>296
ちゃんと32bit「内部」アーキテクチャだと明記している。

http://pdf1.alldatasheet.com/datasheet-pdf/view/226542/INTEL/INTEL386.html
> ■ Full 32-Bit Internal Architecture

286の基板に載せられる386ってコンセプトだから当たり前だが。
300：ナイコンさん[] 2012/10/02(火) 07:38:02.41: >>298
NECがV30後継として8080/Z80互換機能搭載の486を作ってくれたら最強だったのにね。
別に他のメーカーが同様の発想で作っても良かった。
301 + 2：ナイコンさん[sage] 2012/10/02(火) 07:55:42.59: 68000搭載のメガドライブは32bitと言いたいところだが、
外部アドレスバス32bit無いから32bitゲーム機とは言いがたいかも
302：ナイコンさん[sage] 2012/10/02(火) 09:43:26.69: >>301
68000自体は自称でも32bitCPUとは言ってないけどな。
303：ナイコンさん[sage] 2012/10/02(火) 13:23:11.12: >>301
68000は内部16bitのプロセッサだよ。レジスタの幅が32bitあるというだけ。
304：ナイコンさん[sage] 2012/10/02(火) 20:55:19.91: 現在担当のフリースケールはローコスト32bitと言ってるけどな
305：ナイコンさん[sage] 2012/10/02(火) 21:04:06.03: モトローラと違う会社なんだから流儀が違っても不思議はない＞フリースケール
306 + 3：ナイコンさん[sage] 2012/10/02(火) 21:33:56.70: 今の「このCPUはRISCかCISCか」みたいな論争と同様、
「このCPUは16bitか32bitか」なんてほとんど意味ないだろ
外部バス幅がどうとかレジスタ長がどうとかメーカーがこう言ってるとか・・・
307：ナイコンさん[sage] 2012/10/02(火) 21:38:07.58: >>306
意味がないとかあるとか、そんな話誰もしてませんよ？
308：ナイコンさん[sage] 2012/10/02(火) 21:40:41.28: >>306
>今の「このCPUはRISCかCISCか」みたいな論争と同様、

いまどきそんな論争しとるバカなんていないだろ。
309：ナイコンさん[sage] 2012/10/02(火) 21:42:10.24: >>306
>「このCPUは16bitか32bitか」なんてほとんど意味ないだろ

68000や386が現役の頃やそれ以前はマーケティング的な意味があったよ。
310 + 3：ナイコンさん[sage] 2012/10/02(火) 21:44:10.42: 中はデュアルポート32ビットRAMと独立バスのROMだから128bitと呼んでもいいレベル
演算対象がメモリへでも１サイクルで終わるんだから68000の子孫も6809の子孫も大したもんだ
311：ナイコンさん[sage] 2012/10/02(火) 21:46:16.50: >>310
誤爆? つーか電波?
312：ナイコンさん[sage] 2012/10/02(火) 22:06:45.46: >>310
>中はデュアルポート32ビットRAMと独立バスのROMだから128bitと呼んでもいいレベル

せめて何について言及してるんだかくらい書いとけ。
313：ナイコンさん[] 2012/10/02(火) 22:59:43.67: 68000は32bit、メガドライブは32bit、X68000は32bit
、メガドライブにメガCDと32Xを装着すれば、
Z80(8bit)+68000(32bit)×2+SH2(32bit)×2だから
136ビット級だな。
314：ナイコンさん[sage] 2012/10/02(火) 23:07:17.02: >>310
ColdFire+?
315：ナイコンさん[] 2012/10/02(火) 23:17:17.89: 自称16bitのテキサス・インスツルメンツ TMS9900やゼネラル・インスツルメンツ CP1600
、なんか8bitとあまり変わらないような希ガス。外部メモリーアドレス幅は16bit。
8086も64KB以上にアクセスするにはセグメント方式(バンク切り替え機能と言えるか)
でアクセスするから似たようなもんかな。
316 + 2：ナイコンさん[sage] 2012/10/02(火) 23:26:48.21: 8bit CPUよりも16bit CPUの方が意外と種類が少ない感じだね。32bit になると
RISC系が沢山出てくるし。純粋な16bit CPUってもの少数派の感じで、
よく使われている16bit CPUでは8-16bit系(8086、65816)と
16-32bit系(MC68000)って感じだな。
317 + 1：ナイコンさん[sage] 2012/10/02(火) 23:37:37.65: いまDIPで入手可能な一番性能が良いCPUってどれよ
318 + 1：ナイコンさん[sage] 2012/10/02(火) 23:44:28.44: >>316
16bitは中途半端だからな。
アドレス幅が16bitじゃさすがにアレだし24bitとか欲しくなるのが目に見えてるんだから
最初から32bitにしとけって事だ。

>>317
はいはいPIC、PIC
PIC32なら中身はMIPSだし性能的には問題無いだろ
最近、ARMコアのDIP品も出回ってるけどアレはM0だからな～
319：ナイコンさん[sage] 2012/10/02(火) 23:46:36.99: >>318
>PIC32なら中身はMIPSだし性能的には問題無いだろ
サンクス、これから資料集めて読みまくる
320：ナイコンさん[sage] 2012/10/03(水) 02:25:40.18: MIPSってキャリーフラグとかローテートって機能がないんだな
C言語にまったく無い概念だからどうでもいいといえばどうでもいいんだが
321：ナイコンさん[sage] 2012/10/03(水) 02:27:51.46: mipsなんて完全にオワコンのアーキテクチャだったけどな、ライセンスが安いとかあんのかな? いまだに生きてるのが信じられん。
322：ナイコンさん[sage] 2012/10/03(水) 06:21:45.30: >>316
>8bit CPUよりも16bit CPUの方が意外と種類が少ない感じだね。

お前が知らないだけ。
組み込み用途には結構使われてるし種類も多い。最近32bitプロセッサに侵食されてきてはいるけどな。
323 + 1：ナイコンさん[] 2012/10/04(木) 15:35:44.93: >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：ナイコンさん[] 2012/10/04(木) 15:37:29.50: なんだ8080とZ80は4ビットか
325：ナイコンさん[sage] 2012/10/04(木) 16:07:20.03: ノート: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：ナイコンさん[sage] 2012/10/04(木) 16:10:29.50: 8080Aのデータシートのブロック図見るとALUは8ビットっぽいけどね。

http://www.classiccmp.org/dunfield/r/8080.pdf
327：ナイコンさん[sage] 2012/10/04(木) 16:40:42.73: 見やすくするために、4bit ALUの2回回しは省いたんチャウチャウかわいいよね
328：ナイコンさん[sage] 2012/10/04(木) 18:12:13.22: Z80は4bitALU。
設計者の嶋氏の著書マイクロコンピュータの誕生p144で「8ビット構成のALUを4ビットに変更した事によって～」と触れられている。
329：ナイコンさん[sage] 2012/10/04(木) 18:21:30.20: 嶋氏の著書で8080の演算回路についても書かれているが、キャリールックアヘッドってか
プロセス違いによる回路設計上の問題点が主題になってる。
Z80ALU回路について触れられる文章において
「8080Aでは～かなりの面積を無駄にした。こんどは内部～、先に述べた8ビット構成のALUを4ビットに～」と書かれているので
8080Aでは8bitALUである事が推測されるが。

実際の8080チップ写真に置いてもALU部分が8bit処理である事は見て取れるが。
330：ナイコンさん[sage] 2012/10/04(木) 18:25:59.16: >>323
>こんなことはWikiの
>MC68000の項目にもしっかり書かれている事実なわけですよ。

オモロイｗ
331：ナイコンさん[sage] 2012/10/04(木) 18:32:10.79: 1D SEX
332：ナイコンさん[sage] 2012/10/04(木) 20:04:22.33: MC68000はあの巨大なDIPパッケージで他を圧倒するだろ
MC68000と同じ基板に並べたら8086なんてただのICにしか見えん
あのでかさは32bit級と言っても過言ではない
333：ナイコンさん[sage] 2012/10/04(木) 20:17:53.73: 32bitだからでかいってこと別にないけどな
http://akizukidenshi.com/catalog/g/gI-05852/
http://akizukidenshi.com/catalog/g/gI-06071/
334 + 6：ナイコンさん[] 2012/10/05(金) 22:32:56.16: 組込系だ制御系だといいつつプログラムしかしなかったからプロセッサが8ビットだとか16ビットだとか32ビットだとか気にしなかったな。
データやロジックが実装されているストレージに収まるかどうか、処理が時間道理に完了するかどうかのほうが重要だったから。

「おい、処理をあとｎクロック短くしてくれ」だけなら意外に簡単。
『処理をｎクロック短く、かつ、データをｍバイト以下に抑えてスタック消費をｐバイト以下にしろ』とかの複合攻撃だったからなぁ・・・
335：ナイコンさん[sage] 2012/10/05(金) 22:59:37.78: >>334
>組込系だ制御系だといいつつプログラムしかしなかったからプロセッサが8ビットだとか16ビットだとか32ビットだとか気にしなかったな。

アセンブリで組んでなかったんじゃね?
336：ナイコンさん[sage] 2012/10/05(金) 23:02:59.93: >>334
8ビットと32ビットじゃプログラムのチューニングの仕方も結構違うと思うけど、気にしないで
やってけるもんなのか？
337：ナイコンさん[sage] 2012/10/05(金) 23:10:09.57: 最近スレ違いが度を越しているな
誰も8086,Z80,6809,6502の話してないじゃん
組み込みがどうのこうの、なんて話は電気電子板でやれよ。
338：ナイコンさん[sage] 2012/10/05(金) 23:10:37.66: 組み込みって言っても範囲広いからなあ。

ＵＩ周りとかだと、あまりビット数なんて意識しないけど、8bit でリッチな UI と言うのは
あまりないだろうね。

そもそもクロック気にするような状況だと、ビット数というよりプロセサの種別の方が気
になると思うから、>>334 はどう見ても聞きかじりの知ったか君にしか見えない。
339 + 1：ナイコンさん[sage] 2012/10/06(土) 00:24:35.43: Z80に32bit演算の出来るFPUを繋げたら
究極の8bitCPUになれる
340：ナイコンさん[sage] 2012/10/06(土) 00:53:35.74: >>334
プロセッサのアーキテクチャも意識しないでプログラムの最適化なんて大したことできないと思うんだけど、現実の話ですか？
341：ナイコンさん[sage] 2012/10/06(土) 01:15:25.13: >>334
>「おい、処理をあとｎクロック短くしてくれ」だけなら意外に簡単。
>『処理をｎクロック短く、かつ、データをｍバイト以下に抑えてスタック消費をｐバイト以下にしろ』とかの複合攻撃だったからなぁ・・・

ヌルいプログラム書いてっただけの話だろ。
342 + 1：ナイコンさん[] 2012/10/06(土) 02:11:24.56: >>339
つ Z380
343 + 1：ナイコンさん[sage] 2012/10/06(土) 02:19:37.04: >>342
http://www.zilog.com/docs/serial/z380.pdf
> 32-Bit Internal Data Paths and ALU

なんて書いてあるし、8bitCPUじゃねぇだろ。浮動小数点演算も機能としてないみたいだし。
344 + 1：ナイコンさん[sage] 2012/10/06(土) 02:20:47.20: Z800･Z280 24ビットリニアアドレッシング
Z380 24ビットリニアアドレッシング/32ビットリニアアドレッシング
eZ80 24ビットリニアアドレッシング

いずれもZ80上位互換だが、拡張部分はそれぞれ非互換である
345：ナイコンさん[sage] 2012/10/06(土) 02:25:43.55: >>344
>Z800

Z800って実在しないだろ
346 + 2：ナイコンさん[sage] 2012/10/06(土) 02:28:09.11: Z800･Z280 24ビットリニアアドレッシング
Z380 24ビットリニアアドレッシング/32ビットリニアアドレッシング
eZ80 24ビットリニアアドレッシング
R800 24ビットリニアアドレッシング

eZ80はR800の技術を使用しているとか
347：ナイコンさん[sage] 2012/10/06(土) 02:29:19.86: >>343
せやな
348：ナイコンさん[sage] 2012/10/06(土) 02:31:27.24: >>346
>R800 24ビットリニアアドレッシング

MMUで物理アドレス空間が24ビットまで使えるってだけじゃん
349：ナイコンさん[sage] 2012/10/06(土) 02:35:53.12: >>346は「リニアアドレッシング」の意味を理解してない
350 + 2：ナイコンさん[sage] 2012/10/06(土) 02:36:19.12: Z280 20886的拡張で使い難い。遅い。
Z380 32bit扱うにはショボイ。
R800 速い。
eZ80 速い。仮想80モードも搭載。

Z380とR800とeZ80は似ているらしい
351：ナイコンさん[sage] 2012/10/06(土) 02:40:28.27: >>350
>20886的拡張

意味分からん
352：ナイコンさん[sage] 2012/10/06(土) 02:47:33.72: 内容が不確かと評判のWikipediaに

HD64180 - Wikipedia
http://ja.wikipedia.org/wiki/HD64180
> 除算命令を備えている。

と書かれていた。評判通りだな。
353：ナイコンさん[sage] 2012/10/06(土) 06:06:58.05: >>334
>『処理をｎクロック短く、かつ、データをｍバイト以下に抑えてスタック消費をｐバイト以下にしろ』とかの複合攻撃だったからなぁ・・・

コンパイラの出力眺めながら最適なコードを吐くようソースを修正したり、場合によっては
アセンブラで関数書いたりって作業になると思うけど、「プロセッサが8ビットだとか
16ビットだとか32ビットだとか」気にしないでどうやるんだ??

アセンブリレベルの最適化しないにしても、プロセッサによって効率のいい変数のサイズも
違ったりすんのに。
354：ナイコンさん[sage] 2012/10/06(土) 06:12:20.60: >>350
>Z280 20886的拡張で使い難い。遅い。

286的って事?例えが変だろう。
パソコン向けの拡張と言うべき。

速度が期待外れ的に遅いってのがZ280の問題点だが
もし速度が速かったら、今度は16bitアドレスが枷になって、Z80互換CPUの限界を露呈しただろう。
命令セット互換の辛さだな…
355 + 1：ナイコンさん[sage] 2012/10/06(土) 06:20:08.41: インテルは8080用のソースプログラムを8086や80386、現在のSandy Bridgeに至るまで
簡単なコンバータで変換できる機構を用意できてんのにザイログは何馬鹿なことやってんだ?
バイナリ互換なんてパソコンでもない限り必要ないのにな。
356 + 1：ナイコンさん[] 2012/10/06(土) 10:37:56.19: アセンブラとかバイナリ直うちとか、原始時代のお猿さんたちかよｗ
357：ナイコンさん[sage] 2012/10/06(土) 10:54:39.01: >>355
パソコンこそ必要ないだろ
358：ナイコンさん[sage] 2012/10/06(土) 10:55:50.02: ああごめ。
パソコンこそ必要だったわ
素で間違った
359：ナイコンさん[sage] 2012/10/06(土) 11:03:16.34: mipsまだ生きてるみたいじゃんスマホ・タブレット向けにやってる。javaにopengl、mipsと
くればワークステーションの怨念の塊よね、ARMだといまいち怨念が足りない。
360：ナイコンさん[] 2012/10/06(土) 11:20:39.38: >>356
うるせー馬鹿
361：ナイコンさん[] 2012/10/06(土) 12:39:44.94: メガドライブが32ビットになるのさ

メガドライブスーパー32X　CM
http://www.nicovideo.jp/watch/sm717736
362：ナイコンさん[] 2012/10/06(土) 13:43:53.37: ARMってどうにもマイコンって気がするんだよな。
先入観的に。
363：ナイコンさん[] 2012/10/07(日) 17:53:01.16: 組込みなんて動いてナンボな世界だろ。
コロコロ石かえたりすんの？
リスキー過ぎるな
364：ナイコンさん[sage] 2012/10/07(日) 18:04:51.28: コロコロ石変えるなんて誰か言ってる?
365：ナイコンさん[sage] 2012/10/07(日) 20:03:10.04: 誰も言ってないと思う。

ただ、例の震災で石変える羽目になったとかで、いくらか受注案件が増えたよ (w
366：ナイコンさん[] 2012/10/07(日) 21:11:14.51: 色々な石を経験してるとしか思えない書き込みがちらほらあるから。
今の現場はプログラミングリレーからＰＣボードで窓組込７になったんだ。
367：ナイコンさん[sage] 2012/10/07(日) 22:21:06.86: > 色々な石を経験してるとしか思えない書き込みがちらほらあるから。

この板ジジイばっかだから、何十年もやってりゃそりゃ色々経験すんだろ。
368 + 3：ナイコンさん[] 2012/10/08(月) 13:42:17.19: 同じ世代の複数機種を経験するって…
369：ナイコンさん[sage] 2012/10/08(月) 13:59:54.64: 別に普通にあると思うが。
370：ナイコンさん[sage] 2012/10/08(月) 16:33:13.82: >>368
外注でソフト開発する会社なんかだとふつー。
元請けレベルのデカい機器メーカーだと、そうでもないのだろうけど。
371：ナイコンさん[sage] 2012/10/08(月) 16:45:07.86: >同じ世代の複数機種を経験するって…

普通じゃね? つーかそれぐらい対応できんとその道でメシ食えないだろ。
372：ナイコンさん[] 2012/10/08(月) 16:58:31.75 BE:622257825-BRZ(10002: 柔軟に他機種でアセンブルプログラミングできないとね。
373：ナイコンさん[sage] 2012/10/08(月) 17:13:37.86: まあ組み込み系だと珍しくないわな。

業務系だと、それこそ 30年間 COBOL 一筋の COBOLER とか VB しかやったことない
VBer とかがいたりしたけど。
374：ナイコンさん[sage] 2012/10/08(月) 17:15:59.54: >>368
いままでどういうのやってきたかちょろっと書いてみ?
375：ナイコンさん[sage] 2012/10/08(月) 17:38:30.14: 釣れますか？　>>368
376 + 2：ナイコンさん[sage] 2012/10/08(月) 17:45:22.78: PCやゲーム機が8bitだった時代はどうやってソフト開発したんだ
ROM BASIC使わずマシン語で高速に実行したい場合
FORTRANやC言語などのコンパイラとかあったの？
それとも全部人間がアセンブリ言語で作っていたのか
377：ナイコンさん[sage] 2012/10/08(月) 18:00:31.99: >>376
>FORTRANやC言語などのコンパイラとかあったの？

あった。

>それとも全部人間がアセンブリ言語で作っていたのか

こっちの方が主流。
378：ナイコンさん[sage] 2012/10/08(月) 19:01:23.20: ↑釣られるなよ
379：ナイコンさん[sage] 2012/10/08(月) 19:22:50.72: >↑釣られるなよ

意味分からん。当たり前の事実しか書かれていないが？
380：ナイコンさん[sage] 2012/10/08(月) 20:40:27.54: まあこんな閑静なスレだから、釣り宣言も釣られたレスも枯れ木の賑わいだろ
381：ナイコンさん[] 2012/10/09(火) 08:01:01.87: ITどかた上がりのじい様たちが集う枯れ木山だね。
382 + 2：ナイコンさん[sage] 2012/10/09(火) 22:54:55.86: >>376
今は効率的なコンパイラとコンパイラに合わせたcpuがあるけど、当時は下手にコンパイルするより
人間が組んだ方が速かったもんなぁ。
そのノウハウがいまのコンパイラに注ぎ込まれてるから、今は下手にニーモック書くよりコンパイラ通した方が速いし。
383：ナイコンさん[sage] 2012/10/09(火) 23:03:55.58: >>382
>今は下手にニーモック書くよりコンパイラ通した方が速いし。

ホントに下手糞が書いた場合よりはな。
384 + 1：ナイコンさん[sage] 2012/10/10(水) 01:56:29.92: BDS Cはなかなか速かった。
Lattice C 1.xは糞だった
385：ナイコンさん[sage] 2012/10/10(水) 02:28:06.04: >>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：ナイコンさん[sage] 2012/10/10(水) 03:17:11.17: >>382
> 今は下手にニーモック書くよりコンパイラ通した方が速いし。

いまでもちゃんと効率考えて組めばコンパイラの吐いたコードなんかよか早いもん組めるよ。

いまどきのプロセッサで極限まで高速化するにはキャッシュやパイプラインやストールの
原因なんかを意識しないといけないんでけっこうしんどいけど。
387 + 2：ナイコンさん[sage] 2012/10/10(水) 03:39:05.92: >今は下手にニーモック書くよりコンパイラ通した方が速いし。

↑こーゆーこと訳知り顔で語る奴は大抵の場合分かってない
388：ナイコンさん[] 2012/10/10(水) 08:54:22.03: 95年ぐらいまでのコンパイラが吐くより効率の良いコード書けるが21世紀になってからのは太刀打ちできねーな。

元より今時のプロセッサ相手にアセンブラとか無駄なことはしないけど。
389 + 1：ナイコンさん[] 2012/10/10(水) 09:24:11.47: >>387はAVRとかPICとかのセルフコンパイラーとアセンブラ比べたりしてんのかな？
390：ナイコンさん[sage] 2012/10/10(水) 11:06:06.25: まあ1バイト単位でｶﾞﾘｶﾞﾘ削ったりしないしな。
当然速度も十分速いし。
391：ナイコンさん[sage] 2012/10/10(水) 12:51:17.36: >>389
>>>387はAVRとかPICとかのセルフコンパイラーとアセンブラ比べたりしてんのかな？

AVRやPICにセルフコンパイラなんてある? ちょっと想像できん。
392：ナイコンさん[sage] 2012/10/10(水) 14:42:53.20: 言葉の意味分かってないんじゃないかな。
393：ナイコンさん[] 2012/10/10(水) 18:26:19.57: 仕事なら１バイト削らなきゃ仕様を満たさないとなれば削るが、んな馬鹿馬鹿しいことはやらないし。
ページャーぐらいしかンな経験ないな。
394 + 2：ナイコンさん[sage] 2012/10/11(木) 17:12:21.63: 月間マイコン1986/05のT-TIMEインタビュー記事で
デーモンクリスタルってゲームを作ったプログラマーの人が
「MZ-1500でコンパイラ使ってる」って書いてたな。
GAMEか何かだとは思うけど、まぁアセンブラ絶対主義ってのもな…
395：ナイコンさん[sage] 2012/10/11(木) 17:42:00.13: >まぁアセンブラ絶対主義ってのもな…

誤爆？
396：ナイコンさん[sage] 2012/10/11(木) 18:00:03.65: >>394
>まぁアセンブラ絶対主義ってのもな…

何関係ない話してんの？
397：ナイコンさん[sage] 2012/10/11(木) 18:05:03.05: >>394
当時の市販ソフトで、BASICで組まれたのやなんらかのコンパイラ使用を謳ったソフトなんて珍しくなかったけど、知らんの？

つーか何言いたいのか解らん。
398：ナイコンさん[sage] 2012/10/11(木) 18:15:57.62: 最適化の話をしてる人を見るとアセンブラ絶対主義者に見える病気の人では？

要求される条件に従い実行効率や開発効率を考慮してアセンブラでもコンパイラでもインタプリタでも使い分けれればいいってだけの話だけどね、頭悪い人なんだろうな。
399：ナイコンさん[] 2012/10/11(木) 19:05:30.79: まあ極限の世界で闘えるのはアセンブラだけやな
400：ナイコンさん[sage] 2012/10/11(木) 19:06:52.91: そんなことはない
401：ナイコンさん[sage] 2012/10/11(木) 19:07:33.61: >極限の世界で闘えるのはアセンブラだけ

↑こーゆーこと訳知り顔で語る奴は大抵の場合分かってない
402：ナイコンさん[sage] 2012/10/11(木) 19:12:14.49: 使えないヤツの書くコードはムダだらけ
403：ナイコンさん[] 2012/10/11(木) 21:07:28.12: 今どきアセンブラにこだわる奴が使える奴とは思えないわな～
おまけにアセンブラーが威力発揮せるようなプアな環境なんて使い物にならんし。
30年前はともかくｗ
404：ナイコンさん[sage] 2012/10/11(木) 21:18:24.51: ゲームやら組み込みやら、動作環境のパフォーマンス引き出さな商売ならんこともあるの知らんのね。
405：ナイコンさん[sage] 2012/10/11(木) 21:20:46.76: >今どきアセンブラにこだわる奴が使える奴とは思えないわな～
>おまけにアセンブラーが威力発揮せるようなプアな環境なんて使い物にならんし。

いまだに使われてるちっこい組み込み用のマイコンとか想像もつかんのだろうな
406：ナイコンさん[sage] 2012/10/11(木) 21:23:32.37: >今どきアセンブラにこだわる奴が使える奴とは思えないわな～
>おまけにアセンブラーが威力発揮せるようなプアな環境なんて使い物にならんし。
>30年前はともかくｗ

JavaかVBしか知らんようなニワカが言いそうなセリフだなｗ　釣りとしてはよく出来てる。
407：ナイコンさん[sage] 2012/10/11(木) 22:04:15.84: 最初は30年前のこと言っていて、途中から現代の話かよ

年寄りってのは話がむちゃくちゃで、憑いていくのが大変だな
408：ナイコンさん[sage] 2012/10/11(木) 22:12:40.77: アセンブラなんて選択肢のひとつでしかないのに、端っから否定するような奴にできる仕事なんてたかが知れてるだろ。
409 + 1：ナイコンさん[] 2012/10/11(木) 22:37:36.29: 組み込みだってずいぶん前からクロス開発当たり前だし、アセンブラー使わなきゃならないなんて案件は絶無だけどね。
たいていは言語仕様的に書けないような部分をインラインアセンブラで書くぐらいだな。

隠居爺の脳内歴史じゃ違うのかもしれんが。
410：ナイコンさん[sage] 2012/10/11(木) 22:51:39.34: >組み込みだってずいぶん前からクロス開発当たり前だし、

それ以前はセルフ開発が当たり前だったみたいな言い方だなｗ
411：ナイコンさん[] 2012/10/11(木) 22:53:47.14: AMD64でアセンブル、やる気の起こるハードが無い
412 + 1：ナイコンさん[sage] 2012/10/11(木) 22:54:04.51: アセンブリ使わなければ要求する性能を達成できないというなら
コンパイラで書いても十分な性能を達成できるハードウェアに変更するし

コンパイラで書いて十分な性能が出ているものを、さらに効率化するため
とか言ってアセンブリで書こうとするような奴はプロジェクトから叩き出すし

大昔の、しょぼいプロセッサに狭いメモリしか無かった時代に
それ以上のものを求めても手に入らなかったから仕方なく書いていたならともかく、
デバイスドライバや割り込み・メモリマネージャまでCで書く時代が
いったい何十年続いてると思ってるんだか、あるいはそれを知らないのかしらんが、
21世紀の今頃になってアセンブリ最強とか言ってる奴は頭どうかしてる
413 + 3：ナイコンさん[sage] 2012/10/11(木) 22:56:29.38: えらそうに「コンパイラが吐くコードを意識しながらコーディングするんだ」とか言ってた奴らも、
実際はそんなことできていなかった。
口プロレスでこういう事ほざく奴に限って、能力はたいした事のない口だけ野郎だったしなー
414：ナイコンさん[sage] 2012/10/11(木) 22:57:49.59: 使わないと使えないの区別ができないバカ
415：ナイコンさん[sage] 2012/10/11(木) 22:59:15.84: >>413
職場のレベルの低さを自慢してどうすんの?
416：ナイコンさん[sage] 2012/10/11(木) 23:01:25.36: >>412
>アセンブリ使わなければ要求する性能を達成できないというなら
>コンパイラで書いても十分な性能を達成できるハードウェアに変更するし

家庭用ゲームとかでも同じことできる？

>コンパイラで書いて十分な性能が出ているものを、さらに効率化するため
>とか言ってアセンブリで書こうとするような奴

なんでプロジェクトに基地外がいるの？
417 + 1：ナイコンさん[] 2012/10/11(木) 23:03:37.25: C++のコードをアセンブラレベルで効率的に書き直せるのかな？
418 + 1：ナイコンさん[sage] 2012/10/11(木) 23:08:08.10: >>417
ループの内っ側や末端の関数なら大した手間ではないし効果も期待できることもある
419：ナイコンさん[sage] 2012/10/11(木) 23:47:16.60: アセンブラ最高
アセンブラは大人のたしなみ
420：ナイコンさん[sage] 2012/10/11(木) 23:57:29.48: 小生も最近物忘れが目立ってきたのでボケ防止のためにアセンブリ
421 + 2：ナイコンさん[] 2012/10/12(金) 00:04:15.33: >>418

万とか億とかの単位で単純ループするとか？
もしそんな事があるなら、言語以前の問題でわないかと…
422：ナイコンさん[sage] 2012/10/12(金) 00:04:33.77: アセンブラ
アセンブリ
アセンブル
アセンブレ
アセンブロ
423：ナイコンさん[sage] 2012/10/12(金) 00:17:57.93: 昔のPC板で「21世紀」とか何を言っているんだか。
21世紀とは永遠に訪れない夢のような未来。
424 + 1：ナイコンさん[sage] 2012/10/12(金) 00:20:09.36: >家庭用ゲームとかでも同じことできる？

家庭用ゲームのプログラマーなんて、底辺中の底辺じゃねーか
しかも今はメーカー・ミドルウェア開発（こっちはエリート）と
アプリケーション（消費者向け製品）のプログラマは完全に階層が別れてる
425：ナイコンさん[sage] 2012/10/12(金) 00:33:57.91: >>421
>万とか億とかの単位で単純ループするとか？

1万回ループするなんて全然珍しい話ではないけど何言ってんの???
426：ナイコンさん[sage] 2012/10/12(金) 00:34:34.57: わずか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 + 3：ナイコンさん[sage] 2012/10/12(金) 00:35:03.53: ループ内処理をアセンブリにして小手先で効率化するくらいなら
ループ展開しちゃった方がたぶんずっと楽になるよね（メモリは喰うけど）
428：ナイコンさん[sage] 2012/10/12(金) 00:35:34.46: >>424
>しかも今はメーカー・ミドルウェア開発（こっちはエリート）と
>アプリケーション（消費者向け製品）のプログラマは完全に階層が別れてる

実際そんなにミドルウェア製品なんて使われないぞ? ゲーム関係で仕事したことあんの??
429：ナイコンさん[sage] 2012/10/12(金) 00:36:37.90: >>427
いまどきのプロセッサはループ展開すると速くなるって単純なもんでもなかったりするよ
430 + 2：ナイコンさん[sage] 2012/10/12(金) 00:39:57.73: プレステ3のようにハードウェア設計者側のオナニーで扱いにくい構成にしてしまった結果
効率的なミドルウェアの開発に失敗して、アセンブリ使わないと性能を発揮できない糞ハードが
なぜか21世紀の10年期をまたいで存在してしまっているけど、そのくらいへぼい、最低の環境でもないと
いまどき「家庭用ゲームのプログラマー」はアセンブリなんか使わないよ

10年くらい前なら、CPU側でSIMD命令を使った処理を書くのにアセンブリしか無かった
みたいな事情はあったけど、それも今ではGPUに丸投げする時代だしねえ
モダンなGPUでは命令は中間コードで持っていて（これ自体をコンパイラが吐くわけだけど）、
それをデバイスドライバ内に持ったJITコンパイラでさらに機械語に変換して食わせてるわけで。
最も処理の効率化が求められ、その見返りも大きなGPU内の処理でさえ、こんな有り様なんだよね。

MS-DOSで頭が止まっているような怠惰なオッサン連中には、想像もつかない世界だったかもしれないね。
ちょっと残酷なことをした。
431：ナイコンさん[sage] 2012/10/12(金) 00:41:08.33: >>427
ループ内処理をアセンブリ化するのと、ループ展開は全然別の話じゃん。
それに、ループ展開で効率化すんならアセンブリ化の際に当たり前にやってるだろ。
432：ナイコンさん[sage] 2012/10/12(金) 00:41:16.56: >いまどきのプロセッサはループ展開すると速くなるって単純なもんでもなかったりするよ

キャッシュを無駄に食いつぶしちゃうからね。
それに、いまどきループ処理で無駄なコードを吐くようなコンパイラも、ごみだ。
433 + 1：ナイコンさん[sage] 2012/10/12(金) 00:42:26.58: >実際そんなにミドルウェア製品なんて使われないぞ? ゲーム関係で仕事したことあんの??

いまどき碌なミドルウェアもないゲーム機なんて、SONYの据え置き機くらいしかないぞ？
ゲーム関係で仕事したこと、ないよね？
434：ナイコンさん[sage] 2012/10/12(金) 00:42:30.20: >>430
>プレステ3のようにハードウェア設計者側のオナニーで扱いにくい構成にしてしまった結果
>効率的なミドルウェアの開発に失敗して、アセンブリ使わないと性能を発揮できない糞ハードが
>なぜか21世紀の10年期をまたいで存在してしまっているけど、そのくらいへぼい、最低の環境でもないと
>いまどき「家庭用ゲームのプログラマー」はアセンブリなんか使わないよ

なんだ現代の話じゃん。何必死に否定してんの？
435 + 1：ナイコンさん[sage] 2012/10/12(金) 00:44:46.27: 最低の例外くらいしか存在しない、って話してやってるのに、なにを一般化して語ってんの？
それにゲーム本体のプログラマはアセンブリなんか書かないし、書けないよ。
436 + 1：ナイコンさん[sage] 2012/10/12(金) 00:45:39.49: じゃあなんだ、アセンブラ使ってると思ってる連中は、いまだにゲームのプログラムではアセンブラで直接ハードウェアを叩いてると思っているわけかｗ
437：ナイコンさん[sage] 2012/10/12(金) 00:45:39.79: >>433
>いまどき碌なミドルウェアもないゲーム機なんて、SONYの据え置き機くらいしかないぞ？

任店のはライブラリってレベル
438：ナイコンさん[sage] 2012/10/12(金) 00:46:39.05: >>436
必要があればアセンブラも使うけど何か？
439：ナイコンさん[sage] 2012/10/12(金) 00:51:05.51: 素人でも分かりやすい例だと8bitのPICなんかだとコンパイラで組んだ場合とアセンブラでの場合とで速度やサイズが段違いだから今でも全然アセンブラ有利だけどな。
まあ、ここ数年でPICの上位シリーズが随分伸びてるんで8bitにこだわる理由もなくなっては来てるが。
440：ナイコンさん[sage] 2012/10/12(金) 00:54:16.76: >>421
億は兎も角、万ならそんな驚く話ではないな。
441 + 1：ナイコンさん[sage] 2012/10/12(金) 00:54:38.32: いまだに8bitなんか使ってるような底辺・小規模の組み込み系くらいだろ
それもブートストラップの一部だけどうしても（CPUがマイナーすぎてコンパイラが対応してないから）アセンブリで書かないと通らない
みたいなニッチな事情で。
442：ナイコンさん[sage] 2012/10/12(金) 00:56:47.40: >>435
>それにゲーム本体のプログラマはアセンブリなんか書かないし、書けないよ。

ゲーム本体のプログラムが全てとでも言いたげだなﾜﾛﾀｗ
443：ナイコンさん[sage] 2012/10/12(金) 00:59:27.13: >>441
>いまだに8bitなんか使ってるような底辺・小規模の組み込み系くらいだろ

いまだに数が一番多い分野じゃん。馬鹿なの？
444：ナイコンさん[sage] 2012/10/12(金) 02:30:55.44: ファミコンのゲームソフトも職人がコード書いてハードの限界を追求したんだろうな
445：ナイコンさん[sage] 2012/10/12(金) 02:46:19.68: 6502の職人で有名どころだと岩田とかナーシャジベリとかか
まあ岩田が限界に挑戦したって言ってるところ話は想像つかんけど
446：ナイコンさん[sage] 2012/10/12(金) 02:48:43.31: いまでもパチンコ/パチスロの当たり制御は保通協の関係でアセンブラなんじゃないかな。
447：ナイコンさん[sage] 2012/10/12(金) 03:08:00.69: >>413
コンパイラの出力見てソースの書き方考えるって普通のことじゃん。
448：ナイコンさん[sage] 2012/10/12(金) 03:19:21.59: >>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：ナイコンさん[sage] 2012/10/12(金) 03:29:25.39: >>413
>えらそうに「コンパイラが吐くコードを意識しながらコーディングするんだ」とか言ってた奴らも、
>実際はそんなことできていなかった。
>口プロレスでこういう事ほざく奴に限って、能力はたいした事のない口だけ野郎だったしなー

じっさいそういう必要があるからVTuneみたいなツールも存在するわけだが。
450：ナイコンさん[sage] 2012/10/12(金) 04:25:57.53: >>427
ループ展開するとキャッシュヒットが減ることがあるのであんまし薦められない
キャッシュに入れば爆速に出来るが外れると速度が落ちる
後、分岐予測でミスが出にくくなる必要もあるだろう
ある程度短くブロック分けして、サブルーチンにする所とただのループとベタ展開を使い分ける事が大事じゃないかな
451：ナイコンさん[sage] 2012/10/12(金) 04:35:40.41: 塵も積もれば山となる
標準関数なんか激遅だから気をつけろよ
452：ナイコンさん[sage] 2012/10/12(金) 04:52:02.67: >>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：ナイコンさん[sage] 2012/10/12(金) 05:33:32.36: ( ´－｀) .｡oO（なんでみんなそんなに必死なんだろう・・）
454：ナイコンさん[sage] 2012/10/12(金) 05:46:40.54: 分からないものを無理に理解しようとしなくていいし、知らないものを必死に否定しなくとも良い。
455：ナイコンさん[sage] 2012/10/12(金) 05:55:05.18: >標準関数なんか激遅

場合に拠る
456：ナイコンさん[] 2012/10/12(金) 07:21:24.68: OSやデバドラでなきゃアセンブラ使わないのは何年も前からの常識だよ。
そういう極一部のニーズが全てにあてはまるとか思うのは勝手だけど、世間の非常識だって理解しような。
457：ナイコンさん[sage] 2012/10/12(金) 07:27:44.01: 自分の知らん世界のことは非常識と思える頭は幸せだヌーン
458：ナイコンさん[sage] 2012/10/12(金) 07:30:46.39: >そういう極一部のニーズが全てにあてはまるとか思うのは勝手だけど、

誰も言ってもいないことを喚き始めたかｗ
459：ナイコンさん[sage] 2012/10/12(金) 07:43:22.01: >OSやデバドラでなきゃアセンブラ使わないのは何年も前からの常識だよ。
>そういう極一部のニーズが全てにあてはまるとか思うのは勝手だけど、世間の非常識だって理解しような。

十年前、二十年前に作られていまだに稼動してるシステムなんてゴマンとあんのに、
プログラムの保守とか想像したこともないんだろうなあ。
460：ナイコンさん[sage] 2012/10/12(金) 09:09:02.83: Visual Studioにアセンブラが入ってるのも非常識とか言いそう
461：ナイコンさん[sage] 2012/10/12(金) 09:22:09.51: コンパイラの出力コードを手直しすればいいだけなのでコンパイラに負ける事はほぼ有り得ない
想定と実環境が大きく異なったときにたまたま負ける可能性はある
462：ナイコンさん[] 2012/10/12(金) 10:19:20.02: プレイステーション系のゲーム機はアセンブリでガリガリ書かないと
パフォーマンスを発揮しない。
463：ナイコンさん[sage] 2012/10/12(金) 10:42:04.48: プレステ２でゴリゴリ書いてみたい^^
464：ナイコンさん[sage] 2012/10/12(金) 10:48:49.48: 64bitOS開発やったときはアセンブラの読解力は必須だったよ。
ソースはメモリーコピー部分以外Cだったけど。
465：ナイコンさん[sage] 2012/10/12(金) 11:04:17.11: 高級言語を扱う場合でも
パッケージに入ってるDLLがｸｿな場合、
機械語を見てバグの当たりをつけて
メーカーにねじ込む目的でVSのアセンブラは使うけどな。

まあ、書いたりはしない。
466：ナイコンさん[sage] 2012/10/12(金) 12:31:01.18: 知って損は無い言語。
467：ナイコンさん[] 2012/10/12(金) 21:34:49.61: 損はしないが役に立つこともあまりないな。
468 + 1：ナイコンさん[sage] 2012/10/12(金) 22:02:57.69: ここ昔のPC板だぜ？
アセンブラを語るんなら、今現在アセンブラが役立つか、じゃなくて
8bit機や、ごく初期の16bit機でのアセンブラの意義を語るべきだと思うんだが。

今のこのスレには当時のアセンブラ経験者なんて居なさそうだな。
469：ナイコンさん[sage] 2012/10/12(金) 22:08:25.33: >>468
いるよﾉｼ
470：ナイコンさん[sage] 2012/10/12(金) 22:18:33.99: 当時のアセンブラは経験ないな。
なんせアセンブラがなかったからな。
ハンドアセンブル。

(なかった=一般人は入手困難って意味)
471 + 2：ナイコンさん[] 2012/10/12(金) 22:59:08.39: 8-bit CPUでC言語を使う会
472：ナイコンさん[] 2012/10/12(金) 23:10:08.07: ベーマガだかザベだかに自作アセンブラを投稿してた人もいたよな。
DOSのTASMとかならそれなりに経験者いるんでないかい。

俺はCP/MのASM使ってたけど。
473：ナイコンさん[sage] 2012/10/12(金) 23:18:54.35: レジスタやアドレスを意識しなくていいIntrinsicsだけどSSEやAVX使うならアセンブラ必須
欲しい命令があちこちで抜けてるIntelのバカアーキテクチャは最低だぜ
474：ナイコンさん[sage] 2012/10/12(金) 23:39:12.72: >>471
MSX-DOSの？
475：ナイコンさん[sage] 2012/10/13(土) 00:23:19.08: >>471
BDS-Cはまあまあ使えた。
当時としてはコンパイルが軽かったのと、実行効率が低すぎてはなかったギリギリのバランスだった。
476：ナイコンさん[sage] 2012/10/13(土) 00:25:02.37: FMのDOH-CやDraco-Cを使ってた人の感想が聞きたい
477：ナイコンさん[sage] 2012/10/13(土) 00:34:48.54: >467
役に立たせるだけの知能がないだけだろ。
478：ナイコンさん[sage] 2012/10/13(土) 00:40:01.16: 自分がそうだから他人も含めて世の中世間の全てはそうだと思ってるおめでたい頭の奴に何か言ったところで無駄
479：ナイコンさん[sage] 2012/10/13(土) 03:35:00.31: 下駄
480：ナイコンさん[sage] 2012/10/13(土) 05:19:41.03: 6809と6502ってどう違うの？
両方ともよく知らないもので
481：ナイコンさん[sage] 2012/10/13(土) 05:32:08.85: 6809は6502に比べて307大きい
482：ナイコンさん[sage] 2012/10/13(土) 06:27:33.58: 307命令追加されているって事でイイの？
483 + 7：ナイコンさん[] 2012/10/13(土) 06:41:39.84: そういや、CPUの特性にあわせたアルゴリズムで最大性能ひきだせるとか言ってたバカが居たな。
CPUの特性にあわせた実装するとかならわかるが。
484 + 2：ナイコンさん[] 2012/10/13(土) 06:51:37.52: 組込みの仕事の何パーセントがアセンブラー必須なんだ？
100？
99？
アセンブラ使わないのは組込みでわありませんw

朦朧爺の妄想垂れ流しww
485：ナイコンさん[sage] 2012/10/13(土) 06:59:00.54: >組込みの仕事の何パーセントがアセンブラー必須なんだ？
>100？
>99？
>アセンブラ使わないのは組込みでわありませんw
>
>朦朧爺の妄想垂れ流しww

↑ちょっと何いいたいのか分からん
486：ナイコンさん[sage] 2012/10/13(土) 07:02:39.59: > 組込みの仕事の何パーセントがアセンブラー必須なんだ？
> 100？
> 99？
> アセンブラ使わないのは組込みでわありませんw

これは>>484の主張? それとも朦朧爺の妄想?

解釈次第で主張が180度変わる投稿を平気でする>>484は馬鹿だと思う。
487：ナイコンさん[sage] 2012/10/13(土) 07:05:09.47: >>483
乗除算の機能のないCPUで、乗除算を使わないアルゴリズム(実装でなく)を使用した経験ならあるが?
488 + 1：ナイコンさん[sage] 2012/10/13(土) 07:16:41.21: >>483
前スレの>>474-561みてみれ
489：ナイコンさん[sage] 2012/10/13(土) 07:18:25.53: >>483
>そういや、CPUの特性にあわせたアルゴリズムで最大性能ひきだせるとか言ってたバカが居たな。
>CPUの特性にあわせた実装するとかならわかるが。

バカはお前じゃね？
490：ナイコンさん[sage] 2012/10/13(土) 07:20:13.57: バカども同士、仲良くね
491：ナイコンさん[sage] 2012/10/13(土) 07:20:38.71: >>483
>>484
同じ奴？
492：ナイコンさん[sage] 2012/10/13(土) 07:32:13.30: >>483
Z80と6809で、特性にあわせたアルゴリズムで最大性能をひきだそうとした例

8086 vs. Z80 vs. 6809 vs. 6502　その7
http://logsoku.com/thread/ikura.2ch.net/i4004/1319314159/474-561n
493：ナイコンさん[sage] 2012/10/13(土) 08:00:41.81: >>483
> そういや、CPUの特性にあわせたアルゴリズムで最大性能ひきだせるとか言ってたバカが居たな。
> CPUの特性にあわせた実装するとかならわかるが。

DDAとか知らない世代かしら?
494 + 5：ナイコンさん[] 2012/10/13(土) 08:07:38.34: LZH圧縮をCPUにあわせたアルゴリズムで～と言ってた奴。
LZH圧縮てか、ハフマン符号化とかスライド辞書とかのアルゴリズムはCPU関係ないしょ？

DDA？
495：ナイコンさん[sage] 2012/10/13(土) 08:14:56.68: >>494
> LZH圧縮てか、ハフマン符号化とかスライド辞書とかのアルゴリズムはCPU関係ないしょ？

V30みたいなビットフィールド操作命令が使えるCPUだと便利かもね。
496：ナイコンさん[sage] 2012/10/13(土) 08:21:07.82: >>494
>LZH圧縮てか、ハフマン符号化とかスライド辞書とかのアルゴリズムはCPU関係ないしょ？

ハフマン木やLZSSの辞書の表現はCPUの特性を考慮すべきだな。
497：ナイコンさん[sage] 2012/10/13(土) 08:31:01.03: >>483
>そういや、CPUの特性にあわせたアルゴリズムで最大性能ひきだせるとか言ってたバカが居たな。

仮にLZHのことだとして、

・圧縮率
・圧縮速度
・圧縮時のメモリ使用量
・展開速度
・展開時のメモリ使用量

性能って上の5つぐらいで評価できると思うけど、そりゃCPUの特性に合わせて何を重視するかで
アルゴリズムなんて当たり前に変わってくるだろ。確かDOS版のLhaでも何種類かの圧縮形式
サポートしてたぞ。
498：ナイコンさん[sage] 2012/10/13(土) 08:39:29.55: >>494
>LZH圧縮てか、ハフマン符号化とかスライド辞書とかのアルゴリズムはCPU関係ないしょ？

LZH自体、当時の16ビットプロセッサ用に最適化された実装だと思うけどね。
499：498[sage] 2012/10/13(土) 08:41:07.76: 訂正

実装→仕様
500：ナイコンさん[sage] 2012/10/13(土) 09:45:01.14: >>494
>LZH圧縮てか、ハフマン符号化とかスライド辞書とかのアルゴリズムはCPU関係ないしょ？

どうだろ？
Lha当時のPCといまどきのPC比べても、いまどきのPCはCPUが速くなった程度には
メモリの方は速くなってないから、「最大性能」目指すなら、アルゴリズムがいくらか
複雑になってもメモリアクセス減らす工夫したりすんのは有効だったりすんじゃないの。
501 + 1：ナイコンさん[sage] 2012/10/13(土) 10:28:07.11: アルゴリズムはCPUのアーキテクチャに左右されると思うぞ。
たとえばZ80のパソコンが全盛期だった頃、
乗除算命令が当たり前のように実装されていたら
画面に斜めの直線引くのにBresenhamのアルゴリズムなんか使わずに
乗除算命令を使う奴が大多数を占めていたと思う
502：ナイコンさん[sage] 2012/10/13(土) 10:32:56.61: メモリアクセス減らすって、レジスタだけで圧縮演算するんすか！？
503：ナイコンさん[sage] 2012/10/13(土) 10:39:52.36: 一旦ハッシュ値計算しておいて辞書の検索に使ったりすんのは有効かもね。
504：ナイコンさん[sage] 2012/10/13(土) 10:50:16.19: >>494
>DDA？

http://en.wikipedia.org/wiki/Digital_differential_analyzer_(graphics_algorithm)
505： ◆0uxK91AxII [sage] 2012/10/13(土) 11:31:10.73: >>501
どうせ除算は遅いから、ブレゼンハムおいしいです＾ｑ＾になる
ふつーの人は速いのを呼ぶだけ
506 + 2：ナイコンさん[sage] 2012/10/13(土) 11:46:12.84: >どうせ除算は遅いから、ブレゼンハムおいしいです＾ｑ＾になる

最初に一回やるだけの除算がそんな問題になるかな?
507：ナイコンさん[sage] 2012/10/13(土) 11:53:06.66: > そういや、CPUの特性にあわせたアルゴリズムで最大性能ひきだせるとか言ってたバカが居たな。
> CPUの特性にあわせた実装するとかならわかるが。

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

なんかマヌケなこと書いて引っ込みが付かなくなって、必死に考えた言い訳がLZHかｗ　笑えるｗｗ
508：ナイコンさん[sage] 2012/10/13(土) 12:12:43.27: Z80の時はアルゴリズム2、3個考えてどれが速いか比較してプログラム書いてた。
32bitCPUあたりからは命令数減らすようには考えるけど、アルゴリズムまではそんなにこだわらなくなった。
509 + 1： ◆0uxK91AxII [sage] 2012/10/13(土) 12:40:52.24: >>506
整数演算で直線の方程式を使うのを想定していたから、ソレは無理。
510：ナイコンさん[] 2012/10/13(土) 13:07:54.88: 6809 ビッグエンディアン
6502 リトルエンディアン
511 + 1：ナイコンさん[sage] 2012/10/13(土) 13:10:35.74: >どうせ除算は遅いから、ブレゼンハムおいしいです＾ｑ＾になる

それは、当時の「除算は加減算より遅い」というアーキテクチャに依存する発言だな。
今のLSI技術なら整数の除算なんて1クロックで終わる。
当時そういうアーキテクチャがなかったからからこそBresenhamが重視された。
512 + 1：ナイコンさん[sage] 2012/10/13(土) 16:03:21.48: >>506
最初に割り算使うやり方だと小数計算使うから途中の計算も重くなるよ
513 + 1：ナイコンさん[sage] 2012/10/14(日) 00:58:16.48: >>512
>最初に割り算使うやり方だと小数計算使うから途中の計算も重くなるよ

横640ドットとかだったら、小数点以下10ビットの固定小数点で精度は十分だよ。
514：ナイコンさん[sage] 2012/10/14(日) 01:21:45.47: >>509
>整数演算で直線の方程式を使うのを想定していたから

意味分からん
515：ナイコンさん[sage] 2012/10/14(日) 01:23:46.36: >>511
>それは、当時の「除算は加減算より遅い」というアーキテクチャに依存する発言だな。

割り算は最初に一回だけやればいいので、加算と単純に較べられない
516 + 6：ナイコンさん[sage] 2012/10/14(日) 01:44:31.63: >今のLSI技術なら整数の除算なんて1クロックで終わる。

そんなわけはない。
除算は原理的に並列化できないから整数除算はビット数分だけ時間がかかる。
浮動小数点除算なら、表引き＋ニュートン法で逆数＋乗算で加速できるけど、
どんなに頑張っても２～３クロックは必要（普通はもっと遅い）

例えばほら。
http://sonnyclark.seesaa.net/article/151202289.html

今でもこの手の問題（有理数倍のリサンプリングとか）には DDA 使ってるけどな。
だいたい DDA も固定小数点の積算も本質的に同じだろ。
最初の除算が無駄なだけ。
517 + 1：ナイコンさん[sage] 2012/10/14(日) 02:28:09.55: >>513
640*480の頃のVRAMはピクセルとビットが対応してたからそんな実装非効率すぎる
画面のXY座標からアドレスとビットパターンをもう一回計算するのかい
518：ナイコンさん[sage] 2012/10/14(日) 07:56:38.80: >>516
>>今のLSI技術なら整数の除算なんて1クロックで終わる。
>そんなわけはない。

10bit ÷ 10bit 程度なら、表から引けばいいだけだろ。
519 + 1：ナイコンさん[sage] 2012/10/14(日) 09:00:01.47: >>516
>だいたい DDA も固定小数点の積算も本質的に同じだろ。
>最初の除算が無駄なだけ。

加算一回してキャリー見るだけの積算とDDAが同じなわけないじゃん
520：ナイコンさん[sage] 2012/10/14(日) 09:03:37.79: >>517
>640*480の頃のVRAMはピクセルとビットが対応してたからそんな実装非効率すぎる
>画面のXY座標からアドレスとビットパターンをもう一回計算するのかい

お前にコーディング能力がないことは解った
521 + 4：ナイコンさん[sage] 2012/10/14(日) 10:25:42.57: 昔のハードを前提に語ってるのなら除算テーブルなんかに貴重なメモリを消費する訳にいかないだろ
522：ナイコンさん[sage] 2012/10/14(日) 10:28:45.86: >>516
>例えばほら。
>http://sonnyclark.seesaa.net/article/151202289.html

「加減乗除それぞれループに要する時間を差し引いた10億回の
計算時間が測定ができるよう工夫をした。かなりの試行錯誤の
末、最適化なしコンパイルとシングルユーザモードでの実行に
よりミリ秒レベルまで再現性のあるデータがとれるようになっ
た。」

って、こういうことするときって最低でもコンパイラの出力提示するし、
普通はアセンブリで組むよね。

何？このテスト。バカじゃないかしら。
523：ナイコンさん[sage] 2012/10/14(日) 10:29:58.97: >>521
>昔のハードを前提に語ってるのなら

「今のLSI技術なら～」が読めないんですね分かります
524：ナイコンさん[sage] 2012/10/14(日) 10:31:52.93: >>521

> >今のLSI技術なら整数の除算なんて1クロックで終わる。
>
> そんなわけはない。
525：ナイコンさん[sage] 2012/10/14(日) 10:34:56.78: >>521
PC-8001用のフライトシミュレータ(と言う名のワイヤーフレームデモ)で除算テーブルにごっそりメモリ割いてたの見たことあるけどな?
526：ナイコンさん[] 2012/10/14(日) 10:39:17.53: RAMの節約の為に640x400か512x480にしてください。
527 + 2：ナイコンさん[sage] 2012/10/14(日) 10:58:49.53: というか、8ビット時代の実際のコーディングの話なら
高速化重視のときラインルーチンはBresenhamをやめて最初に除算で差分を求めるのが定石だったけどな
nドット連続で書き込むことが先に確定しているほうがループ展開や場合分けで高速化できるから
除算のコストを払っても短い線でなければずっと速い
528：518[sage] 2012/10/14(日) 11:04:46.35: >>521 読んで、突っ込もうと思ったら既にボッコ状態だった (w
529：ナイコンさん[sage] 2012/10/14(日) 11:34:54.65: >>527
>除算のコストを払っても短い線でなければずっと速い

ラインの長さで場合分けをするのが正しい
530 + 1：ナイコンさん[sage] 2012/10/14(日) 11:52:13.37: 何を持って正しいかも定義しないで、「正しい」とか言い切る奴って…
531：ナイコンさん[sage] 2012/10/14(日) 11:57:47.83: 正しいは正義
532 + 1：ナイコンさん[sage] 2012/10/14(日) 12:03:51.62: >>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 + 1：ナイコンさん[sage] 2012/10/14(日) 12:22:34.82: >>532
t への代入を繰り返してるけど、展開して１クロックで終わるようにしてくれるの？
534：ナイコンさん[sage] 2012/10/14(日) 12:28:51.59: >>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 + 3：ナイコンさん[sage] 2012/10/14(日) 12:40:18.57: >>527
今でもDDAだぜ
WindowsのGDI関数はおバカだから対象がメモリ上の仮想スクリーンでも
自分で描かないと遅くて使い物にならん
>>519
8bitや16bitCPUなら分数を分数のまま扱うから余分な精度確保と整数部分の取出しがない分
キャリー発生時に減算が一個入るだけのDDAの方が速いよ
536：ナイコンさん[sage] 2012/10/14(日) 12:41:01.78: >>530
>何を持って正しいかも定義しないで、「正しい」とか言い切る奴って…

「何を持って正しいかも定義しないで、「正しい」とか言い切る」ことが正しいのか誤っているのかまず定義すれ。
537：ナイコンさん[sage] 2012/10/14(日) 12:42:51.88: >>535
>8bitや16bitCPUなら分数を分数のまま扱うから余分な精度確保と整数部分の取出しがない分

お前にコーディング能力がないことは十二分にわかった
538：ナイコンさん[sage] 2012/10/14(日) 12:44:07.93: >>535
>8bitや16bitCPUなら分数を分数のまま扱うから余分な精度確保と整数部分の取出しがない分

まっさか座標を小数点以下まで持って計算するとでも思ってるのかな?
539：ナイコンさん[sage] 2012/10/14(日) 13:02:32.15: >>535
> 8bitや16bitCPUなら分数を分数のまま扱うから余分な精度確保と整数部分の取出しがない分
> キャリー発生時に減算が一個入るだけのDDAの方が速いよ

馬鹿がいる
540 + 2：ナイコンさん[] 2012/10/14(日) 14:12:37.74: ピクセル座標で演算するなら隣のピクセルにドット打ったりしなきゃいいだけのはずだから、小数点以下10ビットは取りすぎだと、素人は思う。
点が抜けたり余分に打ったりしないていど、がどのぐらいの精度になるか分からないだけだが小数点以下2ビット以上あればよさげな気がする。

垂直水平と斜め線と円弧でロジック違うのは判るけど線の長さでも変えるもんなの？
541：ナイコンさん[sage] 2012/10/14(日) 14:13:32.75: 傾きがちょうど1.0の時も場合わけがいるな
線分発生なんてボトルネックでも何でもないのにアホくせ
542 + 1：ナイコンさん[sage] 2012/10/14(日) 14:23:43.21: >>540
>ピクセル座標で演算するなら隣のピクセルにドット打ったりしなきゃいいだけのはずだから、小数点以下10ビットは取りすぎだと、素人は思う。

横640ドット移動する間に縦1ドット移動する程度の傾きのラインを描画するとした場合、
1/640ドットの精度が必要となる。 →10bitの精度が必要ということ
543：ナイコンさん[sage] 2012/10/14(日) 14:26:34.78: >>540
>垂直水平と斜め線と円弧でロジック違うのは判るけど線の長さでも変えるもんなの？

高速化を考えるなら有効。
ただし、場合分けにも処理やコード量が嵩むから、そのへんはトレードオフを考慮しなければいけない。
544：ナイコンさん[] 2012/10/14(日) 15:33:33.28: 精度は画面幅に依存ってことね。
10ビット要るのは納得。

直線ひくだけなら単純な等差数列だからわり算一度きりでいいはずだよね？
しかし0度～45度と45度～90度と45度ドンピシャとでロジック変えないとドットが縦か横にズレるとか、意外だった。
8ビットCPUじゃ面倒そうだっのが正直な感想。

ググる先生大活躍したけど日本語の画像座標のこと書いてるサイトがあんまり見つからなかった。
コンピュータ系の専門学校とかで扱わないのかな。
545 + 2：ナイコンさん[sage] 2012/10/14(日) 16:48:29.41: 普通のLINE
●●●●●□□□□□
□□□□□●●●●●
N-BASICのLINE
●●●●●●●●●□
□□□□□□□□□●
546：ナイコンさん[sage] 2012/10/14(日) 17:21:33.11: >>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：ナイコンさん[sage] 2012/10/14(日) 17:23:23.90: ----------------------------------------------------------------
試しに今使ってる 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 + 1：ナイコンさん[sage] 2012/10/14(日) 17:24:25.32: 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：ナイコンさん[sage] 2012/10/14(日) 17:28:57.92: >>548
ソースコード出てこないと何とも言えないですよね。
550 + 1：546[sage] 2012/10/14(日) 17:37:46.01: 考え直してみると、ブログ主は64bit-ubuntu上で確認を行ったということなので、128bit÷64bit の命令を試したということだろうか?
それなら倍かそれ以上は遅くなって当たり前だな。
551 + 1：ナイコンさん[sage] 2012/10/14(日) 18:15:43.87: 割り算が遅いって思ってるから/3するより.33…掛けた方がいいかなと思ってる、最近のマシン速いし
意味無さそうだけど。識者の方は如何してますか。
552：ナイコンさん[sage] 2012/10/14(日) 18:36:40.87: 8bit CPUの頃に約1/3の計算をしたくて、8bitの値を85倍して16bitの値にし、インクリメントして上位8bitを使ったような記憶ならある。

同様に、22倍して7で割って直径→円周ということにしたこともあった。
553：ナイコンさん[sage] 2012/10/14(日) 18:47:42.53: >>551
Cray-1 には、除算命令がなく逆数を掛けることで処理していたのは結構有名な話
554 + 1：ナイコンさん[] 2012/10/14(日) 18:57:17.78: >>545
座標の基準がドットの左上か中心かで変わるみたいだね。
555 + 1：ナイコンさん[sage] 2012/10/14(日) 19:03:30.15: >>554
DDAの積和のところで初期値が適正でないだけな気がする。
556 + 1：ナイコンさん[] 2012/10/14(日) 19:17:10.48: >>555
不慣れな英語を流し読みしただけだから勘違いかもしれないけど
CGと学術系(サイエンティフィ？)なグラフでは使い分けられてる、見たいなことが書かれてたよ。
初期値を0.5変えるだけだろうけど。

ブクマしときゃよかったorz。
ガラケだから検索辛いんだ。
557：ナイコンさん[sage] 2012/10/14(日) 19:24:50.79: >>556
数学的には(0,0)-(1,1)にプロットしたとして2ドット描かれるのはおかしいと気付け
558 + 1：ナイコンさん[] 2012/10/14(日) 19:37:52.40: 別におかしくないよ。
(0,0)と(0,0.5)が同じ位置にドットが打たれるかそうじゃないかだから。
ピクセルの中心が基準なら違う位置に、左上基準なら同じ位置にドットが打たれるってだけだから。
559：ナイコンさん[sage] 2012/10/14(日) 19:46:34.33: >>558
座標(0,0)から(1,0)を結ぶ線分の長さは1だが、画面には長さ2のラインが描かれる。

↑説明してみ?
560：ナイコンさん[] 2012/10/14(日) 19:46:37.29: (0,0)-(1,1)で2つ打つのは正しい。
(0,0)-(0.9,0.9)なら１つだけになる左上基準と２つになる中心基準で違いがでてくる。
561 + 1：ナイコンさん[] 2012/10/14(日) 19:53:04.96: 画面上の座標1,1の守備範囲は1.0≦x＜2.0、yも同じ。
終点座標は始点と異なるピクセルを示してる。

こんなんで良い？
562：ナイコンさん[sage] 2012/10/14(日) 19:55:38.06: >>561
長さの話ですよ
563：ナイコンさん[] 2012/10/14(日) 19:58:20.12: 中心基準なら 0.5≦x＜1.5 以下略。

線分の縦横どちらかの長さが≧1.0の時点で2個以上のドットが打たれるんだよ。
中心基準も左上基準もどちらもね。
564：ナイコンさん[sage] 2012/10/14(日) 20:05:58.93: 長さ1の線分を描画すると長さ2のラインが描画されるということは、ドットの中心に座標があるということ。
そう考えると、N-BASICのラインの描画は正しくないという結論になる。
565 + 1：ナイコンさん[sage] 2012/10/14(日) 20:10:47.05: モダンなハードだと、座標はドットの角にあるのでひとつの辺を共有するポリゴンを2個描画したとしても共有する辺は二度描きされない。
566 + 1：ナイコンさん[] 2012/10/14(日) 20:21:47.86: 条件書き出してみればかんたんだよ。
左上基準なら
0≦x＜1なら一番左、
1≦x＜2なら２番目
だから。
0,0-1,0は隣接する２つのピクセルにドットか打たれるって一目瞭然でしょ？
567 + 1：ナイコンさん[sage] 2012/10/14(日) 20:25:47.25: 面倒なのは画面内の線分だけ切り出すクリッピングなんだよな
まじめにやると乗除算を使うからZ80には重荷
568：ナイコンさん[sage] 2012/10/14(日) 20:39:52.96: >>567
昔やってたときはバイナリーサーチみたいなアルゴリズムで乗除算は使わなかったような記憶があるなあ。
569：ナイコンさん[sage] 2012/10/14(日) 20:41:51.33: >>566
「線分の長さ」の意味が理解できないバカは引っ込んでてね
570：ナイコンさん[sage] 2012/10/14(日) 20:49:37.23: イタタタ。
論理座標とディスプレイ上の描画が頭のなかでリンクしてないバカにバカとか言われたよ。
どんなコンピュータでも最後はハードウェアに依存するって当たり前すぎる認識がない奴がこのスレに居るんだな。
571：ナイコンさん[sage] 2012/10/14(日) 20:58:55.07: ドットの中心に座標があることが理解できないバカは滑稽ｗ
572：ナイコンさん[sage] 2012/10/14(日) 21:34:04.73: >>516
>除算は原理的に並列化できないから整数除算はビット数分だけ時間がかかる。

例えば、除数を 0倍～15倍した値を予め求めておいて(16個)、被除数の上の桁から
引けるかどうかの判定を16個同時に並列してやって、引けた数字の一番大きいやつ
採用すれば一度に4ビット分計算できんじゃないの?
573 + 3：ナイコンさん[sage] 2012/10/14(日) 23:06:13.32: >>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：ナイコンさん[sage] 2012/10/15(月) 00:42:06.14: >>573
よくわからんから図を書いて説明してくれ
575 + 1：ナイコンさん[sage] 2012/10/15(月) 00:43:22.67: DDAループ内で2分の１の確率で発生するレジスタ加算の１命令４クロックを節約するために
長さチェックして頭で割り算やって45度専用ルーチン用意するなんて実装本当にやった人いるの？
オレならそんな長い線分来たらゴメンナサイで済ますぞ。どうせフレームレートは変わらんし
576：ナイコンさん[sage] 2012/10/15(月) 02:15:38.51: >>573
まともに読んでないけど言ってることはDDAじゃね?
577：ナイコンさん[sage] 2012/10/15(月) 02:21:51.64: >>575
>DDAループ内で2分の１の確率で発生するレジスタ加算の１命令４クロックを節約するために
>長さチェックして頭で割り算やって45度専用ルーチン用意するなんて実装本当にやった人いるの？

DDAも45度専用ルーチンも理解してないなｗ
578 + 1：ナイコンさん[sage] 2012/10/15(月) 02:27:00.87: そういや昔、初代Pentiumの中にある除算表の一部がバグって
誤った計算結果が出てリコールするかしないかの騒動があったな
579：ナイコンさん[sage] 2012/10/15(月) 02:35:36.44: >>578
あれは浮動小数点の割り算だから関係ない話
580：ナイコンさん[sage] 2012/10/15(月) 02:38:53.25: アレは今でもIntelにお願いすれば交換してくれる
581：ナイコンさん[sage] 2012/10/15(月) 02:57:25.54: 6809ならやる価値あるか
個々の命令がクソ遅いから節約効果は大きいし
逆数表と得意の乗算使えば損益分岐点はかなり短い
582：ナイコンさん[sage] 2012/10/15(月) 03:08:08.25: この時代のCPUって除算が1クロックで終わらせられるほどIPC高いの？
583：ナイコンさん[sage] 2012/10/15(月) 03:16:45.51: バカは放置で
584：ナイコンさん[sage] 2012/10/15(月) 11:48:38.16: Bresenhamはテクスチャマッピングをするまで
585 + 1：ナイコンさん[sage] 2012/10/15(月) 12:07:00.52: >>573
傾きが3/7の線なら途中の横並び数は2-2-3-2-2-3だから意味無いよね
傾きが水平に近くて長い線分専用にするしかないけど普通はやらないわ
586 + 1：ナイコンさん[sage] 2012/10/15(月) 15:45:34.17: http://www.youtube.com/watch?v=eADSS9FgNxA&feature=relmfu
本編は平面シューティングでｶﾞｯｶﾘしたが１ページ３プレーンのVRAMで２色のワイヤーフレーム
Z80とは思えないデモだった
587：ナイコンさん[sage] 2012/10/15(月) 17:09:26.57: シルフィードは偉大だよ。
588：ナイコンさん[sage] 2012/10/15(月) 17:19:33.92: >PC-8001用のフライトシミュレータ(と言う名のワイヤーフレームデモ)で除算テーブルにごっそりメモリ割いてたの見たことあるけどな?

サインテーブルとか68k使ってた頃でもインチキして
589：ナイコンさん[sage] 2012/10/15(月) 17:22:20.05: インチキして360度は4096分割(1象限1024度)なスチャラカプログラム作ってたな
Z80でやってた頃は1象限256分割で、360度が1024分割というアバウトさ
640x400だとさすがに襤褸が出るが、320x200や256x256ならいける
590：ナイコンさん[sage] 2012/10/15(月) 17:22:22.44: >>586
>１ページ３プレーンのVRAMで２色のワイヤーフレーム

解析してないから断言できんけど、描画と表示を別プレーンに割り当てて、パレット切り替えでページフリップしてると思う。こんな感じで。

発進のシーン

Bプレーン描画　Rプレーン表示　Gプレーン表示
↓
Bプレーン表示　Rプレーン描画　Gプレーン表示
↓
Bプレーン表示　Rプレーン表示　Gプレーン描画

機体のスペック表示のシーン

Bプレーン描画　Rプレーン表示　Gプレーン表示
↓
Bプレーン表示　Rプレーン描画　Gプレーン表示
591 + 4：ナイコンさん[sage] 2012/10/15(月) 18:17:40.74: シルフィードは母艦と戦闘機で色が違うから、明らかに2プレーン使ってるよ
OP後半の諸元表示のところは1色だけどな
ゲーム本編でも2プレーン3色(赤青白+黒)だし

移植されたPCDOS版のOPは、全編通して320x200ドット単プレーン表示へ退行
（その甲斐あって、フレームレートは向上したが）
592：ナイコンさん[sage] 2012/10/15(月) 18:23:43.19: >>591
>シルフィードは母艦と戦闘機で色が違うから、明らかに2プレーン使ってるよ

同時に更新する必要はないと思うから描画中に隠すプレーンは1枚でいいと思うよ。
593：ナイコンさん[sage] 2012/10/15(月) 18:29:21.91: >>591
>ゲーム本編でも2プレーン3色(赤青白+黒)だし

目ぇ大丈夫?
http://www.youtube.com/watch?v=8hVwAfy88NE
594：ナイコンさん[sage] 2012/10/15(月) 18:55:58.83: FM77版もあったよな？
595：546[sage] 2012/10/15(月) 19:18:26.40: >>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：ナイコンさん[sage] 2012/10/15(月) 19:25:11.27: >>ゲーム本編でも2プレーン3色(赤青白+黒)だし
>
>目ぇ大丈夫?
>http://www.youtube.com/watch?v=8hVwAfy88NE

何に文句をつけているのか理解できない
597：ナイコンさん[sage] 2012/10/15(月) 19:26:59.78: >何に文句をつけているのか理解できない

目も頭も悪いんだなｗ
598：ナイコンさん[sage] 2012/10/15(月) 19:31:58.68: >>596
>>>ゲーム本編でも2プレーン3色(赤青白+黒)だし

>>目ぇ大丈夫?

>何に文句をつけているのか理解できない

緑やらシアンやら使った敵出てるじゃん

分かりやすいのはこの辺
http://www.youtube.com/watch?v=8hVwAfy88NE&t=190
599 + 2：ナイコンさん[sage] 2012/10/15(月) 19:40:43.08: >分かりやすいのはこの辺
一部のボス以外は2プレーン描画だよ

3プレーン目はステージやシーンによって背景に使ったり
ボスに使うなど使い分けているが、
自機や弾やザコ敵は3プレーン目は使わない

自機も地形も2プレーン描画で、
レーザーと爆炎を3プレーン目に持って行ったテグザーや
キャラは2プレーンで地形を1プレーン描画した
ドラスレ/ザナドゥと同じ考え方だ
600 + 1：ナイコンさん[sage] 2012/10/15(月) 19:45:56.74: >>599
>一部のボス以外は2プレーン描画だよ
>
>3プレーン目はステージやシーンによって背景に使ったり
>ボスに使うなど使い分けているが、
>自機や弾やザコ敵は3プレーン目は使わない

ザコ敵に緑やシアンや黄色も使ってるみたいだけど?
http://www.youtube.com/watch?v=8hVwAfy88NE&t=21
http://www.youtube.com/watch?v=8hVwAfy88NE&t=28
601：ナイコンさん[sage] 2012/10/15(月) 19:49:00.71: テクスチャー入ってもいないんだし、88SRのALU使って描画してるだろうから、
重ね合わせとかしない限りはプレーン数減らしても描画の速度は変わらん筈。
602：ナイコンさん[sage] 2012/10/15(月) 19:49:51.38: >>591
>ゲーム本編でも2プレーン3色(赤青白+黒)だし

なんだ嘘か
603：ナイコンさん[sage] 2012/10/15(月) 23:09:33.98: あれって頂点データ垂れ流し方式なのかな
604 + 1：ナイコンさん[sage] 2012/10/16(火) 00:15:27.02: >>585
あの時代のライン描画の高速化はVRAMの読み書き回数をいか減らすか、がポイントで
特に水平に近い長い線を描くときそれが効いてくるからそれでいいんだよ。
1点を描くのに、まともに3プレーンアクセスが必要な機種はVRAM3枚分の読み込み・合成・書き込みが必要になるが、
横8ドット＝1バイトが線で埋まることがあらかじめわかっていれば書き込み以外をまるまる省くことができる。
VRAMアクセス減らすのにBresenhamで空ループさせる手もあるけど、なら割り算したほうが結局は速い。

逆に短い線や縦に伸びる線はどの方法を使ってもVRAMアクセス回数は大して変わらないから
それなら横長の線が劇的に速くなるほうがいい。実際やってみるとかなり効果あったよ。
605 + 1：ナイコンさん[sage] 2012/10/16(火) 00:24:09.89: >>604
そのテストプログラムを公開してくれよ
606：ナイコンさん[sage] 2012/10/16(火) 00:51:41.81: >>605
おそらく予期した返答だと思うけど、現存してない。
公開するには思い出しながら一から作り直すことになるが、完成させる自信はないなｗ。
607 + 1：ナイコンさん[sage] 2012/10/16(火) 01:47:36.12: Coreアーキテクチャ以降は倍精度実数でも除算が６クロックなんだよな
逆数テーブル引くのが空しくなるぜ
608：ナイコンさん[sage] 2012/10/16(火) 03:00:02.66: >>596
>何に文句をつけているのか理解できない

りかいできまちたか？
609：ナイコンさん[sage] 2012/10/16(火) 06:58:46.97: 盛り上がってるな
610： ◆0uxK91AxII [sage] 2012/10/16(火) 08:12:50.78: >>607
fdivかよー／(^o^)＼
611：ナイコンさん[] 2012/10/16(火) 15:19:21.25: ここはレベルの低い話しかしてないんだねー
もっと深い話題があると思ったんだが
612：ナイコンさん[sage] 2012/10/16(火) 15:20:52.17: そのレベルの低い話もできないのがお前。
613：ナイコンさん[sage] 2012/10/16(火) 15:21:57.49: 語りたい深い話題があるなら自分から話を振るべき
614：ナイコンさん[sage] 2012/10/16(火) 19:18:13.00: >ここはレベルの低い話しかしてないんだねー
>もっと深い話題があると思ったんだが
そりゃ8bit全盛期の、いまから見たらクソみたいなCPUを語る場だからな。
最新のCPUの高度な話題を求めてるんなら、こんなスレに来たお前が情弱。
615 + 1：ナイコンさん[sage] 2012/10/16(火) 19:42:27.23: Z80全盛時でもロクな乗算除算ルーチンが公表されていなかったよな
平方テーブル方式や16bit加算を使わない8x8乗算が一般化してりゃもう少し文化が育っていたかもしれん
616：ナイコンさん[sage] 2012/10/16(火) 19:49:02.29: オープンソースという概念やネットワークがなかった技術的に発展途上だったなどとなんとなく想像
617 + 1：ナイコンさん[sage] 2012/10/16(火) 20:18:35.85: >>615
出来が良い乗除算ルーチンはなくてもコプロつかえばOKでしょ
618：ナイコンさん[sage] 2012/10/16(火) 20:19:20.44: ニューメリカルレシピとかをどれだけのプログラマーが読んだんだろ。
619：ナイコンさん[sage] 2012/10/16(火) 20:23:06.58: >>617
Z80にコプロは付かない
620 + 1：ナイコンさん[sage] 2012/10/16(火) 20:24:59.44: Z80用はなかったけど、8bit一般用のはあったろ
621：ナイコンさん[sage] 2012/10/16(火) 20:25:02.74: 雑誌ならインターフェースやbit、ときどき数学セミナー、無理して書泉グランデでDDJ
最新知りたきゃACMの論文見ろな時代だった。
622：ナイコンさん[sage] 2012/10/16(火) 20:26:42.07: >>620
数値演算プロセッサとコプロの区別がつかない人？
623：ナイコンさん[sage] 2012/10/16(火) 20:30:52.89: うん区別が付かない
何が違ってどう使い分けるか教えていただけると助かる
624：ナイコンさん[sage] 2012/10/16(火) 20:33:29.03: CPUの機能が拡張されて見えるのがコプロセッサ
数値を演算するのが数値演算プロセッサ
625：ナイコンさん[sage] 2012/10/16(火) 20:35:17.79: CPUガワにもコプロと結託する機能が必要って事？
626：ナイコンさん[sage] 2012/10/16(火) 20:36:38.93: コプロに完全に乗っ取られるものもありました。はい。
627：ナイコンさん[] 2012/10/16(火) 20:47:13.68: 8087は8086の命令読み込みを監視しながらESC命令を見つけたら乗っ取る。
んで処理したら8086へ主導権を返す。
487SXは486SXを止めて乗っ取る。

ぐらいしか乗っ取り型のコプロセッサは知らない。
628：ナイコンさん[sage] 2012/10/16(火) 21:00:35.25: 487SXは486SXを止めっぱなしになるのでコプロではないと思う。
629：ナイコンさん[sage] 2012/10/16(火) 21:06:46.82: 80287からI/Oポートを使うようになったでしょ
だれかこの事を簡単に説明してくれませんか
630：ナイコンさん[sage] 2012/10/16(火) 22:44:05.37: >>565
旧MacOSのQuickDrawはそういう環境だった。もう25年は前の話なんだな。
631 + 1：ナイコンさん[sage] 2012/10/17(水) 00:39:50.00: 簡単に平方根を求める方法を教えてください！
符号なし、小数切り捨てで構いません
632：ナイコンさん[sage] 2012/10/17(水) 00:41:19.52: sqrt()
633：ナイコンさん[sage] 2012/10/17(水) 00:45:10.69: >簡単に平方根を求める方法を教えてください！

>>488
634 + 1：ナイコンさん[sage] 2012/10/17(水) 15:46:00.05: Am9511,CDP1855,74LS384
Z80にわざわざこんなの付けて自分で専用プログラム作る必要あるなら16bitマシン調達するのが正解
ROMカートリッジのソフトならありだけどゲーム機で高速CPU載せたのが少し出ただけだったな
635：ナイコンさん[sage] 2012/10/17(水) 16:46:22.94: >>634
TurboPascalでAm9511サポートされてたり…
ポートアドレス書いてライブラリ再構築で使える。
向こうはS100バス機普及もあって使える機械が多かったって事だろう。
74LS384に関してはI/Oか日経バイトかなんかに8801向けカードの製作記事が載った事があったかな。
636 + 1：ナイコンさん[sage] 2012/10/18(木) 00:29:42.65: >りかいできまちたか？

わからんね。自キャラ・雑魚キャラ・弾は2プレーン描画、地形と爆炎が別プレーン
ボス級キャラのみ3プレーン使う「場合もある」ようにしか見えないが。
（自機・雑魚と重複するのは1プレーンのみで、ボス・地形も2プレーン描画かもしれない）
637：ナイコンさん[sage] 2012/10/18(木) 09:55:10.64: 赤緑のアレだろう
638：ナイコンさん[sage] 2012/10/18(木) 11:37:24.65: >>636
>自キャラ・雑魚キャラ・弾は2プレーン描画、地形と爆炎が別プレーン
>ボス級キャラのみ3プレーン使う「場合もある」ようにしか見えないが。

「ゲーム本編でも2プレーン3色(赤青白+黒)だし」という主張だった筈だが？ｗ

雑魚キャラ・ボスキャラが「3色(赤青白+黒)」以外使ってる時点で主張はボロボロなんだがなあ？ｗｗ
639：ナイコンさん[sage] 2012/10/18(木) 15:32:31.57: 全然スレチ。
640：ナイコンさん[sage] 2012/10/18(木) 16:37:16.54: >>599
>レーザーと爆炎を3プレーン目に持って行ったテグザーや
>キャラは2プレーンで地形を1プレーン描画した
>ドラスレ/ザナドゥと同じ考え方だ

要するにお前の頭がそれ以上ついていってないってことだよ
641：ナイコンさん[sage] 2012/10/18(木) 16:43:43.91: 憶測でなく、実機でN-BASICリセットでVRAM吸い出して確認してみたら？
642：ナイコンさん[sage] 2012/10/18(木) 17:44:08.17: >>591
>ゲーム本編でも2プレーン3色(赤青白+黒)だし

地形が表示されるシーンや敵艦体内部に限ってはザコ敵中ボス含めてその色使いだが

http://www.youtube.com/watch?v=8hVwAfy88NE&t=272
http://www.youtube.com/watch?v=8hVwAfy88NE&t=421

それ以外のシーンでは黄色だの緑だの色使ってるぞ。
643 + 1：ナイコンさん[sage] 2012/10/18(木) 18:45:35.21: OPのワイヤーフレーム、変わった処理してるね。
プレーン1を縦縞で固定。
プレーン2と3を切り替えながら描画して
偶数ラインONなら青、奇数ラインONなら黄色を表示。

プレーン1 　　： 01010101 固定
プレーン2/3　： 00000000 黒+黒
プレーン2/3　： 10101010 青+黒（母艦描画に使用）
プレーン2/3　： 01010101 黒+黄（星描画に使用）
プレーン2/3　： 11111111 青+黄（時機描画に使用）

これで１プレーン書き換えだけで４色表示させてる。
644：ナイコンさん[sage] 2012/10/18(木) 19:10:10.44: >>643
面白いな
645 + 1：ナイコンさん[sage] 2012/10/18(木) 19:33:16.46: ttp://ichigo-up.com/cgi/up/qqq/nm57148.bmp

自キャラ白、赤、青
ボス　　　白、赤、緑、水色、黄色

黒含めて7色。

自機といっぱい出てくる雑魚キャラは2プレーン描画で
１体だけのボスは3プレーンかな？

あと１色は爆発用とか。
646：ナイコンさん[sage] 2012/10/18(木) 19:35:01.92: 随分暗い白だな
647：ナイコンさん[sage] 2012/10/18(木) 19:35:19.68: ゲームアーツのことだから、面の途中で描画プログラム変えるぐらいはやりそう。
648：ナイコンさん[sage] 2012/10/18(木) 19:36:46.52: >>645
>自機といっぱい出てくる雑魚キャラは2プレーン描画で

>>600見れ
649 + 1：ナイコンさん[sage] 2012/10/18(木) 19:53:42.27: M88の画面キャプチャBMPのカラーパレットが実際のパレットと一致してるかわからんが

000:黒
001:白
010:グレー？
011:赤
100:青
101:緑
110:水色
111:黄色

さて、ゲームアーツが何も考えずにこんな配色にするとは思えないんだが…。
650：ナイコンさん[sage] 2012/10/18(木) 20:06:12.42: >>649
同じステージでも、背景に地上が表示されているときと表示されなくなったときで
爆発パターンの色が違うからパレットも固定ではないと思う。
ダメージ食らったときに画面が赤くなるのもパレットチェンジだろうし。
651：ナイコンさん[] 2012/10/18(木) 20:54:46.90: ゲームアーツだしな。
何やらかしてても納得するよ。
だってゲームアーツなんだもん。
652：ナイコンさん[sage] 2012/10/19(金) 00:53:49.55: 4096色中同時発色16色が使えるとかあったけれど絵とか表現する時どう？
653：ナイコンさん[sage] 2012/10/19(金) 09:13:05.81: PC-98のことか？
某漫画家がエロゲの画像描いてた時は「64色あればなんでも描けるのに」って愚痴ってたらしい。
654：ナイコンさん[sage] 2012/10/19(金) 09:51:29.29: >>631
敵キャラとの距離か?
テーブル用意したら?
655：ナイコンさん[age] 2012/10/19(金) 11:59:24.42: 走査線ごとに切り替えて32色出す
656：ナイコンさん[sage] 2012/10/19(金) 12:53:46.99: 8801SRに320＊200のモードがあればもっと色々なことができたのに残念
PC6000シリーズに遠慮したとしても不要と判断したにしても大きな誤り
657：ナイコンさん[sage] 2012/10/19(金) 13:06:09.85: この話題は、そろそろこっちに移動したほうが良くないか？

【8bit機】CRTC,VDP,ALU,メモリマップ,MMU 専スレ
http://read2ch.com/r/i4004/1221375066/
658：ナイコンさん[sage] 2012/10/19(金) 13:20:16.27: >>545
富士通の場合 (F-BASIC v1.0～v3.0)
階段部分が太い特殊なLINE
●●●●●□□□□□
□□□□●●●●●●
659：ナイコンさん[sage] 2012/10/19(金) 20:55:17.24: これは酷いなぁ
階段部分が目立って目について仕方なさそう
660：ナイコンさん[sage] 2012/10/19(金) 21:09:40.47: 円も32角形とかそんなんだった気がする >FM
661：ナイコンさん[sage] 2012/10/20(土) 21:30:04.41: モンテカルロなやり方と誤差でかそうなだな>>FM
662 + 2：ナイコンさん[sage] 2012/10/21(日) 00:29:18.18: 最近自作したMC680ボードでtiny basicを動かそうとした。
OS-9の会社のアセンブラソースが入手できたので走らせようとしたが動かん。
解読したところ自分自身のコードを動的に書き換えて動作してる部分を発見。
それをフラッシュROMに焼いて動かそうとしたのがダメだった。富士通がイン
デックス関係の演算追加したくなった意味が理解できた。6502も改良方向の
１つはそれなのだろう。そういう不足アドレシングモードを自己書き換えで
補って使ってたのだろう。自己書き換え部分修正して動かす予定。
663：ナイコンさん[sage] 2012/10/21(日) 00:30:42.21: >>662 MC680でなくMC6800
664 + 1：ナイコンさん[sage] 2012/10/21(日) 02:05:00.05: 自作といえばラッピングワイヤーと電動ラップツールの存在は知っていたけどハンドラップツール
の存在を最近知った。もっと前から知ってれば電子工作で色々作れたな。最近だと秋葉の大きな
工具屋にも殆ど置いてないし。電子立国日本の終焉か。
665：ナイコンさん[sage] 2012/10/21(日) 02:33:12.20: >もっと前から知ってれば電子工作で色々作れたな。

やる気さえあれば、方法なんて二の次でハンダ付けでも電動工具使ってでも電子工作やってただろ。
666：ナイコンさん[sage] 2012/10/21(日) 03:31:20.13: 簡単な工作ならそれでいいけど。ハンドラップツール無しでハンドラップしてみなw
667：ナイコンさん[sage] 2012/10/21(日) 03:42:10.16: >ハンドラップツール無しでハンドラップしてみなw

なんで?
668 + 1：ナイコンさん[sage] 2012/10/21(日) 03:59:51.21: ラッピングした事無いような素人はほっとき
669：ナイコンさん[sage] 2012/10/21(日) 04:04:32.85: >>668
「自作といえばラッピングワイヤーと電動ラップツールの存在は知っていた」ってんだから、
「ラッピングした事無いような」じゃなくて実際無いんだろ。
670：ナイコンさん[sage] 2012/10/21(日) 04:08:03.18: >>664
>最近だと秋葉の大きな
>工具屋にも殆ど置いてないし。電子立国日本の終焉か。

今どきラッピングで工作できる部品なんてほとんど使わんだろ。
アマチュアがFPGA使って個人で業者に基板発注する時代なの理解してっか？
671：ナイコンさん[sage] 2012/10/21(日) 04:47:44.41: なんでわざわざ発注すんだよ秋月あたりで出来合いの基盤買ってデータ焼いてコネクタ挿して
動かしてそれを自作でございとやりゃいいだろ。
672：ナイコンさん[sage] 2012/10/21(日) 09:58:15.69: 趣味なんだから、人それぞれの方法でやればいいだけだろ。

まあ、ラッピングしたことあるとかぐらいしか自慢のネタがないなら
しょうがないけど。
673 + 1：ナイコンさん[sage] 2012/10/21(日) 23:07:20.97: FPGA評価ボードとかは使った事ある人なら判るかも知れないが
特に半導体ベンダ提供の物はFPGA機能を試す為に作られている物が多く
大抵のGPIOが配線済みになってたりするので、使う用途によっては、とても使いにくいものだったりする。

ttp://akizukidenshi.com/catalog/g/gM-05113/
これなんか、FPGAの評価用というより、ソフトプロセッサIPであるMicroBlazeを評価する為の物だったりするので、I/Oはほぼ使えなかったり。
秋月ではFPGAやCPLDの扱いって昔から弱いからな。
秋葉の店頭小売なら千石やマルツの方がまだ強い。

それはともかく、アマチュアなら、今はラッピング線よりもUEW使って配線してる人が多いのでは無いかな。
ラッピング線、専用工具無しだと剥きづらいし、実際にラッピングで作るには専用ICソケットとか使わなきゃいけないしな～
674：ナイコンさん[sage] 2012/10/21(日) 23:34:07.74: >>673
この間転職したソフト屋だけど、プロの人も試作とかではUEW使ってるね。

治具とかつくるのにハンダやらされるんだが、実装の話なんてそれこそ
ラッピングの時代までの知識しかなくてUEWなんて知らなかったから、導通しなくて頭抱えたわ。
675：ナイコンさん[sage] 2012/10/22(月) 00:43:21.42: １プレーンのVRAMへの16bitDDAライン処理を書いてみたら
Z80が71～104クロック/dot
6809が39～66クロック/dotくらいになった

FMもSRも長さ50の線を１秒間に1000本くらいは描けるがいろんな意味でどっちもダメダメなことに違いは無い
676：ナイコンさん[sage] 2012/10/22(月) 00:52:21.16: スタックポインタをVRAM上に設定して
PUSH
PUSH
PUSH
PUSH
PUSH
...
677：ナイコンさん[sage] 2012/10/22(月) 01:31:54.69: >>662
OS-9は6809からだと思ったが?
678：ナイコンさん[sage] 2012/10/22(月) 01:40:37.75: >１プレーンのVRAMへの16bitDDAライン処理を書いてみたら
>Z80が71～104クロック/dot
>6809が39～66クロック/dotくらいになった

遅杉じゃね？

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

2ch検索

他のスレッド

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

2ch検索

他のスレッド

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