【Renesas】ルネサス総合 part9©2ch.net

ルネサスの製品全般について

■マイコン総合
http://japan.renesas.com/prod/mcumpu/

前スレ
【Renesas】ルネサス総合 part8
http://wc2014.2ch.net/test/read.cgi/denki/1391644674/

2ゲット！

オープンの方にはいらんかね？

>>前スレ1000

>アセンブラも使うし、使わなくてもデバグ時には必要な知識だし、コンパイラの出力コードを評価するにも
>アセンブラの知識は必須だよ？何言ってんの？？

何言ってんの？？
アセンブラの知識は必須だよ。あたりまえだよ。
初めて使うマイコンでも、それくらいの用途なら、
Cとアセンブラ並べて表示すれば、ほとんど読めるわアホ。

全部アセンブラで書くなら知らんけど、そんな話は最初からしてない。

>>4
3点言ってるけど理解してる？

・アセンブラも使う
・デバグ時には必要な知識である
・コンパイラの出力コードを評価するにもアセンブラの知識は必須である

分かってるよｗ
どんなけアセンブラ依存なコード書いてんだよｗ

言い直そうか？

ひとつCPU理解したことあるなら、
CPUの基本なんて変わらんから、
初めての触るマイコンでも
Cとアセンブラ並べて表示すれば、そんな仕事できる。

ちゃんと前スレの最初から読めよ。
Cメインって前提で話してんだよ。

>>6
>ひとつCPU理解したことあるなら、
>CPUの基本なんて変わらんから、
>初めての触るマイコンでも
>Cとアセンブラ並べて表示すれば、そんな仕事できる。

効率無視すりゃね。
ユーザーが既に理解してるアーキテクチャには学習コストが発生しないから作業的にも効率は上がるし
メリットはあるって話をこっちはしてるよ。

CPU変わる度に仕様を何日も勉強してんの？
RL78もどうせ無くなるんだよ？大丈夫？

こちらは、遅そうなところの把握、
割込クロック数とか、分岐のペナルティとか、
その辺のオーバーヘッドが分かれば、クロック比例と捉えて、
あとはその都度調べる、かな。
コンパイラの吐き出すコード見て、
避けるべき書き方がないかは、常に考えてる。

アプリ寄りのレイヤは、抽象度上げて、レジスタ名すら使ってないので、
CPU仕様については、変わっても、ほとんど困らない。
周辺ユニットにはいつも泣かされる。。。

さて、やっと話が戻り、上をふまえて、

前スレ995
>コンパイラのパーサはともかく、バックエンドの開発は大変なんだよ。
>それより規模の違うコアを数種類用意することで、どれだけシリコンが節約できるのよ。
同意

前スレ996
>・開発ツールの開発コスト削減
>・ユーザーの学習コスト削減
>・ユーザーの過去のプログラム資産の継承
一つ目だけ同意。3つ目も少しだけ同意（アセンブラのライブラリなんて要らんけど）

ルネサスの都合で同じ命令体系ってことなら、納得。
高級言語メインのユーザにはメリットはほとんど無いと思ってる。
と主張したかった。頼むわｗ

>>8
>CPU変わる度に仕様を何日も勉強してんの？

それだけで何日も掛けることはないだろうけど、一度深いところまで理解したアーキテクチャがあったとして
それとは違うアーキテクチャについて同等程度に習熟するにはそれなりの期間は要するね。

Cでだめなら、あきらめろ！！

RL78/G10なんてROM容量も小さいんで、Cで組むとしてもコンパイラがどういうコード吐くか、
リンクされるライブラリはどういうのかをかなり意識する必要もあると思うし、かなりアセンブリ
寄りの思考は必要になると思うよ。

ま、CPUの寿命とコードの寿命が一致でいいなら、お好きなように。

仕事は辛いね。趣味だと、ディスコンの無いFPGA上のCPUですので。

話がそれるけど、過去ログにもあったけど、経験談でいくと、
純正RL78コンパイラもの吐き出すコードはウンコなので、
アセンブラとにらめっこして、おかしなC言語になっていくよりは、
IARのコンパイラを買うのがgoodです。これも趣味じゃ買いにくい値段だけど。
RXの純正コンパイラは優秀なのになぁ

>>12
>純正RL78コンパイラもの吐き出すコードはウンコなので、

>RXの純正コンパイラは優秀なのになぁ

こういう経験積んでるのに、アーキテクチャの数が少なければツール選定ひとつとってもユーザの苦労は
少なくなることも想像できない人なんだね。

同和の糞どもは何故差別されて怒るのか。差別されて当然の身分だろうw日本語堪能なチョン猿どもが

同和の糞どもは何故差別されて怒るのか。差別されて当然の身分だろうw日本語堪能なチョン猿どもが

同和の糞どもは何故差別されて怒るのか。差別されて当然の身分だろうw日本語堪能なチョン猿どもが

同和の糞どもは何故差別されて怒るのか。差別されて当然の身分だろうw日本語堪能なチョン猿どもが

同和の糞どもは何故差別されて怒るのか。差別されて当然の身分だろうw日本語堪能なチョン猿どもが

同和の糞どもは何故差別されて怒るのか。差別されて当然の身分だろうw日本語堪能なチョン猿どもが

同和の糞どもは何故差別されて怒るのか。差別されて当然の身分だろうw日本語堪能なチョン猿どもが

同和の糞どもは何故差別されて怒るのか。差別されて当然の身分だろうw日本語堪能なチョン猿どもが

同和地区（被差別部落）の多くは南北朝時代以前まで、一部は平安時代までさかのぼれる古い歴史がある

要するに、ﾁｮﾝとは全く別物。混同するなよ、>>14-21こそﾁｮﾝ

>>13

想像できるよ。どんなに準備しても、苦労はあるからね。
CPU変わるたびに、対応だけで（必要以上に）忙しくしてる人も想像できるよｗ

ツールも選定したくないよね。ルネならeclipseで統一ウェルカムです。
CS+なんて不要。HEW？早くトイレに流しましょう。

命令セットは統一で、開発環境は複数？ 矛盾した方針ですねぇ。

繰り返すけど、周辺ユニットには毎回泣かされます。

>>13
んで、あなたのコードの抽象レベルはどんなんなの？

この前、誰か書き込んでたけど、
PORT3.DR.BIT.BIT3 = 1; とか書いちゃってるの？

最低限、ポート番号を隠蔽、Hi/Lowアクティブ隠蔽して、
led_port.activate(); くらいは書いてる？
あー、例がC++になってしまったが、
テンプレート使えばオーバーヘッドゼロだよ。

釈迦に説法だったらごめんなさい。

今更RL78つまんで 8bit だ 16bit だやってるのもムナシイので ARM 陣営並に小規模チップでも 32bit 使いたい。
RX100番台のもっと小規模なやつ作ってくれ。

>>23-24
他人に絡みたいだけの下らない人物と理解したので相手するのよすわゴメンね。

>>26
OK
会話してたのがどんなレベルの人だったのか知りたいので、
>>24 だけ回答くれると嬉しいな

CPUコアなぞ何でもよかろう。
コアだけの判断なら新規案件ではルネを選ぶか
周辺は速い信号扱う流用はちと厳しい
むしろ開発ツールの違いが厳しい

E1に統一でありがたい。
他のコアも気軽に試せる

統合環境も遅いが統一の流れ。
かとおもったら、新バージョンのCubeSuiteで
対応マイコンが分かれた。なんなの(´・ω・｀)

RX使っているけどアセンブラなんてほとんど見たことない。
ハードウェアマニュアルにもニーモニックの解説すらない。
デバッガの逆アセンブルリストもほとんど見たことない。
どうしても必要なときも過去CPUからの類推でだいたい済ましている。
これで別に困らないけどな。

>>28
日本語で頼む

OS載せるかどうかの階層の前に、
レジスタ操作のレベルでも抽象化して書けるところは山ほどあるよね。

>>24みたいな書き方は、サンプルコードとかでも、
教育的な意味でやって欲しいと思う。
iodefine.hをちょっとラップしたクラス作ればできるわけなので。

CPUが変わっても動くようなプログラム書いてるつもりだけど、
エンディアンだと、リトルじゃないと、動かないかな…。

RL78の純正コンパイラは、コンパイルオプション変えないと、死ねます
http://www2u.biglobe.ne.jp/~tequila/electro_k0r1.html#ELK0R020_09

遊びで RL78 用のマルチタスクフレームワークっぽいもの作ってるけど、このマイコンのインストラクションおもしろいな。
レジスタに1をセットする命令とか、転送命令だけど、ソースが0だと Z フラグが立つ命令とか。現場の声からできました的な。

>>33
便利ですよね。
ハードマニュアルの、「ポート機能使用時の注意事項」
という落とし穴があるので、ご注意ください。
ハマりました。
というか、ポートの設計やばいと思いますｗ

RXでも効率いいです。
RXはポートレジスタへのアクセスは遅く、
ポートを1ビットだけ変更するとき、
読み込み→ビット修正→書き込み
で、遅いわけですが、ビット修正だけで済むと、
ICLK換算だと何クロックもお得でウマーです。

>>33
＞転送命令だけど、ソースが0だと Z フラグが立つ命令

68000とかがそんな感じだった希ガス
日立はMC68000のセカンドソースだったし、その関係で使い慣れてたのかと

>>33
>転送命令だけど、ソースが0だと Z フラグが立つ命令とか。

MOVS命令は活かしどころがわからん

>>36
6502が起源では。ファミコン系列から多くの機種が引き継いでいる。
汎用CPUは少ないけど。

昔のCISCならではだよね。
最近はパイプラインが長かったり、
コンパイラでの最適化が進んだりで、
命令順を並び替えることが多いけど、
本来関係ない命令でフラグが変わるとそれが難しい。

>>37
お前がRL78のMOVS命令と6502のどちらか、あるいは両方について分かってないことは分かった。

>>39
あなたはルネサスのスレに何年も前からずっと貼り付いて、ただひたすら
他人の発言をけなすので有名な人ですね。

>>40
違いますよ。

>>34 の例といい、
同じアドレスに複数の機能を割り振るハード設計は、
基本的にやめてほしい。デバッグできん。

ポートの状態と出力データを同じレジスタとして重ねのてなんか意味あんの？
分けてあれば、ちゃんと出力されてるか確認できるし（RXがそうだっけ）

>43
一般論的には、
インデックス間接の修飾8bitで512個のレジスタにアクセスできる、みたいな。

逆に、広い空間にレジスタばらまくっつーことをARMがやって、
インデックス修飾が届かなくて一手間増えてる。即値ロードもコスト掛かるのに。
AVRはレジスタ増えすぎて重ねてもインデックス修飾が届かなくなってるけど。

MOV命令にdsp:16[Rs]やdsp:16[Rd]が苦もなく使えるRXにはあんま関係ない話だな

>>37
RL78で「転送命令だけど、ソースが0だと Z フラグが立つ命令」というと

MOVS [HL+byte], X

と

MOVS ES:[HL+byte], X

のふたつだけだと思うけど、6502のSTX命令はフラグ変化がないので全然違う。

（6502より後の製品だけど）68000のともだいぶ違うね

68000のロード/ストア/移動兼用命令moveでは、Xフラグのみ不変でNフラグとZフラグがオペランドにより可変、
VフラグとCフラグは（演算字と違ってオーバーフローが起きないから当然だが）0クリアされる
ロードストア系でフラグ変化しないのはLEAとmoveaとフラグレジスタからのmove、複数レジスタmoveであるmovem、
I/Oポート用のmovep、68040で追加されたブロックmove命令であるmove16ぐらい?

6809のマニュアルもググってみたけど、68000と同様っぽいね。68000の祖型というか原型というか、だからかね。

>>48
68Kは、むしろ6809の失敗を反省して、
全然違うものを作ったって感じじゃないか。
祖形というより、全否定という気がする。

>>49
↓の通りなら、68000に6809は関係してない。

http://ja.wikipedia.org/wiki/MC6809
> MC6809は、モトローラが1979年に発売した、8ビットのマイクロプロセッサ。

http://ja.wikipedia.org/wiki/MC68000
> 歴史
> 68000 は1976年に開始された MACSS（Motorola Advanced Computer System on Silicon）
> プロジェクトから出てきたものである。従来製品との互換性を考慮するような妥協したアーキ
> テクチャにはしないということが開発の初期に決定されていた。

> オリジナルのMC68000は、3.5μmルールのHMOSプロセスで製造された。技術サンプルは
> 1979年末に出荷された。

6809の失敗は8086/8088と競合して性能で負けたから。
命令体系が美しくても性能で負けたらプロに選んでもらえない。

6809はアドレッシングモードが強力なのは認めるが特定のレジスタへの操作には
プリフィックスが使われたりで命令体系は美しくはないと思う。

当時Z80の命令セットをマスターした者はその後は何を見ても美しく思えたという。

>>53
それはない。
68Kもあまり美しくないと思うし、86は当時で一番糞だし、
その後もPICは歴代世界最凶だし、ARMもダメ。
なんだかんだで、ルネのH8とかSHはわりといい。
H8あたりは、まだアセンブラでのコーディングを想定してたのかな。

68000も、初期はまだマシではあった気がするが、その後の拡張はヒドイのが少なからず。

68000は最初から致命的なバグがあり、すぐに68010が出たがこれもいまいちだった。

致命的なバグのあった製品があんな長期にわたって生産され続けるわけない

>>34
> ハードマニュアルの、「ポート機能使用時の注意事項」
> という落とし穴があるので、ご注意ください。
ご忠告ありがとう。何かと思ったら結局はバイトアクセスという件ね。
78K0 から使ってるんで、その辺は知ってましたわ。
RX もおもしろいね。高級言語用であろう BOOL 値生成的な命令とか1バイトでジャンプできる命令とか。
ただ、マイコンのせいではないけど、C ソース内にアセンブラが書きにくいんだよね。
V850 も使ってたけど、もう RISC はただ不便なだけにしか感じないな。

68000の致命的なバグつうのはMMU付けても仮想記憶実装できないというアレだろうな。

初期のカタログに載ってた68000用MMUが間もなくカタログから消えたのはバグのせいか

68000より後の製品ではMOVE from SRだったかが特権命令に仕様が
変わったり互換性も完全ではないし、68000は近代的なOSを動作
させるには検証が今ひとつ足りてなかった感じ。でも組み込み用途
なら不便ない場合も多かったんで商売としては成功した製品だろう。
最初に68000なんて選んじゃったMacなんかはずっとまともなOS乗せ
らんなかったけど。

>>61
その後のインテルの成功とかを考えれば、成功したとはいえないでしょ。
設計の悪さだけが、原因じゃないだろうけど、Macは、CPUが完全に足手まといだったし、
組み込み用での実績なんて、H8にも劣るんじゃないか。

>>62
68000は10年間くらいは販売してたし大成功の部類だろ。家庭用ゲーム機で
出た数も多いけどな。
インテルの対抗する製品といえば80186辺りだが、比較にはならん。

>>61
ジジイの戯言だが...
昔、68000系を使ったスーパーミニ作ってたんよ。
68010はまとも(OSのフルスペックという意味で)にUNIX SVR3 や BSD4.3が動いたよ。
一番良かったのは68020と68030だな。順当に性能が上がった。
68040は酷かった。命令を削ったにもかかわらずスケジュールが遅れに遅れて出てきたESもバグが多くて
なかなか既存ソフトが動かなかったわ。

>>54
当時は半導体の集積度に制約が大きく、美しい命令体系と高性能が両立
しなかった。
CRTの同期信号をPICのソフトウェアで生成して、ピンポンゲームを実現した
記事がトラ技に掲載されて、PICの高速性に感動した覚えがある。
Microchipが当時の命令体系を守った製品をいまでも出しているのはすごい。

>>65
そりゃ、なんか的外れ。
命令が汚いのと性能は、基本的に関係ないでしょ。
86系は、命令体系が汚いせいで性能向上に苦労してるし。
まあ、PICにはPICの良いところも有るが、
あれを良い子には見せたくないから、
できればこの世から早く無くなって欲しい。

メモリが遅くて、しかもキャッシュメモリがなかった8086時代には、8086の命令体系はむしろ高速化に寄与してただろ

深いパイプラインに豊富なキャッシュメモリ、複数命令を並列実行するスーパースカラーなどを組み合わせるいまだからこそ、
あの乱雑な命令体系が足を引っ張ってるわけだけどさ。

8086はもともとつなぎで本命はiAPX432だったはずがこれが大失敗
Z80などの8bitCPUと比べれば8086/8088の命令セットはかなり使いやすい
IBMは8bitパソコンを作ろうとして高性能な8bitCPUとして8088を採用した

http://ja.wikipedia.org/wiki/Intel_iAPX_432

忘れ去られたCPU黒歴史　20年早すぎたCPU iAPX 432
i8080の後継を目指したiAPX 432
http://ascii.jp/elem/000/000/628/628116/

大原雄介みたいな馬鹿の書いた文章を貼る神経が知れない

68000は1MIPSの32bitミニコンのVAX11/780の価格を考えれば画期的なCPUだったんだろうな

http://www.computerhistory.org/revolution/mainframe-computers/7/182/736
VAX 11/780 Computer　Cost $120,000 - $160,000

>>70
インサイドインテルという本にも8086はつなぎで本命はiAPX432だったと書かれてる

1980年頃のメインフレームやミニコンの性能を知ると
386を搭載した32bitパソコンはメインフレームやミニコンメーカーにとっては脅威だったのかもしれない
それより高性能だったUNIXワークステーションはIBMやDECの標的にされたしな

>>71
システムの値段とマイクロプロセッサのそれ比べるってアホですか?

>>72
つなぎだ本命だという以前に製品カテゴリが全然違うよ

忘れ去られたCPU黒歴史　20年早すぎたCPU iAPX 432
2011年08月22日 12時00分更新 文● 大原雄介（http://www.yusuke-ohara.com/）
http://ascii.jp/elem/000/000/628/628116/
> 　iAPX 432の開発が始まったのは1975年のこと。当時は「Intel 8800」という名前で開発され
> ていた。名前からもわかるとおり、これは「Intel 8080」の後継となることを想定したプロセッサー
> だった(関連記事)。当時、インテルは競合メーカーであったモトローラ「6800」や、ザイログ「Z80」
> との戦いに追われていた。しかもこれらのメーカーは、次世代向けに「68000」とか「Z800」といった
> 後継製品開発を進めていることも知られていたから、これら競合製品に打ち勝てるだけの性能や
> 機能を盛り込むことを考えた。

いくらかでもマイコンの歴史の知識ある人なら↑見ただけでもう読む気なくすだろうな。

>>74
インテルインサイドという本を読めばわかる
そもそもムーアの法則で8bitから16bit、32bitへとどんどん作れるマイクロプロセッサの性能が上がってる
約3万トランジスタだったのが
286が13万トランジスタ、386が27万トランジスタ
8080だって出た当時は400ドルという高価格だったらしい

約3万トランジスタというのは8086のことな
iAPX432より286の方がよっぽど大規模

http://ja.wikipedia.org/wiki/Intel_iAPX_432
＞当時としては最大規模の集積回路設計である。
＞2チップ構成のGDPは合計で約97,000個のトランジスタを集積しており、
＞1チップのIPは約49,000個のトランジスタを集積している。
＞1979年に登場したモトローラのMC68000は、約40,000個のトランジスタを集積していた。

>>76
トランジスタ数約6000で作られた8080の1974年から何年後にiAPX432出すつもりだったって言ってんの??
「ムーアの法則」って内容わかってて言ってる?

だから8086がつなぎだったと言ってるだろ

>>78
ムーアの法則は18ヶ月で集積度が2倍
1981年にiAPX432が出たとして
1981 - 1974 = 7年
7 * 12 / 18 = 4.66
2 ^ 4.66 = 25.28倍
6000 * 25.28 = 151680
だいたいiAPX432のトランジスタ数と一致する

>>79
あいだに出たからつなぎだったっつー理屈なら8048も8255もつなぎだな

>>80
>6000 * 25.28 = 151680
>だいたいiAPX432のトランジスタ数と一致する

「1チップのIPは約49,000個のトランジスタを集積している。」って自分で引用してなかったか？

IPはインターフェースチップ
2個のGDPとIPをあわせるとだいたいそのくらい

別にIntelをディスるつもりはない
386はメインフレームメーカーやミニコンメーカーにとって脅威だったことだろう
OS/2 Ver1.xxが386をターゲットにせずに286をターゲットにして開発されたのはそういうことだろうな

>>83
>2個のGDPとIPをあわせるとだいたいそのくらい

なんだやっぱムーアの法則わかってないじゃんｗ

>>84
>OS/2 Ver1.xxが386をターゲットにせずに286をターゲットにして開発されたのはそういうことだろうな

IBMのPS/2用に開発されたOS/2が当時IBMが採用してなかった386をターゲットにするわけなかろ?

＞IBMのPS/2用に開発されたOS/2が当時IBMが採用してなかった386をターゲットにするわけなかろ?
ググッて出てきた情報か？
OS/2が出た当時、IBMは386PCだしてたぞ
当時の雑誌持ってるからな

>>87
>＞IBMのPS/2用に開発されたOS/2が当時IBMが採用してなかった386をターゲットにするわけなかろ?

すまん記憶違い。

>ググッて出てきた情報か？

ぐぐったらタワー型で出してたみたいだな。メーンは286だったが。

>>66
命令が綺麗とか、直交性が高いとかは、性能の低いＣＰＵの信者の言い訳。

スパコンが手のひらに乗る！

って、いつになったら乗るんだよ！

いつになっても乗らないよ。その時代において「部屋一杯」詰め込める限度がスパコン。

大昔のスパコンのスペックのコンピュータがってんならまだわかるが、今現在のスパコンがってーのは無理だろうなー
限界イッパイでぶんまわすためのあらゆる手段が講じられて成立してそーだし

日本メーカの話がぜんぜん出ない。
日本メーカ製CPUアーキテクチャが後世に与えた貢献は皆無だ。
V30とかHD64180とか、製品化の技術力はアメリカに勝っていたくらいなのに。
ルネサスが左前になるのは当然だ。

>>81
ちょ、8048はともかく8255は単なる周辺チップ、ファミリーチップじゃん

8080用周辺チップだったっけ、8086用だったっけ?

SHなんて触ると、綺麗に書けなさすぎて、
もう高級言語前提なんだなと。
そうなると、機械語なんてどうでもよくなる。
この贅沢者が。

>>94
8080ファミリ。　使い勝手が良いので10MHz対応やQFP化されて、結構な数が使われたよね。
数年前に、どっかのメーカーが71055の代替品？だしてなかったっけ？

>>96
自己解決。　サンハトヤのだった。　高ぇｗ

RL78/I1Dって、もうチップが普通に出回ってるんだな。
いつものごとく遅れるのかと思ってたのに。
http://www.marutsu.co.jp/pc/i/267710/
CS+にも普通にラインナップされてるし。

スペックだけ見てると、「ああ成らないかな」が大体成ってる。
ソフトで動作クロック変えられるなら、
AC電源供給時は高速モード、バッテリで持ち運び時は中速モード、数年間の間欠測定なら低速モードと切り替えられるよね。
ウェイクアップもかなり早いし。

>>89
おれが、直交性が欲しかったのは、ハンドアセンブルに都合がいいからだがｗ、
直交性の考え方は、その後のRISC時代には、性能にも寄与するようになったろう。
68000が性能上がらなくて廃れていったのは、やはり初期に設計したやつの頭が悪かったと思う。
プレゼンテーション的には成功したかもしれないが、他社のCPU設計者から嘲笑されまくったはず。

>>93
HのZTAT。
後世に与えた影響は絶大。

>>99
誰の分析だったか、データパス長（信号線の引き回しの長さ・複雑さ）が680x0の高クロック化を妨げたとされてるね
それと、初期68000の頃と比べて追加された命令群、追加されたアドレシングモード、アラインメント境界の緩和などの影響で、
マイクロプログラムを必要とする場面が増えすぎてたのもネックだったんじゃないか。

命令が複雑すぎてクロックを上げられなかったことが祟って碌に性能が上がらず開発中断に陥った、
ホントにネックだったのは追加されたアドレシングモードの処理の重さだろうよ

たとえば、メモリ間接アドレシングモードなんて処理が重すぎるだろ

x86は20年も前から内部でμコードに変換する仕組みだし、68kシリーズが同じような
アプローチをできていればマイクロプログラムも処理が重いアドレッシングモードでも
問題なしだろう、コンパイラの出力には使われないだろうが。
モトローラが68kシリーズについてはハイエンド製品はそこそこで諦めて060で止め
ちゃったからそういうアプローチを取るまでには到らなかったってだけ。

>>102
その「20年も前」が来る前に消えたから、68kでは集積度の限界ゆえに採用できなかったんだろ

あと5年か10年ぐらい長く生き延びれたら可能だったと思うけど。


つか、そもそも040以降で、一部の重い命令を削除して例外処理ルーチンに飛んでエミュレーション実行するように変えたのも、
命令変換の亜流みたいなものと言えなくもない気はする

モトローラの製品発売の年表を作ってみると

1987 68030
1988 88100
1990 68040
1991 88110
1993 PowerPC 601
1994 68060

68030か040の辺りで68kシリーズについては見切りをつけた感じ。
68060が94年に出てるがこれば開発が遅れた結果だし、x86 ISAで内部でμコードに置き換える
NexGenの製品が出たのも同年だが、モトローラは既にPowerPCに舵を切っていたので68kで
同等のアプローチの製品が出るわけはなかった。

・68k→88k→PowerPC のアーキテクチャの見直しがなく68k一本でやっていたら？
・80860やItaniumのようなアーキテクチャの見直しがあってもx86を潰さずに残したインテルのように
　モトローラにも開発リソースに余裕があったら？

と「もしも」の話題は尽きないが、まあ実際そういうことができなかったが故の結果だろう。

余裕があっても、新規MPUのマイクロアーキテクチャの迷走で使い潰してたかもしれんって気はする。

PowerPCって、IBM POWERに88000の外部バスを組み合わせた程度の、モトローラ製品と呼ぶには微妙なシロモノだったよな。少なくとも初期の数モデルは。