TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼
ビルゲイツに挑戦
コンピューターおばあちゃん
>
EnterキーをRETURNキーと言っちゃう香具師の数→
大昔のコンピュータグラフィックス@クスクス
お前ら活動中の８ビット機ユーザーを教えて下さい。
PC-98の起動音萌え
マハーポーシャの何か持ってた人いる？
ここだけ永久に1995年なスレ【Win95 OSR 5】
コンピューターおばあちゃん

68k v.s. x86 Round 2


1 ：2016/02/11 ～ 最終レス ：2016/03/20
16Bitパソコン時代のMPU/CPU 68kとx86を語るスレです。
68020,386以降の32BitやZ8kや658xの話題もOKです。

前スレッドが落ちてしまったので。

前スレッド
http://hanabi.2ch.sc/test/read.cgi/i4004/1220728356/

2 ：
>>前スレ978
IBM PCの開発が開始された1980年時点では68kは量産出荷されたばかりで
ソフトの蓄積が皆無で難しい。
しかもコストカットのため8086ではなく8BitBUSの8088を採用したのを
考えると68008が存在しないので選択肢にならないだろう。

可能性としては8bitMPUの6809になるがパーソナルコンピュータ分野の
後発ゆえ16Bitを選択したことを考えるとIBM PCがビッグエンディアンの
Motolora系MPUを選択する可能性は極めて低い。

3 ：
>>1 乙
スレって950超えたあとで書き込みないと落ちるんだっけ？？

4 ：
見返せば良い所より悪い所がてんこ盛りな68kは消えて当然だったな。
モトローラが見切りつけて見捨てたタイミングが一番悪いような気もするが。

5 ：
>>3
一般的には980を越えて24時間以上書き込みが無ければ落ちる。

6 ：
インテルもiAPX432や80860やItaniumと、新アーキテクチャへの置き換えは
何度か試みたけど悉く失敗した結果x86が残ってるというだけのことで、
モトローラは88kは続かなかったけどPowerPCは大成功の部類なので、
68kがほぼ滅んだのはPowerPC成功の証でもあるわけよ。

7 ：
MotoloraのPowerPCを大成功と言うのはちょっと過大評価では？
68kが1980年代に圧倒的に押さえていたワークステーション市場は
PowerPCに変わってもSPARC,MIPSに奪われたまま失地回復出来てないし
パーソナル市場は元々持っていたAppleのMACが68kから横滑りしただけで
贔屓目にみてもIntelの攻勢に踏みとどまったというところ。

68kの機能強化は行き詰っていたのでいつまでAppleをつなぎ止められて
いたかは判らないがMotoloraにとってPowerPCは会社寿命を2000年代まで
延命させたというところでは。

せめてPS3,Wii,XBOX360がPowerPCアーキテクチャで制覇された時にそのCPUの
Cell,XENONの供給者になっていたのなら成功したと言えたかもしれないが。

8 ：
「優勝のみが勝者。2位は敗者の1位」みたいな考えだなあ。
20年以上続いてるアーキテクチャが大成功じゃなくちゃ何なのよ。

9 ：
powerpcは組み込み分野で使われとるよ

10 ：
PowerPCアーキテクチャはIBMがPOWERで使ってるよ

11 ：
そもそも 68K も 68340 とかで組込で結構使われてたし
ＰＣやＷＳしか見えてないだけかと

12 ：
FreescaleってNXPに統合したんか知らんかったわ
http://www.nxp.com/ja/products/microcontrollers-and-processors/more-processors/coldfire-plus-coldfire-mcus-mpus/68kmpus-legacy:68K
http://eetimes.jp/ee/articles/1503/05/news078.html

13 ：
何が理由かしらないけど68kが開発元に見捨てられた時点で「失敗」でしょ。
商業的にとか、技術的にとか色々と「失敗」はあるけど。

14 ：
> 68kが開発元に見捨てられた時点で「失敗」でしょ。

「失敗」か「終了」かは意見が分かれそうだが、DragonBallやColdFireも含めれば
68kの寿命って結構長かったぞ。

15 ：
>>14

個人的には「68kは商業的に失敗した」と思ってる。
「豪華な回路が組めるリッチなユーザーだけ使ってくれればいいよ」的なコンセプトは早過ぎた感が否めないし68008が出るのも遅かったと思う。
最初は高速化に注力してたんだろうからタラレバになっちゃうけど68000と同時、せめて80年のうちに68008が出てればインテルは8088で獲得していたシェアをごっそり失ってたとおもうけど、82年は遅かった。

一時は世界を覇したとおもうんだけどねぇ、68k。
ハード的には「今の視点で見れば」悪い点がそれなりにあるのはしょうがないけどエポックメイキングな製品だっただけにモトローラの方針が残念だわ。

16 ：
68008なんてユーザーにとってもメリットがない製品を引き合いに出す意図が理解不能。

17 ：
組み込みの仕事してるけど68kとPPCとARMしか使ったことがない

18 ：
6301, 6809, 64180, 80186, SH-2, 68020 位かな

19 ：
>>16
そういう傲慢が会社潰すのさ。
モトローラはユーザーニーズ蔑ろにしたからシェアなくしたんだぜ。

20 ：
仕事で、なら6800、8080/Z80、68000～68040、V30、PowerPC G3、ARMv4以降だな。
日電以外でV30系はほとんどなかった。
680x0な仕事でROMRAMあわせて1M以下とかだともったいない気がしたもんだ。

21 ：
>>19
68008にユーザーニーズなんてほとんど無かったろう。

22 ：
8088に対抗して「外部8ビット、アドレス20ビットの16ビットマイコンならウチにもありますよ」的な位置づけ以上のものではなかったしなあ ＞68008

23 ：
68008＋8ビットシステムを流用した先行試作機
でソフトを開発しつつ、平行して本番用68000システムも開発、
とかそういうニーズはあったんじゃない？

24 ：
試作用なんて数が出ないもんニーズの内に入らん

25 ：
Motoloraは1979年に6809を出しているから競合する8Bitマーケットに
68008を出す判断を下すのは無理だろうな。

Intelが8088をあのタイミングで出せたのは8085から既に3年経過していて
かつその市場はZilog Z80に奪われていた状況であったから8086を出した後
早期に8Bitから16Bitへ移行するのを促したかったというのあるだろう。

いずれにしろCPUの投入タイミングはMotoloraはIntelに比べて下手だと思う。

26 ：
タイミング下手なのはしょうがないよね。
インテルの進化に比べて目玉商品なかったし。
悪い石じゃなかったかんだがねー、68000。

27 ：
IBMが8088を採用したのは16bitを強調して他社製品との差別化を図った上で
自社製品と競合しない性能の低いプロセッサという条件に合致したからで、
製品自体が優れてたとかそいうんじゃないよね。

28 ：
性能だけが製品評価の基準では無いと思うが。
陳腐な性能であっても必要な時期にその目的に合致したのならば
それはその時点において優れた製品だ。

Intelの目論見通りパーソナル分野の16Bitへのシフトという
目的を達成できたのだから戦略商品として優れていたと言える。

29 ：
当時として68000やZ8000もあったしなあ、インテルの8088の戦略の何が優れていたという主張? 80386の影も形もない頃の8088は将来を見据えたデザインではなかったし、インテルアーキテクチャが現在まで繁栄してる事実は当時からすれば結果論にすぎないよ。

30 ：
>>28
IBMPCよりちょい後だけどMacやAmigaやATARISTに採用された68000は優れた製品だったよね。

31 ：
IBMがPCのプロセッサを決定する際に選択肢に68008があったとしても
それが採用されたかは疑問。
32bitへのラインナップ展開が見えてるアーキテクチャは当時のIBMの
上位製品への脅威となりうるので敬遠されたと思う。

32 ：
>>21
8bit バスで 64KB を越えるメモリーを使いたいって言うニーズはそこそこあったよ
FM-7 とかは 6809×2 にしてたし、MB-S1 は簡易 MMU 積んでたしね
ただ 8088 に比べて 68008 はパッケージがちょっとでかいのと命令セットが 68000 のままなので命令長が長くローコストシステムに使うのはちょっと躊躇する
要するに本来 32bit の CPU を 8bit バスで使うのはあまりにもバランスが悪かった
たらればの話になるがこの分野は 6809 + MMU の方がよかったかも知れない

33 ：
>>32
そんなニーズには8088やV20ですよ！

34 ：
データバス8bit、アドレスバス24bitのニーズねぇ。変態杉だろ。

35 ：
データバス8ビット、でもアドレスバスは16ビットじゃあ足りない、だよ。
どこから24ビットなんて具体的な数字だしてきたん？

36 ：
>>27, >>31
当時の上位機種ってなんのことだ？
まさか System/360 じゃないよな w

37 ：
68kのアドレスバス。
8bitCPUならバンクメモリでいいじゃん。アドレス指定面倒だし。

38 ：
>>35
68008 PLCC 版はアドレス 22bit なので FC 2bit 分足して 24bit って言ってるのかも w

39 ：
>>36
360が販売されてた時代も知らない素人は引っ込んでてね

40 ：
> まさか System/360 じゃないよな w

System/360がどういう位置づけの機種かも分かってないっぽい

41 ：
68kはコマイ基板に使うにはコストパフォーマンス悪すぎたからなぁ。
そしてコマイ仕事のほうが数あったわけだが。

42 ：
>>34
データバス8bit、アドレスバス24bitは65816がそうだけど、
スーパーファミコンで採用されたことで大成功と言ってもいいんじゃね？

43 ：
>>39
ＰＣと違って汎用機はそんなに簡単買い替えられないから '80年半ばまで 360 は普通に使われてたことも知らない知ったか乙 w

>>40
で、どう言う位置付けなのか説明してみ

て言うか、
> 当時のIBMの上位製品
を具体的に書けよ

44 ：
System/360は知らないけど
System 38のプログラマーだったオレが通りますよ

45 ：
NTTやIDOなんかの仕事で68008を4年か5年使ったなぁ。

後継の装置は486だったが。

46 ：
スーファミはROMがカセットだったからピン数減らしたかったとかあるかも。
自分は通信機器メーカーでPowerPCのG3が出た頃まで通信機器メーカーで働いてたが、
中継器みたいなのはデータバス8ビット、アドレスバス20ビット以上なんてのは珍しくなかった。
大量に使われることはないけど、ニーズはあったわけで。
特に社会インフラなモノに最新鋭なんか怖くて使えなかったし。

47 ：
>>43
> ＰＣと違って汎用機はそんなに簡単買い替えられないから '80年半ばまで 360 は普通に使われてたことも知らない知ったか乙 w

自分で「当時の上位機種ってなんのことだ？」って書いたこともう忘れてるのかな？
なんぼ古くても「稼動してるシステム」は「当時の～機種」って認識？頭の病院逝くべきでは？

48 ：
>て言うか、
>> 当時のIBMの上位製品
>を具体的に書けよ

パソコンより上は汎用機しか思いつかない人?

49 ：
組み込み系のニーズ入れたらピンキリだろう。
今は16bitマイコンってほんとニーズない。8bitの次は32bitって感じ。
なのに16bitCPU、DOS時代はエライ長かった。

50 ：
>>47
「普通に」使われてた
って言う日本語は理解できなかったのか？ w
ＰＣとは時間感覚が違うんだよ

で、
> 当時のIBMの上位製品
は、どうしたんだ？
書けないならいちいち絡んでくるなよ

51 ：
>>48
> パソコンより上は汎用機しか思いつかない人?
そんなご託は具体的な名前挙げてからほざけよ

52 ：
ソコン市場形成期におけるIBMの技術戦略
--- the IBM Personal Computer の開発プロセスに関する技術戦略論的視点からの分析 ---
http://www.sanosemi.com/history_of_IBM-PC.htm
> 7.なぜIBMは、IBM-PCに8088を選択したのか？

> ５）同一社内における商品としての差異化のための、技術的性能のスペック・ダウン
> IBM社の製品構成から考えた場合、IBM PCの技術的性能はさほど高い必要は
> なかった。8088というCPUの性能が他の16ビットCPUよりも相対的に低いこと
> は、IBM社内の製品構成から考えると逆にメリットであった。
> 　というのもIBM PCの性能が高ければ高いほど、IBM社の他のマシンンの
> 売れ行きが鈍ると考えられた。というのも、性能的には優れていたが価格が
> かなり高かったからである。そこでIBM PCの開発に当たってIBM PCは
> 「わざと処理速度を落とす」ように設計されたのである。
(略)
> IBM社内の政治力学的配慮の問題に関して言えば、IBM PCに対してメイン
> フレーム・マシンの端末機能をわざと持たせなかったことにもそのことが
> 示されている。様々なメインフレーム・マシンの端末をエミュレートさせる
> 機能をIBM PCに付加するのは簡単だったが、そうなるとIBM社のこれまでの
> 端末ビジネスが立ちゆかなくなるため、結局のところそうした機能は搭載
> されなかった(ロバート・X・クリンジリー(1993)『コンピュータ帝国の興亡』
> 上巻,アスキー出版局,p.210) と言われている。

53 ：
初代IBMPCのMINIX劇遅だったなぁ

54 ：
>この点に関して、ＩＢＭ　ＰＣの開発プロジェクト・チームに最初から
>参加していた技術者のウィリアム・シドネス（Bill Sydnes）は「８０８６の
>馬力はとてつもなく強力なものであった。このチップを利用すれば、ＩＢＭが
>すでに市場に出していたり、またはこれから市場に出そうとしている製品の
>排気口を広げなくてはならなかったろう。だから、私たちは性能は多少落ちて
>も、８０８８を利用することに決めたのである。・・・・この選択は非常に
>賢明なものだったといえよう。なぜなら８０８８を使う意向だといったおかげで、
>ＩＢＭのあらゆる管理網の目をスルスルと通り抜けることができたからだ」
>（ジェイウムズ・クボスキー、テッド・レオシンス著、近藤純夫訳　(1989)
>『ブルーマジックー　---　IBMニューマシン開発チームの奇跡』経済界,p.55）
>と回想している。

開発チームの人が言ってるならそうなんだろう。

55 ：
>当時の上位機種ってなんのことだ？
>まさか System/360 じゃないよな w

うわ！バカがいる！

56 ：
>書けないならいちいち絡んでくるなよ

>そんなご託は具体的な名前挙げてからほざけよ

あなたが馬鹿すぎるからまともに相手にされてないですよ、それくらい気付け。

57 ：
>ＰＣと違って汎用機はそんなに簡単買い替えられないから '80年半ばまで 360 は普通に使われてたことも知らない知ったか乙 w

IBMが360の後継機への置き換えを勧めてたのも知らない人かな?

58 ：
>>44
コレですね。
https://ja.wikipedia.org/wiki/System/38

「当時の上位機種ってなんのことだ？まさか System/360 じゃないよな w」の人は読むと良いかも。

59 ：
>43
>ＰＣと違って汎用機はそんなに簡単買い替えられないから '80年半ばまで 360 は普通に使われてたことも知らない知ったか乙 w

360のユーザーに対してはIBMは後継機種の売り込みとか考えなかったんですね！勉強になります。

>で、どう言う位置付けなのか説明してみ

PCと市場を食い合う危険性を避けるという前提では、System/360はデスクトップのPCかせいぜいミニコン程度のものだったのでは？

>て言うか、
>> 当時のIBMの上位製品
>を具体的に書けよ

勿論System/360ですよね！馬鹿でもわかります。

60 ：
組込みだと8ビットか32ビットかは妥当だとうな分け方だよな。
16ビットと32ビットの調達コストとか考えると16ビット使うより32ビット使ったほうがマシだし。
ソフトの作りやすさもあるけど10年先20年先の保守考えると、ね。

それでも32ビットが安くなるまでは組込み系は16ビットを使うことが多かったのも事実で・・・

61 ：
68000は、出た当初は良かったんだよ、出た当初は。

62 ：
>>52, >>54
都合のいいところだけ持ってくるなよ…
５番目の理由だし、しかもすぐ下に

ただしBill Sydnesのこうした指摘に関してDavid J. Bradleyは否定的である（ http://www.e-insite.net/tmworld/index.asp?layout=article&articleid=CA187350 ）。

って書かれてるし w
どうみても、それまでに書いてある理由（コスト、開発期間、技術スキル等）で 8088 を選択して、そのついでに社内説得の材料にしただけでしょ

>>58
ないない、汎用機程ではないとしても価格が違いすぎる
IBM 5100 シリーズの方がまだ近い

>>55-57, >>59
何も書けないバカは黙ってろよ w

63 ：
> >>58
> ないない、汎用機程ではないとしても価格が違いすぎる

ミニコンの市場なんてとっくにパソコンに喰われてなくなってることも知らん人かｗ

64 ：
>>62
> ５番目の理由だし、

説明の順番として5番目になってるだけで、優先順位的に 5番の理由てのじゃないだろ。

> １）コスト削減
> ２）関連周辺回路の開発期間の短縮
> ３）先行する８ビットＣＰＵパソコンとの互換性問題
> ４）IBMにおける先行プロジェクトの活用 ---- 先行プロジェクトで蓄積された知識・経験・部品の活用
> ５）同一社内における商品としての差異化のための、技術的性能のスペック・ダウン
> ６）オプション部品による性能向上の可能性

65 ：
こりゃメガドラvsPCE並に勝負つかなそうだ

66 ：
>>62
> しかもすぐ下に
>
> ただしBill Sydnesのこうした指摘に関してDavid J. Bradleyは否定的である（ http://www.e-insite.net/tmworld/index.asp?layout=article&;articleid=CA187350 ）。

リンク先見てもそれらしいこと書いてるの見当たらないんだけど、どういう
主張によって否定的であると言ってんの?
「都合のいいところだけ持ってくるなよ…」 と言ってる人なんだし、「～は
否定的である」だけを見てそれに飛びついてるんじゃないよね?

67 ：
Why the IBM PC Used an Intel 8088
http://forwardthinking.pcmag.com/chips/286228-why-the-ibm-pc-used-an-intel-8088
> Dave Bradley, who wrote the BIOS (Basic Input Output System) for the
> IBM PC, and many of the other engineers involved say IBM had already
> decided to use the x86 architecture while the project was still a task
> force preparing for management approval in August 1980.
> In a 1990 article for Byte, Bradley said there were four main reasons
> for choosing the 8088. First, it had to be a 16-bit chip that overcame
> the 64K memory limit of the 8-bit processors. Second, the processor
> and its peripheral chips had to be immediately available in quantity.
> Third, it had to be technology IBM was familiar with. And fourth,
> it had to have available languages and operating systems.
> That all makes sense in leading to the decision for the 8086 or 8088.
> Newer chips like the Motorola 68000 didn't yet have the peripheral
> chips ready in the summer of 1980. And IBM was very familiar with
> the Intel family; indeed Bradley had just finished creating control
> software for the IBM DataMaster, which was based on the 8-bit 8085.
> Bradley says IBM chose the 8088, with the 8-bit bus because it let
> them save money on RAM, ROM, and logic chips.

↑見ると

> ５）同一社内における商品としての差異化のための、技術的性能のスペック・ダウン

については否定的も何も、言及すらしてないね。

68 ：
>>63
パソコンが世に出る前の話をしているのに、お前はいったい何を言ってるんだよ…
さすがにバカすぎるだろ w

>>64
> 説明の順番として5番目になってるだけで、優先順位的に 5番の理由てのじゃないだろ。

重要なものから書くのはこの手の文章なら当たり前だとわかると思うし、概ね妥当な順序だと思う
そもそも
> ただしBill Sydnesのこうした指摘に関してDavid J. Bradleyは否定的である
って言われてるんだよ？

69 ：
>パソコンが世に出る前の話をしているのに、お前はいったい何を言ってるんだよ…

>>54に引用されてる内容で

>ＩＢＭが
>すでに市場に出していたり、またはこれから市場に出そうとしている製品の

と、将来の製品との競合にも言及されてるけど何言ってるの？

70 ：
>>68
> そもそも
> > ただしBill Sydnesのこうした指摘に関してDavid J. Bradleyは否定的である
> って言われてるんだよ？

で、その指摘の内容は？？

71 ：
訂正
誤)指摘の内容
正)否定的とする主張

72 ：
>>68
>重要なものから書くのはこの手の文章なら当たり前だとわかると思うし、概ね妥当な順序だと思う

5)と6)は内容的にある意味相反してるし、順番に意味はないだろう。思いついた順にならんでるだけ。

73 ：
> １）コスト削減
> ２）関連周辺回路の開発期間の短縮
> ３）先行する８ビットＣＰＵパソコンとの互換性問題
> ４）IBMにおける先行プロジェクトの活用 ---- 先行プロジェクトで蓄積された知識・経験・部品の活用
> ５）同一社内における商品としての差異化のための、技術的性能のスペック・ダウン
> ６）オプション部品による性能向上の可能性

David Bradley氏もなんか順番つけて言ってはいるけど、内容的に被ってる
のもあればそうでないのもあるしこの順番に大して意味ないだろ。

> First, it had to be a 16-bit chip that overcame the 64K memory limit of the 8-bit processors.
> Second, the processor and its peripheral chips had to be immediately available in quantity.
> Third, it had to be technology IBM was familiar with.
> fourth, it had to have available languages and operating systems.

74 ：
たしかに、

>１）コスト削減

が最重要項目ならBradley氏がそれを第一に挙げてないのはおかしいね。

75 ：
>>66-67, >>70-71
Ⅹ氏「その理由は、ＡとＢです」
Ｙ氏「その理由は、ＡとＣです」

「Ｂは理由ではないとＹ氏が言ってる」と取るのが普通だと思うが？

76 ：
>>69
どこかのアホは、
> ミニコンの市場なんて「とっくにパソコンに喰われてなくなってる」ことも知らん人かｗ
と書いてたけど？
まだでてもいないパソコンにどうやってとっくに喰われてなくなるのか詳しく説明してみ w

77 ：
> どこかのアホは、
> > ミニコンの市場なんて「とっくにパソコンに喰われてなくなってる」ことも知らん人かｗ
> と書いてたけど？
> まだでてもいないパソコンにどうやってとっくに喰われてなくなるのか詳しく説明してみ w

ああ、本物の基地外か。

78 ：
>>75
Ⅹ氏「ゾウは鼻が長いです」
Ｙ氏「ゾウは体が大きいです」

「ゾウは鼻が長くないとＹ氏が言ってる」と取るのが普通？

79 ：
>>77
> 何も書けないバカは黙ってろよ w

80 ：
>>74
人によって優先順位が違うのは珍しくないだろ

81 ：
>>78
それ違うことについて言ってるよね？
そう言う区別もつかないの？

82 ：
> まだでてもいないパソコンにどうやってとっくに喰われてなくなるのか詳しく説明してみ w

社内から「将来ウチの部門のナワバリ荒らすようになるもん出すのヤメレ」くらいの
批判は起こることくらい当然予想したんじゃないの？

>この点に関して、ＩＢＭ　ＰＣの開発プロジェクト・チームに最初から
>参加していた技術者のウィリアム・シドネス（Bill Sydnes）は「８０８６の
>馬力はとてつもなく強力なものであった。このチップを利用すれば、ＩＢＭが
>すでに市場に出していたり、またはこれから市場に出そうとしている製品の
>排気口を広げなくてはならなかったろう。だから、私たちは性能は多少落ちて
>も、８０８８を利用することに決めたのである。・・・・この選択は非常に
>賢明なものだったといえよう。なぜなら８０８８を使う意向だといったおかげで、
>ＩＢＭのあらゆる管理網の目をスルスルと通り抜けることができたからだ」

ってそういうことでしょ。
で、結局ミニコンはパソコンに喰われることになったわけだけど。

83 ：
>>81
> それ違うことについて言ってるよね？

え？同じゾウについて言ってるでしょ。

84 ：
>>75
> 「Ｂは理由ではないとＹ氏が言ってる」と取るのが普通だと思うが？

じゃあ

> １）コスト削減
> ２）関連周辺回路の開発期間の短縮
> ３）先行する８ビットＣＰＵパソコンとの互換性問題
> ４）IBMにおける先行プロジェクトの活用 ---- 先行プロジェクトで蓄積された知識・経験・部品の活用
> ５）同一社内における商品としての差異化のための、技術的性能のスペック・ダウン
> ６）オプション部品による性能向上の可能性

↑と

> First, it had to be a 16-bit chip that overcame the 64K memory limit of the 8-bit processors.
> Second, the processor and its peripheral chips had to be immediately available in quantity.
> Third, it had to be technology IBM was familiar with.
> fourth, it had to have available languages and operating systems.

↑で互いに言及してないことについては「～は理由ではないと言ってる」と取るのが普通なんですね。

85 ：
8086と8088だとせいぜい2～3割の性能差だよね。
普通に考えるなら、
8086だと競合するからNGで、8088だと競合しないからOKってのは
話としては信憑性が低いと思うんだが…

86 ：
社内的には「性能の低いほうを敢えて選びましたよ」アピールはできるのでは

87 ：
>>72
> 5)と6)は内容的にある意味相反してるし
してないでしょ
最初は色々目をつけられるから、猫被っておいて
実積できて文句言われなくなった時用に性能向上できる仕組みを仕込んでおく
って言うのは普通にやるでしょ

88 ：
>>82
あんたの話は（その当時における）将来の話だよね？
>>63 は「とっくに」って言ってますけど？
ひょっとして「とっくに」って言う意味説明した方がいい？ w

89 ：
初代IBMPCの基板から8087ソケットあるしなあ、
https://en.wikipedia.org/wiki/IBM_Personal_Computer#/media/File:IBM_PC_Motherboard_(1981).jpg
最初は猫被っておいてって感じではないな。

# たくさん載ってるROMっぽいものはBASIC?

90 ：
>>86
仮に自分が担当者（アピールされる側）だったらそれで納得しちゃうわけ？

91 ：
>>88
> > ないない、汎用機程ではないとしても価格が違いすぎる

↑ミニコンとパソコンは価格が違いすぎるので競争にならないと言ってる人に対して

> ミニコンの市場なんてとっくにパソコンに喰われてなくなってることも知らん人かｗ

↑そのミニコンは今(=2016年)はもうパソコンに喰われてとっくに(=今よりもっと以前)なくなってるんですよという話だけど読んでて理解できないの?

92 ：
>>88
> ひょっとして「とっくに」って言う意味説明した方がいい？ w

ゼヒお願い。

93 ：
> ８０８６の馬力はとてつもなく強力なものであった
これを
8086（を搭載した9801無印)の馬力はとてつもなく強力なものであった
と読みかえると違和感ありまくり、決してそんな凄いものではなかったと思うｗ

94 ：
88の3倍くらい速い気がしたからとてつもなく速かったよ。

95 ：
>>94
SR以前の88はあんまり性能良くない…というか基本8001と同じ性能だしね。

96 ：
おれの場合、V30だったけど、あまりの速さにもうアセンブラいらねって当時思ったね。

97 ：
V30の9801VMなんかだと初代9801の2.7倍速くらいだからな、普通に速いだろな。

98 ：
8080と8086比べたら強力だろ。
8080で言うアキュムレーターと同等機能を持つレジスタの数とサイズ、インデックスに使えるポインタの数、ロード・ストア命令で指定できるレジスタとアドレッシング方式の数。
A4の店頭チラシに書かれるようなスペックだけ比べても「意外に違いがないなぁ」ってなりがちだけど。

8086でアセンブラに慣れた人が8080のアセンブラ使ったりするとすごい実感できると思う。

99 ：
>>91
> ↑そのミニコンは今(=2016年)はもうパソコンに喰われてとっくに(=今よりもっと以前)なくなってるんですよという話だけど読んでて理解できないの?
今の話をして何が嬉しいの？
独り言ならチラ裏へ

>>92
とっくに 意味
でググれ

100 ：
もしNECが68k選んでたら、国民機にならなかった。

101 ：
>>84
少なくとも主要な理由ではなかったととるのは普通だと思う

102 ：
>>100
> もしNECが68k選んでたら、国民機にならなかった。
国民機はEPSONじゃなかったっけ？？

103 ：
>>98
そう言う話をしてる訳じゃないし、その方面だとそれこそ 68K の足元にも及ばん

104 ：
NEC は無理としても 6809 使ってた富士通か日立が出すかと思ってたらまさかのシャープだったな

105 ：
実はNECは68020を採用した機種EWS4800を販売している。
まあこのシリーズは後にMIPSに転向してしまうが。

106 ：
>>99
>今の話をして何が嬉しいの？
>独り言ならチラ裏へ

>>58の「ないない、汎用機程ではないとしても価格が違いすぎる」に対して
結果としてじっさい市場喰われたって話だろ。論破されて涙目なってんじゃねｗ

107 ：
>>106
アンカーぐらいまともにつけろよ…
って言うのはおいとくとして

>>58 （当時の上位機種は）System/38 でしょ
>>62 価格違いすぎやろ

>>63 （2016年には）ミニコン市場なんてなくなってるんだぜ、ﾄﾞｬ

で、それが当時の話となんか関係あるんか？

あと本筋と関係ないけど、System/38 はミニコンと言うよりオフコンだな

108 ：
>>107
>このチップを利用すれば、ＩＢＭが
>すでに市場に出していたり、またはこれから市場に出そうとしている製品の
>排気口を広げなくてはならなかったろう。だから、私たちは性能は多少落ちて
>も、８０８８を利用することに決めたのである。

が理解できない人?

109 ：
>>108
何を言いたいのかイマイチ分からんな。

結果として
「もし8086採用だったらミニコン市場が食われてた、当時8088採用したから助かった、セーフ。」
ということだったら理解しやすいんだが、
実際は8088でも8086でも結果は変わんなかったと思うぞ？

110 ：
インテルは既存顧客の継続を考えてたらしいけど、それが事実ならIBMの存在が大きかったんでないの？

111 ：
>>109
>>108の言う「理解できない人」だったかｗ

112 ：
> あと本筋と関係ないけど、System/38 はミニコンと言うよりオフコンだな

https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%95%E3%82%A3%E3%82%B9%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF
> オフィスコンピュータ（略称：オフコン）は、主に中小企業等での事務処理を
> 行うために設計された、比較的小型のコンピュータ。主に日本のみで使われる
> 呼称で、海外ではミニコンピュータ、ワークステーション、ミッドレンジコン
> ピュータなどと呼ばれるコンピュータの一形態である。

113 ：
>>111
一番最初に「分からん」って表明してるんだし、そんなの当たり前だろｗ

114 ：
>>113
「イマイチ分からん」てことは、いくらかはわかったって意味だぞ？

115 ：
>>109
↓の文章は読んで理解できるかな？

>この点に関して、ＩＢＭ　ＰＣの開発プロジェクト・チームに最初から
>参加していた技術者のウィリアム・シドネス（Bill Sydnes）は「８０８６の
>馬力はとてつもなく強力なものであった。このチップを利用すれば、ＩＢＭが
>すでに市場に出していたり、またはこれから市場に出そうとしている製品の
>排気口を広げなくてはならなかったろう。だから、私たちは性能は多少落ちて
>も、８０８８を利用することに決めたのである。・・・・この選択は非常に
>賢明なものだったといえよう。なぜなら８０８８を使う意向だといったおかげで、
>ＩＢＭのあらゆる管理網の目をスルスルと通り抜けることができたからだ」

116 ：
>>115
誇張されたり脚色されたりして出来たデマ、神話、伝説の類の話だと思う、
開発秘話（笑）とかにはよくある。

そういうマーケティング的な理由は、
文系の読み手、書き手が特に好むので広まりやすい。

117 ：
>>108
ひょっとして…
（1980年頃に）8086（とその後継） のマシンが System/38 の市場を席巻することを予見できない奴はバカだ
って言いたいのか？
そりゃ結果知ってりゃなんとでも言えるわ w
そもそも
> ８０８８を利用することに決めた
にもかかわらず席巻してしまってるから、そう言うこと言うならその判断ですら甘過ぎたってことだろ

118 ：
PC最初の立ち上げでは他部門からの横槍が入らないよう敢えてスペックを
低くしたって読み取れないのかな？ほぼ文章書いてる通りだと思うんだが。

119 ：
> 当時の上位機種ってなんのことだ？
> まさか System/360 じゃないよな w

汎用機は現在でも滅んでないし、IBM が当時販売してたのはとっくに
System/360 じゃなくなってるのにこの人どんだけバカなんだろ?

120 ：
>>118
> PC最初の立ち上げでは他部門からの横槍が入らないよう敢えてスペックを低くした

と言う話とミニコンの市場を喰っちゃったと言う話の区別もつかないのか？

121 ：
>>119
何周遅れだよW
何に食いついてるのか知らんけどお前の悔しさはよくわかった

122 ：
>> PC最初の立ち上げでは他部門からの横槍が入らないよう敢えてスペックを低くした
>
>と言う話とミニコンの市場を喰っちゃったと言う話の区別もつかないのか？

「ないない、汎用機程ではないとしても価格が違いすぎる」って書いたこと
もう忘れちゃったのかな？

123 ：
> 当時の上位機種ってなんのことだ？
> まさか System/360 じゃないよな w

1980年頃の話として System/360 を持ち出す意味がわからん。
当時 IBM が販売してたのは System/370 だし、PC と較べるなら
もっと小規模な製品があっただろう。ネタにすらなってない。

124 ：
IBM 5120とか挙げてればまだ良かったのにねｗ

125 ：
>>122
> 「ないない、汎用機程ではないとしても価格が違いすぎる」って書いたこと
> もう忘れちゃったのかな？
いったいどう関係すると言うんだろう…

126 ：
>>123
> 1980年頃の話として System/360 を持ち出す意味がわからん。
ＩＢＭの代表機種だから出してただけだろ
ｗ 付きだからどう見てもネタだし、何を必死に噛みついてるのかようわからん

127 ：
>>126
> ＩＢＭの代表機種だから出してただけだろ
> ｗ 付きだからどう見てもネタだし、

>>39や>>40に顔真っ赤にして必死に噛み付いてるところ見ると違うと思うよ。

128 ：
>>36はなんで突然「当時の上位機種」なんて言い出してるんだろう?
アンカー貼ってる>>27も>>31もそんなこと言ってないのにな。
なんか、具体的な製品との競合を避けたかなんかという話と勘違いして一人で暴れてる感じ。

129 ：
８０８８で盛り上がるのはまあわかるが、今更 System/360 に突っ込まないといけないって‥
なんか嫌なことでもあったんだろうな

130 ：
ボケならツッコミは望むところだと思うし、時代はずれのトンチンカンなことなら
突っ込まれるのも当たり前の筈。

>８０８８で盛り上がるのはまあわかるが、今更 System/360 に突っ込まないといけないって‥

なんか、突っ込まれてよほど都合の悪いことでもあったのかなと思ってしまうね。

131 ：
>>130
>>121

132 ：
このスレで直截的にコスト・パフォーマンスについて
言及している輩が一人も居ない件w

133 ：
そりゃ、コストパフォーマンス言い出したら68kがボロクソに叩かれるだけだからたろ。
フラットでリニアなメモリと単純なシリアルみたいなIOだけのレベルですらコストパフォーマンス良くないから、68k。
チップセットの存在はでかいってことで。

134 ：
コスト・パフォーマンスは CPU だけで決まる訳じゃない
なんの前提もなしに言及しても >>133 みたいなアホがしゃしゃり出てきて収拾つかなくなるだけ

135 ：
>>133
アンタは、ヴァカか？
当然、IBMはコスパを意識してコンピュータを作製しただろ。
それを考慮しろと言うだけの話しだよ。

136 ：
コスパはどんな分野でもついて回るからわざわざ話題にしないだけ。

137 ：
>>136
今回のIBMのパソコンについては、重要な因子でしょ。
コスパを抜きにして話しをするのは、アリエナイ。

138 ：
CPU 価格だけ見ても１個買うのと１万個買うのじゃ単価が全然違うし、当時インテルが戦略的な販売攻勢をかけてたって話もちらほらある
ＰＣ全体だと設計者のスキルや、周辺デバイスとかソフトウェアも絡んでくるし
当時の状況を把握してない俺らがどうのこうの言い合ってもなんの結論もでないだろ

139 ：
そろそろまとめるか。

勝者はx86。

140 ：
王者はZ80

141 ：
１９７８　インテル　「８０８６作ったンゴ！」
　　　　　モトローラ「ぐぬぬ・・・」

１９７９　モトローラ「新製品だ、６８０００。こいつはすげぇんだぜ！」
　　　　　インテル　「ふぁぁ！？」

１９８２　インテル　「１８６と２８６つくったンゴ！」
　　　　　モトローラ「６８０１０だ、仮想記憶サポートさせたぜ、使えよ」
　　　　　インテル　「仮想記憶？　仮想マシン！？　ナンデ！？　でもアバーは言わない（ｷﾘｯ!」

１９８４　モトローラ「６８０２０だぜ。完全に３２ビット対応だ、他にもいくつか機能強化したぜ」
　　　　　インテル　「な、んだとぉ！？」

１９８５　　インテル　「フル32ビットの３８６作ったけどよぉ・・・」
　　　　　モトローラ「（ニヤニヤ）」

１９８７　モトローラ「６８０３０だ。MMUとキャッシュ強化したぜ」
　　　　　インテル　「・・・」

１９８９　インテル　「４８６作ってみた。ちょびっとRISCの技術導入してちょこっと高速化したよ」
　　　　　モトローラ「ふぁ！？」

１９９０　モトローラ「未完成だけど６８０４０出荷するっす・・・」
　　　　　インテル　「ふーん？（既に無関心）」

１９９１　モトローラ「６８０００シリーズ止めます、これからはAIM連合でPowerPCっすよ！」
　　　　　インテル　「あっそ」

１９９３　インテル　「ペンティアム作ってみた。　あとナンバーで商標登録止めます」
　　　　　モトローラ「ｱﾊﾞｰ！？」

142 ：
>１９９１　モトローラ「６８０００シリーズ止めます、

68060が出たし組み込み用にECシリーズ続けたしやめてないんだよなあ。

143 ：
>>141
> １９８９　インテル　「４８６作ってみた。ちょびっとRISCの技術導入してちょこっと高速化したよ」

486の高速化のキモって
・キャッシュメモリ導入
・ワイヤードロジックによりマイクロコードを減らした
・数値演算ユニット
この辺りじゃね? 「RISCの技術」って何言いたいのかわからんけど関係ないだろ。

144 ：
>>141
88kとi860がないのでやりなおし

145 ：
>>141
>１９８２　インテル　「１８６と２８６つくったンゴ！」
> 　　　　　モトローラ「６８０１０だ、仮想記憶サポートさせたぜ、使えよ」

Intelの286にはCPU内に仮想記憶機構を組み込まれているんだが。
おそらく141は68010が必要とする外付けMMU68451が提供した仮想記憶機構が
どんなものか知らずに書いてるんだろうな。

146 ：
>>141
> １９８５　　インテル　「フル32ビットの３８６作ったけどよぉ・・・」
> １９８９　インテル　「４８６作ってみた。ちょびっとRISCの技術導入してちょこっと高速化した

発表当時は80386と80486なんだよなあ。
つか80386の前の80286は32ビット要素ないし、「フル32ビットの～」も意味わからんな。

147 ：
> １９８５　　インテル　「フル32ビットの３８６作ったけどよぉ・・・」

80386SXが先に出たとでも思ってるのかな?

148 ：
>>143
486で一部の命令が1クロックで実行できるようになった→なんかRISCっぽい？
って感じじゃないかとｗ

149 ：
32行制限のせいで省略してるし６８ｋに関してはWIKI頼りからね。
指摘どおり「68010の仮想記憶」はカタログにかかれてた以上の事はしらない（あと職場の先輩から「あんなものは使うな」って言われたぐらいか）
んで、386のフル32ビット云々のつっこみが理解できない。
「フル32ビット」の表記はインテルの広告で見たような覚えがあるから使っただけなんだが。

まぁその辺もわかる人、気が向いたらサマリー作ってくれるとなんとなく嬉しい。
俺なんかが書いたのより、よほどまとまりのいいのができるでしょ？

150 ：
>>141
> １９８７　モトローラ「６８０３０だ。MMUとキャッシュ強化したぜ」
× インテル　「・・・」
○ インテル　「え"っ、今ごろ？」

151 ：
>>149
>「フル32ビット」の表記はインテルの広告で見たような覚えがあるから使っただけなんだが。

Introduction to the 80386
http://bitsavers.trailing-edge.com/pdf/intel/80386/231746-001_Introduction_to_the_80386_Apr86.pdf

80386 Hardware Reference Manual
http://bitsavers.informatik.uni-stuttgart.de/pdf/intel/_dataBooks/1986_80386_Hardware_Reference_Manual.pdf

INTEL 80386 PROGRAMMER'S REFERENCE MANUAL
http://css.csail.mit.edu/6.858/2015/readings/i386.pdf

↑の辺りには見当たらん感じだなあ。
そのインテルの広告っての他人が確認できるようお前が挙げなきゃ意味ないだろ。

152 ：
> ○ インテル　「え"っ、今ごろ？」

80386には内蔵キャッシュがなかったのにこの反応はわけわからんな

153 ：
>>151
おーすごいすごい、がんばって次はCM関連あつめてくれ。
俺はやらないけどな！

154 ：
こういうタイプは職場でも無能

155 ：
>>142
68340 とか作ってたしね
中規模の組み込み機器にはそこそこ使われてた
途中で部署変わったからはっきりしないけど、2008 年ぐらいまではうちの製品にも入ってた

156 ：
>>152
MMU の方の話でしょ

157 ：
>>145
> 68010が必要とする外付けMMU68451が提供した仮想記憶機構
なんのことを言ってるんだろう…？

158 ：
フル32bitは、レジスタ、アドレスバス、データバスがすべて32bitって意味だったかな。
xxbitCPUの定義が議論されはじめた時代。

159 ：
自社やライバル会社の製品に「中途半端な32bit製品」がない限りはアピールとして意味ないんだよなあ ＞フル32bit

160 ：
ライバル企業の68kは32bitCPUという表現に対抗しただけだろう。
今のintelはアドレスバス40bit、データバス256bitとか需要に沿って変態進化してて、今だから奇妙に思えるだけ。

161 ：
80386より先に外部も32bitの68020が出てるんで何に対抗してるの? という感じだな。

> ライバル企業の68kは32bitCPUという表現に対抗しただけだろう。

1985年当時として68000のことを32bitと表現して売ってたかな?

http://bitsavers.informatik.uni-stuttgart.de/pdf/motorola/68000/68000_16-Bit_Microprocessor_Apr83.pdf

↑見ると表紙に 16-BIT MICROPROCESSOR と書かれていて、本文中にも

> the MC68000 is a fully-implemented 16-bit microprocessor with 32-bit registers,

とあるから 32bit プロセッサとは謳ってない。

162 ：
>ライバル企業の68kは32bitCPUという表現に対抗しただけだろう。
>今のintelはアドレスバス40bit、データバス256bitとか需要に沿って
>変態進化してて、今だから奇妙に思えるだけ。

当時を知らない若い人かな?

163 ：
そうそう。当時インテルはモトローラなんて相手にしてなかった。

164 ：
月刊マイコンだったか、よくx86叩き、68kマンセー記事をよく見かけたが笑いが止まらなかったのはよく覚えている。
その流れが続いて、Windows叩き、Macマンセーの記事もよく書かれていた。

165 ：
x86は32bitでフツーに使われるまで長かったからなあ。
「速い8086」では笑われて当たり前。

166 ：
速い32bitCPUの需要がなかったにすぎない。

167 ：
フル32ビットは、
8088が16ビットだったり
68K＝32ビット説がそれなりに受け入れられてたり
65816＝Apple2GSやスーパーファミコンが16ビットだったり
NS32016もあった。
○ビットというのがマーケティングに利用された（後年のセガサターンの64ビット級とかが顕著な例）こともあって、
その中で正真正銘の32ビットというのをアピールしたかったんじゃない？

168 ：
>「フル32ビット」の表記はインテルの広告で見たような覚えがあるから使っただけなんだが。

という>>149の思い違いかもしれない事実かどうかもわからないことに考察とか意味ない。

169 ：
速い32bit CPUの需要はあったがOSもアプリケーションも整備されるのに時間が掛かった。

170 ：
ユーザは持ってるソフトが速く快適に動くことを望んだ。> DOSが動く速いPC。
PGは一度作ればソフトが多く売れるPCを望んだ > x86が乗ったPC。

当時、誰も速い32bitなど望んでいない。ユーザーから68020は相手にされてなかった。

171 ：
> 当時、誰も速い32bitなど望んでいない。

DOSエクステンダ使ったCADとか普通にあったけど知らんのねｗ

172 ：
>ユーザーから68020は相手にされてなかった。

へー

https://ja.wikipedia.org/wiki/MC68020
>使用例
>コモドールのAmiga、アップルの Macintosh II と Macintosh LC といった
>パーソナルコンピュータだけでなく、サン・マイクロシステムズのSun-3
>ワークステーション、ヒューレット・パッカードのネットワークアナライ
>ザーなどにも使われた。
>フランスのTGVでは、線路を通して列車に送られる信号のデコードにこの
>プロセッサを使用していた。戦闘機ユーロファイター タイフーンの操縦
>制御システムでも使われている。

https://ja.wikipedia.org/wiki/NEWS_(%E3%82%BD%E3%83%8B%E3%83%BC)
>当初のモデルは16-25MHzで動作する68020か68030を2基（1基はCPU、1基は
>I/Oプロセッサ）を搭載していた

173 ：
やはり笑える。当時と同じで68kマンセー君が意味不明に必死杉w
まだ負けたことがトラウマなのだろうw

174 ：
>当時、誰も速い32bitなど望んでいない。

標準でDOSエクステンダ採用したFM-TOWNSの例もあるのに。

175 ：
>>173
x86方面からも

176 ：
>>173
x86方面からも68k方面からもフルボッコにされてるけど気が付かないんかな?

177 ：
> ユーザは持ってるソフトが速く快適に動くことを望んだ。> DOSが動く速いPC。
> PGは一度作ればソフトが多く売れるPCを望んだ > x86が乗ったPC。
>
> 当時、誰も速い32bitなど望んでいない。ユーザーから68020は相手にされてなかった。

自分が知ってることだけが全てって感じの人だなあｗ

178 ：
おまえの知ってることは重箱の隅みたいなものでみなどうでもいいことだってこと。

だから市場から消えたのだよ。アップルもシャープも68kを見捨てた現実を思い出すといいw

179 ：
>おまえの知ってることは重箱の隅みたいなものでみなどうでもいいことだってこと。
>
>だから市場から消えたのだよ。

お前この板の趣旨理解してないね?

180 ：
68kの怨念を晴らすスレだったね、ごめん。

181 ：
なんか、憐れになってきた

182 ：
だよな。何度議論してもx86が勝つという結論は変わらないし。

183 ：
自分が開発したわけじゃないのに
勝ち誇る意味がわからん

184 ：
自身の過去の実績とかを誇れない奴は使ってた道具とかにすがるしかないんだろうな。

185 ：
ベンツ乗ってるとみんなよけるんだよね。なんか勝った気がするじゃん。それと同じ。

186 ：
>>170
こういう恥の多い人間がのうのうと生きていくためには、憐みの目で見られていることすら
気付かない、図太い神経が必要だという分かりやすい事例

187 ：
俺もベンツだけは避けるようにしてる
特に最近のあのデカいロゴは威圧感あるんだよな

188 ：
>>171, >>174
メモリーがもっと必要だっただけ
32bit パワーが求められたわけじゃない

189 ：
>>188
32bit なくしてメモリーをもっと使える方法があったなら教えて

190 ：
68kユーザだったけれど32bitだとは思わないぞ030以降は除く。

191 ：
今の基準はレジスタ幅だから今の基準でいうと、68kはやっぱり32bitCPUだよ。

192 ：
>>189
セグメントレジスタ。さらに横に1bitずらす。

193 ：
>>192
じゃあ80286で十分てことじゃん。実際そうはならなかったが?

194 ：
>>191
> 今の基準は

誰かそんな話してる?

195 ：
マルチタスク、GUIするには当時の32bitCPUは遅すぎた。なのでDOSが速いことが一番重要だった。

196 ：
>>191
> 今の基準はレジスタ幅だから

同じプロセッサでも使うモードのレジスタ幅の違いでプロセッサの分類が変わると?
そんな馬鹿なことあるわけないじゃん

197 ：
>>195
> マルチタスク、GUIするには当時の32bitCPUは遅すぎた。

当時の32bitプロセッサでUNIXとか便利に使えてたけどね。

198 ：
大学にあったNECのEWSとか遅くて死にそうだった。100行もないソースのコンパイルも随分待たされる。たまに落ちて授業が中断してた。
486乗った98も大量にあったけどDOSは爆速だった。GUI、マルチタスクが使えると思ったのは、メモリ64MB、CPU200MHz超えてからだね。
仕事でNT4.0使うようになってから。

199 ：
68020のWSにシリアル端末20台くらいつなげてソースのエディットや
アセンブル、リンクとかしてたけど落ちたりはしてなかったなあ。
速度はまあ速くはなかったが同時にCPU使う処理がそう重なることも
なかったし普通に使えてたわ。

200 ：
93年くらい?に386に8MBのメモリのPCでYggdrasil使ってたけどけっこう快適だったなあ。

201 ：
仮想86モードを使ったマルチDOSセッションとかだ重いものになるけど、
マルチタスク自体は機能としてとても軽いもの、
組み込み向けOSとかOS-9/6809とかでも使えたし、
それによるオーバーヘッドもほとんど無視できるレベル。

202 ：
相変わらず68ｋのお葬式会場というか６８ｋファンの愚痴たれながし会場なのね、ここは。

203 ：
>大学にあったNECのEWSとか遅くて死にそうだった。100行もないソースのコンパイルも随分待たされる。たまに落ちて授業が中断してた。

メモリ足んなかったんじゃね

204 ：
68kって80年代半ばから90年代初めくらいまでは結構活用されたシステム
であることは事実なので、いくら個人の体験で使えなかったと言った
ところでそらおまえのいたところでは使いこなしができなかったんだろ
という話にしかならんな。

205 ：
68kが使えないプロセッサだったのは個人の体験から言える列記とした事実なんだよなぁ。
68kしかしらないやつが遠吠えしたところで歴史は変えられないんだよなぁ。

せめて68020が68000として世に出てれば話しは違ったんだけどな。

206 ：
>>204
ワークステーションではMIPSやSPARCに、パソコンはx86に全然負けてる使われ様でしたが、どころらへんが「結構活用された」んでしょうか？

207 ：
>>206
80年代半ばにSPARCstationが存在したどこかの平行宇宙の方ですか?

208 ：
>>193
286 はリアルモードに戻るのが面倒だったことも知らんのならいちいち絡んでくるなよ

209 ：
>>208
面倒つってもそれ用の機構は用意されてたし当時のDOSで問題あるわけないんだよなあ。

210 ：
>>197
GUI 使ってた？
>>199 みたいにシリアル接続なら 68010 のＷＳでもそこそこ使えてた
でも GUI となると全然ダメ
解像度がＰＣに比べて高かったしフルビットマップだったしろくなアクセラレータもない時代だからしょうがなかったけど

211 ：
>>206
SONY NEWS, Mac とかも知らんのか？
あとお前は知らんだろうが組込用に VME Bus board 製品が結構使われていた

212 ：
>>209
CPU には用意されてないよ
リセットするしかないんだから
ソフトでリセットするハードを追加してリアルモードに戻れる様にしてたけど、当然すごく遅いのであまり実用的でなかった

213 ：
>>212
> ソフトでリセットするハードを追加してリアルモードに戻れる様にしてたけど、当然すごく遅いのであまり実用的でなかった

https://en.wikipedia.org/wiki/Protected_mode
> Later, a triple fault was used to reset the 286 CPU, which was a
> lot faster and cleaner than the keyboard controller method
> (and does not depend on IBM AT-compatible hardware, but will work
> on any 80286 CPU in any system).

214 ：
>>205
何がどう使えなかったのかな？笑わないから言ってみ
それと、代わりに何を使っていたかも言ってみ

215 ：
>>213
>> Later, …
　~~~~~~

216 ：
そもそもOS/2とかXENIXとか使えばリアルモードに戻らなくても良いんじゃないの？

217 ：
実際に68kつかってて「これは素晴らしい！」とか言うのは洗脳されてるモト信者だけだろ。
その信者の集まりがここだから「68ｋは完璧すごいプロセッサ!！」みたいなノリになりがちだが。

218 ：
WSにしろPCにしろ広い分野で使われてたのはある意味すごいけどどれもこれも中途半端だったよな、68k。
インテル抑えてたのは組込み分野とPDAぐらいか？

219 ：
結局8086か68Kかはメモリをどれだけ積むかじゃない？
4MB以上なら68Kの方が良いし、
4MB以下なら8086+バンクメモリ（EMS含む）もありかも、
1MB以下で良いなら8086の方が良いと思うわ。

220 ：
>>215
ちょっと何言いたいんだかわからんな。Later って書いてあるけどもちろん
>>212の投稿 2016/02/21(日) 22:02:26.36 より前の話だぞ?

221 ：
>286 はリアルモードに戻るのが面倒だったことも知らんのならいちいち絡んでくるなよ

古い知識披露して恥掻いちゃったネ

222 ：
>>185
一般人の間では　ベンツ＝ヤクザ　だからな。
避けるのは当たり前。

223 ：
>>216
OS/2はDOS互換環境を実現するためにリアルモード環境に戻る必要性がある。
まあOS/2，Windows共に最初から286を無視して386のみに限定すれば
良かったのだが無謀にも286をサポートしたために後々まで苦しめられることになった。

224 ：
> まあOS/2，Windows共に最初から286を無視して386のみに限定すれば
> 良かったのだが

OS/2と同時発売のPS/2で互換機切り捨て路線のMCA機は80286がローエンド
なんだから無視できるわけないだろアホか

225 ：
>>223
http://virtuallyfun.superglobalmegacorp.com/2012/10/26/ibm-os2-1-1-extended-edition/
> First off the IBM versions of OS/2 1.1 use the 286 triple fault
> method of switching from protected mode to real mode exclusively
> while the Microsoft kernel includes 386 detection & mode switch
> instructions.

226 ：
誰が悪いってIntelが286を仕様欠陥品としてディスコンにしなかったから。

227 ：
GUIって言ってもUNIXでターミナルでvi、cc走らすのと、NTでIEやOffice、VS走らすのじゃ必要リソース全然違うね

228 ：
triple fault で全部解決って思ってるアホがいるみたいだが、CPU をリセットしないとダメなのは変わらんしキーボードコントローラ使ってリセットするよりはマシって話だからな

229 ：
>>220
お前こそ何を言ってるのかさっぱりわからんのだが？
いつの話をしてるつもりなのか年号書いてみ

>>221
煽ることしかできないアホは要らないから w

230 ：
>286 はリアルモードに戻るのが面倒だったことも知らんのならいちいち絡んでくるなよ

>CPU には用意されてないよ
>リセットするしかないんだから
>ソフトでリセットするハードを追加してリアルモードに戻れる様にしてたけど、当然すごく遅いのであまり実用的でなかった

>まあOS/2，Windows共に最初から286を無視して386のみに限定すれば
>良かったのだが無謀にも286をサポートしたために後々まで苦しめられることになった。

>triple fault で全部解決って思ってるアホがいるみたいだが、CPU をリセットしないとダメなのは変わらんしキーボードコントローラ使ってリセットするよりはマシって話だからな

ホントこいつバカｗ

231 ：
>いつの話をしてるつもりなのか年号書いてみ

「後々まで～」なんて書いてるアホがなんか言ってるなｗ

232 ：
>>223
DOSセッション使わなきゃ良い。
なぜそこまでDOSに拘るんだ…

233 ：
>286 はリアルモードに戻るのが面倒だったことも知らんのならいちいち絡んでくるなよ

>CPU には用意されてないよ
>リセットするしかないんだから
>ソフトでリセットするハードを追加してリアルモードに戻れる様にしてたけど、当然すごく遅いのであまり実用的でなかった

>まあOS/2，Windows共に最初から286を無視して386のみに限定すれば
>良かったのだが無謀にも286をサポートしたために後々まで苦しめられることになった。

>triple fault で全部解決って思ってるアホがいるみたいだが、CPU をリセットしないとダメなのは変わらんしキーボードコントローラ使ってリセットするよりはマシって話だからな

○○のひとつ覚えｗ

234 ：
>>232
>>170みたいなこと本気で信じてるからでしょ

235 ：
>>232
当時、DOSソフトが世界最強だったから。
Windows発売時、ゲイツが日本来て、ソフト販売ランキング一位がVzで顔をしかめたぐらい。
ちなみにそのランキング一覧に68kのソフトなど一つも入っていない。

236 ：
286は高速8086と使い方が主流だったと思うが？
バード的なバンク切り替えなEMSだったしな。
286はリアルモードで使うのが現実的。
68000もスーパーバイザーモードのみで使うのが現実的…

237 ：
486でも高速な8086という使い方が主流でしたよ。
OS/2、Windowsにはまだまだバワー不足。

238 ：
>>235
そりゃ日本じゃ国産のDOSマシシが売れてましたからね。

239 ：
>>234
486辺りはWindows3.xあたりがちらほら使われてましたが。
日本語だともっさりでしたけどね。

240 ：
>>224
営業戦略上できないことは承知の上で言うが最上位機のモデル80(386搭載)
のみを対象としていればすんだこと。
実際PS/2の最下位機種のモデル30は対象外だ。
まあ現実には多数存在するPC/AT機をOS/2対象外とするのは出来なかった。

241 ：
そしてユーザーからはOS/2が対象外にされた。

242 ：
>>230
プロテクトモード下にあるOSが保護の全く働かないリアルモードに
戻らなければいけないというのがどれ程の愚行であるのかが理解できないのか。

243 ：
>>230, >>233
お前（等？）は一体誰と戦ってるんだよ
敵は一人と思い込むタイプか？

> ホントこいつバカｗ
> ○○のひとつ覚えｗ
⇒ 煽ることしかできないアホは要らないから w

244 ：
>>231
> 「後々まで～」なんて書いてるアホがなんか言ってるなｗ
そんなことを書いた覚えはないんだが w
まあ、どうせ答えられないんだろ？
だったらおとなしく ROM ってろ

245 ：
>>244
お前が>>223じゃないなら笑われてるのはお前じゃないから安心してりゃいいんじゃね？

246 ：
>>242
ユーザーの求めてるものが

>ユーザは持ってるソフトが速く快適に動くことを望んだ。> DOSが動く速いPC。

という前提ではOSの保護による安全性なんてのは二の次だろ。

>>x86は32bitでフツーに使われるまで長かったからなあ。
>>「速い8086」では笑われて当たり前。
>速い32bitCPUの需要がなかったにすぎない。

>メモリーがもっと必要だっただけ
>32bit パワーが求められたわけじゃない

だそうだし。

247 ：
その通りですよ。286でOS/2だなんて何かの精神修行ですか？

248 ：
>メモリーがもっと必要だっただけ
>32bit パワーが求められたわけじゃない

という主張に於いては80286は正義なんだよなあ。

249 ：
ゲイツ「パソコンのメモリは640KBもあれば十分。」

250 ：
>>249
ソースがないんだよなあ

251 ：
>>249
有名なエピソードだよね。

252 ：
>>250
おそらくDOS動かすにはとかの文脈だろうな。ゲイツはガチPGだからな。

253 ：
>>230, >>233
リアルモードに戻る必要性は286が対象外になった時点で解決したが
286をサポートした結果作成されたカーネルの16Bitコードが95以降にも残って
その結果リソース問題を引き起こし不安定化の原因につながったので
後々まで苦しめられたと評したのだが。

もし9x系で青画面もフリーズも経験しなかったと言うならば
その幸運にあやかりたいね。

254 ：
「セグメントレジスタ。さらに横に1bitずらす。」とか言ってたバカがなんか言ってらあｗ

255 ：
>>245
まあそうだな
見境なしのバカに噛みつかれたと思うことにするよ w
どうせもう一匹のバカ（別人かどうかは知らんが）は恥ずかしくてレスできないだろうし

256 ：
8086のセグメントレジスタってそうやってアドレス拡張したんだけど。
リニアのフラットアドレスしか触ったことない子かな？

257 ：
95の要件が386以降なのだから、16bitコードは削除して32bitコードに書き換えればいいだけ。
なぜそれをしなかったのか。理由は簡単。

258 ：
>8086のセグメントレジスタってそうやってアドレス拡張したんだけど。
>リニアのフラットアドレスしか触ったことない子かな？

386のセグメント理解してない子かな？

259 ：
>なぜそれをしなかったのか。理由は簡単。

「書き換えればいいだけ」なんて簡単なもんじゃなかったからだよ。

260 ：
残念。プログラマも夜は寝たかったからが正解。

261 ：
>>256
セグメントレジスタずらしたところで1セグメント=64kBの制限は変わらんし、
Windowsのリソース不足って1セグメント=64kBの制限が原因なんだが解って
ないなｗ

262 ：
>>248
>> メモリーがもっと必要だっただけ
>> 32bit パワーが求められたわけじゃない
> という主張に於いては80286は正義なんだよなあ。
機能的にはね
ただその増えたメモリーを使うと従来のモードに戻りにくいって言うのが決定的に痛かった
セグメント方式のメモリーマネジメントシステムとしては結構良くできてたから尚惜しかったわ
インテルとしては
> そもそもOS/2とかXENIXとか使えばリアルモードに戻らなくても良いんじゃないの？
って思ってたんだろうね

263 ：
1セグメントで足りないなら2セグメント使えばいいじゃん。
そもそも1seg=64kb制限ってwin95ってリアルモードで動いてんの？その辺詳しく教えて。

264 ：
>なぜそれをしなかったのか。理由は簡単。
NT系統を売りたかったと言う理由かな？
MSの意向がそれならば俺はまんまと嵌められて
NT4.0と2kを買ったことになるな

265 ：
>インテルとしては
>> そもそもOS/2とかXENIXとか使えばリアルモードに戻らなくても良いんじゃないの？
>って思ってたんだろうね

80286って1セグメント64kBに収まるタスクを複数走らせる大規模組み込み用を
意図した製品だし、OS/2とかXENIXみたいなそれ以上のメモリを使用するデザインの
OSの使用はもともと想定外だろ。

266 ：
>>253
９５の頃にはすでに NT 3.5 が出てたから >>264 の言うようにそれに移ればよかっただけ
まあＯＳの堅牢性は上がったけどメーカーもＮＴを家庭で使うことをあまり想定してなくて
某エプソンのモノクロインクジェットプリンタドライバのせいでブルースクリーンを見るはめになったわけだが…Ｗ

267 ：
>>266
NT用ドライバーがあったのならよかったじゃないか。
当時NT系を選択するとサポートされているデバイスが限られて
結局9x系も使わにゃいけなかった。

268 ：
セグメントレジスタがセレクタになってる、ぐらいのっこみがはいらないとか、レベル低すぎ。
リング3な奴らばっかりだな！

269 ：
Windows3xのリソース不足にはほんと泣けたわ。
95以降では泣いた覚えないけどな！

270 ：
>>267
プリンターは物理インターフェースは標準的なもの（当時はセントロ準拠）だし、エプソンやキャノンはビジネスプリンターも売ってるから比較的早い時期からＮＴもサポートされてたよ
独自インターフェースのデバイスは言われる通り全滅に近い状態だったけど

271 ：
9xはスルーしてNTからだわ。おまえらほんと根性あるな。

272 ：
>>265
OS/2 はハイエンド向けだけど、XENIX は初期の版だと 8086 ですら動作するぐらい軽いＯＳだよ
そもそも Unix の思想が小さなツールを組合わせて使うって言うものだから 80286 にはマッチしていると思う
そうは言っても GUI となるとさすがに荷が重いが

273 ：
>>268
セレクタになっても２８６のセグメントサイズは最大６４Ｋのままだが？

274 ：
セレクタになっても、ジャなくて、セレクタって単語出てこない時点でお前らレベルがリング3なんよ。

275 ：
DSとESとが使えたからってのもあるけど、セグメントリミットが64kとかたいした制限にはならなかったよな。
奇数番地からのワードアクセスで例外起こすほうがよほどにクソだわ。

276 ：
>>268
インテル（日本法人）が発行していた60386プログラマーズ・リファレンス
マニュアル内でもセグメントレジスタ（第2章)と記載していてプロテクトモードの
説明の時(第5章)に初めてセレクタと表現されるのでレジスタの呼称としては間違いではない。

277 ：
60386とな！？

386が出て移行は286のもセレクタだろ？

278 ：
>60386とな！？

68306をウッカリ逆から書いちゃっただけだろ。嫌味な揚げ足取りするなよ。
http://cache.nxp.com/files/32bit/doc/ref_manual/MC68306UM.pdf

279 ：
>>274
セレクタって言いたいだけだろｗ

280 ：
俺は386のマニュアル読んだときに「プロテクトモードではセレクタにします」と受け取ったんだが違うの？
286だとリアルでもプロテクトでもセグメント、386以降だとセグメントとセレクタとになる、っての？
そっちのほうが不自然だろ・・・

281 ：
>>278
単なるミスタイプだったんだが逆読みしてPDFまで探し出して来たのには敬意を持ってしまったわ。

>>280
あくまでレジスタの呼称はセグメントレジスタ。(2-3-2)
保護モードの時にはRPL(Bit0,1),GDTorLDTの選択(Bit2),GDTorLDTのディスクプリタの位置(Bit3～15)から
構成されたセレクタがセグメントレジスタに収められている。(5-1-3)
まあモードが変わるごとにレジスタの名前が変わってはたまらんが実際はその時の状況で
混在して使われている。

一応参考PDF：http://css.csail.mit.edu/6.858/2015/readings/i386.pdf
（PDF内検索で5-1-3以前に単語Selectorが使われているとツッコミを入れてくるのがいるだろうな。）

282 ：
>>280
プロテクトモードではディスクリプタテーブルで定義されたセグメントをセグメントレジスタに格納されたセレクタ値で指定する。

283 ：
>>275
メモリが少なけりゃそうなんだけど、
例えば（一つのアプリで）8MBのメモリが使えるのに、
スタック領域は変わらず64KBの制限があったりするのは不便で、
富豪的プログラミングじゃないけど、
「8MBも使えるんだから」ローカル変数で100KBくらいの配列を確保したいとか、
スタックを数MBくらい使う深い再帰のアルゴリズムを実行したいとか思っちゃうのは自然、
ってところで32ビットが必要になってくる。

284 ：
奇数番地のワードアクセスとかどうやってどうCPU実装すりゃいいんだよw
考えただけでもぞっとするわw 分解してアクセスしてからから後でレジスタに突っ込むのかw
常識的にそんなコード書くなw

285 ：
http://www.openspc2.org/reibun/FutureBasic2/easy9/easy9.html
>CPUが68000のマシンでは奇数番地を読み出すとエラーになってしまいますが、
>68020以降およびpowerPCでは問題なく読めます。ただし68020, 68030, 68040
>マシンでは速度が低下してしまいます。

286 ：
http://homepage2.nifty.com/m_kamada/docsproc/68060_05.htm
> 68060 は 68020～68040 と同様にワードまたはロングワードのデータの
> アクセスで奇数アドレスを指定できるので、PC を奇数にしようとした場合以外
> でアドレスエラーが発生することはありません。

287 ：
Pen100MHz
24 X86 :MOV r8, [m8] L: 19.96ns= 2.0c T: 5.01ns= 0.50c
25 X86 :MOV r16, [m16] L: 19.96ns= 2.0c T: 19.96ns= 2.00c
26 X86 :MOV r32, [m32] L: 19.96ns= 2.0c T: 5.01ns= 0.50c

ワードアクセスだけやたら遅い。

288 ：
Intelは486以降ACビットとAMビットを操作すればアライメントチェック例外を
発生できるようになったけど68020以降は無条件でアライメントチェックは
なくなってしまったの？

289 ：
>>287
オペランドサイズプリフィックスの影響が出てるんじゃ？

290 ：
68kはプログラマー側から見ると率直な32bitCPUだからプログラムが組みやすい
I/Oをメモリーマップドのみだから純粋なC言語だけで対応できる

x86は16bitCPUかつセグメントやI/O操作にアセンブラ併用が必須だからメンドイ
386移行はリアルモードとプロテクトモードとか初期化しないと32bitになってくれないしとにかく煩雑で使いにくい

291 ：
アライメント例外は使うことなかったな。
必要性が判らん。

292 ：
煩雑なのはOS開発してる人だけ。ユーザーは過去の資産も使えるカッコイイCPU。それがx86。

293 ：
>>290
IOは普通にライブラリ関数、わざわざインラインアセンブラで書く意味ないだろ。
cでセグメント操作明示的に行うとかDonだけシビアなのさ。
それでないと仕様満たさないとかだとしたら、それは根本的なところがクソな仕事ととしか言えないわ。

294 ：
>>283
たしかに再帰使うとスタックが64kはせまいね。
関数呼び出しの時点でスタックセグメント切り替えるコード吐くコンパイラはなかったのかな？

295 ：
>IOは普通にライブラリ関数、わざわざインラインアセンブラで書く意味ないだろ。

組み込みじゃ普通。標準で提供されるライブラリ関数の実装がインラインアセンブラだったりするし。

https://www.lsi-j.co.jp/products/lsic86.html ←「図1. ソースプログラム」参照

out のたびにアドレスとデータをスタックに積むかレジスタに設定するかして
関数をcallなんてやってられんだろ。

296 ：
組み込みだったらなおさら再帰とかあり得ん。

297 ：
>たしかに再帰使うとスタックが64kはせまいね。

そもそも再帰なんて使うのが間違い。

298 ：
たった数レスなのに
・再帰でスタック領域が云々
・組込みで I/O アクセスが云々
がごっちゃなる奴もいるんだなｗ

299 ：
>>290
はぁ？
DOS時代のCのソース見たこと無いだろう。
I/O操作なんて普通に関数呼び出しだしセグメント：オフセットからなる
ポインタはfarやhugeといった修飾子は付くが普通に取り扱えたが。

もちろんasm文なんかもあったがもっぱらアセンブラによる高速化目的で必須ではない。
（例；配列で構成された多倍長整数の演算等）

どちらかと言えば68kで採用されているメモリマップドI/Oで保護,監視はどうしてるんだ？
プロテクトモードを有するx86は286だとI/O命令全体を例外処理したり
386以降はI/Oマップを使って個別のポートに対してきめ細かに例外発生の有無を設定できる。

当然スーパーバイザモードを有する68kも当然出来るとは思うが68030のMMUを使ってもアドレスは
ページ単位の管理だろうしMMUを持たない68000-68020などはどうしているのか判らないので
是非教授して欲しい。

>>291
後にx86にSIMD命令がサポートされた時に
アライメント不正を一般保護例外で処理した
ぐらいだからIntelも忘れてしまっているのでは

アライメント例外もフォールト動作ではなくトラップ動作なら
コードのアクセス速度低下要因警告として使えたのかもしれないが。
（まあ少しテクニックを使えばトラップ動作と同等の処理は出来るけど）

300 ：
>>294
> 関数呼び出しの時点でスタックセグメント切り替えるコード吐くコンパイラはなかったのかな？
メモリーモデルとして compact とか large を指定すればいけるんじゃね？
やったことないけど…

301 ：
>>299
> MMUを持たない68000-68020などはどうしているのか判らないので
> 是非教授して欲しい。
I/O 領域はスーパーバイザデータとしてしかアクセスできない様に設計するのはごく普通
「ユーザーモード」や「スーパーバイザモードでもその領域を実行しようとしたら」バスエラーになる

302 ：
>>299
>I/O操作なんて普通に関数呼び出しだし

I/O操作関数がCで書けないことについての不満や疑問はないのかな? だったらまあその程度の使い方しかしてなかったんだなとしか。

303 ：
>>299
>もちろんasm文なんかもあったがもっぱらアセンブラによる高速化目的で必須ではない。
>（例；配列で構成された多倍長整数の演算等

Cで書けるものを例に挙げて何が言いたいのやらｗ

304 ：
>>302
> I/O操作関数がCで書けないことについての不満や疑問
って例えばどういうのがあるの？

どうせ移植性の無い機種依存部分になるんだし、
標準Cで書けないことに不満とかは無いけどな。

305 ：
>って例えばどういうのがあるの？

例えばGPIOで実装されたSPIバスへの操作をCで書くとして、I/O操作のたびに
関数呼び出しが発生して性能が出ない、なんてのは普通にありそうなもんだがな。

306 ：
>>305
それならインラインアセンブラで書いたマクロとかインライン関数で良いじゃないか。

307 ：
x86は16bitCPUかつセグメントやI/O操作にアセンブラ併用が必須だからメンドイ
↓
I/O操作なんて普通に関数呼び出しだし
↓
I/O操作関数がCで書けないことについての不満や疑問はないのかな?
↓
って例えばどういうのがあるの？
↓
例えばGPIOで実装されたSPIバスへの操作をCで書くとして、I/O操作のたびに関数呼び出しが発生して性能が出ない
↓
それならインラインアセンブラで書いたマクロとか

馬鹿丸出しｗ

308 ：
>>305
えーとそれx86か68kかってのと関係ある？

309 ：
>>307
あ、299の人とは別人です。誤解させちゃったか…

310 ：
x86は16bitCPUかつセグメントやI/O操作にアセンブラ併用が必須だからメンドイ
↓
IOは普通にライブラリ関数、わざわざインラインアセンブラで書く意味ないだろ。
↓
I/O操作関数がCで書けないことについての不満や疑問はないのかな?
↓
って例えばどういうのがあるの？
↓
例えばGPIOで実装されたSPIバスへの操作をCで書くとして、I/O操作のたびに関数呼び出しが発生して性能が出ない
↓
それならインラインアセンブラで書いたマクロとか

馬鹿丸出しｗ

311 ：
ていうかinpとかoutpとかインライン展開されないコンパイラとか見たこと無いけど。
メモリマップトI/Oへのバースト書き込みが最適化で消されてはまったことならある。

312 ：
>>308
理解できない人はこの議論に加われない人

313 ：
バイナリをすらすら読める重要性をやっと理解してくれたか。

314 ：
>ていうかinpとかoutpとかインライン展開されないコンパイラとか見たこと無いけど。

お前が知らないだけ。

315 ：
>>311
> ていうかinpとかoutpとかインライン展開されないコンパイラとか見たこと無いけど。
大抵は標準ヘッダーでそうなってるし、
自前でインラインアセンブラを使ってそうなるように書くことも出来るだろね、
それが出来ないなら組み込み向けのコンパイラとしてはあきらかに不適格と言っていい。

> メモリマップトI/Oへのバースト書き込みが最適化で消されてはまったことならある。
#pragmaなんちゃらで最適化を制御すれば良い。

どっちも大した不都合では無く、些細なことだと思うんだがなぁ…

316 ：
> メモリマップトI/Oへのバースト書き込みが最適化で消されてはまったことならある。

I/O の定義に volatile 書いてなかっただけだろ。

317 ：
>ていうかinpとかoutpとかインライン展開されないコンパイラとか見たこと無いけど。

Cygwin の gcc 4.9.3 で
#include <intrin.h>

int hoge(void)
{
　　outp(0, 0);
　　return inp(1);
}

を gcc -O2 -S hoge.c した結果が↓
_hoge:
　　　　subl　　　$28, %esp
　　　　movl　　　$0, 4(%esp)
　　　　movl　　　$0, (%esp)
　　　　call　　　_outp
　　　　movl　　　$1, (%esp)
　　　　call　　　_inp
　　　　addl　　　$28, %esp
　　　　ret

VC++2010Expressだと↓
_hoge　PROC　　　　　　　　　　　　　　　　　　　　　　　　; COMDAT
　　　　xor　　al, al
　　　　xor　　edx, edx
　　　　out　　dx, al
　　　　mov　　edx, 1
　　　　in　　al, dx
　　　　movzx　eax, al
　　　　ret　　0

318 ：
>自前でインラインアセンブラを使ってそうなるように書くことも出来るだろね、

インラインアセンブラが使えるかはコンパイラ次第。

>それが出来ないなら組み込み向けのコンパイラとしてはあきらかに不適格と言っていい。

DOSで動いてるPCでシビアなI/O操作が必要な場合もあるので組み込み向けコンパイラに限ったことではない。

319 ：
>>318
> DOSで動いてるPCでシビアなI/O操作が必要な場合もあるので組み込み向けコンパイラに限ったことではない。
まぁ、たしかに…
DOSにしろWindowsにしろインラインアセンブラも使えないようなコンパイラをあえて選択する理由は無いのかも。

320 ：
>>301
ユーザーにはI/O操作は最初から与えられてないということでいいのかな。
それならばユーザーがメモリマップドI/O空間を不正にアクセスしたのをどう検出するの。

68000のレジスタを見る限り特定のアドレス空間をユーザーアクセス不能に設定する特殊レジスタは見あたらないのだが。
外部ロジックでアドレスラインとFC0-2でも使って不正アクセスを検出してMPUに通知するのかな？
もしそうならば外部支援無しの単体ではシステム資源保護は出来ない欠陥MPUということになってしまうが。

>>302
DOS時代はBorland系のCを使っていたが普通にインライン展開をしてくれていたはずだから
特に意識してなかったな。

>>303
当然Cのコードで記述できるが。
例で挙げたものは多倍長加減算の配列要素ごとの演算で発生するキャリー,ボローを抽出して
上位桁の計算に伝播させるのをCで記述した結果冗長で速度が出ないコードになるのを
回避する目的でアセンブラ最適化するわけで速度を気にしない教育学習目的程度のものなら
そのままCの記述でする。
文中の『必須ではないが』というのが見えてないようだな。

>>309
>>307は昨日の>>230,>>233だろ。
そんな煽り野郎は無視しとけ。

321 ：
>文中の『必須ではないが』というのが見えてないようだな。

文中の、『もっぱら』以外の例を挙げてくれるのかな? とおもったら
挙げられた例はどうでもいい内容だったという指摘だけど、理解
してるかな?

322 ：
>DOS時代はBorland系のCを使っていたが普通にインライン展開をしてくれていたはずだから
>特に意識してなかったな。

意識してなかったから「インライン展開をしてくれていたはず」なんだろ。

323 ：
>DOS時代のCのソース見たこと無いだろう。
>I/O操作なんて普通に関数呼び出しだし

>DOS時代はBorland系のCを使っていたが普通にインライン展開をしてくれていたはず

どっちも「普通に」と言ってるのが興味深いなｗ

324 ：
そういえばDOS時代になってほとんどプログラム書かなくなったな。
X68KやMacと違って良質なフリーソフトが大量に供給されたからな。

325 ：
良質なフリーソフトが勝手に生えてくると思ってる人かな

326 ：
おそらくx86のほうがプログラムが組みやすかったのだろう。

327 ：
この頃はエディタの優劣で開発効率が決まる。
Unixがショボイのばかりなのはviのせい。

328 ：
>>320
> もしそうならば外部支援無しの単体ではシステム資源保護は出来ない欠陥MPUということになってしまうが。
そんな極端なことを言い出したら大抵の汎用プロセッサは外部支援なしの単体ではメモリーアクセスすら出来ない欠陥 CPU と言うことになってしまうが？ w
方法はいくつかあるけどアドレスデコードの条件にＦＣを加えるだけで対応してる機器が多いと思う
（ユーザーモードでアクセスするとデバイスから DACK が返らないので、タイムアウトでバスエラーになる）

329 ：
Cコンパイラはプリプロセッサ活用すると面白いことが色々できるからなー。
c=(inp)(port); で関数呼び出し、 c=inp(port); でインライン展開とかやってる処理系もあったな。
コンパイル時のオプションでインライン展開優先にするか関数呼び出し優先にするか、みたいな切り替えできるのもあったし。

話しはズレるが、C言語でプログラム書けるというならmalloc()/free()とinp()/outp()と、あとprintf()系ぐらいは独自実装できなきゃな。

330 ：
ｃｒｔ0も実装できなきゃなってか？

331 ：
>>327
初期のMS-DOSのEDLINも操作性は相当駄目かと。
一時はDOS上にCP/M86エミュレータを載せてCP/M86版WordMasterを使っていたぐらいだｗ

332 ：
>>328
>そんな極端なことを言い出したら大抵の汎用プロセッサは外部支援なしの単体ではメモリーアクセスすら出来ない欠陥 CPU と言

>うことになってしまうが？ w
MPU/CPUがバスをドライブする為にトランシーバーやバッファを用いるのは設計上当然のこと。
その当然のことを論拠にして68000がメモリマップドI/Oを保護する機構をMPU内に持たず
外部ロジックに頼らなければいけない設計の言い訳にしてるのは反論としてもちとなさけないｗ
（外部回路にしなければいけない合理的な理由があるのならこの文は撤回するよ）

CPU単体で保護が実現できる286は68000より3年も後発のCPUだから保護機構設計に関して
有利であったとはいえるが68010でも対策されてないようだから根本的にシステム資源（I/O）を
保護しなければいけないという考えが欠落してるみたいだと思う。

まあ286もI/O命令をすべて例外処理というのは多少乱暴であるとは思うが古典的設計の
I/OマップドI/Oの利点の一つだな。

333 ：
>>330
むしろ、理由があって標準スタートアップを使いたくない
→標準ランタイムやヒープの初期化が行われない
→標準のmallocが使えない
→標準のprintfが使えない（一時バッファをmallocで確保してたりする）
→自前のmalloc,printfを使わざるをえない
というパターンが多いんじゃね？

334 ：
>>331
EDLINは行テンプレートが使えるから、
ラインエディタとしては（UNIXのEDやCP/MのEDに比べ）操作性良いほうなんじゃね？
正規表現が使えないので機能的には残念だけど…

335 ：
なんでIO処理をインライン関数なりマクロなりで定義しておくとか、独自ライブラリにまとめておくって言う手抜きをしないのかね？
1回書いてしまえばどんな実装だろうとあとは呼び出すだけだろうに。

それとも独自ライブラリ使えないしょぼい環境使うしかなかったとか・・・？

336 ：
> なんでIO処理をインライン関数なりマクロなりで定義しておくとか、独自ライブラリにまとめておくって言う手抜きをしないのかね？

誰もそんなこと「しない」なんて言ってませんよ?

337 ：
>>336
文面から『「都度つど書かなきゃいけない＝毎回書かないとだめで」面倒』て受け取れたからね。
まさかその「1回かいてしまえば」が面倒と言うならそれはプログラマーとしての適正が疑われるよ。

斜めに見れば「独自のIO関数かけないx86糞」って言いたいだけとも受け取れるけどね。

338 ：
68kに限らずI/Oがメモリ空間にマップされたアーキテクチャでは例えばレジスタを

typedef struct {
　　struct {
　　　　uint8_t recv;
　　　　uint8_t send;
　　} data;
　　union {
　　　　struct {
　　　　　　uint8_t valid:1;
　　　　　　uint8_t busy:1;
　　　　　　uint8_t :6;
　　　　};
　　} status;
} register_t;
#define register (*(volatile register_t*)0x12345678)

こんな感じで定義して

while (!register.status.valid) {
　　;
}
uint8_t data = register.data.recv;
while (register.status.busy) {
　　;
}
register.data.send = data;

こんな感じにアクセスするのとかって普通にやってると思うけど、
「1回書いてしまえばどんな実装だろうとあとは呼び出すだけだろうに」って人は
I/O空間にマップされたI/Oへの操作は例えばどんな感じで書いてんの?

339 ：
よく知らないんだけどx86も640KB-1MBにIOがマップされてたんだよね？

340 ：
>>332
> MPU/CPUがバスをドライブする為にトランシーバーやバッファを用いるのは設計上当然のこと。
想定通りのレスで笑たわ
わざわざ「汎用プロセッサ」って限定してる意味もわかってないんだろうな w

> 外部ロジックに頼らなければいけない設計の言い訳にしてるのは反論としてもちとなさけないｗ
アドレスデコードって書いてあるの見えるか？
大抵の 80286 システムもこの「外部ロジック」に頼ってメモリーアクセスしてるんだよ
それにＦＣを加えるだけ
極論すればアドレス線が増えたのと変わりない

> （外部回路にしなければいけない合理的な理由があるのならこの文は撤回するよ）

> まあ286もI/O命令をすべて例外処理というのは多少乱暴であるとは思う

お前さんが書いてる通りだろ
一部の I/O アクセスをユーザーモードでやりたい奴がいるかも知れない
細かく制御したいなら MMU 付ければいいだけ

341 ：
>>338
汎用の指定番地を指定サイズで読み書きする、それこそinpやoutpなんかと同等が一番手抜きだった。
デバイスに合わせればそれぞれ。
ビジーなら触らずに抜けるとか待ってからとかそれぞれだから。
たまにエンディアン変換しなきゃならない間抜けの尻拭いとかもあるし。
好みの問題もあるけど、構造体をマクロ定義しておいて、展開はまずやらない。
ソースにコメントがっちり書いとく。
後で見たとき判りやすいから。

342 ：
>>339
メモリ空間のとこでもおける。
IOマップトIOのことと勘違い、かな？

343 ：
>>339
x86はアーキテクチャでは無くCPUなのでアーキテクチャによって異なるが、
IBM PCにしろPC-98にしろ、メモリマップドIOはほとんど無いんじゃないか？
IOカード側(ISA,Cバス)のIOカード上に実装されたメモリの一部が
この領域で見えるのは良くあるが。例えばBIOSとか、VRAMとか、共有メモリとか。

344 ：
>>343
> IBM PCにしろPC-98にしろ、メモリマップドIOはほとんど無いんじゃないか？
VRAM って歴とした出力デバイスだと思うが…

345 ：
>>338
#define REGISTER_PORT 0x1234
#define REGISTER_DATA (REGISTER_PORT+0)
#define REGISTER_STATUS (REGISTER_PORT+1)
#define REGISTER_VALID 0x80
#define REGISTER_BUSY 0x40

while (!(inp(REGISTER_STATSU) & REGISTER_VALID))
;
uint8_t data = inp(REGISTER_DATA);
while (inp(REGISTER_STATUS) & REGISTER_BUSY)
;
outp(REGISTER_DATA, data);
だろ。

そのレベルのコードで一番分かりやすいのは、
結局ベタベタのアセンブラのコードだと思うけどね。

346 ：
>>345
ポートやその中のビットの定義が増えてくとドンドン辛くなる書きかただね。

347 ：
>>346
例えば？

348 ：
・どのポートは何ビットでアクセスするのか
・どのポートにどのビットが対応してるか
なんてのがプログラマが任せになってるね。

349 ：
>>348
むしろその方がいい。
同じポートでも読み書きやその順番や回数で違った意味を持つことがあるのがI/Oデバイスだから、
中途半端に抽象化しようとするより、
そのままを明示的にコーディングしたほうが読むときに分かりやすいし、デバッグもしやすいし、バグも減るよ。

350 ：
馬鹿はこれだから困る

351 ：
プログラムは判りやすいのが一番。

x86でアセンブラでプロテクトモードと格闘するのだけは、もうやりたくない。

352 ：
JavaもCOBOLも触りたくない。

353 ：
>>338はレジスタの定義とそれを操作する実装とを分離して取りうる組み合わせの間違いを排除しるけど

> 中途半端に抽象化しようとするより、
> そのままを明示的にコーディングしたほうが読むときに分かりやすいし、
> デバッグもしやすいし、バグも減るよ。

おまえ基準ではそうなのかもね。

354 ：
>>338
おそらくは680x0想定のコードだとは思うが少し違和感を感じてしまったので少しツッコミを。
register_t構造体内のdataはおそらくstructでなくunionだとは思うが（スルーする>>345優しいなぁ）
#define register (*(volatile register_t*)0x12345678) はちょっと。

8BitのI/Oデバイスの様だから0x…78ではなく…79としておいた方が良いと思う。
もっともそれならば構造体のdataとstatusの間にアドレス調整のchar gap;をいれておかないと
いかんけどね。

まあこのコードが6809で語られているならば何も言う必要はないが
一応このスレは68k vs x86だから実務経験を疑われないように。

355 ：
>>343
>IBM PCにしろPC-98にしろ、メモリマップドIOはほとんど無いんじゃないか？
一応メモリマップドI/Oが使われていた実例としてNECの9821のPEGCや
グラフィックアクセラレータカードで使われていた。
しかし後の9821にCirusLogicのChipが搭載された時には元のI/OマップドI/Oに戻ったので
この頃のNECは何考えていただろうと思ったものだ。

356 ：
>>354
> register_t構造体内のdataはおそらくstructでなくunionだとは思うが（スルーする>>345優しいなぁ）

送信と受信のレジスタが共用されてる場合もあればそうでない場合もあると思うけど「structでなくunionだとは思う」理由って何??

357 ：
>>354
> 8BitのI/Oデバイスの様だから0x…78ではなく…79としておいた方が良いと思う。
> もっともそれならば構造体のdataとstatusの間にアドレス調整のchar gap;をいれておかないと
> いかんけどね。
>
> まあこのコードが6809で語られているならば何も言う必要はないが
> 一応このスレは68k vs x86だから実務経験を疑われないように。

浅い実務経験しかないんだなあという印象

358 ：
> #define register (*(volatile register_t*)0x12345678) はちょっと。

数字の並びからアドレスに意味がないことを見て取れないとは頭の程度を疑わざるを得ないな。

359 ：
>>353
>>338はレジスタの定義とそれを操作する実装とを分離して取りうる組み合わせの間違いを排除しるけど
register.status.busy = 0
とかを、全然排除できてなくない？

360 ：
>>359
それは禁止されてる操作なの??

361 ：
8086で0x00,0x02,0x04にデバイスのレジスタがマッピングされてる、なんて例があったな。
今は昔の（携帯事業から撤退しちゃってる）某社から出てたPHS端末で、中身はまんまPCの回路流用かよ！？って突っ込みいれたくなるROM/RAM配置だった。
VRAMエリアがそのままLCDにメモリマップトIOになってたりとかキーボードのポートにテンキーからの入力つながってたりとか・・・
BIOSやらOSやらはさすがに独自だったけど。

362 ：
>>354
> まあこのコードが6809で語られているならば何も言う必要はないが

アドレス空間が 32bit の 6809 が出てくるまでお前はレス禁止な

363 ：
>>361
>8086で0x00,0x02,0x04にデバイスのレジスタがマッピングされてる、なんて例があったな。
680x0(60を除く)なんてそのためmovepなんて変態的な命令もあったんだが。

364 ：
>>356
8BitDataでかつ構造体内にrecv,sendとあれば
普通真っ先に連想するものがUARTかACIAというところ。
まあstatusのビットが一致してるのかは知らないけど。
電子化した雑誌資料を調べるのも面倒なんで。

365 ：
>>364
余計なツッコミを食らう前にUARTはUSART(8251)に訂正しておこう。
まあ本命はACIAの方だと思っているが。

366 ：
別に UART (16550A) でいいと思うぞ
ってか DOS/V 機ならむしろこっちの方が普通だったと思うし
ただ 16550A を含めてこの手のデバイスで送受信レジスタのアドレスが別の奴は見たことない
世の中には俺の知らないデバイスもあるとは思うけど…

367 ：
配置されてるアドレス見りゃ実際のものでないことはすぐに理解できると思うんだが
レジスタの定義を実在の何かと思い込みたい奴はアスペかなんかかな

368 ：
UARTは書き込みでコマンド、読み出しでステータス。
書き込みで送信、読み出しで受信。
レジスタ減らせばそれだけになるからねー。

369 ：
UARTかどうかすらも言及されていないものをそれと決め付けるのは
頭の固い年寄りであることの証左

370 ：
CPUから見て、SIOでもPIOでないIOデバイスがどれぐらいあるのかなぁ。

371 ：
> SIOでもPIOでないIOデバイス

また変な決め付けﾜﾛﾀｗ病院Rｗ

372 ：
「例え」という概念が理解できない人なんだろうなあ。

373 ：
>>371
ふーん？
決め付けというなら、本当の所をちゃんと説明できるんだよね？
説明してみ。
笑ってやるから。

374 ：
> 説明してみ。
> 笑ってやるから。

自分が笑われてること理解してないのかな??

375 ：
>>372
トンチンカンな揚げ足取りを笑われて「実在のデバイスである説」を
引っ込められなくなった様にも見える

376 ：
>>374

> 決め付けというなら、本当の所をちゃんと説明できるんだよね？
への回答が欲しいなぁ。
できないなら謝罪しろよ。
できるなら説明しろよ。

377 ：
「ボクチンの好きなCPU馬鹿にされてくやしいぃ！でも反論できないぃぃ！」
で「決め付けだぁ！」ってわめいてるだけかな？

実務経験皆無というか実際にプログラムした経験があるのかどうかも妖しい半人前以下レベルだがプライドだけは10人前のキチガイかもしれないな。

378 ：
> 決め付けというなら、本当の所をちゃんと説明できるんだよね？

「本当の所」があるという決め付けｗ　馬鹿の考えは想像の上だわｗｗ

379 ：
>>354
「例え」と前置きされて言われてることはその言われてることが全てであって
言及外のことをあれこれ言ったところでツッコミにはならんよ。
例え話が理解できない基地外だなあと呆れられるだけ。

380 ：
50過ぎのジジイだと思うけどおっそろしく頭の固い奴だなあﾜﾛﾀｗ

381 ：
>>366
パラレルを使えば入出力を別々にする場合も可能だったりする。
例えばPPI(8255)でPortA，Bを共にモード1に設定してPortAを入力recv，
PortBを出力sendにするとPortCがStatusになるので>>338の例の形に
することは出来る。
もっともStatusのBit配列は全く異なるから>>338がこれを想定していたとは
考えられないけどね。

まあこのスレ内では>>338のコメントを待たずに説明に使われたデバイスは
実在しないと断定してるみたいだがその根拠が今のところ無いも同然なのが。

382 ：
>>378
決めつけと言い切ってる根拠を教えてくれよぉ、馬鹿にもわかるようにさぁｗｗｗｗ

できないなら「馬鹿にして子面なさい、俺のほうが馬鹿なんです」って土下座して首吊って死んでね。
お前みたいなごみが一人へればそれだけこの世界はマシになるから。

383 ：
>>381
架空のデバイスでかまわないじゃないか。
もともと「こんな感じでコーディングするんじゃないの？」っていうためのモノなんだから。
そこに書かれたソースからどんな動作するデバイスなのか理解できないような馬鹿はここにいないでしょ。

384 ：
>決めつけと言い切ってる根拠を教えてくれよぉ、馬鹿にもわかるようにさぁｗｗｗｗ

際限ない馬鹿への説明は命題的に不可能では？
あるいは、説明をしたら理解する根拠は示してくれるのかな？

385 ：
違和感を感じた時に気が付くべきだったんだがつい構造体dataの方に目を奪われていた。

>>338のコードってもろに処理系依存のビットフィールドを使ってるよな。
68kはビットのナンバリングがLSB=0だけどビットフィールドエンディアンはMSBからだったよな。
（x86系は言うまでも無くLSBから）

すなわちvalid,busyはビットフィールドを使うより古典的に

#define VALID 0x??
#define BUSY 0x??

と定義して使うかもしくは#ifdefでエンディアン毎にビットフィールドを
定義しないと処理系依存コードになってしまうよな。
実務経験を疑う以前にド素人というレベルのコードだったわ。

386 ：
>>385
もともと「こんな風にコーディングするんじゃね？」のサンプルだろ。
そんなのにいつまでも噛み付く玄人さんカッコイイなぁ、いや実に素晴らしいわ。
素晴らしいぐらいに馬鹿だわ。

387 ：
>>384
なんだ、決め付けって言いたいだけのただのキチガイか。

388 ：
>>385
> >>338のコードってもろに処理系依存のビットフィールドを使ってるよな。
> 68kはビットのナンバリングがLSB=0だけどビットフィールドエンディアンはMSBからだったよな。
> （x86系は言うまでも無くLSBから）
処理系依存の意味も理解してない知ったか乙 w

まあ、ステータスを読むだけならいいけど
>>368 が言うようにステータスレジスタとコントロールレジスタが同一アドレスのデバイス（例えば 6850 とか）で
コントロールレジスタの特定ビットを操作したい時とかは使いものにならない
なのでビットフィールドってほとんど使ったことないや

389 ：
>>383
>架空のデバイスでかまわないじゃないか。
架空のデバイスだからこそ一般性とか汎用性とかを求められる、
自分の主張を説明するのに都合が良いだけの、特殊な架空デバイスを持ち出しても意味が無いからね。

そういうことで>>338に関してもUART風のデバイスだと考えて良いと思うよ。

390 ：
>>388
>ステータスレジスタとコントロールレジスタが同一アドレスのデバイス
そこはunionを使えばまだなんとかなるかもと思うけどデバイスが多機能な
グラフィックコントローラーみたいなものだととんでもないことになるね。

例えばPC/ATのVGAアダプタを考えてみるとインデックスは良しとしても
それで設定されるパラメーターをビットフィールドで定義することを考えたら
確実に気が狂ってしまう。

391 ：
>>390
>同一アドレスのデバイスでコントロールレジスタの特定ビットを操作したい
がメインの部分なのに、
>ステータスレジスタとコントロールレジスタが同一アドレスのデバイス
で区切っちゃダメだろｗ

392 ：
>>390
これもIntelの石での説明になるが割り込みコントローラー8259みたいに
設定で連続に複数のパラメータを送り込む必要がある場合には
個別のパラメータのビットフィールドの定義しても意味が無く
ocw1，ocw2，…とunionで定義してもコントローラを設定する時に
Cの文中で今現在設定しているパラメータが何に該当するのかを
明示できる程度の役割にしか使えないね。

393 ：
>>392
×ocw1，ocw2，…
○icw1，icw2，…
連続で設定しなければいけないのは初期化のicwの方だった。

394 ：
> 架空のデバイスだからこそ一般性とか汎用性とかを求められる、
> 自分の主張を説明するのに都合が良いだけの、特殊な架空デバイスを持ち出しても意味が無いからね。

理解不能な理屈だな。キチガイかな?

395 ：
コマンドとステータスが同じアドレスな割込コントローラがががが

396 ：
>>388
>>338は自ら
>68kに限らずI/Oがメモリ空間にマップされたアーキテクチャでは例えばレジスタを
と一般論としてメモリマップドI/Oをコードとして示してるので
エンディアンに依存するビットフィールドを使うのはまずいよな。

リトルエンディアンかつメモリマップドI/OのCPU、例えばARMを想定すれば
このコードが駄目なことは自明。
（別にx86もメモリマップドI/Oの使用は禁止はされてないがレアケースだから例にはせず）
でこういうのを処理系依存と呼ばないならなんて言うんだ？

397 ：
>>396
自ら処理系依存と書きながら
> 68kは（…中略…）ビットフィールドエンディアンはMSBからだったよな。
って決めつけてるところがバカって言われてるんだろ

398 ：
エンディアン違うプロセッサーでソース使いまわすならビットフィールドはＮＧだね。
バグの温床だ。

399 ：
ビットフィールドのビットの並び方は‥
× プロセッサによって異なる
〇 処理系（もっと言うとコンパイラー）によって異なる

400 ：
>>399
ほへ、初耳だ。
それは知らなかった、というか気づかなかった。

401 ：
68kのコンパイラでビットフィールドがリトルエンディアンな
コンパイラは実際にあるの？
あるのならそれはそれで恐ろしいと思うけど。

402 ：
>>396
> >68kに限らずI/Oがメモリ空間にマップされたアーキテクチャでは例えばレジスタを
> と一般論としてメモリマップドI/Oをコードとして示してるので
> エンディアンに依存するビットフィールドを使うのはまずいよな。

なんで??

403 ：
>>401
コンパイルオプションで切り換えられるコンパイラすらある
-mno-reverse-bitfields
-mreverse-bitfields
When enabled, bitfields within a struct are allocated in reverse order. This is useful with legacy code that depends on the (inherently non-portable) ordering of bitfields via a union.

http://www.johnloomis.org/altera/nios2/gnutools/binutils/gcc/Altera-Nios-II-Options.html

404 ：
「68kのコンパイラで～実際にあるの？」という問いにAlteraなんとかを例示する意味が分からん

405 ：
しかもNextで表示される68kのgccオプションの中には
-mreverse-bitfieldsオプションはないんだよな。
68kでの例を示して欲しいな。

406 ：
short a1:1;
で宣言したのって　sizeof(a1)　で返る値ってsizeof(char)と同じ？　それともsizeof(short)と同じ？
決まってないとか、sizeof(short)と同じならバイトサイズのＩ／Ｏデバイスのレジスタ読書きに使うのはＮＧなんじゃ・・・

407 ：
馬鹿がなんか言ってて笑えるｗ

408 ：
"gcc reverse bitfields"でぐぐってみたらパッチをあてて
ビットフィールドを反転させるという事例があるみたいだね。
最初にヒットするのを見ると投稿者からx86で行われていると思われる。

68kでもLSBから始まるビットフィールドオプション対応の処理系があっても
不思議ではないか。
既に存在するなら教えて欲しいな。

409 ：
>最初にヒットするのを見ると投稿者からx86で行われていると思われる。

これ↓ならRX用のパッチみたいだけど?
https://gcc.gnu.org/ml/gcc/2012-10/msg00016.html

410 ：
x86は当分終わりそうに無いが、68000の「失敗」もしくは「終了」って何が原因かねぇ。

411 ：
>>409
投稿者名からx86と決め打ちしていたけど本人のHPに行ったらRX-62Nボード
のページがあるからそっちの方のことか。
RX-62Nのgccは#pragma bit_orderが対応していないと言う国内の記事も
あるからそれに対応したんだろうな。

しかし投稿者名を見た時にDOS時代のgccでは大変お世話になったことを
思い出してしまった。

412 ：
>>410
当時独占していたワークステーション市場をSPARC，MIPSなどのRISC勢に
奪われたのが凋落の始まり。
いわゆるRISC vs CISC論争の波に飲み込まれてしまった。

このRISCに対応してMC88000なるRISC MPUの開発も進めたが
こちらも成功せず（採用はLunaぐらいか）開発のリソースを
68kと88kと2つ進めたことも68kの新作MPUが遅れた原因とも言われている。

あと半導体技術ではIntelni比べて遅れているところがあったようで
発熱問題に悩まされて開発が遅れたという話もあった。

最終的にはIBM，APPLEと組んでのAIM連合を組んだ時に68kは
見捨てられる運命になった。

413 ：
>>412
開発リソース分けちゃったのかー・・・そりゃ無理だわ。

414 ：
PowerPCがうまいこといったんで68kは組み込み用途に舵切って高性能路線はやめただけ。

415 ：
>>413
Intelも色々開発してるけど、
>1990年、i960の設計チームはi386の後継プロセッサの第二設計チームに移行し、
>Pentium Proの設計に携わることになる。
https://ja.wikipedia.org/wiki/Intel_i960
とあるからマネージメント次第？
それとも結局は資金力とかプロセス技術の方が重要なのかも。

416 ：
そりゃ半導体専業のIntelと通信機器が本業で所詮半導体は一部門でしかなかった
Motoloraじゃ力の入れようが違うだろう。
後にMotoloraが半導体事業を切り離すことになったのも本業の通信から
立案されて進められたイリジウムが大失敗した穴埋めだからね。

417 ：
>>413
インテルは 8086 と同時期に iAPX 432 なんてトンデモプロセッサー開発してたりしたけどね w
D-RAM から撤退と言う苦しい決断をしてまで開発リソースをプロセッサーに集中させたのが結果的は功を奏したんだろうな

418 ：
>>403
結局68kでビットフィールドがリトルエンディアンという
68kコンパイラは実在するの？
オプション，#pragmaを使ってでも変更できるものを示せば
この話はそれでお終いなのに。

まあ68kがわざわざそのそうな機能を持つ事ははだはだ疑問なんだが。
例えばバイエンディアンCPUなら両方に対応するためそのような
機能を要求されるのは当然で>>403が示す資料からもIA-64(Itanium)や
をPOWERならオプション-mbig-endian ，-mlittle-endianで選択できる事が判る。

http://www.johnloomis.org/altera/nios2/gnutools/binutils/gcc/IA-64-Options.html#IA-64%20Options
http://www.johnloomis.org/altera/nios2/gnutools/binutils/gcc/RS-6000-and-PowerPC-Options.html#RS%2f6000%20and%20PowerPC%20Options

しかしそれもターゲット次第でルネサスRXシリーズあたりだとバイエンディアンではあるが
パッチ情報の存在からサポートされていないようだ。
ましてはビッグエンディアンの68kがサポートする必然性は無いよね。

このままだと実在しない架空コンパイラというそしりを受けることになるよ。

419 ：
コンパイラが実在しないからと言って規格が変わるわけじゃないんだが
何を言いたいのかさっぱりわからん

420 ：
Cのビットフィールドの順序は処理系依存なんでしょ？
つまりどうでもいいこと。

421 ：
ビットフィールドとバイトエンディアンを微妙に混同してる人がおかしな妄想してるだけ

422 ：
>>421
意味がわからんが・・・？
いったい何が混同するんだい。
struct {
unsigned busy:1;
}register;
で register.busy=1 が0x8000になるか0x0001になるかが処理系依存だからよろしくないってだけだろ。

423 ：
intだって16bitだったり、32bitだったり処理系依存だからよくない!! っことか。そういう人もいるかもね。
おれは処理系依存が多いから逆にCは普及したと思ってる。

424 ：
>>422
>>418 に言えよ

425 ：
> 処理系依存だからよろしくない

まず　処理系依存==悪　という考えが間違い。

426 ：
>>424
なら
> ビットフィールドとバイトエンディアンを微妙に混同してる人がおかしな妄想してるだけ
の「おかしな妄想」って言ってるところ教えてくれよ。
俺なりに「おかしな妄想」てのに突っ込んだだけなんだから。
言葉足らずで噛み付くだとかガキかよ。

427 ：
バイトエンディアンｗｗｗ

428 ：
>>425
「処理系依存」はいうなれば必要悪。
でもすべてが「必要」じゃない。
ビットフィールは「不必要悪」。

429 ：
ビットフィールｗｗｗ

430 ：
便利な機能を不必要と断ずるのが間違い。

431 ：
68k使いはケチくさいなぁ。x86なんてboolean用途で16bitや32bit使うなんて普通だぞw

432 ：
> 68k使いはケチくさいなぁ。x86なんてboolean用途で16bitや32bit使うなんて普通だぞw

RAMが少なくて複数のbooleanをひとつのバイトに割り当てることはありうるし
反対にROMの容量に余裕がなければコードサイズが肥大することを避けるために
複数の変数をひとつに押し込めることをやらない選択もある。
要はバランスだしそういう取捨選択ができない奴は無能なだけ。

433 ：
>>426
>> ましてはビッグエンディアンの68kがサポートする必然性は無いよね。

434 ：
>>418が言うように68kでリトルエンディアンビットフィールドの
処理系の実例を出せばそれでお終いなのになに下らんことやってんだ？
百の論より一つの証拠だろ。

435 ：
>>427
話についていけないの？

436 ：
正直何を揉めてるかさっぱり分らない。

437 ：
>>434
>>419

438 ：
IDがないので誰と誰が揉めてるかも分らない。

439 ：
>>418
CPUと処理系は関係ない、
必用があればx86向けのビッグエンディアン
(int a=0x1234で、*((char*)&a) == 0x12がtrue)なコンパイラを作ることも可能。

エンディアンとビットフィールドも関係ない、
必要があればビッグエンディアンでビットフィールドがLSBから割り当てられるコンパイラを作ることも可能。

ありえないほど意味が無いとしても、
「規格上正しいCコンパイラ」としてそれらを作ることができる。

440 ：
>>435
バイトオーダーとバイエンディアンを混同してる馬鹿を嗤ってるだけｗ

441 ：
>>>403が実在することを匂わせてしまっているからね。
まあ処理系を設計者が勝手気まま設計することは可能だろうけど
合理的思考で設計すればMPU/CPUによって取りうる選択肢は制限されることになるだろう。

442 ：
ドトール傘下のエクセルシオールカフェ赤羽東口店では店員が自分の事、好きだと言い始めたので
優しくしたら他の店員のやっかみ、最低の接客だ

443 ：
バイトエンディアン？
なんか新しい単語だな。
バイエンディアンという用語を理解してないのか？

444 ：
bi-endianかよ。カタカナは紛らわしいな。

445 ：
>>440
それなら「どう混同してて何がおかしいのか」ちゃんと指摘すればいいのに。
ただ笑ってるだけなんて、笑ってるお前のほうが馬鹿に見えるぜ。

446 ：
実際、実務でビットフィールド使うことなんてほとんど無いんじゃね？とは思う。
使ってるのを見たこと・・・なくはないけどごく小数。

447 ：
それなら君が教えればいいじゃないw
分からないのww

448 ：
>>447
なんだ、いつものキチガイか。

449 ：
>>445
自分で勘違いして喚いてる基地外にそこまで親切にしてやる義理は感じないなあ。
「～すればいい」というおまえがしてやりゃいんじゃね?

450 ：
>>439
そりゃ規格で「プロセッサのエンディアンと合致していること」なんてうたってないだろうけど、まっとうな感覚してればプロセッサに合わせるだろ。

451 ：
x86用のプログラム書いてるつもりで
union {
　char a;
　short b;
　long c;
}v;
で v.c=0x01234567; てしたとき v.a!=0x1; でv.b!=0x0123;　な事になるのか。
そりゃ普通ないだろ。つかこんな動きしたら「コンパイラのバグ」だろ。

452 ：
いまごろ一生懸命検索しているのかと思うと涙出てくるよねw

453 ：
unionの定義はオフセットが0だから。

454 ：
規格の話と実際の話を分けて考えられない男の人って...

455 ：
レジスタそのままmovでメモリに突っ込むから、わざわざ途転させる馬鹿はいない。
一体何をモメているんだ。

456 ：
>>446
メモリマップドI/Oの優位性を示すCコードでビットフィールドを使ったら
MPU依存コードだと批判されたので架空の処理系を想定して反論している
という話の流れの中で実際は…と書いても68k狂徒(教徒)は理解してくれないよ。
>>338が68kのコードでは限定していればこんなことにはならなかったのに。

457 ：
>>445
wをとばしている>>440はおそらく>>444で自分の馬鹿さを
認識してるだろうから恥ずかしくてもう出てこれないだろうよ。

458 ：
>>451
ビッグエンディアンの処理系では極自然なことですので理解してあげましょう。

459 ：
>>446
組み込みマイコンか、デバイスドライバー屋さん位だな。

460 ：
>>459
例えば画像処理でピクセルごとになんらかの属性を持たせる場合、
struct {
int flag1;
int flag2;
uint pixeldata;
}
より
struct {
int flag1 : 1;
int flag2 : 1;
uint pixeldata;
}
の方がデータが小さくなる分メモリ容量も帯域も節約(↑の例だと2/3になる）できて、
ピクセルのコピーや移動処理なんかを高速に処理できるようになる。

461 ：
実際ほとんどの実装は、#defineして | するのが一般的。

462 ：
>>457
> wをとばしている>>440はおそらく>>444で自分の馬鹿さを
> 認識してるだろうから

マジ意味わからん

463 ：
>>456
周回遅れすぎるww

464 ：
68k妄信してる奴がキモい。

465 ：
68kの良いところ。
レジスタがでかい。
セグメントリミットがない。
だけか？

466 ：
>>465
直交性

467 ：
>>464
つ[鏡]

468 ：
>>467
な、こういう事するキモいキチガイばっかりするのが68k信者なんだぜ。

469 ：
>>464
>>338のコードを>>385が実在の処理系を例にして批判したら
けちをつけられて反発した68k派が処理系依存という単語を元に
実在の確認されていない処理系で批判してるんだからなぁ…

>>385の主張もビットフィールドの使用を全否定してるのではなく
使うなら#ifdefでエンディアンごとにビットフィールドを定義しろだから
言ってることはまともな方。

どっちがキチガイ度が高いかは明らかだな。

470 ：
> 違和感を感じた時に気が付くべきだったんだがつい構造体dataの方に目を奪われていた。
>
> >>338のコードってもろに処理系依存のビットフィールドを使ってるよな。
> 68kはビットのナンバリングがLSB=0だけどビットフィールドエンディアンはMSBからだったよな。
> （x86系は言うまでも無くLSBから）
>
> すなわちvalid,busyはビットフィールドを使うより古典的に
>
> #define VALID 0x??
> #define BUSY 0x??
>
> と定義して使うかもしくは#ifdefでエンディアン毎にビットフィールドを
> 定義しないと処理系依存コードになってしまうよな。
> 実務経験を疑う以前にド素人というレベルのコードだったわ。

教科書的なプログラムしか知らない実務経験なさそうな感じ。

471 ：
>>469
「68k派」なんてのがこのスレにいると思ってるのはお前だけ。

472 ：
>>469
>>425

473 ：
>>472
> すなわちvalid,busyはビットフィールドを使うより古典的に
>
> #define VALID 0x??
> #define BUSY 0x??
>
> と定義して使うか
これだけを主張しているなら処理系依存＝悪で排除しろ
という偏狭な考えに囚われていると言えるけど

>もしくは#ifdefでエンディアン毎にビットフィールドを
> 定義しないと処理系依存コードになってしまうよな。
こっちの主張はビットフィールドには処理系依存があるからそれを考慮して
#ifdefでエンディアン毎にコーディングしないといけないということだから
処理系依存＝悪とは言ってる訳ではないと思うが。

474 ：
依存性バリバリの使い回しできないソースなんざ墓の中に持ってくぐらいの役にしかたたないしなー。

475 ：
68k依存のソースってもうこの世に消えたんじゃないかと思うぐらいだもんな。
それに比べて依存性バリバリのDOSのソースは未だに最新PCで動くもんなぁ。

476 ：
> と定義して使うかもしくは#ifdefでエンディアン毎にビットフィールドを
> 定義しないと処理系依存コードになってしまうよな。
> 実務経験を疑う以前にド素人というレベルのコードだったわ。

複数の処理系で動作するよう処理系依存を避けるのがプロのレベル、とでも
言いたげだなあｗ　どんだけ暇なんだよｗ　仕事の目的見失ってるだろｗ

477 ：
>>473
> >もしくは#ifdefでエンディアン毎にビットフィールドを
> > 定義しないと処理系依存コードになってしまうよな。
> こっちの主張はビットフィールドには処理系依存があるからそれを考慮して
> #ifdefでエンディアン毎にコーディングしないといけないということだから

処理系依存＝悪 だから #ifdef で場合分けしてでも複数の処理系で通るように
書かないといけないというキチガイの主張そのものだろｗ

478 ：
全員集合スレから逃げてきたのか、通りで。

479 ：
x86なら多くの動作環境，動作モードがあるために例えばDOS(16Bit)，Windows(16,32,64Bit),UNIX(32,64Bit)
どれでも対応できるようにソースの中で#ifや#ifdefでその違いを吸収させるようコーディングしたり
面倒ならば環境,モードを限定してコンパイル時に警告するようにしておくからな。

480 ：
低可読性のソースだから奴素人てんじゃないの？
可読性落としてる原因が処理系依存なとこだっただけで。

481 ：
処理系依存しないコードは理想だけど普通に無理。
その理想を目指したJavaですら、Write once, debug everywhere.　と言われるぐらいVM間の実装差を吸収できない。

482 ：
処理系を統一すればいいだけ

483 ：
>>481
普通に無理だからって、わざわざ依存するソースかくのはどうかと思うよ。

484 ：
おまえはx86なのにビッグエンディアンでも同じように動くコード書くのか？
qsort()すら使えないじゃないか。

485 ：
>>482
現実に出来ない妄想を書いてもなぁ。
病院行って薬貰ってこい。

486 ：
現実はアーキテクチャが統一、とまではまだだが、淘汰と住みわけが進んでるからなー。
ますますビックエンディアンは先細りだよな。
しばらくは無くならんたろうが。

487 ：
クロス開発なんかしてると当たり間のように依存性排除に進むよな。
PC上でデバッグしてクロスコンパイルして実機に・・・なんてやってると。

488 ：
エミュレータ上でデバッグするものじゃないの？

489 ：
>>488
Androidみたいに至れり尽くせりなクロス開発ばっかじゃないの、世の中は。

「OS呼出しはエミュレーションする（ハードウェアレベルは知らん！）」っていうのが、やってる仕事的に多いかな。
これは「C言語のソースレベル」のデバッグで、ぶっちゃければ動いてるのはWindowsやLinuxのアプリだから、当然それようのコンパイラでコンパイルするわけね。
で、「動いた実機に突っ込むぜ～！」ってなっても、ターゲット向けのコンパイルでエラー吐くようならデバッグしてる意味ないでしょ？

潤沢にお金と機材と、たっぷりな時間、があれば事情は違うけど。

490 ：
>>486
おいおい、そんなビッグエンディアンMPUに喧嘩を売るようなことを。
でも昔の感覚だとMIPSとかSparcとかはビッグエンディアンだったけど
今はバイエンディアンになってるみたいだから単独のエンディアンしか
持たないのは古いCPU/MPUを起源とするx86とか68kとかH8あたりか。
それでも過去の流れからデフォルトのエンディアンは今でも
ビッグの方がメジャーだろうな。

491 ：
> これは「C言語のソースレベル」のデバッグで、ぶっちゃければ動いてるのはWindowsやLinuxのアプリだから、当然それようのコンパイラでコンパイルするわけね。

むかしやったクアルコムの携帯の仕事がそんなんで最低だったなあ。今でもそんなクソみたいな仕事あんの?

492 ：
最近は
・単体テストは Windows や Linux
・機能確認はエミュレータ
・システムテストは実機
って言うのが多い
もちろん完全にきれいに別れてる訳じゃないけど

493 ：
>>491
あるよ。
ハードごと新規開発な案件を年に1件ぐらい受けるんだけどお客さんにカネないからこっちも色々切り詰めないとアシがでるんで苦肉の策に近い。

Brewのアレぐらいなら、まだ諦めつくけどもっと悲惨。

494 ：
ここの人は無職かと思ってたよ。

495 ：
無職だよ
想像で語ってんの

496 ：
昼間に書き込んでるのは無職の可能性が高いだろうね。

497 ：
494、495の自演はなんなん？

498 ：
なんなんなんなんなんなんなんなんｗｗｗｗｗｗｗ
どこの奴だｗ

499 ：
ここですら「６８ｋまんせー！」なんてやってるのは、「ボクチンの好きな６８ｋDisるのゆるさなーい！」っつって発狂したキチガイだけになっちゃったね。

500 ：
脳内でそういう輩を設定しないとプライドが保てない人かな

501 ：
現役のx86が過去の遺物と化した68kに対してそんなことをする必要はないよ。
おそらく記憶の中で過度の美化が進行して妄想というレベルにまで達しているんだろう。

502 ：
1980年代は68kは垂涎のCPUであったよ。
でもそれは比較対象が8086,286であったことと、
当時情報は満ち溢れていたものの一般Userが触れることの
出来なかったUNIXが使えることだったから386が登場して
PC－UNIXが使えるようになった時には68kに対する
羨望というものは失われていたな。

503 ：
最初に「良いもの」つくって驕って改良しなかった（できなかった？）のがね。
「継続は力なり」のインテルとは対照的だよね。
386の2年後にでた030が性能で劣るあたりが既にね・・・

504 ：
>>500
んにゃ。
単なる事実。

505 ：
俺が68000の嫌いな所。
ビックエンディアン。
奇数番地からのワードアクセスでバスアライメント例外起こす。
割込みン時に参照するアドレスがROM(電源オンしたばかりの時)
意味不明なユーザーモード。

あとウザイ信者。

506 ：
>>503
でも386ってプログラムキャッシュもデータキャッシュも内蔵してなかったよね？

507 ：
コア性能稼げないからボトルネックのメモリアクセス速くしよう、と言うのは当時としては妥当だね。
2年あとでコア性能負けてるか。
68020がパイオニアとしてのモトローラの限界かね？

508 ：
当時はマルチタスクのUNIXすげーなと思ってたが実際触ると結構不安定だし
使いにくいし遅いしで大したことなかった。まだ軽いDOSのほうがはるかに実用的だった。
NT使うようになってからはUNIXはゴミと化した。NTとUNIXの差がx86と68kの差になったね。

509 ：
UNIXならスパークステーションだな！
個人の好みと趣味で。

あのピザボックスが。

510 ：
なんでcにはnearとかfarとかあったんだ？　隠蔽してくれりゃいいのに。

511 ：
nearだfarだの、わざわざ付けてたの！？

512 ：
>>510
コンパイル時にメモリモデルを指定して、そのまま使うだけなら特に付ける必要はなかった。

けど、物理アドレス（セグメント：オフセット）指定でVRAMに直接アクセスしたいとか、
別のメモリモデルでコンパイルされたライブラリとリンクしたい
とかになると、さすがに付けなきゃどうしようも無い。

513 ：
>>512
別なメモリモデル用のライブラリとリンクなんてトリッキーだな。
far char*で宣言すれば初期化のときぐらいだろ、セグメント意識するのは。

514 ：
16bit時代のx86は
smallモデルでCS=DS=SSにしないとまともにC言語プログラムが組めなかった気がするが
メモリーモデルをHugeだかLargeだかにしてビルドすればそんな事無く near far も不要で普通に使えたんだっけ？

515 ：
>>513
トリッキー…
別のメモリモデルという言い方が悪く、
全メモリモデル用と言った方が良いのかも、普通に
extern char far * far func(char far * s);
のように明示的に指定されてるライブラリのことで、

これをスモールモデルから使うには、
char far * p;
p = func("hello");
とする必用が出てくる。
(戻り値のfarポインタからスモールモデルの既定値のnearポインタに変換すると、
セグメント値が失われて不正なアドレスを指してしまうため。)

516 ：
>>506
x86にキャッシュが載るのはIntel純正CPUは486からだな。
（互換CPUなら386から載せたものもある）

でもキャッシュを載せると発熱問題が顕在化してくるので
クロックの高速化が難しくなるんだよね。
それだけが原因とは言わないが8k(4k+4k)に拡大した68040は
68030の最大クロックを越えることが出来なかった。

517 ：
386のPCの広告にはよくノーウェイトメモリアクセスってあったよ。キャッシュなんかいらなかったのさ。

518 ：
メモリモデルがどうであれ、x86のスタックセグメントは64kだったんだよな。
ヒープばんじゃい!

519 ：
386 33MHz+外付けキャッシュ64KBの機種は結構あった、
98系だとH98 model70がそうだった。

520 ：
>>517
でも初期のタウンズはたっぷりウェイト入ってたな

521 ：
>>514
CS=DS=SSはTinyモデル（.EXEじゃなく.COMのモデル）。
基本的に全てDS=SSで、DS!=SSなのはWindowsのDLLとかの特殊なケース。

コンパイル時の指定は暗黙的にどう扱われるかを指定するだけで、
それ以上の意味はあんまり無い。

522 ：
>>515
そりゃぁfar*で戻してくるなら受け側もfar*にしとかないとダメじゃん。
longやint、shortで戻してくるのをcharで受けるのと同じなんだし。

68kしか使ったことがないと「ポインタのサイズが違う」ってのが目くじら立てる大問題みたいだね。
sizeof(char*)がsizeof(far char*)かsizeof(near char*)なんてのが重大バグの原因になるような奴や、性能が満足に出せない原因になるような奴はそもそもプログラマーに向いてない。

523 ：
>>521
DSで扱うデータが64k超えてるメモリモデル全般でDS!=SSじゃなかったっけ？
初期値はDS=SSだったんだっけ・・・？

524 ：
いかにセグメントがPGを混乱させるかが分るな。

525 ：
>>523
>DSで扱うデータが64k超えてるメモリモデル全般でDS!=SSじゃなかったっけ？
違うよ。

526 ：
>>517
ノーウェイトといっても実際にはFastPageModeでRASが同一でCASだけを
変更できる場合に限られていたような。
RASが変わるならウェイトが入ってしまうので
RASも含めての完全なノーウェイトって当時あったっけ？

527 ：
メモリモデルのラージ、ヒュージはDS!=CSだね。

528 ：
>>525
DS==SSが成り立つのはMS-Cのデフォルトの場合でTurbo-CだとDS!=SSだったりする。
またMS-Cもオプションで変更することは可能。
つまり処理系依存。

529 ：
とりあえずTurboCのマニュアルを引っ張りだしたぞ
http://f.xup.cc/xup6nvbjfex.png
http://f.xup.cc/xup6nvrepob.png
http://f.xup.cc/xup6nvbizbv.png
http://f.xup.cc/xup6nvbitbw.png
http://f.xup.cc/xup6nvbikal.png

530 ：
>>529
ぐっじょぶ！
ミディアムとコンパクトを逆に覚えてた。

smallとlargeでほとんど用がたりたからなー。

531 ：
ぼくにはまだセグメントは早すぎるかもしれない。

532 ：
80286のアセンブリ言語に挫折した僕でも68000なら3日で覚えられました

533 ：
286で挫折ってことは、プロテクトモードがらみ？
だとすると・・・　ﾅﾑｰ、成仏しろよ

534 ：
リアルモードでは単なるセグメントレジスタ操作やセグメント間
Jump/Call命令だったものがプロテクトモードに移行すると
リングプロテクションを伴うレベルチェックやJump/Callでは
タスクゲートやコールゲートも含まれてくるからな。

しかもセレクタ値だけを見ても直感的には判らずセレクタが
指し示すディスクプリタを把握してないといけないという面倒さが。

まあプロテクトモードを最初に触ったのは386で単にプロテクトモードに
移行してプロテクトメモリをアクセスして戻ってくるだけだったから
そんな面倒なことを考えることはなかったけど。

もし386が登場した1985年当時にUnrealMode(セグメントリミットを解除する隠しモード）
の存在が知られていればDOS環境で32Bitレジスタを使ってプロテクトメモリ利用が
楽になったんだろうけど発覚した89年頃にはDOSでのメモリ拡張はEMSが主流になっていて
386でも仮想EMSが使われていたから極めて限られたケースでしか使うことが出来なかった。

535 ：
そう言えば、68kしかアセンブラ知らない奴がWindowsの仮想メモリ理解できなくて逆ギレしてたなー。

536 ：
68kをSHARP X68kで使っていたのならありえる話かもな。
MacはたしかSystem7でサポートしていたはずだから。

537 ：
プロテクトモードを直にさわるなんて勉強でしかやったことないなぁ。
途中で投げ出したし。
そのかわりVCPIの使い方を覚えた。

538 ：
NetBSD/x68k…

というかアセンブラで仮装メモリー関連のコードを書いたり意識したりする事なんて
仮装メモリーを持ったOSのカーネルを書く時位で
OS上のアプリや多少のデバイスドライバ程度じゃ触らないし触れないもんだがな
Windowsカーネルの中核部分の開発でもやってたのかな？

539 ：
X68kに載っていたCPUで仮想メモリ（スワップファイル）実現できるの？
68000は当然無理だし68030もMMU無しのECだったと思うんだが。

540 ：
NetBSDは要MPU乗せ替え

541 ：
>>537
プロテクトモードは結構活用したけど。
メモリアクセスするためのメモリウンイドウを作るために
ページングモードに移行させたりもしたな。
こいつは仮想EMSがBIOSROM領域をどこまでUMB化できるか
確認するためのチェックツールにも使っていた。

まあDOSで本格的にプロテクトメモリを使える様になるのは
DOS-EXTENDER環境、特に仮想記憶機構を持つDJGPPが
手に入ってからかな。
（ソフトバンクのCマガジンが雑誌のおまけFDに掲載した。）

542 ：
System7だと90年だっけ？　91年だっけ？　
ぐぐったらコンパック386＋Windows/386が86年、規格のEMS 4.0が87年、EMM386.SYSが89年。
仮想メモリまわりに関しちゃ、IBM-PC系が先行してんのね・・・
リアルモードのままじゃメモリ狭くてやってらんないから当然といえば当然だけど。

543 ：
シャープのアレって「ワークステーションもどき」だったんだな・・・

544 ：
ミニコン・ワークステーションに採用されているCPUと同じものを搭載したPCという感じだったかな
ワークステーションは68020になってたしメガドライブがすぐ後に出たりして68000自体はすぐにリーズナブルになった感じだけど

ワークステーションじゃ1983に68010ベースのSunOSが出て外付けmmuで仮装メモリー処理してたり
RISC勢に塗り替えられるまでは68000系が主流だったか
それ以前は個別の専用チップ？な感じで

intel系は386が出てからPC-UNIXが動くようになって
じわじわと時間をかけてサーバー系に進出していった

545 ：
シェアみるとNTサーバが一気に普及して、PC-UNIXが既存UNIXの代替になっていったかんじ。

546 ：
Intelもサーバークラスに関してはx86ではなくIA-64のItaniumで対応しようと考えてたのだが
1990年代の互換CPUとの競争、特にAMDとのクロック戦争でx86のパフォーマンスが急激に向上して、
Itanium(Merced)の開発が遅れたのも相まってリリースされた時にはx86に及ばないという結果になってしまった。

しかもx86のパフォーマンスはSparc,MIPS等のRISCをも凌駕していたのでサーバーメーカーも
x86へシフトをおこしだした。
とどめはAMDがAMD64を提唱してIntelもそれに追従することになり64Bit RISCの優位性が無くなり
RISCの押さえていた市場を急速に侵食していった。
（Sparcを出していたSUNがx86を出すぐらいであった。)

個人的にはItaniumが提案したEPIC、特にプレディケートによる条件分岐の排除なんかは
面白そうだなと思っていたんだけどね。

547 ：
x86が多機能高性能化でトータルなコストが高くなってる、という背景もあってだろう、組込みやポータブルデバイスだとARMの伸びがすごいね。
Androidのお陰もあるだろうけど。

歴史は繰り返す。
ただ歴史の主役から退りぞいちゃった68kと違ってインテルが引退させたいx86はまだまだこき使われそうだが。
Windows、Linux、Android。
x86とARM。
これの組合わせさえフォローできてればプログラマーとしての仕事はしばらくなくなりそうに無い。

548 ：
ARM64が出てきてようやくx86に敵うようになったからなインテル強すぎ
あれは金にいわせて天才の群れで手作業で最適化してるんだろうか

549 ：
ARMの面白いところは条件コードだったんだけどな・・・

550 ：
http://pc.watch.impress.co.jp/docs/topic/feature/20131228_629501.html
>【後藤】みんなすごい誤解していて、ARMの64bitがほかのCPUの64bitと
> 違うって事を全然考えてない。ARMはともかく32bitの出来がひどい。
> 何がひどいか? RISCなのに汎用レジスタが16本しかない、その内の
> 3本はプログラム関連で使っちゃうので、汎用に使えるのはたった13本。
> これで、ロード/ストアアーキテクチャのハンドリングをしなきゃなら
> ない。そうするとコンパイラが効率的なコードを吐けない。ので、
> コードステップが非常に長くなる。一方64bitになると汎用レジスタが
> 31本、SIMDメディアレジスタが32本だから、コンパイラがものすごく
> 効率的なコードを吐けるようになる。
>【山田】つまり今のARMの32bitはひどいと。
>【後藤】ひどい。だって、僕の知り合いでネイティブARM 32bitに触れた
> 人は皆「変態命令セット」って言ってるし(笑)。

551 ：
> 何がひどいか? RISCなのに汎用レジスタが16本しかない、

馬鹿丸出し。コンパイラの出力とか覗いたことないんだろうな、
と思ったら自分でARMは知らんと言ってるか。

> 僕の知り合いでネイティブARM 32bitに触れた
> 人は皆「変態命令セット」って言ってるし(笑)。

552 ：
AMDもARMも微細化、高速化できるのは、
すべてはインテルのセミコン業界への莫大な再投資によるおこぼれだということを忘れてはいけない。

553 ：
恩着せがましい自社の利益のための投資だろ覚えとく必要性も特に感じない

554 ：
自社の利益のために再投資しなかった68kだけは忘れないで・・・

555 ：
x86では条件コードはCMOV命令で十分と判断しちゃったからな。
もっともPentium4時代は実行速度は遅くメリットが得られたのはCore以降かな。

556 ：
>>554
自社の利益のためと言うより負債で資産を切り売りしなければいけない状況だったんだが。

557 ：
確かにARMのレジスタが15本だからコンパイラが効率が言いコードが吐けないとか言い切るのは無知、無勉強の証拠だわね。
レジスタの数が多いのが正義ならレジスタの数が半減するThumbモードは世間から拒否されたのにねー。

558 ：
x86もレジスタ少ないからだめだったなAMD64ですごく速くなった
普通に68kが進歩してれば結構な性能差をつけて勝てたのではと思う

559 ：
このスレッド内だとレジスタ数が多いのが正義という考えに無条件に同意する人は結構いると思うよな

560 ：
何個くらいあればまあ十分という線はあるしあればあるほど良いという馬鹿もそうはいないんじゃない。
68kについてはアドレスレジスタがスタックポインタを含めて8個というのは持て余し気味だったし
データレジスタが8個ではもうちょっと欲しいという感じだったな。
アドレスレジスタとデータレジスタを別にするデザインはあんま筋の良いものではなかったと思う。

561 ：
バランス悪いx86でRISCをシバき回したインテルを見ると
大事なのはレジスタ数より再投資である

562 ：
AMD64で大して速くなってないし。

563 ：
汎用レジスタがAX、BX、CX、DXのx86はレジスタ少なすぎ、ってか　SS:[BP+ｎ]がレジスタの変わりだからなー。
いちいちスタック経由なのがなー。

564 ：
SIとDIもあるぞ

565 ：
>>564
SIとDIは一応インデックスレジスタの扱いじゃぁ・・・

実際のところ、汎用性はAX>DX>BX>CX>SI>=DIだって教わった。

566 ：
多少レジスタ増やしたところで、処理によっては簡単に溢れる。C言語とか書くときレジスタ数意識しないし。
結局、データバスの帯域増やして、一次キャッシュ増やして、mov eax, dword[ebp+n]を高速化したほうがトータルではお得。
そうやって高速化済みだからAMD64でレジスタ増やしても大して速くならなかった。

567 ：
> 一次キャッシュ増やして、mov eax, dword[ebp+n]を高速化したほうがトータルではお得。

いまどきのx86プロセッサでは当たり前にやってるアウトオブオーダー実行には
メモリアクセスは障害になるので誤り。

568 ：
今時のx86は、スループット0.5clockでアクセスできる。それとも32kb/4の数の汎用レジスタ用意しろと言ってるのか？
RISCであろうとメモリアクセスが一番のボトルネックだからこそ、結局そのアプローチが正解だったのだ。

569 ：
>>560
> アドレスレジスタとデータレジスタを別にするデザインはあんま筋の良いものではなかったと思う。
汎用レジスタ×16 にするとあの命令ビット数に収まらんよ

570 ：
変にレジスタ増えるとスレッドコンテキストの切り替えが大変。

571 ：
x86だろうがなんだろうがノイマン型であるかぎりメモリアクセスは永遠にボトルネックだろ・・・

SS:[EDP+ｎ]って触るのはぶっちゃければほとんどCPUだからキャッシュがフラッシュされるケースは少ない。
割り切ってキャッシュの読み書きを高速化するほうが余程に現実的だろう。
頭打ちになってる気はしないでもないが。

572 ：
アウトオブオーダー実行ってのはコンピュータの「逐次処理」って原理と言うか原則にケンカ売る技法だからなぁ。
根本的な解決手段ではなくてあくまでも「CPUの空き時間を減らす」ための小細工でしかないんだよな。

573 ：
>>558
x64でのレジスタの使われ方を見ているとCの関数の引数が
スタック渡しからレジスタ渡し（VCで4，gccで6個)に
変わってメモリアクセスが減少する効果はあるだろうけど
贅沢な使い方をしているなという印象が。

こう考えるとレジスタ数の制限が厳しい8086を対象にした
LSI-C86が引数レジスタ渡しを実現していたのは驚異的だった。

574 ：
単に __fastcall 指定するだけじゃ・・・

575 ：
PowerPCでも引き数のレジスタ渡しは４つまでだったからな。

576 ：
LSIC-86はちっこい関数をコンパイルすることしか想定してないから
レジスタの使い方が巧く見えるのもそういう条件に限るんだよなあ。

577 ：
もともとのLSIC-80でもレジスタ渡ししてた、
というか8080の貧弱な命令セットでスタックフレームにアクセスすると、
かなり大変なことになるから、実用性を考えるとレジスタ渡しは必然だったと思う。

578 ：
スタックとか操作が無駄だからポインタ使って丸ごとテーブル渡しがいいとおも

579 ：
テーブルコピーってのはENTRY/LEAVE命令のことか？

580 ：
>>562
お前が32bitOSしか使った事がないならそう感じるかもな

581 ：
各種ベンチの通りだが大して速くなってない。
AMD64はなんちゃって64bitで、中身はx86を流用してるのだから当然。
8080→8086、286→386みたいな性能Upはしない。

582 ：
ベンチマークテストの結果も提示せずに早くないと言っても
何のテストをしたのかわからないから主張に説得力は全くないよ。
せめて結果を示しているHPのURL程度は記載した方が良いんじゃね。

583 ：
よほど悔しかったのか知らんけど、だれも早くないなんて言ってないよ^^

584 ：
アプリもマルチスレッド上等な時代だからねー。
コア数多いほうがトータルな性能かせげるからなー。

585 ：
64ビットOSはメモリ多く使えるからってのが「速い」の大きな要因でプロセッサ性能はあまり寄与してない。

586 ：
32bitだって4G積める全部認識はしないが。つうか使ったこと無いのか妄想で書くなよ

587 ：
>>586
4GB積んでも4GB以上の仮想メモリを使おうとするとアドレッシングが面倒臭い

588 ：
64bitでも4Gしか積んでなけりゃ仮想のお世話になるよな
同じメモリー量積んだ年代の近いIA32とAMD64で全然速さが違う

589 ：
ぜんぜん違う、は言い過ぎ。

590 ：
全然違うってどれぐらい？
0.1%? それとも0.01%?

591 ：
それがわかってないのにいちゃもんつけてたの?レス乞食かようざいから消えろ

592 ：
「全然速さが違う」とか言ってた馬鹿が具体的な数字も説明もできないで逆切れｗ

593 ：
レス乞食には教えてあげないお前は永遠にバカでいればいい

594 ：
無職には見つけられないベンチマークの結果まとめたサイト見てるから問題ないんだがな。

595 ：
論拠は主張する側が提示するものという常識も知らないのかｗ職務経験のない奴はこれだからｗ

596 ：
何が実務だこの自宅警備員が妄想を論拠として主張すんな基地外

597 ：
全然速いとか言い出した時に具体的な数値出してれば妄想扱いされないのにねー。

598 ：
>>596
> 何が実務だ

「実務」って↓のどれへのレス?

>>354
> 一応このスレは68k vs x86だから実務経験を疑われないように。

>>357
> 浅い実務経験しかないんだなあという印象

>>377
> 実務経験皆無というか実際にプログラムした経験があるのかどうかも妖しい半人前以下レベルだがプライドだけは10人前のキチガイかもしれないな。

>>385
> 実務経験を疑う以前にド素人というレベルのコードだったわ。

>>446
> 実際、実務でビットフィールド使うことなんてほとんど無いんじゃね？とは思う。

>>470
> 教科書的なプログラムしか知らない実務経験なさそうな感じ。

599 ：
>>446
お前笑われてんぞ?

http://wc2014.2ch.sc/test/read.cgi/denki/1424761591/647-
> 647 ：774ワット発電中さん：2016/03/05(土) 20:01:36.40 ID:KQBgvGsP
> https://twitter.com/u_akihiro/status/706009786958000128
> > すごいよ、ハードウェアがc言語で記述されているよ
> > https://pbs.twimg.com/media/CcxAILYVAAAMz7C.jpg
>
> https://twitter.com/s_osafune/status/706040794143027200
> > ぎゃー
>
> https://twitter.com/s_osafune/status/706040834781622273
> > HEWの呪いだ
>
> https://twitter.com/s_osafune/status/706042064966803456
> > HEWのこの記法さあ、ビットアクセスが大前提になってるからGCCだとコンパイル時にエラー出ない上にちゃんと動かないんだよね。呪い、それ以外の言葉を持たない。
>
> https://twitter.com/s_osafune/status/706042565728993280
> > さらにこれ構造体のアクセスで、プリプロセッサから見たら明示的なIOアクセスと識別できないんで即値アドレスのメモリアクセス扱いになっちゃう。つまり、データキャッシュが入ってくると壊滅する。

600 ：
コードによってはAMD64は10%弱ぐらい速くなってるが、SSE+SSE2が基本命令として組み込まれたのが大きい。

601 ：
何と比較して

602 ：
こういう使い方もある
https://en.wikipedia.org/wiki/X32_ABI

603 ：
600よお前は何と何を比較したんですか

604 ：
実務経験ないのがそんなに悔しいなら仕事すれば良いのに。

605 ：
HEWの奴はなにしたいの？
バカにするなら自分の経験とスキルで正面からバカにすれば良いのに。

606 ：
怒ってる怒ってるﾌﾟﾌﾟ

607 ：
馬鹿が晒されて逆切れｗ

608 ：
他人のフンドシで相撲とる、だっけ？
やーねー、仕事できない実務経験ないキチガイって。

609 ：
http://kotowaza-allguide.com/hi/hitonofundoshi.html
>人の褌で相撲を取る
>【読み】ひとのふんどしですもうをとる
>【意味】人の褌で相撲を取るとは、他人のものを利用したり、他人に便乗したりして、利益を得ること。

違うんじゃない

610 ：
んなことより600よお前は何と何を比較したんですか

611 ：
他人のモノを利用する、が何となくそれっぽいとは思う。
利用できてないけど。

612 ：
600みたいな奴は仕事もできない典型

613 ：
何と戦ってんだろ、コイツ…

614 ：
どうした600元気ないぞ拾い食いしてお腹壊したか

615 ：
AMD64の速度Upについて言ってるんだから比較元は明確だけれども

616 ：
じゃあはよ答えろクソ

617 ：
明言しないことで明確にしないテクニック

618 ：
>>602
AMDもAMD64の速度低下の一番の要因は無駄にでかいアドレスポインタなんてのは分かってたんだから、
初めからそういうモード容易しときゃよかったのにな。

619 ：
モードじゃないけどね

620 ：
容易じゃないけどね

621 ：
ちなみに命令セットのことなんだけどねわかんないか

622 ：
いやモードの話をしてるんだけど。

623 ：
602のリンク先で説明されてるのはABIなんだけど。

624 ：
いま馬鹿は一所懸命ABIを検索してます

625 ：
なぜそういうABIを用意したと思ってるんだ。

626 ：
モードｗ 命令セットｗ 馬鹿ばっかりだなｗ

627 ：
>なぜそういうABIを用意したと思ってるんだ。

英語読めないの??

628 ：
アフィカスがまた暴れてるのか。

629 ：
64bitでもnearポインタとかfarポインタとかを定義しておけばよかっただけ

630 ：
600のミラクルバカをおちょくってるのでネタバレ禁止

631 ：
いかにgoogle先生が賢くても600ほどの馬鹿だと救いようがないな

632 ：
>>618
5-8%高速化してるってことは、x64はそれだけx86より遅くなってたということだな。

633 ：
>>618
確かにそういうモードがあればなぁ。4GB以上使うアプリなんてほとんどないからな。
ポインタこねくりまわすアプリは32bitコードのほうが速いけど、レジスタも増えてSSEも標準で使えればさらに速くなるし。

634 ：
恥隠しに自演始めたｗ

635 ：
汎用レジスタが64bitって使い道があまりない。数を数えるには大きすぎる。
なので高速化する場面があまりにも限られてる。研究者には必須なのだろうけど。

636 ：
答えちまったほうが楽だったと思うがな元気でなチンパン600

637 ：
自演もなにも今時アンカーのつけ方すら知らない馬鹿はおまえだけだから分りやすいw

638 ：
64bitレジスタに即値代入だと32bitレジスタより遅くなる64bitCPUばかり。

639 ：
>>635
16bit環境用に4TB超えのATAドライバ書いた時は面倒くさかったぞ

640 ：
AMDx64か。
プリフィックスの塊みたいなもんだしなぁ。

641 ：
>>635
っ　80ビット浮動小数点演算ユニット

642 ：
同じクロックなら、というタラレバでx86とx64比べたら大体10～15%ぐらいx64が優速になるのかな？

意外に遅いのねx64。

643 ：
ググればベンチ結果いっぱい落ちてるだろ。

大して速くなってない。

644 ：
レジスタ幅が倍になったから速度が倍になるわけではないからな。

ただ単純な思考実験で言うが例えば64Bit長の乗算を考えれば
64BitCPUでは1命令ですむものが32BitCPUでは4命令＋αになるから
コードによってレジスタ幅の効果は大きく変わってしまう。
レジスタ数の増加も同様に32BitCPUではレジスタを使いきってしまう
状況下では64BitCPUの効果が発揮されてくる。

古典的なCPUのベンチマークになるドライストーン値の結果を
示したものだとこんな結果になるようだ。

つhttp://news.mynavi.jp/special/2005/compiler/013.html

645 ：
大原雄介みたいな素人が書いた記事が何かの参考になるかな?

646 ：
大原雄介ってこういう記事書く人ね。

http://news.mynavi.jp/articles/2013/12/28/galileo/002.html
> ただし、この結果として性能は猛烈に高い。以前chipKit32を比較した
> ときのSketch(List 4)をそのまま実施してみたところ、
>
> Arduino Uno　所要時間約44秒
> Galileo　　　約1秒未満(一瞬)
>
> だった(以前Arduino Unoでは約11秒だったので大分遅くなってるのだが、
> Arduino IDEのバージョンが大分違うので、おそらくこれが影響している
> のではないかと思う。ちなみに今回は1.0.5を利用)。これは81億回の
> 足し算を500回繰り返すものだが、性能面では勝負にならないほどGalileoが
> 高速だった。まぁ16MHz駆動の8bit MCUと400MHz駆動のPentium互換CPUで
> 性能が同じでは話にならないので当然ではあるが、とりあえずArduino IDEで
> 記述したSketchは、仮想マシンなどで動くのではない様である。まぁこれは
> これで、ループなどでタイミング調整を行っているSketchでは問題が出てくる
> かもしれないが。

647 ：
こんな記事も。

http://ascii.jp/elem/000/000/935/935757/
> 　では逆にCRAY-1が登場した1976年はどんなプロセッサーがあったの
> だろうか。インテルが8085をリリースしたばかりの頃である。8085は
> 8080の後継品で、動作周波数はこの当時は3MHzどまりでなかったかと
> 記憶している。
>
> 　整数演算性能は3MIPSという計算になるが、FPUは搭載しておらず、
> 外付けでも存在しないので、どうしても浮動小数点演算を行なおうと
> するとソフトウェアでのエミュレーションとなる。この当時に8085で
> 浮動小数点演算をエミュレーションでやらせた場合の性能は探したが
> 見つからなかった。
> 　ただ一般にFPUをALU(整数演算ユニット)でエミュレーションすると
> 50～1000倍程度時間がかかる(これはなにと比較するかによってばらつきが
> 大きい)から、とりあえず100倍とすると、8085の性能はおそらく0.03MFLOPS
> ほどになる。CRAY-1と比較すると5000倍以上の性能差になるわけだ。

648 ：
http://kei-sakaki.jp/2013/09/19/oohara-386-pipeline-in-nikkei-winpc-2013-october/
> 大原雄介さんの連載「PC技術興亡史」の「第30回 CPU」を読んで、
> 自分の記憶とあまりに違うので、念のために8086から80386までの
> パイプライン構造を調べてみました。
> 私が気になったのは以下の記述です：
>
> 　80386はIntelで初めてパイプライン処理を実現した製品だ。Intelは
> 「Parallel Pipeline（並列パイプライン）」と呼んだが、実態はごく
> 普通のパイプライン処理である。
> 　80286までは1つの命令のフェッチ（読み出し）／デコード／実行という
> 一連の作業が終わって、ようやく次のフェッチに取り掛かる仕組みだった。
> 80386は命令の処理のいくつかの段階で切り上げた上で、並行して処理
> できる
～（中略）～
> 　実は80286や8086でもパイプライン自体は実装されていた。ただし、
> 命令の並列処理が事実上できていなかった。
> 日経WinPC 2013年10月号 P.136より引用
>
> さて…。私の記憶が確かならば、8086もパイプラインを採用しており、
> また80286と80386は16ビットか32ビットかの差はあれ、基本的に同じ
> 構造であったはずなのです。
(以下略)

649 ：
>>644
リスト19:Func_3()アセンブルコード(-O3 -m32)
Func_3:
pushl %ebp
xorl %eax, %eax
movl %esp, %ebp
cmpl $2, 8(%ebp)
leave
sete %al
ret

リスト20:Func_3()アセンブルコード(-O3 -m64)
Func_3:
xorl %eax, %eax
cmpl $2, %edi
sete %al
ret

32、64の違いじゃなく単に引数がレジスタ渡しになってるだけ、参考にならない。

http://news.mynavi.jp/special/2005/compiler/010.html
↑レジスタが多いと多くの引数、変数をレジスタに割り当てられるので高速になった例

http://news.mynavi.jp/special/2005/compiler/012.html
↑レジスタが多いと退避、復帰の手間がかかるので低速になった例
（Func1のリストが割愛されてるのでとてもわかりにくいが）

の方が興味深いところだろう。

650 ：
>>645-648
CPUの評価にドライストーンベンチマークが不適切というならば
不適切である理由を論理的に明示して批判すれば良いものを、
直接的には関係しない著者の過去の記事を持ってきて素人同然との
印象操作で結果の否定を試みる努力を見ているとどれだけ必死なのかと思ってしまうな。

651 ：
> リスト19:Func_3()アセンブルコード(-O3 -m32)
> Func_3:
> pushl %ebp
> xorl %eax, %eax
> movl %esp, %ebp
> cmpl $2, 8(%ebp)
> leave
> sete %al
> ret

どう見ても改善の余地ありまくりのコードだしなあ、32bit と 64bit のアーキテクチャの比較にはなってない罠。
ライター無能杉。

652 ：
> 直接的には関係しない著者の過去の記事を持ってきて素人同然との

えっ?! 過去の記事??

64bit環境で試すコンパイラ - アセンブルコードに見るその実力
http://news.mynavi.jp/special/2005/compiler/013.html
> 大原雄介　 [2005/05/26]

Intel Galileoを試す - 超小型SoC「Quark X1000」搭載のArduino互換ボード
http://news.mynavi.jp/articles/2013/12/28/galileo/002.html
> 大原雄介　 [2013/12/28]

スーパーコンピューターの系譜　代表作CRAY-1と地球シミュレータ
http://ascii.jp/elem/000/000/935/935757/
> 2014年09月22日 12時00分更新 文● 大原雄介（http://www.yusuke-ohara.com/）

日経WinPC 10月号掲載の大原雄介さんの記事について
http://kei-sakaki.jp/2013/09/19/oohara-386-pipeline-in-nikkei-winpc-2013-october/
> 日経WinPC 2013年10月号 P.136より引用

…むしろここ数年の最近の記事では??

653 ：
>>650
> CPUの評価にドライストーンベンチマークが不適切というならば

誰もそんなこと言ってないじゃんｗ

素人ライターの記事では32ビット64ビットの比較になってないって嗤ってるだけｗｗ

654 ：
>>650
>直接的には関係しない著者の過去の記事を持ってきて素人同然との
>印象操作で結果の否定を試みる努力を見ているとどれだけ必死なのかと思ってしまうな。

コンピュータの性能について筆者はそれを語るだけの知識を有してないって批判のどこが「直接的には関係しない」の？

655 ：
レジスタ数増えて、スレッド切り替えコストが増えて、APIのポインタ渡しもサイズが倍に増えて、
32bitOSに比べて64bitOSはなんかもっさり感があるよな。

656 ：
> リスト19:Func_3()アセンブルコード(-O3 -m32)
> Func_3:
> pushl %ebp
> xorl %eax, %eax
> movl %esp, %ebp
> cmpl $2, 8(%ebp)
> leave
> sete %al
> ret

手元のCygwinのgcc version 4.9.3 (GCC)で試してみたら
>_Func_3:
>　　　　xorl　　%eax, %eax
>　　　　cmpl　　$2, 4(%esp)
>　　　　sete　　%al
>　　　　ret
になったしなあ、出力コードに無駄があることに言及してないライターは素人と言われても仕方ないわ。

657 ：
>CPUの評価にドライストーンベンチマークが不適切というならば
>不適切である理由を論理的に明示して批判すれば良いものを、
>直接的には関係しない著者の過去の記事を持ってきて素人同然との
>印象操作で結果の否定を試みる努力を見ているとどれだけ必死なのかと思ってしまうな。

↑コイツ素人ライターの大原じゃね?

658 ：
>>550とか>>644とかを見ると日本のPC関連を紹介してるメディアの酷さが良く分かるなｗ

659 ：
>つhttp://news.mynavi.jp/special/2005/compiler/013.html

こんな糞記事を誇らしげに挙げる神経がわからんｗ

660 ：
ジョブスがパソコンとマウスを発明したってテレビで言ってた。

661 ：
>>650
お前、>>646 >>647 がどれだけ馬鹿な内容か理解してないだろｗ

662 ：
> Arduino Uno　所要時間約44秒
> Galileo　　　約1秒未満(一瞬)

RISC vs CISC　　実際、20年前に起きたことがまた繰り返されただけ。とうとうAtmelは買収されてしまった。

663 ：
> > Arduino Uno　所要時間約44秒
> > Galileo　　　約1秒未満(一瞬)
>
> RISC vs CISC　　実際、20年前に起きたことがまた繰り返されただけ。とうとうAtmelは買収されてしまった。

馬鹿がまた一人。出鱈目な記事なのになんで疑問のひとつも抱かないの？

664 ：
>>662
お前、>>646 >>647 がどれだけ馬鹿な内容か理解してないだろｗｗ

665 ：
>>663
詳しく。何がデタラメなんですか？

666 ：
>>665
いつものキチガイだったら絶対答えは無いよ。

667 ：
>>666
いつものキチガイは664だったか。
663の指摘はまぁね、元記事のライターの「ライターとしてのスキル」がねぇ・・・

668 ：
>>663
何が出鱈目なのか教えてください。

669 ：
>>668
> これは81億回の足し算を500回繰り返すものだが、

という説明に違和感覚えないようでは重症だぞ?
81億回*500回=4兆5百億回の足し算を16MHzや400MHzのプロセッサが
数十秒や1秒未満で実行できると思うか? ライターが処理内容を
把握してないのは明白。

670 ：
#define REPEAT　90000
void setup()
{
　pinMode(13, OUTPUT);
}

void loop()
{
　unsigned long　lpCnt1,lpCnt2,lpCnt3;
　unsigned long　num;

　delay(1000);
　digitalWrite(13, HIGH);
　for(lpCnt1=0; lpCnt1<500; lpCnt1++)
　{　
　　for(lpCnt2=0; lpCnt2<REPEAT; lpCnt2++)
　　{　
　　　for(lpCnt3=0; lpCnt3<REPEAT; lpCnt3++)
　　　{　
　　　　num+=lpCnt2+lpCnt3;
　　　}
　　}
　}
　if(num)　digitalWrite(13, LOW);
　else　 digitalWrite(13, LOW);
　while(1);
}

「81億回の足し算を500回繰り返す」って言ってるけど2回の足し算を81億回*500回繰り返してるなあ、
つかループでも足し算してるしなあ、
つか if と else で実行する内容同じだし無駄なループはサックリ削除されるかもなあ、
ライター馬鹿じゃね? 何を比較してるつもりなんだ??

671 ：
>>586
32bit だと、仮想メモリーつかっても、プロセス当たりのメモリ空間は4Gしか取れない。

672 ：
>>662や>>665-668みたいな記事見ても内容理解しないボンクラ読者ばっかりだから
ライターもこんな糞記事書いて食えていけてるんだろうな。

673 ：
記事の内容が適切だったと仮定しても

> > Arduino Uno　所要時間約44秒
> > Galileo　　　約1秒未満(一瞬)
>
> RISC vs CISC　　実際、20年前に起きたことがまた繰り返されただけ。とうとうAtmelは買収されてしまった。

この結論はないわなあ。8bitのAVRと32bitのQuarkじゃ本来の用途や価格からして違う別のカテゴリの製品でぶつかるもんじゃないのに。

674 ：
> これは81億回の足し算を500回繰り返すものだが、

コンピュータの速度を体験的に理解してる人ならこの繰り返し回数が
異常だってのは普通に気づくわなあ、そういった感覚のない人間が
コンピュータの性能に関する記事書いてても何の説得力もない罠。
違うライターの記事だが、

第5世代Core i5の性能はIntel 4004の3500倍であることが判明！ムーアの法則50周年
http://weekly.ascii.jp/elem/000/000/328/328294/

こういう馬鹿記事書いちゃうのもコンピュータの速度についての感覚が
ないことが原因なんだろう。これについてはおかしいと気付いてる読者も
少なからずいたみたいだが。
https://twitter.com/search?q=http%3A%2F%2Fweekly.ascii.jp%2Felem%2F000%2F000%2F328%2F328294%2F&src=typd

675 ：
インテルが振り返る「ムーアの法則」誕生から50年 - 2015年夏は特別展示企画も予定
http://news.mynavi.jp/articles/2015/04/22/intel/
> 1971年に10μmプロセスで製造されたIntel 4004と、2015年に14nmプロ
> セスで製造されたIntel Core i5プロセッサ(Broadwell)を比較すると、
> トランジスタの性能は3500倍、電力効率は90,000倍、コストは60,000分の1と、
> 「高性能」「高い電力効率」「低コスト」を実現した

↑の記事では「トランジスタの性能は3500倍」と納得できる内容で書かれている。
先のライターの馬鹿記事は恐らくは書いてる本人が取材した内容を理解していない。

676 ：
>>672
ボンクラ連中は>>647の記事のおかしいとこもわかってないんだろうｗ

677 ：
まあ、たかだか10%、多目に見ても15%が全然速いとか言い切っちゃう低レベルだから仕方ないよね。

678 ：
>>650
> 直接的には関係しない著者の過去の記事を持ってきて素人同然との
> 印象操作で結果の否定を試みる努力を見ているとどれだけ必死なのかと思ってしまうな。

そうですか。

679 ：
>>600
何との比較?

680 ：
>>673
記事のとおり、Arduino互換ボードとしての比較だから、用途はArduino用途として同じカテゴリですよ。
それに今、8bit Arduinoから、32bit Arduinoの移行が進んでるから、性能比較して当然ですね。
8bit avr でパワーが足りなかったためにカメラ関連等諦めてたArduio用途に対してGalileoは使えそう。興味のある記事です。
Avr32がコケて買収された以上、歴史の繰り返しでパワー用途ではRISCよりCISCになるのは同意。

681 ：
> 記事のとおり、Arduino互換ボードとしての比較だから、用途はArduino用途として同じカテゴリですよ。

で、AVRはQuakeに負けてAtmelは買収されることになったんだ? バカかｗ

682 ：
訂正:
誤)Quake
正)Quark

683 ：
>8bit avr でパワーが足りなかったためにカメラ関連等諦めてたArduio用途に対してGalileoは使えそう。興味のある記事です。

インテルが諦めたGalileoを今から「使えそう」って何週遅れだよｗ

684 ：
>>680
>それに今、8bit Arduinoから、32bit Arduinoの移行が進んでるから、

選択肢は増えてはいるが移行は進んでないんじゃないかな。
プログラム開発終わったらArduinoからマイコン抜いて自作の基板に挿し換えるお手軽さを代替するものは存在しないし。

685 ：
>>680
> Avr32がコケて買収された以上、歴史の繰り返しでパワー用途ではRISCよりCISCになるのは同意。

ATMEL ARMもやってるし買収先のMICROCHIPの上位マイコンはMIPSなんだけど何言ってんの?

686 ：
訂正:
誤)何週遅れ
正)何周遅れ

687 ：
>>670
どうでもいい処理が残ってるのは単にサンプルスケッチコピペしただけだろう。
ソース乗せてる以上、下らない揚げ足とりだな。これでキレてたらOracleやMSのバギーなサンプルなんて読めないよ。

ソースを見れば単に32bit変数の足し算性能を比較するためなんてPGなら誰でも分るだろう。

688 ：
>>680
>記事のとおり、Arduino互換ボードとしての比較だから、用途はArduino用途として同じカテゴリですよ。

お前さあ、インテルがArduino互換ボードの為にQuark出したと思ってんの?

689 ：
>>687
「どうでもいい処理」ってどこのこと? 具体的にご指摘PLZ

690 ：
>>684
Lチカの軽い用途も多いからすべては移行しないけど、
これからAVRチップの入手性がどうなるか読めない。ディスコンも覚悟しなきゃならない。

691 ：
>>688
おいおいおまえは何を勘違いしてるんだ？

692 ：
「これは81億回の足し算を500回繰り返すものだが、性能面では勝負にならないほどGalileoが高速だった。」と記事にはあるから少なくとも繰り返し部分は「どうでもいい処理」ではないな。>>687の回答に期待。

693 ：
>おいおいおまえは何を勘違いしてるんだ？

質問に答えられない馬鹿↑

694 ：
>>687
>ソースを見れば単に32bit変数の足し算性能を比較するためなんてPGなら誰でも分るだろう。

最適化で削除されるかもしれない処理で性能なんて計れないよ?

695 ：
>>689

もう指摘したでしょ。　>>670

696 ：
>>695
お前の言う「どうでもいい処理」ってどこのこと? 具体的にご指摘PLZ

697 ：
Lチカの判定だろw。このスレってほんとレベル低いなw この記事書いた本人じゃないのww 馬鹿すぎwww

　if(num)　digitalWrite(13, LOW);
　else　 digitalWrite(13, LOW);

698 ：
>>697
俺の考える「サックリ削除されるかも」な部分はループ部分全体なんで、それを削除されるとプログラム全体は

void setup()
{
　pinMode(13, OUTPUT);
}

void loop()
{
　delay(1000);
　digitalWrite(13, HIGH);
　digitalWrite(13, LOW);
　while(1);
}

と同等となり何も計れないという主張なんだが?

699 ：
どうだろう。gccはかなり馬鹿だからな。加算ループ削除させないためにnumを無理やり使ったのだろう。

700 ：
つまり >>670 の負けだな。

701 ：
>加算ループ削除させないためにnumを無理やり使ったのだろう。

加算ループ削除させないためにはnumの値が如何様でも

>　digitalWrite(13, LOW);

するロジックじゃダメなんだよなあ。せめて

　if(num)　digitalWrite(13, LOW);
　else　 digitalWrite(13, HIGH);

とかするべきだし、そもそも定数回繰り返しの加算なんかは定数式に
置き換えもされることもあるからプログラム自体ナンセンスなんだわ。
せめてプログラムコンパイル後にオブジェクトを逆アセンブルして
同じロジックでコード出力されてることを確認しないと意味ない。

702 ：
おっと名前欄間違えた。

703 ：
同じメモリー量積んだ年代の近いIA32とx64で全然速さが違う

704 ：
ちなみに、「サックリ削除されるかも」と書いたが当時のGalileo専用の
Arduino IDEでこのプログラムをコンパイルするとループ部分がサックリ
削除されることは確認済みだから。

> Galileo　　　約1秒未満(一瞬)

って当たり前なんだよな。プロセッサの比較になんてなってないんだよ。

705 ：
そもそもif(num)がなくて測れなくて、if(num)追加したら測れたのでそこで仕事が終わっただけだろう。
ループでウェイトなんてマイコンじゃ当たり前の処理を削除する馬鹿gccが原因。正直どうでもいい揚げ足取りだわ。

706 ：
>>687
>ソースを見れば単に32bit変数の足し算性能を比較するためなんてPGなら誰でも分るだろう。

「81億回の足し算を500回繰り返す」テストがどれだけナンセンスなものか理解してないなｗ

707 ：
>>705
>そもそもif(num)がなくて測れなくて、if(num)追加したら測れたのでそこで仕事が終わっただけだろう。

ちょっと何言ってるかわからんですね。

>ループでウェイトなんてマイコンじゃ当たり前の処理を削除する馬鹿gccが原因。

削除されないようループ変数volatileにしたり普通するけどね、プログラム書いた奴が素人だったことが原因。

708 ：
マイコンでコンパイラの最適化なんてするほうが馬鹿

709 ：
せめてこうだったらループも削除されなかったかもなあ。

extern unsigned long repeat;
void setup()
{
　pinMode(13, OUTPUT);
}

void loop()
{
　unsigned long　lpCnt1,lpCnt2,lpCnt3;
　unsigned long　num;

　delay(1000);
　digitalWrite(13, HIGH);
　for(lpCnt1=0; lpCnt1<500; lpCnt1++)
　{　
　　for(lpCnt2=0; lpCnt2<repeat; lpCnt2++)
　　{　
　　　for(lpCnt3=0; lpCnt3<repeat; lpCnt3++)
　　　{　
　　　　num+=lpCnt2+lpCnt3;
　　　}
　　}
　}
　if(num)　digitalWrite(13, LOW);
　else　 digitalWrite(13, HIGH);
　while(1);
}

repeat の実体は別ファイルで定義ね。

710 ：
これArduinoだから素人、学習者が使うものやで。ifやloop削除したらあかん用途や。

711 ：
> マイコンでコンパイラの最適化なんてするほうが馬鹿

コンパイラの最適化を理解できない素人プログラマーではそう言う人は一定数いるね。

712 ：
> これArduinoだから素人、学習者が使うものやで。

いまのArduino言語はvolatileも仕様に入ってるの知らない人かな?

713 ：
>>712
無駄なループ、無駄な判定、無駄な計算は実行しないと言語仕様にあるのかね？
仕様外の結果を出す糞gccのために追加された仕様ではないのかね？

714 ：
>これArduinoだから素人、学習者が使うものやで。ifやloop削除したらあかん用途や。

素人の用途程度には使える時間待ち関数が標準で提供されてるよ。

715 ：
現に二つのarduinoの処理系で違う結果が出てるじゃん。
gccのバグ以外の何ものでもねーじゃん。

716 ：
>>713
Arduinoのリファレンスに無駄なループで時間待ちができるという記述があるのかねｗ

717 ：
>>715
「gccのバグ」ってどこのことを言ってんの?
ターゲットのアーキテクチャもコンパイラのバージョンも違うんで同一のコードが出力されるわけもないが。

718 ：
gccがよく速いコードを出すという話があるが実は必要な処理まで削ってる可能性が高い。

gccのせいで飛行機が落ちませんように-人-

719 ：
> 無駄なループ、無駄な判定、無駄な計算は実行しない
> 仕様外の結果を出す糞gcc

いまどきのコンパイラはすべて糞って主張かな?
…まあ昔のPC板だし最適化もろくにしない何十年前のツールしか知らない人がいても不思議はないが。

720 ：
javaを思いだすね。JVMの挙動が処理系によって全然違う。

721 ：
コンパイラの最適化がONにできるとか、ぬるい仕事してんのね・・・
制動系（車のブレーキとかが代表的かね)や電話の中継器、交換機とか消防司令システムとかやってると、正直コンパイラのバグが怖くて最適化ONになんかできねぇ。

722 ：
>正直コンパイラのバグが怖くて最適化ONになんかできねぇ。

コンパイラの挙動理解してない素人はそういうこと言うね。

723 ：
>>719
VSではそんな経験ないな。PGの希望通りの動きをする。それに比べてgccは斜め横の最適化する。

724 ：
>>722
挙動理解してるから言ってんだよ。
人の命預かるシステムを軽く見るんじゃねぇよド素人が。

725 ：
>正直コンパイラのバグが怖くて最適化ONになんかできねぇ。

最適化OFFだとコンパイラのバグには平気になるのかな? 不思議な思い込みだな。最適化有効にしたほうがコンパイラがデータフロー解析まじめにやってくれるし出力コードも読みやすくなるのにな。最適化OFFでどうやって信頼性を担保してるのかすごい不思議。

726 ：
>>721
最適化させなければコンパイラは信用できる、
ってもんでも無いと思うんだが…

てか、逆にその程度の認識しか無い奴が
そんな重要なコードを書いてることのほうがよほど恐ろしいんだがｗ

727 ：
>>725
コンパイラのバグの多く、というか「問題のあるコードが出力される原因」のほとんどが最適化にあるの知らんのか？
同じソースから最適化なしでコンパイルしただけでどれだけ不安要素がなくなるか知らないだろ、お前は。

ブレーキの反応速度が１０％向上します。でも1万回に1回効かなくなる可能性があります。とういうなら１０％遅いほうを選ぶ。
人の命が懸かる製品をつくるってのは、そう言うことだ。

728 ：
普通に信頼度は、 最適化するほど下がると思うけど。
現にPGの意図を無視して最適化してるのが今回の例。
処理速度を測るために加算ループコード書いたのに、削除してる。
そして削除させないために必死に無駄なコードを追加。
今度は処理系の違いで挙動が変わってきた。

ここまで来るともう害しかないわ。
5分で終わるシンプルなことにいらんトラブルで何時間かけさせるつもりだよ。

729 ：
>正直コンパイラのバグが怖くて最適化ONになんかできねぇ。

某マイコンメーカーの人から、ユーザーからのコンパイラのバグだという
苦情で一番多いのがvolatileつけ忘れ、というかそれ以前にvolatileを
理解してないプログラマによるバグって話は聞いたことあるなあ。
この人もなんかそんな感じですねｗ

730 ：
「最適化されても機能が実現できる書き方できないヘボが悪い」と、現実知らないお坊ちゃまは言いますよ。

731 ：
>現にPGの意図を無視して最適化してるのが今回の例。

わかってないプログラマがツールのせいにしてるだけｗ

732 ：
糞記事書いた素人ライターでもあるまいに今ここでgccを非難してる馬鹿の意図がわからんｗ

733 ：
> 普通に信頼度は、 最適化するほど下がると思うけど。
> 現にPGの意図を無視して最適化してるのが今回の例。
> 処理速度を測るために加算ループコード書いたのに、削除してる。
> そして削除させないために必死に無駄なコードを追加。
> 今度は処理系の違いで挙動が変わってきた。
分かってない典型ｗ　こういう馬鹿とプロジェクト組む人は不幸だなあｗ

734 ：
>>729
コンパイラのリビジョンヒストリーを見ると
最適化がらみのバグの修正が意外と多いｗ

735 ：
>>729
最初に疑うだろ、volataile付けわすれって。
つか普通に解析ツールが警告するだろ・・・

736 ：
> 処理速度を測るために加算ループコード書いたのに、
「実行時間」は保証されていない副作用でしかないことを理解してないｗ

737 ：
>>733
君と組まされるほうがよほどに不幸だよ。
「わかってるつもりで何も判ってない馬鹿」と回りは見るからね。

738 ：
安心してください。
時代の流れは脱gccです。FreeBSDも脱gcc果たしました。gccはオワコンです。

739 ：
以前、原因不明のバグを調査して行ったら、結局リンカがバグってたことがあったｗ

740 ：
>>738
なんか勘違いしてるみたいだが、↓程度のプログラムなら clang は当たり前にループ削除するぞ?
#include <stdio.h>
#define REPEAT 90000
int main()
{
　　unsigned long lpCnt1,lpCnt2,lpCnt3;
　　unsigned long num;
　　num = 0;
　　for(lpCnt1=0; lpCnt1<500; lpCnt1++) {
　　　　for(lpCnt2=0; lpCnt2<REPEAT; lpCnt2++) {
　　　　　　for(lpCnt3=0; lpCnt3<REPEAT; lpCnt3++) {
　　　　　　　　num+=lpCnt2+lpCnt3;
　　　　　　}
　　　　}
　　}
　　if(num) puts("end");
　　else puts("end");
　　return 0;
}

741 ：
>>723
試しに今使ってる PC に入れてた VC++ Express 2010 で↓を
int main()
{
　　int n = 0;
　　for (int i = 0; i <= 10000; i++) {
　　　　n += i;
　　}
　　return 0;
}
/O2 でコンパイルした結果が↓
_main　PROC
　　　　xor　　eax, eax
　　　　ret　　0
普通に無駄ループ削除してるね。

742 ：
なんだ糞記事のどこが糞か理解できなかった馬鹿が暴れてんのかｗ

743 ：
if(num)　digitalWrite(13, LOW);
else　 digitalWrite(13, LOW);
↓
digitalWrite(13, LOW);
のif削除とか、
for (i=0; i<500; i++)
;
の空ループ削除、
程度の最適化はDOS時代のMSCでもやるな。
今回のGCCは
if(num)が削除されたのでnumを求める必要がなくなり、
num+=lpCnt2+lpCnt3も削除、
結果、完全な空ループになるループまるごと削除。
おそらくこういう単純なロジックだと思うよ。
そもそも
if (a() || b())
でa()がtrueならb()は実行されないというのは初期の言語仕様レベルで規定されてるし、
C言語はそういう系統の言語だと割り切ったほうが良いかもな。

744 ：
>>741
すばらしく綺麗なコードになったなー。
思わず笑っちゃったわ。

745 ：
>>730
「最適化されても機能が実現できる書き方できないヘボが悪い」と
「複数人で構成されるプロジェクトではヘボに合わせる他ない」ってのは
相反するものではないし「ヘボが悪い」事実は変わらない。

746 ：
>>740
vcは削除されなかった。さすがMSだ。

747 ：
>>745
現実を知ってるならわざわざ言わないでしょ？

748 ：
>>741
普段使ってるコンパイラだとこうなったぞ

　　push　　　ebp
　　mov　　　 ebp,esp
　　xor　　　 eax,eax
@1:
　　inc　　　 eax
　　cmp　　　 eax,10000
　　jle　　　 short @1
　　xor　　　 eax,eax
　　pop　　　 ebp
　　ret

749 ：
VC++ 2010 Express で1から10の和を計算
int main()
{
　　int n = 0;
　　for (int i = 1; i <= 10; i++) {
　　　　n += i;
　　}
　　return n;
}
_main　PROC
　　　　mov　　eax, 55
　　　　ret　　0

750 ：
1から11の和を計算
int main()
{
　　int n = 0;
　　for (int i = 1; i <= 11; i++) {
　　　　n += i;
　　}
　　return n;
}
_main　PROC
　　　　push　　esi
　　　　xor　　edx, edx
　　　　xor　　ecx, ecx
　　　　xor　　esi, esi
　　　　mov　　eax, 1
$LL10@main:
　　　　add　　edx, eax
　　　　lea　　ecx, DWORD PTR [ecx+eax+1]
　　　　add　　eax, 2
　　　　cmp　　eax, 10
　　　　jle　　SHORT $LL10@main
　　　　cmp　　eax, 11
　　　　jg　　SHORT $LN8@main
　　　　mov　　esi, eax
$LN8@main:
　　　　lea　　eax, DWORD PTR [ecx+edx]
　　　　add　　eax, esi
　　　　pop　　esi
　　　　ret　　0

751 ：
>>748
それでも
n += i;
はばっちり削除されてんね。

752 ：
実際のところ、クリティカルな部分はアセンブラで書くのが一番信用できるんだよな。

753 ：
>>741
デバッグモードならちゃんとコンパイルされて動きトレースできね。ほんとMSは分かってるわ。
int n = 0;
0095138E mov dword ptr [n],0
for (int i = 0; i <= 10000; i++) {
00951395 mov dword ptr [i],0
0095139C jmp wmain+37h (9513A7h)
0095139E mov eax,dword ptr [i]
009513A1 add eax,1
009513A4 mov dword ptr [i],eax
009513A7 cmp dword ptr [i],2710h
009513AE jg wmain+4Bh (9513BBh)
n += i;
009513B0 mov eax,dword ptr [n]
009513B3 add eax,dword ptr [i]
009513B6 mov dword ptr [n],eax
}

754 ：
>>751
nはコンパイル時にwarning出る

755 ：
>>743
PGの意図を汲めないKYなコンパイラgcc。
そもそも||　は orであって、英語のorには排他の意味もあるからそれが自然。

756 ：
> そもそも||　は orであって、英語のorには排他の意味もあるからそれが自然。
| も orであってどっちも評価されるがそれは不自然なのか?

757 ：
論理演算子とビット演算子の区別くらいしろｗ

758 ：
|はビット演算子だから、数学的でないと。排他的論理和 ^ もちゃんと容易されてるしちゃんと区別しなさいってことだな。
perlでも open() or die();
英語的に自然だろ？

759 ：
>>758
andだとおかしく無いか？

760 ：
結論として「最適化はプログラマの意図しないコードを吐く」が正解ってことだね。

761 ：
>>755
ｇｃｃなんて昔からボロクソに悪く言われてたから今更だよ。

762 ：
最適化をオフにしたらプログラマの意図した通りに動く以上、
volatileがあるから最適化は言語仕様内と言うのは無理があるよ。

763 ：
>>759
open(OUT,xx) and print OUT xx
自然じゃないか？

764 ：
>>762
最適化「してもいいよ」で「しなくてはいけない」じゃないからねー。
volatileやregisterも仕様としてはめっちゃ後出しだしね。

765 ：
registerはK&R初版からあった気がする。

766 ：
>>762
お前Cの言語仕様理解してんの?
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

767 ：
5.1.2.3 Program execution
1 The semantic descriptions in this International Standard describe the behavior of an
abstract machine in which issues of optimization are irrelevant.

768 ：
>registerも仕様としてはめっちゃ後出しだしね。
馬鹿発見ｗ

769 ：
>issues of optimization
おれの英語力じゃよくわからが最適化に問題があるのか。
>are irrelevant.
勝手にやってろ。巻き込むなと言ってるわけだな。

770 ：
書いたコードそのまんまって、突き詰めると、
a=1+2+3+4+5+6+7+8+9+10;
を
a=55;
にするのは反則で、
ちゃんと9回の足し算と1回の代入をしてくれなくちゃヤダってことなるよね、
そうなることを期待してベンチマークコードを書いたのかもしれないし。

771 ：
http://kikakurui.com/x3/X3010-2003-01.html
> 5.1.2.3　プログラムの実行 この規格における意味規則の規定では，
> 最適化の問題を無視して抽象計算機の動作として記述する。
> 　ボラタイルオブジェクトへのアクセス，オブジェクトの変更，ファ
> イルの変更，又はこれらのいずれかの操作を行う関数の呼出しは，
> すべて副作用（side effect）と呼び(11)，実行環境の状態に変化を
> 生じる。式の評価は，副作用を引き起こしてもよい。副作用完了点
> （sequence point）と呼ばれる実行順序における特定の点において，
> それ以前の評価に伴う副作用は，すべて完了していなければならず，
> それ以降の評価に伴う副作用が既に発生していてはならない。（副
> 作用完了点の要約を附属書 C に示す。）
> 　抽象計算機では，すべての式は意味規則で規定するとおりに評価
> する。実際の処理系では，値が使用されないこと，及び（関数の呼
> 出し又はボラタイルオブジェクトのアクセスによって起こる副作用を
> 含め）副作用が必要とされないことが保証できる式は，評価しなくて
> よい。

772 ：
registerは初期の頃のCにコンパイラ開発者によって追加された。
どの変数をレジスタに割り当ててればいいかの実装が面倒なので追加されたらしい。
つまり、プログラマに高速化するための手段として用意したわけではなく、
コンパイラの実装を楽にするための機能として追加された。

773 ：
～という妄想だったとサ。

774 ：
あってるよ。妄想で否定するなよ。

775 ：
>>766
> 副作用が必要とされないことが保証できる式は，評価しなくてよい。
プログラマは副作用を必要としてるわけだから、評価しなくちゃいけないってことだな。

776 ：
>>775
プログラマが副作用を必要とするならvolatile修飾子等でコンパイラに指示する必要があるってことだよ。
暗黙的には「副作用を必要としていない」とみなされる。

777 ：
なるほど。さっぱり分らん。

778 ：
>　評価しなくて良い
「評価してはいけない」じゃないからね。
コンパイラに最適化禁止のオプションがあるのは何のためか。

779 ：
最適化しないと性能だせないとかだったらどんだけ無駄なソースかいてるのって話しだな。
しかしIA-32でregister修飾子が有効になるケースなんてあるンかね？
めっちゃ小さい関数でないと無効化される気がする。

780 ：
>>778
C言語の仕様では
・どうやって最適化をするか
・最適化をしないとはどういうことか
等は全く規定されていないでしょ、なので最適化とは全く関係ないレベルの話になる。
つまり、
「値が使用されない」及び「副作用が必要とされない」ことがコード的に明白な式については、
コンパイラは評価しても良いし、しなくても良い。
逆にプログラマ側から見ると評価されるかも知れないし、されないかも知れない
というのがC言語の仕様。

781 ：
>>779
最適化無しだと>>753なコードになるんだぞ？
変数のレジスタ割り当てすらされてない、
ソースの書き方とかそういうレベルの話ではないよ。

782 ：
>>781
処理が遅いなら遅いなりに性能出す書き方があるでしょ。
トータルで性能満たせば良いわけだし。
ループの高速化が性能確保の肝で最適化しない限り仕様を満たさない、というようなケースがそんなに有るとは思わんし。
ただ、そういうケースほど要求の優先度高かったりするんよね。

783 ：
> プログラマ側から見ると評価されるかも知れないし、されないかも知れない
> というのがC言語の仕様。
池田信夫かよ。

784 ：
>>782
> 処理が遅いなら遅いなりに性能出す書き方があるでしょ。
配列でのアクセスを避けてポインタ、中間ポインタを多用したりとか、
極端な例だと、インライン関数が展開されないなら、自力でソースに展開しちゃえば良いじゃない。
とか、可読性も保守性も下がるしその分バグも増えるしで、あんまり良くない。
> トータルで性能満たせば良いわけだし。
コードの効率はそのままCPUタイムや消費電力に直結するから、効率は良ければ良いほど良いってのはある。

785 ：
速度と消費電力は反比例。クロック落として電圧下げたほうが消費電力低下に直結ですよ。

786 ：
>>784
大前提として、マトモに動いて、と言うのがあってこそだけどね。
741みたいな例は極端たけど、期待する動作しないコード吐かれたって意味ないし。

787 ：
意図されない最適化をされると動かなくなるから最適化禁止って要は
コンパイラの挙動を理解してないってことなんだよなあ。
Cってプロがアセンブラ代わりに使うものなんで、素人はPascalでも
使ってなさいってこった。

788 ：
>>785
その通り。つまりコードの効率が良ければ、
低電圧、低クロックで動作する低速、低消費電力のCPUで十分になるし、
同じCPUでも、実行時間が短くなれば、その分CPUがHALTしてる時間が増えて
消費電力も少なくなるんだよね。
最近じゃとても重要な要素だと思うんだがなぁ…

789 ：
意図しない最適化ってなんのことだ？
誰かそんな話し、してる？

790 ：
最近のスマホは電話機じゃないからなー。
フリーズとか、通信機器として致命的なバグでも放置だからなー。
治しようがないから仕方ないけど。

791 ：
>>787
キミの知ったかはいつまで続くのでしょうか？

792 ：
>>789
> 現にPGの意図を無視して最適化してるのが今回の例。
> 処理速度を測るために加算ループコード書いたのに、削除してる。

793 ：
> 処理速度を測るために加算ループコード書いたのに、
ﾌﾟﾌﾟ! コイツC言語解ってねぇｗ

794 ：
>>787
コンパイラの挙動というか本質的にはC言語を理解してないんだと思うね。
大前提として、Cはアセンブラのような低級言語ではなく、抽象化された高級言語でしかないから、
言語仕様の範囲内で最適化（場合によっては反最適化ｗ）されても、プログラマは全く文句を言える立場に無い。
（C言語的に適切に）最適化されたら動かなくなるコードとかぶっちゃけ潜在的なバグと言っても良いくらいで、
それを最適化OFFで長年動かしてると、そのコードが「実績のあるコード」として信頼され、
ビルド環境や処理系が変わったときに、致命的な問題を引き起こしたりするのが一番怖い。

795 ：
「人の命預かるシステム」とか「人の命が懸かる製品」とか偉そうに
言ってるのが解ってない奴ってのがね…。

796 ：
最適化を切る理由は>>734でいいんじゃねリスク低減なんだろ

797 ：
> 現にPGの意図を無視して最適化してるのが今回の例。
> 処理速度を測るために加算ループコード書いたのに、削除してる。
こんなこと言う奴の書くプログラムってどんなんだろ? 怖いもの見たさでちょっと気になるな。

798 ：
>>796
>>734の言う製品がそうだというだけの話じゃね? 実在するものかも分からんけどさ。

799 ：
そこら辺は知らないがプラットホームを跨ぐ場合もあるだろうし地雷よけなんでしょ

800 ：
> ループでウェイトなんてマイコンじゃ当たり前の処理を削除する馬鹿gccが原因。
こういうこと言う奴がいるプロジェクトならそりゃもうそこらじゅう地雷だらけだろうなｗ

801 ：
割込あれば良いけど…CPU以外の物とタイミングを合わせる場合は？

802 ：
> ループでウェイトなんてマイコンじゃ当たり前の処理
コンパイラが吐いたコードに合わせてループ回数でウエイト時間調整すんのかな？
こんなコードがあちこちに紛れてりゃそりゃ最適化なんてできんわなあｗ

803 ：
マイコンの入門書はほぼすべてループでWaitですよ。

804 ：
世の中に数多あるであろうマイコンの入門書をほぼすべて読みつくしたとはスゴイ

805 ：
ループを用いないで速度計測するのも難しそうだ

806 ：
ベンチ作ったらgccに計算全部削除されてました、へへ

807 ：
volatileも使えない奴がC言語でループWAITが必要なコードなんか書くな
だいたい今どきのCPUはそもそも命令実行クロック数が一定じゃない
（キャッシュヒットや分岐予測によるパイプラインの乱れ等で実行速度が可変する）
CPUの差し替えによる高速化はおろか動作状況にすら依存するようなコードは本来書くべきじゃないし
書かざる得ないなら高級言語や一般的な開発環境に頼るな
入門書の目的はI/O WAITを教える事じゃないからとりあえず一番簡単な方法として必要な箇所にループWAITを書いてあるだけで
まともにやる場合は割り込みを待つなりI/Oの応答信号をポーリング監視するなりしてタイミングを計るもんだ

808 ：
話は"マイコン"の場合だよね…
>命令実行クロック数が一定じゃない
そういうCPUを使うかな？
>高級言語や一般的な開発環境に頼るな
わかる
>割り込みを待つなりI/Oの応答信号をポーリング監視
周辺チップがそのような機能をサポートしていな場合があるよね

809 ：
>>807
今回は avr と quark の話なんですけどw
同じプラットフォーム、同じコードなのに、avrは削除されず、quakは削除された。
さっきから一人ズレすぎですよw

810 ：
> 今回は avr と quark の話なんですけどw
ブレーキがどうこう、人の命を預かる云々とか言ってる馬鹿もいるし
とっくに話は変わってるだろｗ

811 ：
> 同じプラットフォーム、同じコードなのに、avrは削除されず
馬鹿発見ｗｗｗ

812 ：
x86と68ｋのスレでマイコンの時点で・・・

813 ：
タイミング調整をループでなんて20年前に廃れただろ。

814 ：
どっちもマイコンじゃねーか。

815 ：
> 同じプラットフォーム、同じコードなのに、avrは削除されず、quakは削除された。
16MHzのAVRで81億回の加算を500回繰り返して数十秒? マジで??

816 ：
>>813
Linux、FreeBSDのコード見てみな。

817 ：
>>815
マジです。
ただし、「C言語のソースでは」ですよ！

818 ：
>>816
具体的にファイル名と関数名プリーズ。
そしたら見るわ。

819 ：
ｇｃｃなんてゴミは言いすぎだがクソなコンパイラ使うしかない時点でお察しだよな。

820 ：
>>815
確かに計算が合わない。
avr はadd は1クロックかかる。しかも8bitレジスタ。quarkは32bitレジスタで0.5クロックのはず。
このスレで常駐しているコンパイラの挙動に詳しい人がAVRではどういうコードが吐かれたか詳しいらしい。ぜひ説明してもらおう。

821 ：
>>820
え?? 説明してくれるのは「avrは削除されず」って主張してる>>809でしょ?

822 ：
>>821
申し訳ございません。私の勘違いでした。
vc++では削除されないので、まさかデフォルト設定で平気で削除する処理系がこの世に存在するとは思いもよりませんでした。
大海を知りながら、井の中を知らずと恥じるばかりです。ですのでavr環境ではどのようなコードを吐かれたのかご教授願います。

823 ：
>挙動理解してるから言ってんだよ。
>人の命預かるシステムを軽く見るんじゃねぇよド素人が。
コンパイラの挙動理解してるプロっぽいこの人↑に説明してもらいたい

824 ：
コンパイラのスペシャリストが居るみたいだからたぶんさくっと説明してくれるだろうｗｗｗ

825 ：
>どうでもいい処理が残ってるのは単にサンプルスケッチコピペしただけだろう。
>ソース乗せてる以上、下らない揚げ足とりだな。これでキレてたらOracleやMSのバギーなサンプルなんて読めないよ。
>
>ソースを見れば単に32bit変数の足し算性能を比較するためなんてPGなら誰でも分るだろう。
この人プログラム見るの得意そう。ぜひこの人に解説してもらいたい。

826 ：
>これArduinoだから素人、学習者が使うものやで。ifやloop削除したらあかん用途や。
Arduinoに詳しいですね。ぜひ>>815について説明して下さい。

827 ：
00000100 <loop>:
100: af 92 push r10
102: bf 92 push r11
104: cf 92 push r12
106: df 92 push r13
108: ef 92 push r14
10a: ff 92 push r15
10c: 0f 93 push r16
10e: 1f 93 push r17
110: 68 ee ldi r22, 0xE8 ; 232
112: 73 e0 ldi r23, 0x03 ; 3
114: 80 e0 ldi r24, 0x00 ; 0
116: 90 e0 ldi r25, 0x00 ; 0
118: 0e 94 25 01 call 0x24a ; 0x24a <delay>
11c: 8d e0 ldi r24, 0x0D ; 13
11e: 61 e0 ldi r22, 0x01 ; 1
120: 0e 94 f8 01 call 0x3f0 ; 0x3f0 <digitalWrite>
124: 60 e0 ldi r22, 0x00 ; 0
126: 70 e0 ldi r23, 0x00 ; 0
128: 28 c0 rjmp .+80 ; 0x17a <loop+0x7a>
12a: 28 0f add r18, r24
12c: 39 1f adc r19, r25
12e: 4a 1f adc r20, r26
130: 5b 1f adc r21, r27
132: 27 5d subi r18, 0xD7 ; 215
134: 36 4f sbci r19, 0xF6 ; 246
136: 4b 49 sbci r20, 0x9B ; 155
138: 5e 40 sbci r21, 0x0E ; 14

828 ：
あれ? 連続する空白が圧縮されて見辛いか。

829 ：
loop() の逆アセンブルが90行近くあって分割して貼るのが面倒臭くなったので貼るのヤメ。
出力コードの内容は、
・データはすべてレジスタに割付られてる
・ソースでは3重ループだが、コードでは最内側のループが定数式に変換され2重ループになってる
・最外側のループがソースでは unsigned long の変数(4バイト)を使って処理されているが、コードでは 2バイトのデータで繰り返し処理されている
・演算結果のnumを評価しており、その結果で digitalWrite(13, LOW) か digitalWrite(13, LOW) を実行している
未確認だが、Arduino と Galileo で IDE から呼び出される際の最適化レベルが違う感じ。

830 ：
訂正:
誤)IDE から呼び出される際の最適化レベル
正)IDE からコンパイラが呼び出される際に指定される最適化レベル

831 ：
>・最外側のループがソースでは unsigned long の変数(4バイト)を使って処理されているが、コードでは 2バイトのデータで繰り返し処理されている
C++の型推論とかなしにこの最適化をするのはちょっとびっくり。

832 ：
最新、arduino ide 1.6.7 だとこうなった。加算ループ完全削除。
void loop()
{
unsigned long lpCnt1,lpCnt2,lpCnt3;
unsigned long num;
delay(1000);
e8: 68 ee ldi r22, 0xE8 ; 232
ea: 73 e0 ldi r23, 0x03 ; 3
ec: 80 e0 ldi r24, 0x00 ; 0
ee: 90 e0 ldi r25, 0x00 ; 0
f0: 0e 94 f0 00 call 0x1e0 ; 0x1e0 <delay>
digitalWrite(13, HIGH);
f4: 61 e0 ldi r22, 0x01 ; 1
f6: 8d e0 ldi r24, 0x0D ; 13
f8: 0e 94 b5 01 call 0x36a ; 0x36a <digitalWrite>
{
num+=lpCnt2+lpCnt3;
}
}
}
if(num) digitalWrite(13, LOW);
fc: 60 e0 ldi r22, 0x00 ; 0
fe: 8d e0 ldi r24, 0x0D ; 13
100: 0e 94 b5 01 call 0x36a ; 0x36a <digitalWrite>
104: ff cf rjmp .-2 ; 0x104 <loop+0x1c>

833 ：
void loop()
{
　unsigned long　lpCnt1,lpCnt2,lpCnt3;
　unsigned long　num;
　delay(1000);
　digitalWrite(13, HIGH);
　for(lpCnt1=0; lpCnt1<500; lpCnt1++)
　{　
　　for(lpCnt2=0; lpCnt2<REPEAT; lpCnt2++)
　　{　
　　　for(lpCnt3=0; lpCnt3<REPEAT; lpCnt3++)
　　　{　
　　　　num+=lpCnt2+lpCnt3;
　　　}
　　}
　}
　if(num)　digitalWrite(13, LOW);
　else　 digitalWrite(13, LOW);
　while(1);
}
loop() の中で delay(1000) やってるから
> Galileo　　　約1秒未満(一瞬)
なわけはないわなあ。1秒は掛かる筈。

834 ：
ああ、違うか。
digitalWrite(13, HIGH) と digitalWrite(13, LOW) の間の時間を計ってるのか。

835 ：
gccの最適化はほんと酷いな。バージョンによってこんなに違うコード吐くのかよ。
コンパイラの挙動を把握とか言ってる奴は大嘘つきだろ。できるわけがない。gccの品質が低すぎる。

836 ：
使ってるコンパイラの挙動くらい把握してて当たり前。
> コンパイラの挙動を把握とか言ってる奴は大嘘つきだろ。できるわけがない。
馬鹿はあらゆるアーキテクチャに移植されたgccすべての挙動を把握するとかって話と勘違いしてるんだろう。

837 ：
>>724
お前、大嘘つきだってよｗ

838 ：
やっぱ貼っとくか。
00000100 <loop>:
100:　 af 92　　　　　 push　　r10
102:　 bf 92　　　　　 push　　r11
104:　 cf 92　　　　　 push　　r12
106:　 df 92　　　　　 push　　r13
108:　 ef 92　　　　　 push　　r14
10a:　 ff 92　　　　　 push　　r15
10c:　 0f 93　　　　　 push　　r16
10e:　 1f 93　　　　　 push　　r17
110:　 68 ee　　　　　 ldi　　 r22, 0xE8　　　 ; 232
112:　 73 e0　　　　　 ldi　　 r23, 0x03　　　 ; 3
114:　 80 e0　　　　　 ldi　　 r24, 0x00　　　 ; 0
116:　 90 e0　　　　　 ldi　　 r25, 0x00　　　 ; 0
118:　 0e 94 25 01　　 call　　0x24a　 ; 0x24a <delay>
11c:　 8d e0　　　　　 ldi　　 r24, 0x0D　　　 ; 13
11e:　 61 e0　　　　　 ldi　　 r22, 0x01　　　 ; 1
120:　 0e 94 f8 01　　 call　　0x3f0　 ; 0x3f0 <digitalWrite>
124:　 60 e0　　　　　 ldi　　 r22, 0x00　　　 ; 0
126:　 70 e0　　　　　 ldi　　 r23, 0x00　　　 ; 0
128:　 28 c0　　　　　 rjmp　　.+80　　　　　　; 0x17a <loop+0x7a>
12a:　 28 0f　　　　　 add　　 r18, r24
12c:　 39 1f　　　　　 adc　　 r19, r25
12e:　 4a 1f　　　　　 adc　　 r20, r26
130:　 5b 1f　　　　　 adc　　 r21, r27
132:　 27 5d　　　　　 subi　　r18, 0xD7　　　 ; 215
134:　 36 4f　　　　　 sbci　　r19, 0xF6　　　 ; 246
136:　 4b 49　　　　　 sbci　　r20, 0x9B　　　 ; 155
138:　 5e 40　　　　　 sbci　　r21, 0x0E　　　 ; 14

839 ：
13a:　 2e 0d　　　　　 add　　 r18, r14
13c:　 3f 1d　　　　　 adc　　 r19, r15
13e:　 40 1f　　　　　 adc　　 r20, r16
140:　 51 1f　　　　　 adc　　 r21, r17
142:　 01 96　　　　　 adiw　　r24, 0x01　　　 ; 1
144:　 a1 1d　　　　　 adc　　 r26, r1
146:　 b1 1d　　　　　 adc　　 r27, r1
148:　 ff e8　　　　　 ldi　　 r31, 0x8F　　　 ; 143
14a:　 af 2e　　　　　 mov　　 r10, r31
14c:　 ff e5　　　　　 ldi　　 r31, 0x5F　　　 ; 95
14e:　 bf 2e　　　　　 mov　　 r11, r31
150:　 f1 e0　　　　　 ldi　　 r31, 0x01　　　 ; 1
152:　 cf 2e　　　　　 mov　　 r12, r31
154:　 d1 2c　　　　　 mov　　 r13, r1
156:　 ea 0c　　　　　 add　　 r14, r10
158:　 fb 1c　　　　　 adc　　 r15, r11
15a:　 0c 1d　　　　　 adc　　 r16, r12
15c:　 1d 1d　　　　　 adc　　 r17, r13
15e:　 80 39　　　　　 cpi　　 r24, 0x90　　　 ; 144
160:　 ef e5　　　　　 ldi　　 r30, 0x5F　　　 ; 95
162:　 9e 07　　　　　 cpc　　 r25, r30
164:　 e1 e0　　　　　 ldi　　 r30, 0x01　　　 ; 1
166:　 ae 07　　　　　 cpc　　 r26, r30
168:　 e0 e0　　　　　 ldi　　 r30, 0x00　　　 ; 0
16a:　 be 07　　　　　 cpc　　 r27, r30
16c:　 f1 f6　　　　　 brne　　.-68　　　　　　; 0x12a <loop+0x2a>
16e:　 6f 5f　　　　　 subi　　r22, 0xFF　　　 ; 255
170:　 7f 4f　　　　　 sbci　　r23, 0xFF　　　 ; 255
172:　 81 e0　　　　　 ldi　　 r24, 0x01　　　 ; 1
174:　 64 3f　　　　　 cpi　　 r22, 0xF4　　　 ; 244
176:　 78 07　　　　　 cpc　　 r23, r24

840 ：
178:　 61 f0　　　　　 breq　　.+24　　　　　　; 0x192 <loop+0x92>
17a:　 80 e0　　　　　 ldi　　 r24, 0x00　　　 ; 0
17c:　 90 e0　　　　　 ldi　　 r25, 0x00　　　 ; 0
17e:　 a0 e0　　　　　 ldi　　 r26, 0x00　　　 ; 0
180:　 b0 e0　　　　　 ldi　　 r27, 0x00　　　 ; 0
182:　 ef e8　　　　　 ldi　　 r30, 0x8F　　　 ; 143
184:　 ee 2e　　　　　 mov　　 r14, r30
186:　 ef e5　　　　　 ldi　　 r30, 0x5F　　　 ; 95
188:　 fe 2e　　　　　 mov　　 r15, r30
18a:　 e1 e0　　　　　 ldi　　 r30, 0x01　　　 ; 1
18c:　 0e 2f　　　　　 mov　　 r16, r30
18e:　 11 2d　　　　　 mov　　 r17, r1
190:　 cc cf　　　　　 rjmp　　.-104　　　　　 ; 0x12a <loop+0x2a>
192:　 21 15　　　　　 cp　　　r18, r1
194:　 31 05　　　　　 cpc　　 r19, r1
196:　 41 05　　　　　 cpc　　 r20, r1
198:　 51 05　　　　　 cpc　　 r21, r1
19a:　 29 f0　　　　　 breq　　.+10　　　　　　; 0x1a6 <loop+0xa6>
19c:　 8d e0　　　　　 ldi　　 r24, 0x0D　　　 ; 13
19e:　 60 e0　　　　　 ldi　　 r22, 0x00　　　 ; 0
1a0:　 0e 94 f8 01　　 call　　0x3f0　 ; 0x3f0 <digitalWrite>
1a4:　 04 c0　　　　　 rjmp　　.+8　　　　　　 ; 0x1ae <loop+0xae>
1a6:　 8d e0　　　　　 ldi　　 r24, 0x0D　　　 ; 13
1a8:　 60 e0　　　　　 ldi　　 r22, 0x00　　　 ; 0
1aa:　 0e 94 f8 01　　 call　　0x3f0　 ; 0x3f0 <digitalWrite>
1ae:　 ff cf　　　　　 rjmp　　.-2　　　　　　 ; 0x1ae <loop+0xae>

841 ：
正直、いちいち逆アセしてチェックしないととても業務では恐くて使えないレベルのコンパイラだな、gccは。
あと、 >>829　の説明ではよく分らんわ。結局、numを正しく計算できるコードなのかね？
> 最内側のループが定数式に変換

842 ：
>>841
> 正直、いちいち逆アセしてチェックしないととても業務では恐くて使えないレベルのコンパイラだな、gccは。
え? お前、人命が信頼性がどうこう言っててコンパイラの出力コード確認しないの??

843 ：
>>842
それは別人だが、おれはMSに完全の信頼を置いてるからな。GNUはライセンスからして胡散臭かろう。ウイルスと変わらん。

844 ：
>>843
> それは別人だが、おれはMSに完全の信頼を置いてるからな。
ああ、自分が使ってるコンパイラの挙動も把握しない>>723の素人か。スマン人違いだったか。

845 ：
>>844
だからVCは削除しないと言ってるだろう。みんな大嫌いgccのはハミゴコンパイラの挙動を把握してなかっただけだよ。
しかもバージョン違うと最適化処理が全く違うってほんと斜め横の最適化www　そりゃJVMもまともに動かないはずだわ。

846 ：
>>845
> だからVCは削除しないと言ってるだろう。
>>741
>>749

847 ：
>>846
>>740 のソースね。

848 ：
1重の無駄ループは削除して3重の無駄ループは削除しないって、
そりゃコンパイラの最適化機能がクソダサイだけじゃんｗ

849 ：
川俣晶って人が
「CPUにとって直交性は重要じゃ無い、むしろ無い方が優れてる」
「レジスタ数は少ない方がいい、なぜならサブルーチンを呼ぶときに全レジスタを退避しなければならず、無駄が多くなるから」
って言ってたんだけど、そうなの？

850 ：
サブルーチン呼び出しで全レジスタを退避なんて普通はしない。
全レジスタの退避/復帰が問題になるのは普通はコンテキスト切り替えの場合。

851 ：
>>849
サブルーチン自身が使う（壊す）分のレジスタだけ退避すれば良いけど、
片っ端から変数をレジスタに割り当てまくるとかして、
全部使い切ちゃうなら、当然全部退避しなければならなくなるね。

852 ：
>>851
>全部使い切ちゃうなら、当然全部退避しなければならなくなるね。
お前はちょっと↓でも読んで勉強するべき。
https://en.wikipedia.org/wiki/Calling_convention
https://en.wikipedia.org/wiki/X86_calling_conventions

853 ：
>>852
よく分からないな。どこが間違ってるか言ってくれ。

854 ：
ｇｃｃ使うなんてｗｗｗ

855 ：
>>852
お前こそ日本語の勉強しろよ・・

856 ：
レベル低いな、お前ら。
日本のプログラマーの９５％がゴミクズって言われるのが良く判るわ。

857 ：
と無職が申しております

858 ：
偏屈無職祭り

859 ：
実際、無職にまでバカにされるレベルだから仕方ない。
使い物にねらねーのばっかだし。

860 ：
> 人の命預かるシステムを軽く見るんじゃねぇよド素人が。
ﾜﾗｗ

861 ：
リコールとか多いしな。
どんだけ全体のレベル下がってんだってな。
エアバックとか、エンストとか信じられん。

862 ：
98%は居る意味ゴミだから、日本人のプログラマは。

863 ：
以前のArduino 11秒
Arduino IDE 1.0.5 44秒
Arduino IDE 1.6.7 1秒未満
gccの品質は全く安定してないな。恐くて使えないわ。

864 ：
以前のArduino 11秒
Arduino IDE 1.0.5 44秒
↑と↓でボードが違うことも理解できない池沼かな?
Arduino IDE 1.6.7 1秒未満

865 ：
>>864
同じだが。

866 ：
最適化オプションが違うんだろうな。Arduino IDEってその辺隠されてた気がするし。

867 ：
VCって3重の無駄ループは削除できないってマジ??

868 ：
avrも随分とクセがあるな。 >>838-840
即値加算がなくて、unsinged longなのに負値にして引き算とか、
+1するだけなのに、incでキャリが動かんから、FF引き算したり、大変だなw
あちらこちらで r1 使ってるのも0固定でしょ？

869 ：
r1はr1:r0レジスタペアにして8Bit乗算命令の上位結果をストアするのに
使われるから0レジスタと言うわけでは無いと思うけど。
>>838-840を見ると即値が第1バイトに下位4Bit，第2バイトに上位4Bitが
入っているのがはっきり判るな。
おそらくレジスタ指定フィールドに分割して入れているんだろうね。

870 ：
r1を0に設定して使ってないという意味ではないので。
cpcがおそらくキャリー付き比較命令だと思えるが特異かなと。
x86あたりだと比較－条件分岐を上位から順に4個並べてしまうからね。

871 ：
RISCのアセンブラは平易に書くと性能でないとか昔どこかに書いてあったけど
最近は良くなったのだろうか最適化

872 ：
x86のバイナリが汚いと言ってた馬鹿がいかに浅はかかが分る。

873 ：
性能と汚いかどうかは別の話だし、x86のバイナリが汚いのは誰もが認める事実だしな。

874 ：
綺麗にすると性能が落ちる。これは既に分かってること。

875 ：
そもそも今時バイナリなんて見ないし

876 ：
x86のアセンブラは短く書くと速くなるとかどこかに書いてあった

877 ：
日本のソフトウェア技術が如何に低いかがわかるスレ

878 ：
便所の落書きにレベル云々が間違ってんぜ

879 ：
言ってる本人が馬鹿で頑固で使い物になんねー無職って所が笑う所?

880 ：
RISC派がなぜ負けたのか未だ理解してなくて笑えるw

881 ：
多様なアドレッシングのほうがスループットを上げやすい。

882 ：
x86以外にRISCより速いのってあるのか？

883 ：
処理性能/消費電力という指標でいえばarmはX86を上回るという話。
万個なマルチCPUスパコン作るならarmということらしい。
alchimedesの末裔の64bit-ARMがintelキラー。胸熱だね。

884 ：
alchimedes >> Acorn Archimedes

885 ：
理研のスパコン京の後継機にARMプロセッサをという案があるみたいだから
パフォーマンスを出せればスパコンのx86からARMへのシフトが増えるかも。

886 ：
>>883
まじか。ソースくれ。

887 ：
F1と軽自動車を比べて軽のほうが燃費がいいと自慢してるようなものだな。
そういうコンセプトで設計されてるにすぎない。同じモバイル向けでもノートPC向けとスマホ向けはまた違ってくるだろう。

888 ：
処理性能/消費電力という指標は、プロセスルールやクロックで消費電力変わるから、
アーキテクチャの指標としてはかなり不適切だな。

889 ：
x86からARMへパラダイム・シフトは現在進行形だよね。
移行組の主力はApple。iPhone/iPadだけなく、Macintoshも近々
３度目のCPUアーキテクチュア変更するらしいね。今度はARM。
しかも自社設計のCPUコア。開発用の言語ソフトウェアも
powered gcc からclang-Swift/llvmへとすでに移行しつつあるし。
MSもWindowsRTとかで準備しているんじゃないの？ってこっちは
コンペチばかりの未踏領域だからMSが成功するかは未知数。
http://itstrike.biz/apple/mac/15831/

890 ：
Z80 → 80186 → 68000(及び系列) → intelのなんだっけ？(とPowerPC@ゲーム機) → ARM … って感じかな

891 ：
ARMコアとx86コアを同等に扱うAMDのCPU戦略
http://pc.watch.impress.co.jp/docs/column/kaigai/20140730_660030.html

892 ：
RTは既に失敗したんですが。

893 ：
32bitもエミュレーションだからな
x86に拘る必要がない

894 ：
x86一強の時代が終わるか。
行き詰まりに来てるしなx86。

895 ：
ノイマン型が終わって早く新世代のコンピュータが登場して欲しい。

896 ：
ARMって 1clock当たりじゃx86の1/4程度の性能なのにデスクトップ、サーバ部門で勝てるのか。
Appleはパクるのは得意だけど、Appleが注力して開発するとほとんど失敗してるぞ。

897 ：
アーキテクチャーの優劣なんて誤差レベル。
最先端のファブで作ったプロセッサーが、最強の性能と省電力性を誇るってのが、現状での結論ではないのか。

898 ：
素人はものごとを自分の理解できる単純な話にしたがるから馬鹿なんだよ。

899 ：
インテルは省電力のために電圧レギュレータすらCPU内に取り込んでるというのに。

900 ：
んな無理して延命しないでさっさと逝ってほしい
LLVM上でx86エミュとかサクサク動いてたらいいな

901 ：
>>880
往生際が悪いのが生きのこる秘訣ですね

902 ：
Itaniumの二の舞になったりしてなー

903 ：
ARMがインテルを倒す？
２０年位かかるな。

904 ：
>>896
1クロック当たりで比べても優劣付かないだろ。
クロック当たりの処理を単純化すれば、
周波数上げやすい
ゲート規模を小さく出来る
パイプラインや、キャッシュ組みやすい

905 ：
チカラワザで高クロックで動いてるx86に勝ててるARMがどれぐらいあるの？
同じ周波数ならx86のが処理能力高いんでしょ？

906 ：
RISC勢の台頭がx86のCRISC化を、互換CPUとの競合がx86の強化を進めたように
ARMとの対抗がx86の新たな進化を生み出すのならばいいのだけどね。
まあ単純に消費電力の軽減という方向に行くならば面白みはないが。

907 ：
ARMがx86超えるのは当分有りそうにないのか。

908 ：
>>904
20年前の知識だなw この板だから許されるだけでw

909 ：
危機感もったインテルがARM買収で潰しにかかる、とか外道やらずに真っ正面からぶつかる方が未来は明るい。

910 ：
一世を風靡したxscaleは手放しちゃったじゃん

911 ：
デスクトップやサーバーでARMがx86に代わる日は来ないよ。
絶対的に非力すぎる。

912 ：
>>909
Intelの利益の源泉は特許独占。セカンドソース拒絶。独禁法的に合法だが極悪w
Armの利益の源泉はオープン・セカンド・ソースで無制限許諾なライセンス。
intelの技術革新はIntel一社の単独努力によるオナニーマスター井のベーション。
Armの技術革新はオープンマーケットで参加各社競合競争状態な乱痴気お祭りショー
観ている分には乱痴気騒ぎの方が面白そうだな。

913 ：
>>911
かつてDECのオルセンもそんなこと言ってcpuのLSI化を拒んだが倒産。
Intelはムーアの法則でDECを蹴散らしたが、ムーアの法則の限界行き詰まりで停滞。
足踏みしたまんまのウサギは亀に追い抜かれるものだ。

914 ：
ん? DECがAlphaやってた頃はインテルよりパフォーマンス上だったろ。
その後コンパックに買われたのはAlphaが原因ではないだろうし。何言いたいんだかわからんな。

915 ：
さらに買収したhpも今ヤバイんだっけ。

916 ：
>>909
かつてAMDとクロック競争をやってた時にIntelはNetBurstアーキテクチャに走って
Prescott以降の爆熱CPUを生み出してしまった過去があるから道を誤る危険性も。
>>907，911
ARM社の主張ではハイエンドのCortex-A72でIntelと戦えるとのことだが。
まあ実機が出てきてみないと実際のところはわからないけどね。

917 ：
>>914
アルファの登場って92年頃でしょ確か。関ヶ原に遅刻到着した徳川家忠みたいなもん。手遅れ。
486/66とかWIN3.1の頃で特許係争明けのAMDもパソコン市場参戦してきた頃。PCの隆盛に
飲み込まれるようににWSベンチャーは軒並み倒産とか買収で姿消してATARIも倒産
commodoreも虫の息。コンパックに吸収されたのが96年か。Intelのロードマップ商売が
華々しく輝いていた頃だな。
オルセンが叩かれたのは80年代初頭までVAXのLSI化を計画推進する頭がなかった事。386が
リリースされた80年代中頃ダウンサイジングという考え方が流行りだした頃に8600/8800とかの
売価億単位なメインフレーマを目指して逆噴射じゃねとか。同時期アルファのまえのmicorVAX
でとりあえずLSI化はしたけど低速非力で評価ガタ落ち。そんな感じ。半導体技術が大躍進した
80年代に無策無作為を続けた結果。企業消滅。

918 ：
Alphaの魂はAthlon・OpteronになってIntelを苦しめた

919 ：
LSI化されたMicroVAXが1984年だが80386よりは先行してたし
>オルセンが叩かれたのは80年代初頭までVAXのLSI化を計画推進する頭がなかった事。
というのは事実と違うのでは。

920 ：
>>918
AMDが手に入れたAlphaの技術はEV6バスだけだろ。
Alpha自身はCompaqを経てIntelに知的資産が移った。

921 ：
>>920
バスとエンジニア

922 ：
インテルに追い付けるかも知れない。
だけど追い抜くのは無理ゲーだな。

923 ：
インテルはPCのマーケットのでかさで莫大な研究開発コストを捻出できてたんだし、
今後のPCのマーケットの縮小次第によってはどうなるかわからんと思う。

924 ：
DECは高価格帯向けだったからSGIと一緒に低価格帯ＰＣに負けて敗退したんだろう

925 ：
ARMの64bitなら同クロックのC2D並らしいじゃんもうちょいだね

926 ：
http://arstechnica.com/gadgets/2015/04/arm-details-its-new-high-end-cpu-core-cortex-a72/
Cortex A72とインテルのCore Mってのと比べてるけどこれ http://ark.intel.com/ja/products/85234/Intel-Core-M-5Y10c-Processor-4M-Cache-up-to-2_00-GHz タブレット用だな。C2D相当はまだ先じゃね。

927 ：
インテル4W ARM 1W未満　性能はどっこい省電力は圧勝だな

928 ：
性能/消費電力でインテルは勝負できないよ。あんな薄利多売したら、微細化投資の金が捻出できない。
つまりインテルがコケたら、セミコン業界がコケる。Appleが儲けたら、メモリや液晶メーカーが傾いたみたいに。

929 ：
ああ98がこけたら日本の半導体産業もアボンしたみたいな嫌な連鎖はあるかもね
でもまあシリコン半導体の進歩も限界だし逝っていいんじゃないでしょうかね

930 ：
PCの出荷台数はここ4年連続で減少している。という話なのでこういう状態がずっと続けば
巨額投資に見合う収益が減り続け借入金返済や新規投資は徐々に難しくなるかもね。
Intelがあのシャープほど債務を抱えるとは思わないが、盛者必衰の理発動で、終わるかもね。

931 ：
市場的なブレイクスルーなければパソコンは終わるか。
かつてのワークステーションが消えたようにタブレットやスマホに押されて消えるのかね。

932 ：
消える事は無いよ
タブレットのソフトウェアキーボードでプログラミングや文章作成とか有りえん
家電量販店での売り場スペースが減るだけだろう

933 ：
>>932
プログラムや文章作成の時だけブルートゥース接続のキーボードでいいんじゃ？

934 ：
>>932
ウチの会社、Amazonクラウドに開発環境置いてノートで開発とかやってんだわ。
社外での応急的な処置だけどね。
その延長でタブレットで、というのも考えてる。
パソコンだけでクローズしてる開発なら置き換え可能だとおもうぞ。

935 ：
うちは個人開発でdropboxにソース上げてクラウドごっこしてるが
スマホの入力補完が効いて案外便利必要記号もテンキーに載ってるし
猿みたいにキー叩くことは稀で思考してるほうが多いから問題ない

936 ：
シンクライアントからファットクライアントへの揺り戻しが来るまで持ちこたえたらインテルにも目はある。

937 ：
Winタブしかインテルの生き残る道は無いだろ。

938 ：
インテルは製造技術だけでも抜きん出てるからARMが天下取ったとしても生きていけるだろ

939 ：
売れる半導体商品がある内はだね。日本の半導体産業の歴史を思えば、
半導体業界で生き残るのは至極の技だという事がわかるはず。
特にCPUとメモリは描線技術を最先端で維持できないと、競争脱落は必至。
血を吐きながら続けるマラソンのようなもの。振り返れば脱落死企業の屍あまた。

940 ：
インテルがXScale捨てたのはx86と心中する覚悟なのかなあ?
インテル最新の製造技術で作られたARMプロセッサてのも見てみたい気はするが。

941 ：
日本のセミコン業界はデフレ円高政策で自民が潰しただけで歴史として参考にはならない。

942 ：
×自民
○民主

943 ：
>>942
ネトウヨってほんと馬鹿だなw

944 ：
チョンw

945 ：
>>942
為替チャート見ろ、馬鹿www

946 ：
おまえこそ、２００９ー２０１２年の為替推移を他の時代と比較して見ろ。バカ
エルピーダを潰したのは民主・白川日銀は定説。

947 ：
これがネトウヨか。半端ない馬鹿だなw
そもそもデフレ時に金融引締め始めたの安倍だろう。

948 ：
>>947
安倍というより、独自裁量の日銀な。安倍一次を潰したのは日銀。
民主の罪は超円高を無策のまま誘導放置し続けたことは通説。

949 ：
市民の視線からの失敗は、ミンシュの成功だから仕方ないよね。

950 ：
高い国産半導体で出来てた98がコケたら他も全部全部コケたんだよ
中台韓AT互換機が日本製を採用する必要もないしな

951 ：
9801で使用されていた半導体って外国製がすげー多い。
CPUが日本製なのはvm2まで。それ以降は全てIntel製
国産デバイスって漢ROMとメモリGDCくらいなものだろう。
スーパー301の標的だったし。ある意味典型的な売国パソコン。

952 ：
アメリカよりも韓国や台湾がシリコンウェハーや製造装置を内製に切り替えてここ数年で急速にシェアを失いつつあるな

953 ：
>>951
9801って何の面白みもないゴミみたいな作りのパソコンだったな。

954 ：
vx2で80286を採用決定したのは米国商務省の貿易摩擦圧力があったから。
痛3にほだされた関本の鶴の一声で決定。同時にNECオリジナルのVシリーズは終了。
玉川矢向電子デバイスのエンジニアは泣いていた。もう一つオマケでVシリーズ標準に
なるはずだったTRON-OSも出る芽がなくなった。米国商務省側のロビイストの親玉は
Intel創業者のロバートノイス。Intel-j社内ではドクターノイスと呼ばれていて尊敬の対象
だった。一度お目にかかったことあるが、細身で眼光鋭いインテリ・ヤクザ。彼ほど
日本の半導体会社を脅しに回った玄人もいない。なにせプレーナー特許保持者だからね。
三菱も富士通も8086作っていたがIntelの訴訟が怖くて製品に乗せることなかった。
NECは訴訟起こされ和解。NEC製の8087は結局市場で日の目を見なかった。

955 ：
>>950
あのときもドル円が140円以上から90円台まで円高が進んだんだよな。
98が10万割るとか考えもしなかったわ。

956 ：
いつの話？

957 ：
>漢ROMとメモリGDCくらいなものだろう。
マザボの主要機能大方じゃん電源やら拡張ボード周辺機器やらもで
国産半導体の天下だった

958 ：
売りは漢字テキストVRAMなんだけど。漢字ROMなんて8bitPCでも載ってたから。

959 ：
>>958
初代9801は漢字ROMは別売りオプションだったけどな。

960 ：
>>953
他の日本のメーカーはその「ゴミみたいな」パソコン以下のクズしか作れなかったんだよねｗｗｗ

961 ：
ゴミ以下のクズがはしゃいでるなぁ……

962 ：
98が素晴らしかったはのx86を採用したからだ。
68kを採用してたから国民機になったはFM-TOWNSだったろう。

963 ：
>>962
日立じゃあるまいし、98が68Kを採用することはあり得なかった。
ただし8086/V30系からV60/70へ転換するロードマップはあった。
DOSは86互換だけで286/386へ行くはずではなかった。

964 ：
NEC も EWS では 68K 使ってたんだが...

965 ：
>>963
V60の出荷は1986年だが既に85年に286を搭載したハイレゾ系のXAを
出荷しているからそのロードマップには疑問がある。
ちなみにV60自身はPC-UX用にPC9801-32という型番の拡張ボードで
販売された。

966 ：
ロードマップの話は84年ごろV60/70の設計管理者のM氏とその周辺から直に聴いた話。
286のIntelのプレゼンは82年に聴きに行った。古い話だ。

967 ：
シャープはX68030出すのが遅すぎ、92年とかもう時代はDOS/V＋Windows目前の、最後のあがきレベルに遅いわ。
信者レベルのユーザーでなきゃ正直「ふ～ん」とか「もうイラネ」の時代だよ。

968 ：
NECは烏合の衆というか寄り合い所帯みたいなモンだからなー・・・
パソコンとワークステーションが足並み揃わないのも当然で・・・
別組織が開発して、それぞれが別の工場に作ってクレーとお願いしてるわけで、販路も別だったし・・・

969 ：
>>963
関本がアホだったのさ。

970 ：
>>967
自ら5年間仕様変更しないという縛りをかけたからなぁ。
開発者達はDog Yearという単語を知らなかったのだろうか。

971 ：
V30は286の半分の速度しかない。
V33で速度だけは286並だったが、メモリ空間は8086並の1Mバイトしか無い。
メインメモリが高速で無いとV33の高速性を発揮できない縛りもある。
98がVシリーズを捨ててインテルを選んだのは圧力ではなく必然だろう。
V60、70、80を積んだ国産OSマシンなんて誰も欲しがらんしな。

972 ：
>>971
286はnチャンネルH-Mosで一世代前のプロセス技術の産物でせいぜい10Mhz止まり。未来は無かった。
当時、CPUの高速化を目指すとすれば、製造プロセスをC-MOS化が必至。IntelはC-MOS移行
に手間取っていて84年にV30でC-MOSCPUを出荷したNECに1-2年遅れていたのよ。そこで
ノイスはロビイングで米国政府に働きかけ、日本の半導体業界に圧力をかけて、半導体の
使用量・金額の30パーセントを米国製にしろ。米国製半導体を買えと米国政府を介して恫喝
したわけ。当時の米国製半導体は品質が悪く不良率が高かったから30パーセントは無理ゲー。
そこで金額が張るCPUを買うことで従順の意を示したわけ。俗に言う日米半導体摩擦。
386は完全なC-MOSじゃないナンチャッテC-MOSでまともなCPUは486～。286は注目されたが
まともに使われることが無いまま死んだCPU。MSはIBMから286用のOS/2を開発を受注したが
作り切れず。遅延遅延で未完成のままIBMに版権丸ごと譲渡。Windows3.0はそんな286に対応し
ているが3.1では非対応。90年代始めのlinuxはそもそも386対応だし。マジで未来が無かったね。
COMPAQが386機を出したのは86年終わり。IBMの386機は87年。84-86年のあの時期、日電が
ACOSの伝統通り非IBM路線でいけば別の歴史もあり得ただろうが、半導体摩擦という
ミッドウェイ海戦でCPUをぶっ潰されてジエンド。それが結局エルピーダ、ルネサスの凋落に
連なっていくわけ。日本製CPU敗れてウィンテルあり。つまらん30年だったなと思うね。
長文ですまん

973 ：
>>969
そそ。関本はアホ。というか、286の採用は大阪城の堀埋めのようなもの。
Vシリーズが真田丸に相当するなら、関本は内外堀埋め承認の大野治長というところか。
Intelは国家安康とかで無理なイチャモン恫喝して天下を奪取した家康みたいな狡猾な狸。
ま、その後98は金儲けの種となって三田のタワーの原資になったけれどもね。今は昔。

974 ：
>>972
日米半導体摩擦時の外国産シェア目標は30%ではなく20%だったはず。
1992年になんとか目標値をクリアさせた。

975 ：
ついでにWindows 3.1の286対応に関して9801版及びDOS/V版については正しいが
米国PC/AT版は普通に対応していた。

976 ：
>>974
↓の論文に詳細があるね。20%強。
日米半導体摩擦における 「数値目標」 形成過程
https://www.jstage.jst.go.jp/article/nenpouseijigaku1953/48/0/48_0_155/_pdf

977 ：
インテルといいクァルコムといい、黒船からずっとアメリカはやること外道だな。

978 ：
NTは286でも対応していたよね？3だか3.5までだったと思う。
勿論日本語版は否対象だったけどね。

979 ：
NTは32bitOSだから最初から386以降必須で、286には対応してないよ。

980 ：
:::::::::::/　　　　　　　　　　 ヽ::::::::::::
:::::::::::|　　ば　　じ　　き　　i::::::::::::
:::::::::::.ゝ　か 　 つ 　 み　 ﾉ:::::::::::
:::::::::::/　 だ　　に　　は　ｲ:::::::::::::
:::::　 |　　な。　　　　　　　ﾞi　　::::::
　　　＼_ 　　　　　　　 ,,-'
――--､..,ヽ__　　＿,,-''
:::::::,-‐､,‐､ヽ.　)ノ　　　　　 ＿,,...-
:::::_|/ ｡|｡ヽ|-i､　　　　　 ∠＿:::::::::
／. ` ' ● '　ﾆ ､　　　　 ,-､ヽ|:::::::::
ニ　＿_ｌ＿_＿ノ　　　　 |・ |　|, -､::
/￣　＿　　| i　　　　　ﾟr ｰ'　　6 |::
|(￣`'　　）/ /　,..　　　 i　　　　　'-
`ー---―' / '（__ ）　　　ヽ 、　　　　　>>973
====（ i）==::::／　　　　　　,/ﾆニニ
:/ 　　 　ヽ:::i　　　　　　　/;;;;;;;;;;;;;;;;

981 ：
NTはRISC版が286をエミュレートしてWin16アプリ動かすことができたから情報が交錯したんじゃないのけ？

982 ：
日本は今でもアメリカの属国だし。
ホワイトハウスから来る紙切れ1枚の命令に従うしかないのが現実だから。

983 ：
半導体と自動車で自動車を選び、
半導体もCPUとメモリでメモリを選び、
そういう選択の結果だからね、仕方ないね。

984 ：
1980年代を通して半導体売上ランキング第一位は日本電気だった。
半導体貿易摩擦で大騒ぎした直後の1987年でさえIntelは第10位。弱小企業だった。
それが1992年に日本電気を抜いて1位。大躍進。
たった5年で訴訟ヤクザ企業Intelが本懐遂げたというわけだ。トランプ怖いw
半導体売上ランキング
https://ja.m.wikipedia.org/wiki/半導体メーカー売上高ランキング

985 ：
ヤクザも何も、
勝手に海賊版CPUを製造・販売してて、
内部のマイクロコードを盗用してたのはNECじゃないかと。

986 ：2016/03/20
最終判決は盗用してないだったけど

おまいら音響カプラーでピーゴーした事ある？
ハードディスクってすごいよね
【名機】昔、何使ってた？
ざべ を語るスレ
YAMAHA YIS
ここだけ永久に1995年なスレ【Win95 OSR 5】
西新宿マイコンショップ慕情 '82
自分の機種を自慢するスレ
おまえら！遊撃手って雑誌知らないですか？
昔のPCっぽいヤツが発売されるぞ
--------------------
浜辺美波ちゃん可愛すぎ問題
【芸能】＜後輩イジメ疑惑＞TKOの木下だけじゃない？ ワケもなく番組をクビにした芸人「J」とは？
【BSニュース】笠井 美穂 Part3
蠍座と蟹座相性ど～お？？
会議8分 会食2時間…　なあ、普通こんな大事になってる時ってもう少ししっかり対応する気持ち出てくるはずだよな？人間なら [723178202]
メタルスラッグ総合
ワッチョイ テスト
【レス厳禁】ひたすら愚痴るスレ108【独り言】
公務員の給与削減、賞与＆退職金ｶｯﾄは国民の総意58
みんなの★公募談話室★3件目.
オカダ・カズチカ&三森すずこが結婚発表 オカダ「”幸せの雨”を家庭に降らせる」
【名無し奥も○○奥も】気楽に井戸端会議5743【みんな来い】
制限速度を守らない無謀な高速・観光バス
岡山の城
【悲報】生駒里奈ただのおばさんになる
【盗作・複垢疑惑】月夜涙総合スレ31【参考にしました】
新型肺炎コロナウイルスの蔓延でセンバツが中止の可能性？
【動画】ミヤネ屋で放送事故　歌舞伎町中継で男が乱入　女性レポーターに絡み中継中止 [１号★]
CSVファイルのスレ
お前らが笑ったコピペを貼れ　in車板91
TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼