板検索:
68k v.s. x86 Round 2 (986)
まとめビュー
1
ナイコンさん[]   投稿日:2016/02/11 22:17:11
16Bitパソコン時代のMPU/CPU 68kとx86を語るスレです。
68020,386以降の32BitやZ8kや658xの話題もOKです。

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

前スレッド
68K v.s. x86
コメント1件


2
ナイコンさん[sage]   投稿日:2016/02/12 00:10:44
>>前スレ978
IBM PCの開発が開始された1980年時点では68kは量産出荷されたばかりで
ソフトの蓄積が皆無で難しい。
しかもコストカットのため8086ではなく8BitBUSの8088を採用したのを
考えると68008が存在しないので選択肢にならないだろう。

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

3
ナイコンさん[]   投稿日:2016/02/12 05:33:57
>1
スレって950超えたあとで書き込みないと落ちるんだっけ??
コメント1件

4
ナイコンさん[]   投稿日:2016/02/12 12:29:48
見返せば良い所より悪い所がてんこ盛りな68kは消えて当然だったな。
モトローラが見切りつけて見捨てたタイミングが一番悪いような気もするが。

5
ナイコンさん[sage]   投稿日:2016/02/12 17:45:46
>3
一般的には980を越えて24時間以上書き込みが無ければ落ちる。

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

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

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

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

8
ナイコンさん[sage]   投稿日:2016/02/14 00:29:46
「優勝のみが勝者。2位は敗者の1位」みたいな考えだなあ。
20年以上続いてるアーキテクチャが大成功じゃなくちゃ何なのよ。

9
ナイコンさん[sage]   投稿日:2016/02/14 01:31:49
powerpcは組み込み分野で使われとるよ

10
ナイコンさん[sage]   投稿日:2016/02/14 06:07:16
PowerPCアーキテクチャはIBMがPOWERで使ってるよ

11
ナイコンさん[sage]   投稿日:2016/02/14 07:26:52
そもそも 68K も 68340 とかで組込で結構使われてたし
PCやWSしか見えてないだけかと

12
ナイコンさん[sage]   投稿日:2016/02/14 12:29:53

13
ナイコンさん[]   投稿日:2016/02/14 13:32:30
何が理由かしらないけど68kが開発元に見捨てられた時点で「失敗」でしょ。
商業的にとか、技術的にとか色々と「失敗」はあるけど。

14
ナイコンさん[sage]   投稿日:2016/02/14 17:14:31
> 68kが開発元に見捨てられた時点で「失敗」でしょ。

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

15
ナイコンさん[]   投稿日:2016/02/14 18:30:52
>14

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

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

16
ナイコンさん[sage]   投稿日:2016/02/14 19:01:53
68008なんてユーザーにとってもメリットがない製品を引き合いに出す意図が理解不能。
コメント1件

17
ナイコンさん[sage]   投稿日:2016/02/14 22:40:57
組み込みの仕事してるけど68kとPPCとARMしか使ったことがない

18
ナイコンさん[sage]   投稿日:2016/02/15 06:07:15
6301, 6809, 64180, 80186, SH-2, 68020 位かな

19
ナイコンさん[]   投稿日:2016/02/15 08:09:46
>16
そういう傲慢が会社潰すのさ。
モトローラはユーザーニーズ蔑ろにしたからシェアなくしたんだぜ。
コメント1件

20
ナイコンさん[]   投稿日:2016/02/15 12:11:32
仕事で、なら6800、8080/Z80、68000〜68040、V30、PowerPC G3、ARMv4以降だな。
日電以外でV30系はほとんどなかった。
680x0な仕事でROMRAMあわせて1M以下とかだともったいない気がしたもんだ。

21
ナイコンさん[sage]   投稿日:2016/02/15 13:36:01
>19
68008にユーザーニーズなんてほとんど無かったろう。
コメント1件

22
ナイコンさん[sage]   投稿日:2016/02/15 14:02:07
8088に対抗して「外部8ビット、アドレス20ビットの16ビットマイコンならウチにもありますよ」的な位置づけ以上のものではなかったしなあ >68008

23
ナイコンさん[sage]   投稿日:2016/02/15 15:01:14
68008+8ビットシステムを流用した先行試作機
でソフトを開発しつつ、平行して本番用68000システムも開発、
とかそういうニーズはあったんじゃない?

24
ナイコンさん[sage]   投稿日:2016/02/15 16:03:46
試作用なんて数が出ないもんニーズの内に入らん

25
ナイコンさん[sage]   投稿日:2016/02/15 17:20:05
Motoloraは1979年に6809を出しているから競合する8Bitマーケットに
68008を出す判断を下すのは無理だろうな。

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

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

26
ナイコンさん[]   投稿日:2016/02/15 18:26:41
タイミング下手なのはしょうがないよね。
インテルの進化に比べて目玉商品なかったし。
悪い石じゃなかったかんだがねー、68000。

27
ナイコンさん[sage]   投稿日:2016/02/15 19:01:43
IBMが8088を採用したのは16bitを強調して他社製品との差別化を図った上で
自社製品と競合しない性能の低いプロセッサという条件に合致したからで、
製品自体が優れてたとかそいうんじゃないよね。
コメント2件

28
ナイコンさん[sage]   投稿日:2016/02/15 20:32:00
性能だけが製品評価の基準では無いと思うが。
陳腐な性能であっても必要な時期にその目的に合致したのならば
それはその時点において優れた製品だ。

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

29
ナイコンさん[]   投稿日:2016/02/15 20:52:23
当時として68000やZ8000もあったしなあ、インテルの8088の戦略の何が優れていたという主張? 80386の影も形もない頃の8088は将来を見据えたデザインではなかったし、インテルアーキテクチャが現在まで繁栄してる事実は当時からすれば結果論にすぎないよ。

30
ナイコンさん[]   投稿日:2016/02/15 21:20:02
>28
IBMPCよりちょい後だけどMacやAmigaやATARISTに採用された68000は優れた製品だったよね。

31
ナイコンさん[]   投稿日:2016/02/15 21:31:23
IBMがPCのプロセッサを決定する際に選択肢に68008があったとしても
それが採用されたかは疑問。
32bitへのラインナップ展開が見えてるアーキテクチャは当時のIBMの
上位製品への脅威となりうるので敬遠されたと思う。
コメント2件

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

33
ナイコンさん[]   投稿日:2016/02/16 10:03:47
>32
そんなニーズには8088やV20ですよ!

34
ナイコンさん[sage]   投稿日:2016/02/16 12:27:54
データバス8bit、アドレスバス24bitのニーズねぇ。変態杉だろ。
コメント1件

35
ナイコンさん[]   投稿日:2016/02/16 12:44:23
データバス8ビット、でもアドレスバスは16ビットじゃあ足りない、だよ。
どこから24ビットなんて具体的な数字だしてきたん?
コメント1件

36
ナイコンさん[sage]   投稿日:2016/02/16 12:48:40
>27, >31
当時の上位機種ってなんのことだ?
まさか System/360 じゃないよな w
コメント2件

37
ナイコンさん[sage]   投稿日:2016/02/16 12:48:46
68kのアドレスバス。
8bitCPUならバンクメモリでいいじゃん。アドレス指定面倒だし。

38
ナイコンさん[sage]   投稿日:2016/02/16 12:58:22
>35
68008 PLCC 版はアドレス 22bit なので FC 2bit 分足して 24bit って言ってるのかも w

39
ナイコンさん[]   投稿日:2016/02/16 14:33:25
>36
360が販売されてた時代も知らない素人は引っ込んでてね
コメント2件

40
ナイコンさん[]   投稿日:2016/02/16 14:36:23
> まさか System/360 じゃないよな w

System/360がどういう位置づけの機種かも分かってないっぽい
コメント2件

41
ナイコンさん[]   投稿日:2016/02/16 16:35:14
68kはコマイ基板に使うにはコストパフォーマンス悪すぎたからなぁ。
そしてコマイ仕事のほうが数あったわけだが。

42
ナイコンさん[]   投稿日:2016/02/16 17:44:19
>34
データバス8bit、アドレスバス24bitは65816がそうだけど、
スーパーファミコンで採用されたことで大成功と言ってもいいんじゃね?

43
ナイコンさん[sage]   投稿日:2016/02/16 19:09:46
>39
PCと違って汎用機はそんなに簡単買い替えられないから '80年半ばまで 360 は普通に使われてたことも知らない知ったか乙 w

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

て言うか、
> 当時のIBMの上位製品
を具体的に書けよ
コメント1件

44
ナイコンさん[sage]   投稿日:2016/02/16 19:44:40
System/360は知らないけど
System 38のプログラマーだったオレが通りますよ
コメント1件

45
ナイコンさん[]   投稿日:2016/02/16 20:02:39
NTTやIDOなんかの仕事で68008を4年か5年使ったなぁ。

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

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

47
ナイコンさん[]   投稿日:2016/02/16 22:15:12
>43
> PCと違って汎用機はそんなに簡単買い替えられないから '80年半ばまで 360 は普通に使われてたことも知らない知ったか乙 w

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

48
ナイコンさん[sage]   投稿日:2016/02/16 22:24:32
>て言うか、
>> 当時のIBMの上位製品
>を具体的に書けよ

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

49
ナイコンさん[sage]   投稿日:2016/02/16 22:33:31
組み込み系のニーズ入れたらピンキリだろう。
今は16bitマイコンってほんとニーズない。8bitの次は32bitって感じ。
なのに16bitCPU、DOS時代はエライ長かった。

50
ナイコンさん[sage]   投稿日:2016/02/16 22:34:21
>47
「普通に」使われてた
って言う日本語は理解できなかったのか? w
PCとは時間感覚が違うんだよ

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

51
ナイコンさん[sage]   投稿日:2016/02/16 22:36:39
>48
> パソコンより上は汎用機しか思いつかない人?
そんなご託は具体的な名前挙げてからほざけよ

52
ナイコンさん[sage]   投稿日:2016/02/16 22:39:23
ソコン市場形成期におけるIBMの技術戦略
--- the IBM Personal Computer の開発プロセスに関する技術戦略論的視点からの分析 ---
http://www.sanosemi.com/history_of_IBM-PC.htm
> 7.なぜIBMは、IBM-PCに8088を選択したのか?

> 5)同一社内における商品としての差異化のための、技術的性能のスペック・ダウン
> 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) と言われている。
コメント1件

53
ナイコンさん[sage]   投稿日:2016/02/16 22:45:47
初代IBMPCのMINIX劇遅だったなぁ

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

開発チームの人が言ってるならそうなんだろう。
コメント2件

55
ナイコンさん[]   投稿日:2016/02/16 22:50:12
>当時の上位機種ってなんのことだ?
>まさか System/360 じゃないよな w

うわ!バカがいる!
コメント1件

56
ナイコンさん[]   投稿日:2016/02/16 23:07:10
>書けないならいちいち絡んでくるなよ

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

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

57
ナイコンさん[]   投稿日:2016/02/16 23:17:58
>PCと違って汎用機はそんなに簡単買い替えられないから '80年半ばまで 360 は普通に使われてたことも知らない知ったか乙 w

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

58
ナイコンさん[]   投稿日:2016/02/16 23:39:15
>44
コレですね。
https://ja.wikipedia.org/wiki/System/38

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

59
ナイコンさん[]   投稿日:2016/02/17 03:32:00
>43
>PCと違って汎用機はそんなに簡単買い替えられないから '80年半ばまで 360 は普通に使われてたことも知らない知ったか乙 w

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

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

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

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

勿論System/360ですよね!馬鹿でもわかります。
コメント1件

60
ナイコンさん[]   投稿日:2016/02/17 05:35:10
組込みだと8ビットか32ビットかは妥当だとうな分け方だよな。
16ビットと32ビットの調達コストとか考えると16ビット使うより32ビット使ったほうがマシだし。
ソフトの作りやすさもあるけど10年先20年先の保守考えると、ね。

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

61
ナイコンさん[]   投稿日:2016/02/17 07:19:33
68000は、出た当初は良かったんだよ、出た当初は。

62
ナイコンさん[sage]   投稿日:2016/02/17 08:16:20
>52, >54
都合のいいところだけ持ってくるなよ…
5番目の理由だし、しかもすぐ下に

ただし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
コメント3件

63
ナイコンさん[]   投稿日:2016/02/17 13:19:05
> >58
> ないない、汎用機程ではないとしても価格が違いすぎる

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

64
ナイコンさん[]   投稿日:2016/02/17 13:29:25
>62
> 5番目の理由だし、

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

> 1)コスト削減
> 2)関連周辺回路の開発期間の短縮
> 3)先行する8ビットCPUパソコンとの互換性問題
> 4)IBMにおける先行プロジェクトの活用 ---- 先行プロジェクトで蓄積された知識・経験・部品の活用
> 5)同一社内における商品としての差異化のための、技術的性能のスペック・ダウン
> 6)オプション部品による性能向上の可能性
コメント1件

65
ナイコンさん[sage]   投稿日:2016/02/17 14:44:55
こりゃメガドラvsPCE並に勝負つかなそうだ

66
ナイコンさん[]   投稿日:2016/02/17 15:15:08
>62
> しかもすぐ下に
>
> ただしBill Sydnesのこうした指摘に関してDavid J. Bradleyは否定的である( http://www.e-insite.net/tmworld/index.asp?layout=article&;;articleid=CA187350 )。

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

67
ナイコンさん[]   投稿日:2016/02/17 15:32:36
Why the IBM PC Used an Intel 8088
http://forwardthinking.pcmag.com/chips/286228-why-the-ibm-pc-used-an-intel-808...
> 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.

↑見ると

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

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

68
ナイコンさん[sage]   投稿日:2016/02/17 16:23:41
>63
パソコンが世に出る前の話をしているのに、お前はいったい何を言ってるんだよ…
さすがにバカすぎるだろ w

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

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

69
ナイコンさん[]   投稿日:2016/02/17 16:29:26
>パソコンが世に出る前の話をしているのに、お前はいったい何を言ってるんだよ…

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

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

と、将来の製品との競合にも言及されてるけど何言ってるの?
コメント1件

70
ナイコンさん[]   投稿日:2016/02/17 16:31:43
>68
> そもそも
> > ただしBill Sydnesのこうした指摘に関してDavid J. Bradleyは否定的である
> って言われてるんだよ?

で、その指摘の内容は??
コメント1件

71
ナイコンさん[]   投稿日:2016/02/17 16:33:19
訂正
誤)指摘の内容
正)否定的とする主張

72
ナイコンさん[]   投稿日:2016/02/17 16:36:33
>68
>重要なものから書くのはこの手の文章なら当たり前だとわかると思うし、概ね妥当な順序だと思う

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

73
ナイコンさん[]   投稿日:2016/02/17 16:42:47
> 1)コスト削減
> 2)関連周辺回路の開発期間の短縮
> 3)先行する8ビットCPUパソコンとの互換性問題
> 4)IBMにおける先行プロジェクトの活用 ---- 先行プロジェクトで蓄積された知識・経験・部品の活用
> 5)同一社内における商品としての差異化のための、技術的性能のスペック・ダウン
> 6)オプション部品による性能向上の可能性

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
ナイコンさん[sage]   投稿日:2016/02/17 16:46:16
たしかに、

>1)コスト削減

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

75
ナイコンさん[sage]   投稿日:2016/02/17 19:11:39
>66-67, >70-71
昌瓠屬修陵由は、AとBです」
Y氏「その理由は、AとCです」

「Bは理由ではないとY氏が言ってる」と取るのが普通だと思うが?
コメント2件

76
ナイコンさん[sage]   投稿日:2016/02/17 19:20:32
>69
どこかのアホは、
> ミニコンの市場なんて「とっくにパソコンに喰われてなくなってる」ことも知らん人かw
と書いてたけど?
まだでてもいないパソコンにどうやってとっくに喰われてなくなるのか詳しく説明してみ w

77
ナイコンさん[]   投稿日:2016/02/17 19:27:23
健全でない言葉が含まれているため表示しません 内容を確認する
コメント1件

78
ナイコンさん[]   投稿日:2016/02/17 19:31:18
>75
昌瓠屮哨Δ鷲,長いです」
Y氏「ゾウは体が大きいです」

「ゾウは鼻が長くないとY氏が言ってる」と取るのが普通?
コメント1件

79
ナイコンさん[sage]   投稿日:2016/02/17 19:38:45
>77
> 何も書けないバカは黙ってろよ w

80
ナイコンさん[sage]   投稿日:2016/02/17 19:39:49
>74
人によって優先順位が違うのは珍しくないだろ

81
ナイコンさん[sage]   投稿日:2016/02/17 19:41:17
>78
それ違うことについて言ってるよね?
そう言う区別もつかないの?
コメント1件

82
ナイコンさん[]   投稿日:2016/02/17 19:45:37
> まだでてもいないパソコンにどうやってとっくに喰われてなくなるのか詳しく説明してみ w

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

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

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

83
ナイコンさん[]   投稿日:2016/02/17 19:46:56
>81
> それ違うことについて言ってるよね?

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

84
ナイコンさん[]   投稿日:2016/02/17 20:19:02
>75
> 「Bは理由ではないとY氏が言ってる」と取るのが普通だと思うが?

じゃあ

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

↑と

> 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.

↑で互いに言及してないことについては「〜は理由ではないと言ってる」と取るのが普通なんですね。
コメント1件

85
ナイコンさん[]   投稿日:2016/02/17 21:42:27
8086と8088だとせいぜい2〜3割の性能差だよね。
普通に考えるなら、
8086だと競合するからNGで、8088だと競合しないからOKってのは
話としては信憑性が低いと思うんだが…

86
ナイコンさん[]   投稿日:2016/02/17 21:54:03
社内的には「性能の低いほうを敢えて選びましたよ」アピールはできるのでは
コメント1件

87
ナイコンさん[sage]   投稿日:2016/02/17 22:51:56
>72
> 5)と6)は内容的にある意味相反してるし
してないでしょ
最初は色々目をつけられるから、猫被っておいて
実積できて文句言われなくなった時用に性能向上できる仕組みを仕込んでおく
って言うのは普通にやるでしょ

88
ナイコンさん[sage]   投稿日:2016/02/17 22:59:17
>82
あんたの話は(その当時における)将来の話だよね?
>63 は「とっくに」って言ってますけど?
ひょっとして「とっくに」って言う意味説明した方がいい? w
コメント2件

89
ナイコンさん[]   投稿日:2016/02/17 23:05:06
初代IBMPCの基板から8087ソケットあるしなあ、
https://en.wikipedia.org/wiki/IBM_Personal_Computer#/media/File:IBM_PC_Motherboard_(1981).jpg
最初は猫被っておいてって感じではないな。

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

90
ナイコンさん[]   投稿日:2016/02/17 23:11:17
>86
仮に自分が担当者(アピールされる側)だったらそれで納得しちゃうわけ?

91
ナイコンさん[]   投稿日:2016/02/17 23:12:22
>88
> > ないない、汎用機程ではないとしても価格が違いすぎる

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

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

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

92
ナイコンさん[]   投稿日:2016/02/17 23:15:26
>88
> ひょっとして「とっくに」って言う意味説明した方がいい? w

ゼヒお願い。
コメント1件

93
ナイコンさん[]   投稿日:2016/02/17 23:23:43
> 8086の馬力はとてつもなく強力なものであった
これを
8086(を搭載した9801無印)の馬力はとてつもなく強力なものであった
と読みかえると違和感ありまくり、決してそんな凄いものではなかったと思うw

94
ナイコンさん[]   投稿日:2016/02/17 23:26:15
88の3倍くらい速い気がしたからとてつもなく速かったよ。
コメント1件

95
ナイコンさん[]   投稿日:2016/02/17 23:40:44
>94
SR以前の88はあんまり性能良くない…というか基本8001と同じ性能だしね。

96
ナイコンさん[sage]   投稿日:2016/02/18 00:12:15
おれの場合、V30だったけど、あまりの速さにもうアセンブラいらねって当時思ったね。

97
ナイコンさん[]   投稿日:2016/02/18 01:41:22
V30の9801VMなんかだと初代9801の2.7倍速くらいだからな、普通に速いだろな。

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

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

99
ナイコンさん[sage]   投稿日:2016/02/18 07:17:17
>91
> ↑そのミニコンは今(=2016年)はもうパソコンに喰われてとっくに(=今よりもっと以前)なくなってるんですよという話だけど読んでて理解できないの?
今の話をして何が嬉しいの?
独り言ならチラ裏へ

>92
とっくに 意味
でググれ
コメント1件

100
ナイコンさん[sage]   投稿日:2016/02/18 07:21:32
もしNECが68k選んでたら、国民機にならなかった。
コメント1件

101
ナイコンさん[sage]   投稿日:2016/02/18 07:25:50
>84
少なくとも主要な理由ではなかったととるのは普通だと思う

102
ナイコンさん[sage]   投稿日:2016/02/18 07:28:37
>100
> もしNECが68k選んでたら、国民機にならなかった。
国民機はEPSONじゃなかったっけ??

103
ナイコンさん[sage]   投稿日:2016/02/18 07:28:50
>98
そう言う話をしてる訳じゃないし、その方面だとそれこそ 68K の足元にも及ばん

104
ナイコンさん[sage]   投稿日:2016/02/18 07:32:08
NEC は無理としても 6809 使ってた富士通か日立が出すかと思ってたらまさかのシャープだったな

105
ナイコンさん[sage]   投稿日:2016/02/18 10:23:41
実はNECは68020を採用した機種EWS4800を販売している。
まあこのシリーズは後にMIPSに転向してしまうが。

106
ナイコンさん[]   投稿日:2016/02/18 12:03:37
>99
>今の話をして何が嬉しいの?
>独り言ならチラ裏へ

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

107
ナイコンさん[sage]   投稿日:2016/02/18 12:53:53
>106
アンカーぐらいまともにつけろよ…
って言うのはおいとくとして

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

>63 (2016年には)ミニコン市場なんてなくなってるんだぜ、ドャ

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

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

108
ナイコンさん[]   投稿日:2016/02/18 13:53:48
>107
>このチップを利用すれば、IBMが
>すでに市場に出していたり、またはこれから市場に出そうとしている製品の
>排気口を広げなくてはならなかったろう。だから、私たちは性能は多少落ちて
>も、8088を利用することに決めたのである。

が理解できない人?
コメント3件

109
ナイコンさん[]   投稿日:2016/02/18 14:18:13
>108
何を言いたいのかイマイチ分からんな。

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

110
ナイコンさん[]   投稿日:2016/02/18 14:37:40
インテルは既存顧客の継続を考えてたらしいけど、それが事実ならIBMの存在が大きかったんでないの?

111
ナイコンさん[sage]   投稿日:2016/02/18 15:14:49
>109
>108の言う「理解できない人」だったかw
コメント1件

112
ナイコンさん[]   投稿日:2016/02/18 15:18:23
> あと本筋と関係ないけど、System/38 はミニコンと言うよりオフコンだな

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

113
ナイコンさん[]   投稿日:2016/02/18 15:43:49
>111
一番最初に「分からん」って表明してるんだし、そんなの当たり前だろw
コメント1件

114
ナイコンさん[]   投稿日:2016/02/18 16:02:57
>113
「イマイチ分からん」てことは、いくらかはわかったって意味だぞ?

115
ナイコンさん[]   投稿日:2016/02/18 16:06:51
>109
↓の文章は読んで理解できるかな?

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

116
ナイコンさん[]   投稿日:2016/02/18 19:12:57
>115
誇張されたり脚色されたりして出来たデマ、神話、伝説の類の話だと思う、
開発秘話(笑)とかにはよくある。

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

117
ナイコンさん[sage]   投稿日:2016/02/18 19:49:39
>108
ひょっとして…
(1980年頃に)8086(とその後継) のマシンが System/38 の市場を席巻することを予見できない奴はバカだ
って言いたいのか?
そりゃ結果知ってりゃなんとでも言えるわ w
そもそも
> 8088を利用することに決めた
にもかかわらず席巻してしまってるから、そう言うこと言うならその判断ですら甘過ぎたってことだろ

118
ナイコンさん[sage]   投稿日:2016/02/18 20:03:28
PC最初の立ち上げでは他部門からの横槍が入らないよう敢えてスペックを
低くしたって読み取れないのかな?ほぼ文章書いてる通りだと思うんだが。
コメント1件

119
ナイコンさん[]   投稿日:2016/02/18 20:07:14
> 当時の上位機種ってなんのことだ?
> まさか System/360 じゃないよな w

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

120
ナイコンさん[sage]   投稿日:2016/02/18 20:29:31
>118
> PC最初の立ち上げでは他部門からの横槍が入らないよう敢えてスペックを低くした

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

121
ナイコンさん[sage]   投稿日:2016/02/18 20:33:53
>119
何周遅れだよW
何に食いついてるのか知らんけどお前の悔しさはよくわかった
コメント1件

122
ナイコンさん[]   投稿日:2016/02/18 20:45:35
>> PC最初の立ち上げでは他部門からの横槍が入らないよう敢えてスペックを低くした
>
>と言う話とミニコンの市場を喰っちゃったと言う話の区別もつかないのか?

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

123
ナイコンさん[sage]   投稿日:2016/02/18 21:07:31
> 当時の上位機種ってなんのことだ?
> まさか System/360 じゃないよな w

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

124
ナイコンさん[]   投稿日:2016/02/18 21:16:39
IBM 5120とか挙げてればまだ良かったのにねw

125
ナイコンさん[sage]   投稿日:2016/02/18 22:03:35
>122
> 「ないない、汎用機程ではないとしても価格が違いすぎる」って書いたこと
> もう忘れちゃったのかな?
いったいどう関係すると言うんだろう…

126
ナイコンさん[sage]   投稿日:2016/02/18 22:06:50
>123
> 1980年頃の話として System/360 を持ち出す意味がわからん。
IBMの代表機種だから出してただけだろ
w 付きだからどう見てもネタだし、何を必死に噛みついてるのかようわからん
コメント1件

127
ナイコンさん[]   投稿日:2016/02/18 22:26:56
>126
> IBMの代表機種だから出してただけだろ
> w 付きだからどう見てもネタだし、

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

128
ナイコンさん[sage]   投稿日:2016/02/18 22:39:34
>36はなんで突然「当時の上位機種」なんて言い出してるんだろう?
アンカー貼ってる>27>31もそんなこと言ってないのにな。
なんか、具体的な製品との競合を避けたかなんかという話と勘違いして一人で暴れてる感じ。

129
ナイコンさん[sage]   投稿日:2016/02/18 23:11:50
8088で盛り上がるのはまあわかるが、今更 System/360 に突っ込まないといけないって‥
なんか嫌なことでもあったんだろうな

130
ナイコンさん[sage]   投稿日:2016/02/19 03:16:15
ボケならツッコミは望むところだと思うし、時代はずれのトンチンカンなことなら
突っ込まれるのも当たり前の筈。

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

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

131
ナイコンさん[sage]   投稿日:2016/02/19 04:56:35

132
ナイコンさん[sage]   投稿日:2016/02/19 06:27:10
このスレで直截的にコスト・パフォーマンスについて
言及している輩が一人も居ない件w

133
ナイコンさん[]   投稿日:2016/02/19 06:44:58
そりゃ、コストパフォーマンス言い出したら68kがボロクソに叩かれるだけだからたろ。
フラットでリニアなメモリと単純なシリアルみたいなIOだけのレベルですらコストパフォーマンス良くないから、68k。
チップセットの存在はでかいってことで。
コメント2件

134
ナイコンさん[sage]   投稿日:2016/02/19 07:23:16
コスト・パフォーマンスは CPU だけで決まる訳じゃない
なんの前提もなしに言及しても >133 みたいなアホがしゃしゃり出てきて収拾つかなくなるだけ

135
ナイコンさん[sage]   投稿日:2016/02/19 07:38:11
>133
アンタは、ヴァカか?
当然、IBMはコスパを意識してコンピュータを作製しただろ。
それを考慮しろと言うだけの話しだよ。

136
ナイコンさん[]   投稿日:2016/02/19 07:57:35
コスパはどんな分野でもついて回るからわざわざ話題にしないだけ。
コメント1件

137
ナイコンさん[sage]   投稿日:2016/02/19 08:04:18
>136
今回のIBMのパソコンについては、重要な因子でしょ。
コスパを抜きにして話しをするのは、アリエナイ。

138
ナイコンさん[sage]   投稿日:2016/02/19 08:49:45
CPU 価格だけ見ても1個買うのと1万個買うのじゃ単価が全然違うし、当時インテルが戦略的な販売攻勢をかけてたって話もちらほらある
PC全体だと設計者のスキルや、周辺デバイスとかソフトウェアも絡んでくるし
当時の状況を把握してない俺らがどうのこうの言い合ってもなんの結論もでないだろ

139
ナイコンさん[sage]   投稿日:2016/02/19 10:09:19
そろそろまとめるか。

勝者はx86。

140
ナイコンさん[]   投稿日:2016/02/19 18:07:10
王者はZ80

141
ナイコンさん[]   投稿日:2016/02/20 05:13:37
1978 インテル 「8086作ったンゴ!」
     モトローラ「ぐぬぬ・・・」

1979 モトローラ「新製品だ、68000。こいつはすげぇんだぜ!」
     インテル 「ふぁぁ!?」

1982 インテル 「186と286つくったンゴ!」
     モトローラ「68010だ、仮想記憶サポートさせたぜ、使えよ」
     インテル 「仮想記憶? 仮想マシン!? ナンデ!? でもアバーは言わない(キリッ!」

1984 モトローラ「68020だぜ。完全に32ビット対応だ、他にもいくつか機能強化したぜ」
     インテル 「な、んだとぉ!?」

1985  インテル 「フル32ビットの386作ったけどよぉ・・・」
     モトローラ「(ニヤニヤ)」

1987 モトローラ「68030だ。MMUとキャッシュ強化したぜ」
     インテル 「・・・」

1989 インテル 「486作ってみた。ちょびっとRISCの技術導入してちょこっと高速化したよ」
     モトローラ「ふぁ!?」

1990 モトローラ「未完成だけど68040出荷するっす・・・」
     インテル 「ふーん?(既に無関心)」

1991 モトローラ「68000シリーズ止めます、これからはAIM連合でPowerPCっすよ!」
     インテル 「あっそ」

1993 インテル 「ペンティアム作ってみた。 あとナンバーで商標登録止めます」
     モトローラ「アバー!?」
コメント5件

142
ナイコンさん[]   投稿日:2016/02/20 12:07:16
>1991 モトローラ「68000シリーズ止めます、

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

143
ナイコンさん[sage]   投稿日:2016/02/20 12:15:27
>141
> 1989 インテル 「486作ってみた。ちょびっとRISCの技術導入してちょこっと高速化したよ」

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

144
ナイコンさん[sage]   投稿日:2016/02/20 12:24:24
>141
88kとi860がないのでやりなおし

145
ナイコンさん[sage]   投稿日:2016/02/20 13:15:22
>141
>1982 インテル 「186と286つくったンゴ!」
>      モトローラ「68010だ、仮想記憶サポートさせたぜ、使えよ」

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

146
ナイコンさん[]   投稿日:2016/02/20 14:17:59
>141
> 1985  インテル 「フル32ビットの386作ったけどよぉ・・・」
> 1989 インテル 「486作ってみた。ちょびっとRISCの技術導入してちょこっと高速化した

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

147
ナイコンさん[sage]   投稿日:2016/02/20 15:31:39
> 1985  インテル 「フル32ビットの386作ったけどよぉ・・・」

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

148
ナイコンさん[]   投稿日:2016/02/20 15:47:58
>143
486で一部の命令が1クロックで実行できるようになった→なんかRISCっぽい?
って感じじゃないかとw

149
141[]   投稿日:2016/02/20 16:20:16
32行制限のせいで省略してるし68kに関してはWIKI頼りからね。
指摘どおり「68010の仮想記憶」はカタログにかかれてた以上の事はしらない(あと職場の先輩から「あんなものは使うな」って言われたぐらいか)
んで、386のフル32ビット云々のつっこみが理解できない。
「フル32ビット」の表記はインテルの広告で見たような覚えがあるから使っただけなんだが。

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

150
ナイコンさん[sage]   投稿日:2016/02/20 16:55:47
>141
> 1987 モトローラ「68030だ。MMUとキャッシュ強化したぜ」
× インテル 「・・・」
○ インテル 「え"っ、今ごろ?」

151
ナイコンさん[]   投稿日:2016/02/20 17:01:52
>149
>「フル32ビット」の表記はインテルの広告で見たような覚えがあるから使っただけなんだが。

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

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

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

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

152
ナイコンさん[sage]   投稿日:2016/02/20 17:05:29
> ○ インテル 「え"っ、今ごろ?」

80386には内蔵キャッシュがなかったのにこの反応はわけわからんな
コメント1件

153
ナイコンさん[]   投稿日:2016/02/20 17:07:25
>151
おーすごいすごい、がんばって次はCM関連あつめてくれ。
俺はやらないけどな!

154
ナイコンさん[sage]   投稿日:2016/02/20 17:12:51
こういうタイプは職場でも無能

155
ナイコンさん[sage]   投稿日:2016/02/20 17:15:58
>142
68340 とか作ってたしね
中規模の組み込み機器にはそこそこ使われてた
途中で部署変わったからはっきりしないけど、2008 年ぐらいまではうちの製品にも入ってた

156
ナイコンさん[sage]   投稿日:2016/02/20 17:26:36
>152
MMU の方の話でしょ

157
ナイコンさん[sage]   投稿日:2016/02/20 17:33:12
>145
> 68010が必要とする外付けMMU68451が提供した仮想記憶機構
なんのことを言ってるんだろう…?

158
ナイコンさん[sage]   投稿日:2016/02/21 02:34:59
フル32bitは、レジスタ、アドレスバス、データバスがすべて32bitって意味だったかな。
xxbitCPUの定義が議論されはじめた時代。

159
ナイコンさん[sage]   投稿日:2016/02/21 03:43:47
自社やライバル会社の製品に「中途半端な32bit製品」がない限りはアピールとして意味ないんだよなあ >フル32bit

160
ナイコンさん[sage]   投稿日:2016/02/21 03:57:27
ライバル企業の68kは32bitCPUという表現に対抗しただけだろう。
今のintelはアドレスバス40bit、データバス256bitとか需要に沿って変態進化してて、今だから奇妙に思えるだけ。

161
ナイコンさん[sage]   投稿日:2016/02/21 11:55:36
80386より先に外部も32bitの68020が出てるんで何に対抗してるの? という感じだな。

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

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

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

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

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

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

162
ナイコンさん[]   投稿日:2016/02/21 12:08:53
>ライバル企業の68kは32bitCPUという表現に対抗しただけだろう。
>今のintelはアドレスバス40bit、データバス256bitとか需要に沿って
>変態進化してて、今だから奇妙に思えるだけ。

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

163
ナイコンさん[sage]   投稿日:2016/02/21 12:30:12
そうそう。当時インテルはモトローラなんて相手にしてなかった。

164
ナイコンさん[sage]   投稿日:2016/02/21 12:36:27
月刊マイコンだったか、よくx86叩き、68kマンセー記事をよく見かけたが笑いが止まらなかったのはよく覚えている。
その流れが続いて、Windows叩き、Macマンセーの記事もよく書かれていた。

165
ナイコンさん[]   投稿日:2016/02/21 13:05:01
x86は32bitでフツーに使われるまで長かったからなあ。
「速い8086」では笑われて当たり前。

166
ナイコンさん[sage]   投稿日:2016/02/21 15:02:52
速い32bitCPUの需要がなかったにすぎない。

167
ナイコンさん[]   投稿日:2016/02/21 15:08:50
フル32ビットは、
8088が16ビットだったり
68K=32ビット説がそれなりに受け入れられてたり
65816=Apple2GSやスーパーファミコンが16ビットだったり
NS32016もあった。
○ビットというのがマーケティングに利用された(後年のセガサターンの64ビット級とかが顕著な例)こともあって、
その中で正真正銘の32ビットというのをアピールしたかったんじゃない?

168
ナイコンさん[]   投稿日:2016/02/21 15:23:36
>「フル32ビット」の表記はインテルの広告で見たような覚えがあるから使っただけなんだが。

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

169
ナイコンさん[]   投稿日:2016/02/21 15:33:00
速い32bit CPUの需要はあったがOSもアプリケーションも整備されるのに時間が掛かった。

170
ナイコンさん[sage]   投稿日:2016/02/21 15:42:12
ユーザは持ってるソフトが速く快適に動くことを望んだ。> DOSが動く速いPC。
PGは一度作ればソフトが多く売れるPCを望んだ > x86が乗ったPC。

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

171
ナイコンさん[sage]   投稿日:2016/02/21 15:44:00
> 当時、誰も速い32bitなど望んでいない。

DOSエクステンダ使ったCADとか普通にあったけど知らんのねw
コメント1件

172
ナイコンさん[]   投稿日:2016/02/21 15:48:04
>ユーザーから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
ナイコンさん[sage]   投稿日:2016/02/21 15:50:43
やはり笑える。当時と同じで68kマンセー君が意味不明に必死杉w
まだ負けたことがトラウマなのだろうw
コメント2件

174
ナイコンさん[]   投稿日:2016/02/21 15:51:40
>当時、誰も速い32bitなど望んでいない。

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

175
ナイコンさん[]   投稿日:2016/02/21 15:52:59
>173
x86方面からも

176
ナイコンさん[]   投稿日:2016/02/21 15:54:07
>173
x86方面からも68k方面からもフルボッコにされてるけど気が付かないんかな?

177
ナイコンさん[]   投稿日:2016/02/21 15:56:05
> ユーザは持ってるソフトが速く快適に動くことを望んだ。> DOSが動く速いPC。
> PGは一度作ればソフトが多く売れるPCを望んだ > x86が乗ったPC。
>
> 当時、誰も速い32bitなど望んでいない。ユーザーから68020は相手にされてなかった。

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

178
ナイコンさん[sage]   投稿日:2016/02/21 16:03:12
おまえの知ってることは重箱の隅みたいなものでみなどうでもいいことだってこと。

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

179
ナイコンさん[]   投稿日:2016/02/21 16:07:52
>おまえの知ってることは重箱の隅みたいなものでみなどうでもいいことだってこと。
>
>だから市場から消えたのだよ。

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

180
ナイコンさん[sage]   投稿日:2016/02/21 16:19:18
68kの怨念を晴らすスレだったね、ごめん。

181
ナイコンさん[sage]   投稿日:2016/02/21 16:21:02
なんか、憐れになってきた

182
ナイコンさん[sage]   投稿日:2016/02/21 16:25:26
だよな。何度議論してもx86が勝つという結論は変わらないし。

183
ナイコンさん[sage]   投稿日:2016/02/21 17:52:17
自分が開発したわけじゃないのに
勝ち誇る意味がわからん

184
ナイコンさん[]   投稿日:2016/02/21 17:57:17
自身の過去の実績とかを誇れない奴は使ってた道具とかにすがるしかないんだろうな。

185
ナイコンさん[sage]   投稿日:2016/02/21 18:07:57
ベンツ乗ってるとみんなよけるんだよね。なんか勝った気がするじゃん。それと同じ。
コメント1件

186
ナイコンさん[sage]   投稿日:2016/02/21 19:27:21
>170
こういう恥の多い人間がのうのうと生きていくためには、憐みの目で見られていることすら
気付かない、図太い神経が必要だという分かりやすい事例

187
ナイコンさん[sage]   投稿日:2016/02/21 19:28:48
俺もベンツだけは避けるようにしてる
特に最近のあのデカいロゴは威圧感あるんだよな

188
ナイコンさん[sage]   投稿日:2016/02/21 19:42:14
>171, >174
メモリーがもっと必要だっただけ
32bit パワーが求められたわけじゃない
コメント1件

189
ナイコンさん[sage]   投稿日:2016/02/21 19:49:32
>188
32bit なくしてメモリーをもっと使える方法があったなら教えて
コメント1件

190
ナイコンさん[sage]   投稿日:2016/02/21 19:53:09
68kユーザだったけれど32bitだとは思わないぞ030以降は除く。

191
ナイコンさん[sage]   投稿日:2016/02/21 19:54:43
今の基準はレジスタ幅だから今の基準でいうと、68kはやっぱり32bitCPUだよ。
コメント2件

192
ナイコンさん[sage]   投稿日:2016/02/21 19:56:09
>189
セグメントレジスタ。さらに横に1bitずらす。
コメント1件

193
ナイコンさん[sage]   投稿日:2016/02/21 20:08:44
>192
じゃあ80286で十分てことじゃん。実際そうはならなかったが?
コメント1件

194
ナイコンさん[]   投稿日:2016/02/21 20:10:10
>191
> 今の基準は

誰かそんな話してる?

195
ナイコンさん[sage]   投稿日:2016/02/21 20:13:40
マルチタスク、GUIするには当時の32bitCPUは遅すぎた。なのでDOSが速いことが一番重要だった。
コメント1件

196
ナイコンさん[]   投稿日:2016/02/21 20:15:53
>191
> 今の基準はレジスタ幅だから

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

197
ナイコンさん[]   投稿日:2016/02/21 20:17:42
>195
> マルチタスク、GUIするには当時の32bitCPUは遅すぎた。

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

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

199
ナイコンさん[]   投稿日:2016/02/21 20:45:08
68020のWSにシリアル端末20台くらいつなげてソースのエディットや
アセンブル、リンクとかしてたけど落ちたりはしてなかったなあ。
速度はまあ速くはなかったが同時にCPU使う処理がそう重なることも
なかったし普通に使えてたわ。
コメント1件

200
ナイコンさん[sage]   投稿日:2016/02/21 20:48:12
93年くらい?に386に8MBのメモリのPCでYggdrasil使ってたけどけっこう快適だったなあ。

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

202
ナイコンさん[]   投稿日:2016/02/21 20:54:56
相変わらず68kのお葬式会場というか68kファンの愚痴たれながし会場なのね、ここは。

203
ナイコンさん[]   投稿日:2016/02/21 20:55:10
>大学にあったNECのEWSとか遅くて死にそうだった。100行もないソースのコンパイルも随分待たされる。たまに落ちて授業が中断してた。

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

204
ナイコンさん[]   投稿日:2016/02/21 21:07:00
健全でない言葉が含まれているため表示しません 内容を確認する
コメント1件

205
ナイコンさん[]   投稿日:2016/02/21 21:13:07
68kが使えないプロセッサだったのは個人の体験から言える列記とした事実なんだよなぁ。
68kしかしらないやつが遠吠えしたところで歴史は変えられないんだよなぁ。

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

206
ナイコンさん[]   投稿日:2016/02/21 21:15:22
>204
ワークステーションではMIPSやSPARCに、パソコンはx86に全然負けてる使われ様でしたが、どころらへんが「結構活用された」んでしょうか?
コメント2件

207
ナイコンさん[]   投稿日:2016/02/21 21:38:37
>206
80年代半ばにSPARCstationが存在したどこかの平行宇宙の方ですか?

208
ナイコンさん[sage]   投稿日:2016/02/21 21:40:34
>193
286 はリアルモードに戻るのが面倒だったことも知らんのならいちいち絡んでくるなよ
コメント1件

209
ナイコンさん[sage]   投稿日:2016/02/21 21:45:01
>208
面倒つってもそれ用の機構は用意されてたし当時のDOSで問題あるわけないんだよなあ。
コメント1件

210
ナイコンさん[sage]   投稿日:2016/02/21 21:50:41
>197
GUI 使ってた?
>199 みたいにシリアル接続なら 68010 のWSでもそこそこ使えてた
でも GUI となると全然ダメ
解像度がPCに比べて高かったしフルビットマップだったしろくなアクセラレータもない時代だからしょうがなかったけど

211
ナイコンさん[sage]   投稿日:2016/02/21 21:57:39
>206
SONY NEWS, Mac とかも知らんのか?
あとお前は知らんだろうが組込用に VME Bus board 製品が結構使われていた

212
ナイコンさん[sage]   投稿日:2016/02/21 22:02:26
>209
CPU には用意されてないよ
リセットするしかないんだから
ソフトでリセットするハードを追加してリアルモードに戻れる様にしてたけど、当然すごく遅いのであまり実用的でなかった
コメント2件

213
ナイコンさん[sage]   投稿日:2016/02/21 22:08:35
>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).
コメント1件

214
ナイコンさん[sage]   投稿日:2016/02/21 22:08:52
>205
何がどう使えなかったのかな?笑わないから言ってみ
それと、代わりに何を使っていたかも言ってみ

215
ナイコンさん[sage]   投稿日:2016/02/21 22:44:49
>213
>> Later, …
 ~~~~~~
コメント1件

216
ナイコンさん[]   投稿日:2016/02/21 23:08:11
そもそもOS/2とかXENIXとか使えばリアルモードに戻らなくても良いんじゃないの?
コメント1件

217
ナイコンさん[]   投稿日:2016/02/21 23:18:48
実際に68kつかってて「これは素晴らしい!」とか言うのは洗脳されてるモト信者だけだろ。
その信者の集まりがここだから「68kは完璧すごいプロセッサ!!」みたいなノリになりがちだが。

218
ナイコンさん[]   投稿日:2016/02/21 23:34:45
WSにしろPCにしろ広い分野で使われてたのはある意味すごいけどどれもこれも中途半端だったよな、68k。
インテル抑えてたのは組込み分野とPDAぐらいか?

219
ナイコンさん[]   投稿日:2016/02/21 23:44:06
結局8086か68Kかはメモリをどれだけ積むかじゃない?
4MB以上なら68Kの方が良いし、
4MB以下なら8086+バンクメモリ(EMS含む)もありかも、
1MB以下で良いなら8086の方が良いと思うわ。

220
ナイコンさん[]   投稿日:2016/02/22 02:03:21
>215
ちょっと何言いたいんだかわからんな。Later って書いてあるけどもちろん
>212の投稿 2016/02/21(日) 22:02:26.36 より前の話だぞ?
コメント1件

221
ナイコンさん[sage]   投稿日:2016/02/22 02:36:55
>286 はリアルモードに戻るのが面倒だったことも知らんのならいちいち絡んでくるなよ

古い知識披露して恥掻いちゃったネ
コメント1件

222
ナイコンさん[sage]   投稿日:2016/02/22 04:33:33
>185
一般人の間では ベンツ=ヤクザ だからな。
避けるのは当たり前。

223
ナイコンさん[sage]   投稿日:2016/02/22 06:14:59
>216
OS/2はDOS互換環境を実現するためにリアルモード環境に戻る必要性がある。
まあOS/2,Windows共に最初から286を無視して386のみに限定すれば
良かったのだが無謀にも286をサポートしたために後々まで苦しめられることになった。
コメント3件

224
ナイコンさん[]   投稿日:2016/02/22 06:22:09
> まあOS/2,Windows共に最初から286を無視して386のみに限定すれば
> 良かったのだが

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

225
ナイコンさん[sage]   投稿日:2016/02/22 06:35:08
>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
ナイコンさん[sage]   投稿日:2016/02/22 06:51:39
誰が悪いってIntelが286を仕様欠陥品としてディスコンにしなかったから。

227
ナイコンさん[sage]   投稿日:2016/02/22 07:13:04
GUIって言ってもUNIXでターミナルでvi、cc走らすのと、NTでIEやOffice、VS走らすのじゃ必要リソース全然違うね

228
ナイコンさん[sage]   投稿日:2016/02/22 07:13:54
triple fault で全部解決って思ってるアホがいるみたいだが、CPU をリセットしないとダメなのは変わらんしキーボードコントローラ使ってリセットするよりはマシって話だからな

229
ナイコンさん[sage]   投稿日:2016/02/22 07:29:02
>220
お前こそ何を言ってるのかさっぱりわからんのだが?
いつの話をしてるつもりなのか年号書いてみ

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

230
ナイコンさん[]   投稿日:2016/02/22 07:30:01
>286 はリアルモードに戻るのが面倒だったことも知らんのならいちいち絡んでくるなよ

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

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

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

ホントこいつバカw
コメント4件

231
ナイコンさん[]   投稿日:2016/02/22 07:34:15
>いつの話をしてるつもりなのか年号書いてみ

「後々まで〜」なんて書いてるアホがなんか言ってるなw
コメント1件

232
ナイコンさん[]   投稿日:2016/02/22 07:35:36
>223
DOSセッション使わなきゃ良い。
なぜそこまでDOSに拘るんだ…
コメント2件

233
ナイコンさん[sage]   投稿日:2016/02/22 07:36:28
>286 はリアルモードに戻るのが面倒だったことも知らんのならいちいち絡んでくるなよ

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

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

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

○○のひとつ覚えw
コメント3件

234
ナイコンさん[]   投稿日:2016/02/22 07:38:25
>232
>170みたいなこと本気で信じてるからでしょ
コメント1件

235
ナイコンさん[sage]   投稿日:2016/02/22 07:41:19
>232
当時、DOSソフトが世界最強だったから。
Windows発売時、ゲイツが日本来て、ソフト販売ランキング一位がVzで顔をしかめたぐらい。
ちなみにそのランキング一覧に68kのソフトなど一つも入っていない。
コメント1件

236
ナイコンさん[]   投稿日:2016/02/22 07:43:44
286は高速8086と使い方が主流だったと思うが?
バード的なバンク切り替えなEMSだったしな。
286はリアルモードで使うのが現実的。
68000もスーパーバイザーモードのみで使うのが現実的…

237
ナイコンさん[sage]   投稿日:2016/02/22 07:48:31
486でも高速な8086という使い方が主流でしたよ。
OS/2、Windowsにはまだまだバワー不足。

238
ナイコンさん[]   投稿日:2016/02/22 07:51:50
>235
そりゃ日本じゃ国産のDOSマシシが売れてましたからね。

239
ナイコンさん[]   投稿日:2016/02/22 07:58:26
>234
486辺りはWindows3.xあたりがちらほら使われてましたが。
日本語だともっさりでしたけどね。

240
ナイコンさん[sage]   投稿日:2016/02/22 08:16:35
>224
営業戦略上できないことは承知の上で言うが最上位機のモデル80(386搭載)
のみを対象としていればすんだこと。
実際PS/2の最下位機種のモデル30は対象外だ。
まあ現実には多数存在するPC/AT機をOS/2対象外とするのは出来なかった。

241
ナイコンさん[sage]   投稿日:2016/02/22 08:18:45
そしてユーザーからはOS/2が対象外にされた。

242
ナイコンさん[sage]   投稿日:2016/02/22 08:35:01
>230
プロテクトモード下にあるOSが保護の全く働かないリアルモードに
戻らなければいけないというのがどれ程の愚行であるのかが理解できないのか。
コメント1件

243
ナイコンさん[sage]   投稿日:2016/02/22 08:49:22
>230, >233
お前(等?)は一体誰と戦ってるんだよ
敵は一人と思い込むタイプか?

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

244
ナイコンさん[sage]   投稿日:2016/02/22 12:46:54
>231
> 「後々まで〜」なんて書いてるアホがなんか言ってるなw
そんなことを書いた覚えはないんだが w
まあ、どうせ答えられないんだろ?
だったらおとなしく ROM ってろ
コメント1件

245
ナイコンさん[]   投稿日:2016/02/22 13:09:23
>244
お前が>223じゃないなら笑われてるのはお前じゃないから安心してりゃいいんじゃね?
コメント1件

246
ナイコンさん[]   投稿日:2016/02/22 13:17:41
>242
ユーザーの求めてるものが

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

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

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

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

だそうだし。

247
ナイコンさん[sage]   投稿日:2016/02/22 14:11:17
その通りですよ。286でOS/2だなんて何かの精神修行ですか?

248
ナイコンさん[]   投稿日:2016/02/22 15:43:35
>メモリーがもっと必要だっただけ
>32bit パワーが求められたわけじゃない

という主張に於いては80286は正義なんだよなあ。
コメント1件

249
ナイコンさん[sage]   投稿日:2016/02/22 16:38:15
ゲイツ「パソコンのメモリは640KBもあれば十分。」
コメント2件

250
ナイコンさん[]   投稿日:2016/02/22 16:53:48
>249
ソースがないんだよなあ
コメント1件

251
ナイコンさん[]   投稿日:2016/02/22 17:05:55
>249
有名なエピソードだよね。

252
ナイコンさん[sage]   投稿日:2016/02/22 17:53:11
>250
おそらくDOS動かすにはとかの文脈だろうな。ゲイツはガチPGだからな。

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

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

254
ナイコンさん[]   投稿日:2016/02/22 18:22:25
「セグメントレジスタ。さらに横に1bitずらす。」とか言ってたバカがなんか言ってらあw

255
ナイコンさん[sage]   投稿日:2016/02/22 18:22:37
>245
まあそうだな
見境なしのバカに噛みつかれたと思うことにするよ w
どうせもう一匹のバカ(別人かどうかは知らんが)は恥ずかしくてレスできないだろうし

256
ナイコンさん[sage]   投稿日:2016/02/22 18:28:48
8086のセグメントレジスタってそうやってアドレス拡張したんだけど。
リニアのフラットアドレスしか触ったことない子かな?
コメント1件

257
ナイコンさん[sage]   投稿日:2016/02/22 18:35:52
95の要件が386以降なのだから、16bitコードは削除して32bitコードに書き換えればいいだけ。
なぜそれをしなかったのか。理由は簡単。

258
ナイコンさん[]   投稿日:2016/02/22 18:38:49
>8086のセグメントレジスタってそうやってアドレス拡張したんだけど。
>リニアのフラットアドレスしか触ったことない子かな?

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

259
ナイコンさん[]   投稿日:2016/02/22 18:39:59
>なぜそれをしなかったのか。理由は簡単。

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

260
ナイコンさん[sage]   投稿日:2016/02/22 18:41:57
残念。プログラマも夜は寝たかったからが正解。

261
ナイコンさん[sage]   投稿日:2016/02/22 18:42:49
>256
セグメントレジスタずらしたところで1セグメント=64kBの制限は変わらんし、
Windowsのリソース不足って1セグメント=64kBの制限が原因なんだが解って
ないなw

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

263
ナイコンさん[sage]   投稿日:2016/02/22 18:52:57
1セグメントで足りないなら2セグメント使えばいいじゃん。
そもそも1seg=64kb制限ってwin95ってリアルモードで動いてんの?その辺詳しく教えて。

264
ナイコンさん[sage]   投稿日:2016/02/22 18:55:26
>なぜそれをしなかったのか。理由は簡単。
NT系統を売りたかったと言う理由かな?
MSの意向がそれならば俺はまんまと嵌められて
NT4.0と2kを買ったことになるな
コメント1件

265
ナイコンさん[]   投稿日:2016/02/22 18:56:59
>インテルとしては
>> そもそもOS/2とかXENIXとか使えばリアルモードに戻らなくても良いんじゃないの?
>って思ってたんだろうね

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

266
ナイコンさん[sage]   投稿日:2016/02/22 19:01:50
>253
95の頃にはすでに NT 3.5 が出てたから >264 の言うようにそれに移ればよかっただけ
まあOSの堅牢性は上がったけどメーカーもNTを家庭で使うことをあまり想定してなくて
某エプソンのモノクロインクジェットプリンタドライバのせいでブルースクリーンを見るはめになったわけだが…W
コメント1件

267
ナイコンさん[sage]   投稿日:2016/02/22 19:18:44
>266
NT用ドライバーがあったのならよかったじゃないか。
当時NT系を選択するとサポートされているデバイスが限られて
結局9x系も使わにゃいけなかった。
コメント1件

268
ナイコンさん[]   投稿日:2016/02/22 19:24:19
セグメントレジスタがセレクタになってる、ぐらいのっこみがはいらないとか、レベル低すぎ。
リング3な奴らばっかりだな!
コメント2件

269
ナイコンさん[]   投稿日:2016/02/22 19:29:28
Windows3xのリソース不足にはほんと泣けたわ。
95以降では泣いた覚えないけどな!

270
ナイコンさん[sage]   投稿日:2016/02/22 19:36:24
>267
プリンターは物理インターフェースは標準的なもの(当時はセントロ準拠)だし、エプソンやキャノンはビジネスプリンターも売ってるから比較的早い時期からNTもサポートされてたよ
独自インターフェースのデバイスは言われる通り全滅に近い状態だったけど

271
ナイコンさん[sage]   投稿日:2016/02/22 19:36:32
9xはスルーしてNTからだわ。おまえらほんと根性あるな。

272
ナイコンさん[sage]   投稿日:2016/02/22 19:43:32
>265
OS/2 はハイエンド向けだけど、XENIX は初期の版だと 8086 ですら動作するぐらい軽いOSだよ
そもそも Unix の思想が小さなツールを組合わせて使うって言うものだから 80286 にはマッチしていると思う
そうは言っても GUI となるとさすがに荷が重いが

273
ナイコンさん[sage]   投稿日:2016/02/22 19:45:25
>268
セレクタになっても286のセグメントサイズは最大64Kのままだが?

274
ナイコンさん[]   投稿日:2016/02/22 19:57:58
セレクタになっても、ジャなくて、セレクタって単語出てこない時点でお前らレベルがリング3なんよ。
コメント1件

275
ナイコンさん[]   投稿日:2016/02/22 20:06:58
DSとESとが使えたからってのもあるけど、セグメントリミットが64kとかたいした制限にはならなかったよな。
奇数番地からのワードアクセスで例外起こすほうがよほどにクソだわ。
コメント1件

276
ナイコンさん[sage]   投稿日:2016/02/22 20:07:25
>268
インテル(日本法人)が発行していた60386プログラマーズ・リファレンス
マニュアル内でもセグメントレジスタ(第2章)と記載していてプロテクトモードの
説明の時(第5章)に初めてセレクタと表現されるのでレジスタの呼称としては間違いではない。

277
ナイコンさん[]   投稿日:2016/02/22 20:10:17
60386とな!?

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

278
ナイコンさん[sage]   投稿日:2016/02/22 20:45:00
>60386とな!?

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

279
ナイコンさん[sage]   投稿日:2016/02/22 20:50:48
>274
セレクタって言いたいだけだろw

280
ナイコンさん[]   投稿日:2016/02/22 20:58:20
俺は386のマニュアル読んだときに「プロテクトモードではセレクタにします」と受け取ったんだが違うの?
286だとリアルでもプロテクトでもセグメント、386以降だとセグメントとセレクタとになる、っての?
そっちのほうが不自然だろ・・・
コメント2件

281
ナイコンさん[sage]   投稿日:2016/02/22 22:07:29
>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
ナイコンさん[]   投稿日:2016/02/22 22:10:59
>280
プロテクトモードではディスクリプタテーブルで定義されたセグメントをセグメントレジスタに格納されたセレクタ値で指定する。

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

284
ナイコンさん[sage]   投稿日:2016/02/22 22:36:11
奇数番地のワードアクセスとかどうやってどうCPU実装すりゃいいんだよw
考えただけでもぞっとするわw 分解してアクセスしてからから後でレジスタに突っ込むのかw
常識的にそんなコード書くなw

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

286
ナイコンさん[sage]   投稿日:2016/02/22 22:43:30
http://homepage2.nifty.com/m_kamada/docsproc/68060_05.htm
> 68060 は 68020〜68040 と同様にワードまたはロングワードのデータの
> アクセスで奇数アドレスを指定できるので、PC を奇数にしようとした場合以外
> でアドレスエラーが発生することはありません。

287
ナイコンさん[sage]   投稿日:2016/02/22 22:53:33
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

ワードアクセスだけやたら遅い。
コメント1件

288
ナイコンさん[sage]   投稿日:2016/02/22 22:55:53
Intelは486以降ACビットとAMビットを操作すればアライメントチェック例外を
発生できるようになったけど68020以降は無条件でアライメントチェックは
なくなってしまったの?

289
ナイコンさん[sage]   投稿日:2016/02/22 23:06:17
>287
オペランドサイズプリフィックスの影響が出てるんじゃ?

290
ナイコンさん[sage]   投稿日:2016/02/23 07:28:04
68kはプログラマー側から見ると率直な32bitCPUだからプログラムが組みやすい
I/Oをメモリーマップドのみだから純粋なC言語だけで対応できる

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

291
ナイコンさん[]   投稿日:2016/02/23 07:30:29
アライメント例外は使うことなかったな。
必要性が判らん。
コメント1件

292
ナイコンさん[sage]   投稿日:2016/02/23 07:35:51
煩雑なのはOS開発してる人だけ。ユーザーは過去の資産も使えるカッコイイCPU。それがx86。

293
ナイコンさん[]   投稿日:2016/02/23 12:22:47
>290
IOは普通にライブラリ関数、わざわざインラインアセンブラで書く意味ないだろ。
cでセグメント操作明示的に行うとかDonだけシビアなのさ。
それでないと仕様満たさないとかだとしたら、それは根本的なところがクソな仕事ととしか言えないわ。

294
ナイコンさん[]   投稿日:2016/02/23 12:34:24
>283
たしかに再帰使うとスタックが64kはせまいね。
関数呼び出しの時点でスタックセグメント切り替えるコード吐くコンパイラはなかったのかな?
コメント1件

295
ナイコンさん[]   投稿日:2016/02/23 12:36:03
>IOは普通にライブラリ関数、わざわざインラインアセンブラで書く意味ないだろ。

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

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

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

296
ナイコンさん[sage]   投稿日:2016/02/23 12:37:23
組み込みだったらなおさら再帰とかあり得ん。

297
ナイコンさん[]   投稿日:2016/02/23 12:37:42
>たしかに再帰使うとスタックが64kはせまいね。

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

298
ナイコンさん[sage]   投稿日:2016/02/23 12:45:26
たった数レスなのに
・再帰でスタック領域が云々
・組込みで I/O アクセスが云々
がごっちゃなる奴もいるんだなw

299
ナイコンさん[sage]   投稿日:2016/02/23 12:47:19
>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も忘れてしまっているのでは

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

300
ナイコンさん[sage]   投稿日:2016/02/23 12:53:53
>294
> 関数呼び出しの時点でスタックセグメント切り替えるコード吐くコンパイラはなかったのかな?
メモリーモデルとして compact とか large を指定すればいけるんじゃね?
やったことないけど…

301
ナイコンさん[sage]   投稿日:2016/02/23 13:02:13
>299
> MMUを持たない68000-68020などはどうしているのか判らないので
> 是非教授して欲しい。
I/O 領域はスーパーバイザデータとしてしかアクセスできない様に設計するのはごく普通
「ユーザーモード」や「スーパーバイザモードでもその領域を実行しようとしたら」バスエラーになる
コメント1件

302
ナイコンさん[sage]   投稿日:2016/02/23 13:17:58
>299
>I/O操作なんて普通に関数呼び出しだし

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

303
ナイコンさん[]   投稿日:2016/02/23 13:30:37
>299
>もちろんasm文なんかもあったがもっぱらアセンブラによる高速化目的で必須ではない。
>(例;配列で構成された多倍長整数の演算等

Cで書けるものを例に挙げて何が言いたいのやらw
コメント1件

304
ナイコンさん[]   投稿日:2016/02/23 13:55:20
>302
> I/O操作関数がCで書けないことについての不満や疑問
って例えばどういうのがあるの?

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

305
ナイコンさん[]   投稿日:2016/02/23 14:00:29
>って例えばどういうのがあるの?

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

306
ナイコンさん[]   投稿日:2016/02/23 14:05:09
>305
それならインラインアセンブラで書いたマクロとかインライン関数で良いじゃないか。

307
ナイコンさん[]   投稿日:2016/02/23 14:10:57
x86は16bitCPUかつセグメントやI/O操作にアセンブラ併用が必須だからメンドイ

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

I/O操作関数がCで書けないことについての不満や疑問はないのかな?

って例えばどういうのがあるの?

例えばGPIOで実装されたSPIバスへの操作をCで書くとして、I/O操作のたびに関数呼び出しが発生して性能が出ない

それならインラインアセンブラで書いたマクロとか

馬鹿丸出しw
コメント2件

308
ナイコンさん[sage]   投稿日:2016/02/23 14:17:17
>305
えーとそれx86か68kかってのと関係ある?
コメント1件

309
ナイコンさん[]   投稿日:2016/02/23 14:17:52
>307
あ、299の人とは別人です。誤解させちゃったか…
コメント1件

310
ナイコンさん[]   投稿日:2016/02/23 14:20:18
x86は16bitCPUかつセグメントやI/O操作にアセンブラ併用が必須だからメンドイ

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

I/O操作関数がCで書けないことについての不満や疑問はないのかな?

って例えばどういうのがあるの?

例えばGPIOで実装されたSPIバスへの操作をCで書くとして、I/O操作のたびに関数呼び出しが発生して性能が出ない

それならインラインアセンブラで書いたマクロとか

馬鹿丸出しw

311
ナイコンさん[sage]   投稿日:2016/02/23 14:21:20
ていうかinpとかoutpとかインライン展開されないコンパイラとか見たこと無いけど。
メモリマップトI/Oへのバースト書き込みが最適化で消されてはまったことならある。
コメント1件

312
ナイコンさん[]   投稿日:2016/02/23 14:22:41
>308
理解できない人はこの議論に加われない人

313
ナイコンさん[sage]   投稿日:2016/02/23 14:22:45
バイナリをすらすら読める重要性をやっと理解してくれたか。

314
ナイコンさん[sage]   投稿日:2016/02/23 14:24:42
>ていうかinpとかoutpとかインライン展開されないコンパイラとか見たこと無いけど。

お前が知らないだけ。

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

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

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

316
ナイコンさん[]   投稿日:2016/02/23 14:39:25
> メモリマップトI/Oへのバースト書き込みが最適化で消されてはまったことならある。

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

317
ナイコンさん[]   投稿日:2016/02/23 14:46:40
>ていうか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
ナイコンさん[]   投稿日:2016/02/23 14:51:13
>自前でインラインアセンブラを使ってそうなるように書くことも出来るだろね、

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

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

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

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

320
ナイコンさん[sage]   投稿日:2016/02/23 17:10:24
>301
ユーザーにはI/O操作は最初から与えられてないということでいいのかな。
それならばユーザーがメモリマップドI/O空間を不正にアクセスしたのをどう検出するの。

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

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

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

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

321
ナイコンさん[]   投稿日:2016/02/23 17:44:39
>文中の『必須ではないが』というのが見えてないようだな。

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

322
ナイコンさん[]   投稿日:2016/02/23 17:46:24
>DOS時代はBorland系のCを使っていたが普通にインライン展開をしてくれていたはずだから
>特に意識してなかったな。

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

323
ナイコンさん[]   投稿日:2016/02/23 17:49:36
>DOS時代のCのソース見たこと無いだろう。
>I/O操作なんて普通に関数呼び出しだし

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

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

324
ナイコンさん[sage]   投稿日:2016/02/23 18:06:02
そういえばDOS時代になってほとんどプログラム書かなくなったな。
X68KやMacと違って良質なフリーソフトが大量に供給されたからな。

325
ナイコンさん[]   投稿日:2016/02/23 18:17:50
良質なフリーソフトが勝手に生えてくると思ってる人かな

326
ナイコンさん[sage]   投稿日:2016/02/23 18:19:30
おそらくx86のほうがプログラムが組みやすかったのだろう。

327
ナイコンさん[sage]   投稿日:2016/02/23 18:38:08
この頃はエディタの優劣で開発効率が決まる。
Unixがショボイのばかりなのはviのせい。
コメント1件

328
ナイコンさん[sage]   投稿日:2016/02/23 18:39:04
>320
> もしそうならば外部支援無しの単体ではシステム資源保護は出来ない欠陥MPUということになってしまうが。
そんな極端なことを言い出したら大抵の汎用プロセッサは外部支援なしの単体ではメモリーアクセスすら出来ない欠陥 CPU と言うことになってしまうが? w
方法はいくつかあるけどアドレスデコードの条件にFCを加えるだけで対応してる機器が多いと思う
(ユーザーモードでアクセスするとデバイスから DACK が返らないので、タイムアウトでバスエラーになる)
コメント1件

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

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

330
ナイコンさん[sage]   投稿日:2016/02/23 22:41:02
crt0も実装できなきゃなってか?
コメント1件

331
ナイコンさん[sage]   投稿日:2016/02/24 00:16:17
>327
初期のMS-DOSのEDLINも操作性は相当駄目かと。
一時はDOS上にCP/M86エミュレータを載せてCP/M86版WordMasterを使っていたぐらいだw
コメント1件

332
ナイコンさん[sage]   投稿日:2016/02/24 00:19:01
>328
>そんな極端なことを言い出したら大抵の汎用プロセッサは外部支援なしの単体ではメモリーアクセスすら出来ない欠陥 CPU と言

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

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

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

333
ナイコンさん[]   投稿日:2016/02/24 01:32:17
>330
むしろ、理由があって標準スタートアップを使いたくない
→標準ランタイムやヒープの初期化が行われない
→標準のmallocが使えない
→標準のprintfが使えない(一時バッファをmallocで確保してたりする)
→自前のmalloc,printfを使わざるをえない
というパターンが多いんじゃね?

334
ナイコンさん[]   投稿日:2016/02/24 01:47:13
>331
EDLINは行テンプレートが使えるから、
ラインエディタとしては(UNIXのEDやCP/MのEDに比べ)操作性良いほうなんじゃね?
正規表現が使えないので機能的には残念だけど…

335
ナイコンさん[]   投稿日:2016/02/24 04:34:16
なんでIO処理をインライン関数なりマクロなりで定義しておくとか、独自ライブラリにまとめておくって言う手抜きをしないのかね?
1回書いてしまえばどんな実装だろうとあとは呼び出すだけだろうに。

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

336
ナイコンさん[]   投稿日:2016/02/24 04:40:44
> なんでIO処理をインライン関数なりマクロなりで定義しておくとか、独自ライブラリにまとめておくって言う手抜きをしないのかね?

誰もそんなこと「しない」なんて言ってませんよ?
コメント1件

337
ナイコンさん[]   投稿日:2016/02/24 04:54:24
>336
文面から『「都度つど書かなきゃいけない=毎回書かないとだめで」面倒』て受け取れたからね。
まさかその「1回かいてしまえば」が面倒と言うならそれはプログラマーとしての適正が疑われるよ。

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

338
ナイコンさん[sage]   投稿日:2016/02/24 06:46:51
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への操作は例えばどんな感じで書いてんの?
コメント15件

339
ナイコンさん[sage]   投稿日:2016/02/24 06:53:51
よく知らないんだけどx86も640KB-1MBにIOがマップされてたんだよね?
コメント2件

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

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

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

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

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

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

342
ナイコンさん[]   投稿日:2016/02/24 08:04:30
>339
メモリ空間のとこでもおける。
IOマップトIOのことと勘違い、かな?

343
ナイコンさん[sage]   投稿日:2016/02/24 12:35:29
>339
x86はアーキテクチャでは無くCPUなのでアーキテクチャによって異なるが、
IBM PCにしろPC-98にしろ、メモリマップドIOはほとんど無いんじゃないか?
IOカード側(ISA,Cバス)のIOカード上に実装されたメモリの一部が
この領域で見えるのは良くあるが。例えばBIOSとか、VRAMとか、共有メモリとか。
コメント2件

344
ナイコンさん[sage]   投稿日:2016/02/24 13:00:18
>343
> IBM PCにしろPC-98にしろ、メモリマップドIOはほとんど無いんじゃないか?
VRAM って歴とした出力デバイスだと思うが…

345
ナイコンさん[]   投稿日:2016/02/24 14:49:14
>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);
だろ。

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

346
ナイコンさん[sage]   投稿日:2016/02/24 15:55:00
>345
ポートやその中のビットの定義が増えてくとドンドン辛くなる書きかただね。
コメント1件

347
ナイコンさん[]   投稿日:2016/02/24 16:07:47
>346
例えば?

348
ナイコンさん[sage]   投稿日:2016/02/24 16:17:00
・どのポートは何ビットでアクセスするのか
・どのポートにどのビットが対応してるか
なんてのがプログラマが任せになってるね。
コメント1件

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

350
ナイコンさん[sage]   投稿日:2016/02/24 16:41:19
馬鹿はこれだから困る

351
ナイコンさん[]   投稿日:2016/02/24 17:29:07
プログラムは判りやすいのが一番。

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

352
ナイコンさん[sage]   投稿日:2016/02/24 17:42:45
JavaもCOBOLも触りたくない。

353
ナイコンさん[]   投稿日:2016/02/24 17:44:57
>338はレジスタの定義とそれを操作する実装とを分離して取りうる組み合わせの間違いを排除しるけど

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

おまえ基準ではそうなのかもね。
コメント1件

354
ナイコンさん[sage]   投稿日:2016/02/24 17:59:42
>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だから実務経験を疑われないように。
コメント5件

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

356
ナイコンさん[]   投稿日:2016/02/24 18:15:42
>354
> register_t構造体内のdataはおそらくstructでなくunionだとは思うが(スルーする>345優しいなぁ)

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

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

浅い実務経験しかないんだなあという印象
コメント1件

358
ナイコンさん[]   投稿日:2016/02/24 18:19:41
> #define register (*(volatile register_t*)0x12345678) はちょっと。

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

359
ナイコンさん[]   投稿日:2016/02/24 18:35:01
>353
>338はレジスタの定義とそれを操作する実装とを分離して取りうる組み合わせの間違いを排除しるけど
register.status.busy = 0
とかを、全然排除できてなくない?
コメント1件

360
ナイコンさん[]   投稿日:2016/02/24 18:44:40
>359
それは禁止されてる操作なの??

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

362
ナイコンさん[sage]   投稿日:2016/02/24 20:21:42
>354
> まあこのコードが6809で語られているならば何も言う必要はないが

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

363
ナイコンさん[sage]   投稿日:2016/02/24 23:14:57
>361
>8086で0x00,0x02,0x04にデバイスのレジスタがマッピングされてる、なんて例があったな。
680x0(60を除く)なんてそのためmovepなんて変態的な命令もあったんだが。

364
ナイコンさん[sage]   投稿日:2016/02/25 01:12:30
>356
8BitDataでかつ構造体内にrecv,sendとあれば
普通真っ先に連想するものがUARTかACIAというところ。
まあstatusのビットが一致してるのかは知らないけど。
電子化した雑誌資料を調べるのも面倒なんで。
コメント1件

365
ナイコンさん[sage]   投稿日:2016/02/25 03:22:11
>364
余計なツッコミを食らう前にUARTはUSART(8251)に訂正しておこう。
まあ本命はACIAの方だと思っているが。

366
ナイコンさん[sage]   投稿日:2016/02/25 12:58:22
別に UART (16550A) でいいと思うぞ
ってか DOS/V 機ならむしろこっちの方が普通だったと思うし
ただ 16550A を含めてこの手のデバイスで送受信レジスタのアドレスが別の奴は見たことない
世の中には俺の知らないデバイスもあるとは思うけど…
コメント1件

367
ナイコンさん[]   投稿日:2016/02/25 16:26:47
配置されてるアドレス見りゃ実際のものでないことはすぐに理解できると思うんだが
レジスタの定義を実在の何かと思い込みたい奴はアスペかなんかかな

368
ナイコンさん[]   投稿日:2016/02/25 17:43:55
UARTは書き込みでコマンド、読み出しでステータス。
書き込みで送信、読み出しで受信。
レジスタ減らせばそれだけになるからねー。
コメント1件

369
ナイコンさん[]   投稿日:2016/02/25 17:50:38
UARTかどうかすらも言及されていないものをそれと決め付けるのは
頭の固い年寄りであることの証左

370
ナイコンさん[]   投稿日:2016/02/25 18:43:57
CPUから見て、SIOでもPIOでないIOデバイスがどれぐらいあるのかなぁ。

371
ナイコンさん[]   投稿日:2016/02/25 18:58:02
> SIOでもPIOでないIOデバイス

また変な決め付けワロタw病院逝けw
コメント1件

372
ナイコンさん[sage]   投稿日:2016/02/25 19:46:00
「例え」という概念が理解できない人なんだろうなあ。
コメント1件

373
ナイコンさん[]   投稿日:2016/02/25 19:47:31
>371
ふーん?
決め付けというなら、本当の所をちゃんと説明できるんだよね?
説明してみ。
笑ってやるから。

374
ナイコンさん[sage]   投稿日:2016/02/25 19:51:11
> 説明してみ。
> 笑ってやるから。

自分が笑われてること理解してないのかな??
コメント1件

375
ナイコンさん[sage]   投稿日:2016/02/25 20:02:18
>372
トンチンカンな揚げ足取りを笑われて「実在のデバイスである説」を
引っ込められなくなった様にも見える

376
ナイコンさん[]   投稿日:2016/02/25 20:09:34
>374

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

377
ナイコンさん[]   投稿日:2016/02/25 20:14:25
健全でない言葉が含まれているため表示しません 内容を確認する
コメント1件

378
ナイコンさん[]   投稿日:2016/02/25 20:15:49
> 決め付けというなら、本当の所をちゃんと説明できるんだよね?

「本当の所」があるという決め付けw 馬鹿の考えは想像の上だわww
コメント1件

379
ナイコンさん[]   投稿日:2016/02/25 20:24:25
健全でない言葉が含まれているため表示しません 内容を確認する

380
ナイコンさん[sage]   投稿日:2016/02/25 20:27:23
50過ぎのジジイだと思うけどおっそろしく頭の固い奴だなあワロタw

381
ナイコンさん[sage]   投稿日:2016/02/25 22:48:24
>366
パラレルを使えば入出力を別々にする場合も可能だったりする。
例えばPPI(8255)でPortA,Bを共にモード1に設定してPortAを入力recv,
PortBを出力sendにするとPortCがStatusになるので>338の例の形に
することは出来る。
もっともStatusのBit配列は全く異なるから>338がこれを想定していたとは
考えられないけどね。

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

382
ナイコンさん[]   投稿日:2016/02/26 03:14:25
健全でない言葉が含まれているため表示しません 内容を確認する

383
ナイコンさん[]   投稿日:2016/02/26 03:19:05
>381
架空のデバイスでかまわないじゃないか。
もともと「こんな感じでコーディングするんじゃないの?」っていうためのモノなんだから。
そこに書かれたソースからどんな動作するデバイスなのか理解できないような馬鹿はここにいないでしょ。
コメント1件

384
ナイコンさん[sage]   投稿日:2016/02/26 03:52:55
>決めつけと言い切ってる根拠を教えてくれよぉ、馬鹿にもわかるようにさぁwwww

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

385
ナイコンさん[sage]   投稿日:2016/02/26 04:43:34
違和感を感じた時に気が付くべきだったんだがつい構造体dataの方に目を奪われていた。

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

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

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

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

386
ナイコンさん[]   投稿日:2016/02/26 05:07:28
>385
もともと「こんな風にコーディングするんじゃね?」のサンプルだろ。
そんなのにいつまでも噛み付く玄人さんカッコイイなぁ、いや実に素晴らしいわ。
素晴らしいぐらいに馬鹿だわ。

387
ナイコンさん[]   投稿日:2016/02/26 05:08:00
健全でない言葉が含まれているため表示しません 内容を確認する

388
ナイコンさん[sage]   投稿日:2016/02/26 08:41:28
>385
> >338のコードってもろに処理系依存のビットフィールドを使ってるよな。
> 68kはビットのナンバリングがLSB=0だけどビットフィールドエンディアンはMSBからだったよな。
> (x86系は言うまでも無くLSBから)
処理系依存の意味も理解してない知ったか乙 w

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

389
ナイコンさん[]   投稿日:2016/02/26 11:26:04
>383
>架空のデバイスでかまわないじゃないか。
架空のデバイスだからこそ一般性とか汎用性とかを求められる、
自分の主張を説明するのに都合が良いだけの、特殊な架空デバイスを持ち出しても意味が無いからね。

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

390
ナイコンさん[]   投稿日:2016/02/26 11:58:14
>388
>ステータスレジスタとコントロールレジスタが同一アドレスのデバイス
そこはunionを使えばまだなんとかなるかもと思うけどデバイスが多機能な
グラフィックコントローラーみたいなものだととんでもないことになるね。

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

391
ナイコンさん[]   投稿日:2016/02/26 12:16:53
>390
>同一アドレスのデバイスでコントロールレジスタの特定ビットを操作したい
がメインの部分なのに、
>ステータスレジスタとコントロールレジスタが同一アドレスのデバイス
で区切っちゃダメだろw

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

393
ナイコンさん[]   投稿日:2016/02/26 13:07:48
>392
×ocw1,ocw2,…
○icw1,icw2,…
連続で設定しなければいけないのは初期化のicwの方だった。

394
ナイコンさん[]   投稿日:2016/02/26 14:26:26
健全でない言葉が含まれているため表示しません 内容を確認する

395
ナイコンさん[]   投稿日:2016/02/26 16:49:13
コマンドとステータスが同じアドレスな割込コントローラがががが

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

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

397
ナイコンさん[sage]   投稿日:2016/02/27 06:41:01
>396
自ら処理系依存と書きながら
> 68kは(…中略…)ビットフィールドエンディアンはMSBからだったよな。
って決めつけてるところがバカって言われてるんだろ

398
ナイコンさん[]   投稿日:2016/02/27 07:40:41
エンディアン違うプロセッサーでソース使いまわすならビットフィールドはNGだね。
バグの温床だ。

399
ナイコンさん[sage]   投稿日:2016/02/27 08:28:56
ビットフィールドのビットの並び方は‥
× プロセッサによって異なる
〇 処理系(もっと言うとコンパイラー)によって異なる
コメント1件

400
ナイコンさん[]   投稿日:2016/02/27 08:47:19
>399
ほへ、初耳だ。
それは知らなかった、というか気づかなかった。

401
ナイコンさん[]   投稿日:2016/02/27 13:17:26
68kのコンパイラでビットフィールドがリトルエンディアンな
コンパイラは実際にあるの?
あるのならそれはそれで恐ろしいと思うけど。
コメント1件

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

なんで??

403
ナイコンさん[sage]   投稿日:2016/02/27 14:07:38
>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-Nio...
コメント3件

404
ナイコンさん[]   投稿日:2016/02/27 14:20:22
「68kのコンパイラで〜実際にあるの?」という問いにAlteraなんとかを例示する意味が分からん


405
ナイコンさん[]   投稿日:2016/02/27 14:36:08
しかもNextで表示される68kのgccオプションの中には
-mreverse-bitfieldsオプションはないんだよな。
68kでの例を示して欲しいな。

406
ナイコンさん[]   投稿日:2016/02/27 15:36:47
short a1:1;
で宣言したのって sizeof(a1) で返る値ってsizeof(char)と同じ? それともsizeof(short)と同じ?
決まってないとか、sizeof(short)と同じならバイトサイズのI/Oデバイスのレジスタ読書きに使うのはNGなんじゃ・・・

407
ナイコンさん[sage]   投稿日:2016/02/27 16:20:29
馬鹿がなんか言ってて笑えるw

408
ナイコンさん[]   投稿日:2016/02/27 18:57:10
"gcc reverse bitfields"でぐぐってみたらパッチをあてて
ビットフィールドを反転させるという事例があるみたいだね。
最初にヒットするのを見ると投稿者からx86で行われていると思われる。

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

409
ナイコンさん[]   投稿日:2016/02/27 19:06:19
>最初にヒットするのを見ると投稿者からx86で行われていると思われる。

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

410
ナイコンさん[]   投稿日:2016/02/27 19:08:55
x86は当分終わりそうに無いが、68000の「失敗」もしくは「終了」って何が原因かねぇ。
コメント1件

411
ナイコンさん[]   投稿日:2016/02/27 19:31:15
>409
投稿者名からx86と決め打ちしていたけど本人のHPに行ったらRX-62Nボード
のページがあるからそっちの方のことか。
RX-62Nのgccは#pragma bit_orderが対応していないと言う国内の記事も
あるからそれに対応したんだろうな。

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

412
ナイコンさん[sage]   投稿日:2016/02/27 20:22:51
>410
当時独占していたワークステーション市場をSPARC,MIPSなどのRISC勢に
奪われたのが凋落の始まり。
いわゆるRISC vs CISC論争の波に飲み込まれてしまった。

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

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

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

413
ナイコンさん[]   投稿日:2016/02/27 23:12:08
>412
開発リソース分けちゃったのかー・・・そりゃ無理だわ。
コメント2件

414
ナイコンさん[sage]   投稿日:2016/02/27 23:26:09
PowerPCがうまいこといったんで68kは組み込み用途に舵切って高性能路線はやめただけ。

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

416
ナイコンさん[sage]   投稿日:2016/02/28 04:56:39
そりゃ半導体専業のIntelと通信機器が本業で所詮半導体は一部門でしかなかった
Motoloraじゃ力の入れようが違うだろう。
後にMotoloraが半導体事業を切り離すことになったのも本業の通信から
立案されて進められたイリジウムが大失敗した穴埋めだからね。

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

418
ナイコンさん[]   投稿日:2016/02/28 17:01:08
>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-Opti...#IA-64%20Options
http://www.johnloomis.org/altera/nios2/gnutools/binutils/gcc/RS-6000-an...#RS%2f6000%20and%20PowerPC%20Options

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

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

419
ナイコンさん[sage]   投稿日:2016/02/28 17:32:21
コンパイラが実在しないからと言って規格が変わるわけじゃないんだが
何を言いたいのかさっぱりわからん
コメント1件

420
ナイコンさん[sage]   投稿日:2016/02/28 17:37:35
Cのビットフィールドの順序は処理系依存なんでしょ?
つまりどうでもいいこと。

421
ナイコンさん[sage]   投稿日:2016/02/28 18:04:44
ビットフィールドとバイトエンディアンを微妙に混同してる人がおかしな妄想してるだけ
コメント1件

422
ナイコンさん[]   投稿日:2016/02/28 18:08:02
>421
意味がわからんが・・・?
いったい何が混同するんだい。
struct {
unsigned busy:1;
}register;
で register.busy=1 が0x8000になるか0x0001になるかが処理系依存だからよろしくないってだけだろ。
コメント1件

423
ナイコンさん[sage]   投稿日:2016/02/28 18:18:08
intだって16bitだったり、32bitだったり処理系依存だからよくない!! っことか。そういう人もいるかもね。
おれは処理系依存が多いから逆にCは普及したと思ってる。

424
ナイコンさん[sage]   投稿日:2016/02/28 18:18:15
>422
>418 に言えよ
コメント1件

425
ナイコンさん[]   投稿日:2016/02/28 18:19:28
> 処理系依存だからよろしくない

まず 処理系依存==悪 という考えが間違い。
コメント2件

426
ナイコンさん[]   投稿日:2016/02/28 18:28:53
>424
なら
> ビットフィールドとバイトエンディアンを微妙に混同してる人がおかしな妄想してるだけ
の「おかしな妄想」って言ってるところ教えてくれよ。
俺なりに「おかしな妄想」てのに突っ込んだだけなんだから。
言葉足らずで噛み付くだとかガキかよ。
コメント1件

427
ナイコンさん[]   投稿日:2016/02/28 18:30:51
バイトエンディアンwww
コメント1件

428
ナイコンさん[]   投稿日:2016/02/28 18:32:33
>425
「処理系依存」はいうなれば必要悪。
でもすべてが「必要」じゃない。
ビットフィールは「不必要悪」。

429
ナイコンさん[]   投稿日:2016/02/28 18:33:39
ビットフィールwww

430
ナイコンさん[]   投稿日:2016/02/28 18:34:35
便利な機能を不必要と断ずるのが間違い。

431
ナイコンさん[sage]   投稿日:2016/02/28 18:34:45
68k使いはケチくさいなぁ。x86なんてboolean用途で16bitや32bit使うなんて普通だぞw

432
ナイコンさん[]   投稿日:2016/02/28 18:39:12
> 68k使いはケチくさいなぁ。x86なんてboolean用途で16bitや32bit使うなんて普通だぞw

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

433
ナイコンさん[sage]   投稿日:2016/02/28 18:50:51
>426
>> ましてはビッグエンディアンの68kがサポートする必然性は無いよね。

434
ナイコンさん[sage]   投稿日:2016/02/28 18:52:32
>418が言うように68kでリトルエンディアンビットフィールドの
処理系の実例を出せばそれでお終いなのになに下らんことやってんだ?
百の論より一つの証拠だろ。
コメント1件

435
ナイコンさん[sage]   投稿日:2016/02/28 18:52:37
>427
話についていけないの?
コメント1件

436
ナイコンさん[sage]   投稿日:2016/02/28 18:53:59
正直何を揉めてるかさっぱり分らない。

437
ナイコンさん[sage]   投稿日:2016/02/28 18:58:39

438
ナイコンさん[sage]   投稿日:2016/02/28 18:58:49
IDがないので誰と誰が揉めてるかも分らない。

439
ナイコンさん[]   投稿日:2016/02/28 18:59:53
>418
CPUと処理系は関係ない、
必用があればx86向けのビッグエンディアン
(int a=0x1234で、*((char*)&a) == 0x12がtrue)なコンパイラを作ることも可能。

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

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

440
ナイコンさん[sage]   投稿日:2016/02/28 19:09:02
>435
バイトオーダーとバイエンディアンを混同してる馬鹿を嗤ってるだけw
コメント3件

441
ナイコンさん[]   投稿日:2016/02/28 19:09:40
>>403が実在することを匂わせてしまっているからね。
まあ処理系を設計者が勝手気まま設計することは可能だろうけど
合理的思考で設計すればMPU/CPUによって取りうる選択肢は制限されることになるだろう。

442
ナイコンさん[]   投稿日:2016/02/28 19:17:29
ドトール傘下のエクセルシオールカフェ赤羽東口店では店員が自分の事、好きだと言い始めたので
優しくしたら他の店員のやっかみ、最低の接客だ

443
ナイコンさん[]   投稿日:2016/02/28 19:18:01
バイトエンディアン?
なんか新しい単語だな。
バイエンディアンという用語を理解してないのか?

444
ナイコンさん[sage]   投稿日:2016/02/28 19:22:47
bi-endianかよ。カタカナは紛らわしいな。
コメント2件

445
ナイコンさん[]   投稿日:2016/02/28 19:51:21
>440
それなら「どう混同してて何がおかしいのか」ちゃんと指摘すればいいのに。
ただ笑ってるだけなんて、笑ってるお前のほうが馬鹿に見えるぜ。
コメント2件

446
ナイコンさん[]   投稿日:2016/02/28 19:57:40
実際、実務でビットフィールド使うことなんてほとんど無いんじゃね?とは思う。
使ってるのを見たこと・・・なくはないけどごく小数。
コメント4件

447
ナイコンさん[sage]   投稿日:2016/02/28 19:57:44
それなら君が教えればいいじゃないw
分からないのww
コメント1件

448
ナイコンさん[]   投稿日:2016/02/28 20:01:18
健全でない言葉が含まれているため表示しません 内容を確認する

449
ナイコンさん[]   投稿日:2016/02/28 20:09:16
健全でない言葉が含まれているため表示しません 内容を確認する

450
ナイコンさん[]   投稿日:2016/02/28 20:17:16
>439
そりゃ規格で「プロセッサのエンディアンと合致していること」なんてうたってないだろうけど、まっとうな感覚してればプロセッサに合わせるだろ。

451
ナイコンさん[]   投稿日:2016/02/28 20:33:27
x86用のプログラム書いてるつもりで
union {
 char a;
 short b;
 long c;
}v;
で v.c=0x01234567; てしたとき v.a!=0x1; でv.b!=0x0123; な事になるのか。
そりゃ普通ないだろ。つかこんな動きしたら「コンパイラのバグ」だろ。
コメント1件

452
ナイコンさん[sage]   投稿日:2016/02/28 20:43:02
いまごろ一生懸命検索しているのかと思うと涙出てくるよねw

453
ナイコンさん[sage]   投稿日:2016/02/28 20:49:16
unionの定義はオフセットが0だから。

454
ナイコンさん[sage]   投稿日:2016/02/28 21:23:44
規格の話と実際の話を分けて考えられない男の人って...

455
ナイコンさん[sage]   投稿日:2016/02/28 21:42:23
レジスタそのままmovでメモリに突っ込むから、わざわざ途転させる馬鹿はいない。
一体何をモメているんだ。

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

457
ナイコンさん[]   投稿日:2016/02/28 23:27:58
>445
wをとばしている>440はおそらく>444で自分の馬鹿さを
認識してるだろうから恥ずかしくてもう出てこれないだろうよ。
コメント1件

458
ナイコンさん[]   投稿日:2016/02/28 23:37:19
>451
ビッグエンディアンの処理系では極自然なことですので理解してあげましょう。

459
ナイコンさん[sage]   投稿日:2016/02/29 00:37:38
>446
組み込みマイコンか、デバイスドライバー屋さん位だな。
コメント1件

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

461
ナイコンさん[sage]   投稿日:2016/02/29 02:08:09
実際ほとんどの実装は、#defineして | するのが一般的。

462
ナイコンさん[]   投稿日:2016/02/29 02:51:31
>457
> wをとばしている>440はおそらく>444で自分の馬鹿さを
> 認識してるだろうから

マジ意味わからん

463
ナイコンさん[sage]   投稿日:2016/02/29 05:46:59
>456
周回遅れすぎるww

464
ナイコンさん[]   投稿日:2016/02/29 07:28:04
68k妄信してる奴がキモい。
コメント2件

465
ナイコンさん[]   投稿日:2016/02/29 07:45:33
68kの良いところ。
レジスタがでかい。
セグメントリミットがない。
だけか?
コメント1件

466
ナイコンさん[sage]   投稿日:2016/02/29 08:33:12
>465
直交性

467
ナイコンさん[sage]   投稿日:2016/02/29 10:03:32

468
ナイコンさん[]   投稿日:2016/02/29 12:06:45
健全でない言葉が含まれているため表示しません 内容を確認する

469
ナイコンさん[]   投稿日:2016/02/29 12:16:09
健全でない言葉が含まれているため表示しません 内容を確認する
コメント2件

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

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

471
ナイコンさん[]   投稿日:2016/02/29 12:48:39
>469
「68k派」なんてのがこのスレにいると思ってるのはお前だけ。

472
ナイコンさん[sage]   投稿日:2016/02/29 12:50:23

473
ナイコンさん[sage]   投稿日:2016/02/29 17:12:30
>472
> すなわちvalid,busyはビットフィールドを使うより古典的に
>
> #define VALID 0x??
> #define BUSY 0x??
>
> と定義して使うか
これだけを主張しているなら処理系依存=悪で排除しろ
という偏狭な考えに囚われていると言えるけど

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

474
ナイコンさん[]   投稿日:2016/02/29 17:24:49
依存性バリバリの使い回しできないソースなんざ墓の中に持ってくぐらいの役にしかたたないしなー。

475
ナイコンさん[sage]   投稿日:2016/02/29 17:41:43
68k依存のソースってもうこの世に消えたんじゃないかと思うぐらいだもんな。
それに比べて依存性バリバリのDOSのソースは未だに最新PCで動くもんなぁ。

476
ナイコンさん[]   投稿日:2016/02/29 17:54:53
> と定義して使うかもしくは#ifdefでエンディアン毎にビットフィールドを
> 定義しないと処理系依存コードになってしまうよな。
> 実務経験を疑う以前にド素人というレベルのコードだったわ。

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

477
ナイコンさん[sage]   投稿日:2016/02/29 17:59:34
健全でない言葉が含まれているため表示しません 内容を確認する

478
ナイコンさん[]   投稿日:2016/02/29 18:01:26
全員集合スレから逃げてきたのか、通りで。

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

480
ナイコンさん[]   投稿日:2016/02/29 18:07:18
低可読性のソースだから奴素人てんじゃないの?
可読性落としてる原因が処理系依存なとこだっただけで。

481
ナイコンさん[sage]   投稿日:2016/02/29 18:10:49
処理系依存しないコードは理想だけど普通に無理。
その理想を目指したJavaですら、Write once, debug everywhere. と言われるぐらいVM間の実装差を吸収できない。
コメント1件

482
ナイコンさん[sage]   投稿日:2016/02/29 18:13:07
処理系を統一すればいいだけ
コメント1件

483
ナイコンさん[]   投稿日:2016/02/29 18:16:46
>481
普通に無理だからって、わざわざ依存するソースかくのはどうかと思うよ。

484
ナイコンさん[sage]   投稿日:2016/02/29 18:19:53
おまえはx86なのにビッグエンディアンでも同じように動くコード書くのか?
qsort()すら使えないじゃないか。

485
ナイコンさん[sage]   投稿日:2016/02/29 18:27:08
>482
現実に出来ない妄想を書いてもなぁ。
病院行って薬貰ってこい。

486
ナイコンさん[]   投稿日:2016/02/29 18:54:12
現実はアーキテクチャが統一、とまではまだだが、淘汰と住みわけが進んでるからなー。
ますますビックエンディアンは先細りだよな。
しばらくは無くならんたろうが。
コメント1件

487
ナイコンさん[]   投稿日:2016/02/29 19:13:14
クロス開発なんかしてると当たり間のように依存性排除に進むよな。
PC上でデバッグしてクロスコンパイルして実機に・・・なんてやってると。

488
ナイコンさん[sage]   投稿日:2016/02/29 19:23:54
エミュレータ上でデバッグするものじゃないの?
コメント1件

489
ナイコンさん[]   投稿日:2016/02/29 19:49:27
>488
Androidみたいに至れり尽くせりなクロス開発ばっかじゃないの、世の中は。

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

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

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

491
ナイコンさん[]   投稿日:2016/02/29 20:00:15
> これは「C言語のソースレベル」のデバッグで、ぶっちゃければ動いてるのはWindowsやLinuxのアプリだから、当然それようのコンパイラでコンパイルするわけね。

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

492
ナイコンさん[sage]   投稿日:2016/02/29 20:15:02
最近は
・単体テストは Windows や Linux
・機能確認はエミュレータ
・システムテストは実機
って言うのが多い
もちろん完全にきれいに別れてる訳じゃないけど

493
ナイコンさん[]   投稿日:2016/02/29 20:31:38
>491
あるよ。
ハードごと新規開発な案件を年に1件ぐらい受けるんだけどお客さんにカネないからこっちも色々切り詰めないとアシがでるんで苦肉の策に近い。

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

494
ナイコンさん[sage]   投稿日:2016/02/29 20:35:16
ここの人は無職かと思ってたよ。

495
ナイコンさん[sage]   投稿日:2016/02/29 20:35:54
無職だよ
想像で語ってんの

496
ナイコンさん[sage]   投稿日:2016/02/29 20:44:48
昼間に書き込んでるのは無職の可能性が高いだろうね。

497
ナイコンさん[]   投稿日:2016/03/01 05:27:01
494、495の自演はなんなん?

498
ナイコンさん[アゲアゲ姫]   投稿日:2016/03/01 12:05:16
なんなんなんなんなんなんなんなんwwwwwww
どこの奴だw

499
ナイコンさん[]   投稿日:2016/03/01 19:08:23
健全でない言葉が含まれているため表示しません 内容を確認する

500
ナイコンさん[sage]   投稿日:2016/03/01 19:49:56
脳内でそういう輩を設定しないとプライドが保てない人かな
コメント1件

501
ナイコンさん[]   投稿日:2016/03/01 21:14:27
現役のx86が過去の遺物と化した68kに対してそんなことをする必要はないよ。
おそらく記憶の中で過度の美化が進行して妄想というレベルにまで達しているんだろう。

502
ナイコンさん[sage]   投稿日:2016/03/02 04:51:55
1980年代は68kは垂涎のCPUであったよ。
でもそれは比較対象が8086,286であったことと、
当時情報は満ち溢れていたものの一般Userが触れることの
出来なかったUNIXが使えることだったから386が登場して
PC−UNIXが使えるようになった時には68kに対する
羨望というものは失われていたな。

503
ナイコンさん[]   投稿日:2016/03/02 06:29:06
最初に「良いもの」つくって驕って改良しなかった(できなかった?)のがね。
「継続は力なり」のインテルとは対照的だよね。
386の2年後にでた030が性能で劣るあたりが既にね・・・
コメント1件

504
ナイコンさん[]   投稿日:2016/03/02 06:58:37
>500
んにゃ。
単なる事実。

505
ナイコンさん[]   投稿日:2016/03/02 07:29:01
俺が68000の嫌いな所。
ビックエンディアン。
奇数番地からのワードアクセスでバスアライメント例外起こす。
割込みン時に参照するアドレスがROM(電源オンしたばかりの時)
意味不明なユーザーモード。

あとウザイ信者。

506
ナイコンさん[sage]   投稿日:2016/03/02 09:17:32
>503
でも386ってプログラムキャッシュもデータキャッシュも内蔵してなかったよね?
コメント1件

507
ナイコンさん[]   投稿日:2016/03/02 10:13:41
コア性能稼げないからボトルネックのメモリアクセス速くしよう、と言うのは当時としては妥当だね。
2年あとでコア性能負けてるか。
68020がパイオニアとしてのモトローラの限界かね?

508
ナイコンさん[sage]   投稿日:2016/03/02 11:57:39
当時はマルチタスクのUNIXすげーなと思ってたが実際触ると結構不安定だし
使いにくいし遅いしで大したことなかった。まだ軽いDOSのほうがはるかに実用的だった。
NT使うようになってからはUNIXはゴミと化した。NTとUNIXの差がx86と68kの差になったね。

509
ナイコンさん[]   投稿日:2016/03/02 15:13:10
UNIXならスパークステーションだな!
個人の好みと趣味で。

あのピザボックスが。

510
ナイコンさん[sage]   投稿日:2016/03/02 17:21:05
なんでcにはnearとかfarとかあったんだ? 隠蔽してくれりゃいいのに。
コメント1件

511
ナイコンさん[]   投稿日:2016/03/02 17:28:55
nearだfarだの、わざわざ付けてたの!?

512
ナイコンさん[]   投稿日:2016/03/02 17:33:47
>510
コンパイル時にメモリモデルを指定して、そのまま使うだけなら特に付ける必要はなかった。

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

513
ナイコンさん[]   投稿日:2016/03/02 17:45:14
>512
別なメモリモデル用のライブラリとリンクなんてトリッキーだな。
far char*で宣言すれば初期化のときぐらいだろ、セグメント意識するのは。
コメント1件

514
ナイコンさん[sage]   投稿日:2016/03/02 18:39:04
16bit時代のx86は
smallモデルでCS=DS=SSにしないとまともにC言語プログラムが組めなかった気がするが
メモリーモデルをHugeだかLargeだかにしてビルドすればそんな事無く near far も不要で普通に使えたんだっけ?
コメント1件

515
ナイコンさん[]   投稿日:2016/03/02 18:44:32
>513
トリッキー…
別のメモリモデルという言い方が悪く、
全メモリモデル用と言った方が良いのかも、普通に
extern char far * far func(char far * s);
のように明示的に指定されてるライブラリのことで、

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

516
ナイコンさん[]   投稿日:2016/03/02 19:12:23
>506
x86にキャッシュが載るのはIntel純正CPUは486からだな。
(互換CPUなら386から載せたものもある)

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

517
ナイコンさん[sage]   投稿日:2016/03/02 19:15:07
386のPCの広告にはよくノーウェイトメモリアクセスってあったよ。キャッシュなんかいらなかったのさ。
コメント2件

518
ナイコンさん[]   投稿日:2016/03/02 19:35:19
メモリモデルがどうであれ、x86のスタックセグメントは64kだったんだよな。
ヒープばんじゃい!

519
ナイコンさん[]   投稿日:2016/03/02 19:40:03
386 33MHz+外付けキャッシュ64KBの機種は結構あった、
98系だとH98 model70がそうだった。

520
ナイコンさん[sage]   投稿日:2016/03/02 19:42:40
>517
でも初期のタウンズはたっぷりウェイト入ってたな

521
ナイコンさん[]   投稿日:2016/03/02 19:43:33
>514
CS=DS=SSはTinyモデル(.EXEじゃなく.COMのモデル)。
基本的に全てDS=SSで、DS!=SSなのはWindowsのDLLとかの特殊なケース。

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

522
ナイコンさん[]   投稿日:2016/03/02 19:45:41
>515
そりゃぁfar*で戻してくるなら受け側もfar*にしとかないとダメじゃん。
longやint、shortで戻してくるのをcharで受けるのと同じなんだし。

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

523
ナイコンさん[]   投稿日:2016/03/02 19:52:46
>521
DSで扱うデータが64k超えてるメモリモデル全般でDS!=SSじゃなかったっけ?
初期値はDS=SSだったんだっけ・・・?
コメント1件

524
ナイコンさん[sage]   投稿日:2016/03/02 20:25:02
いかにセグメントがPGを混乱させるかが分るな。

525
ナイコンさん[]   投稿日:2016/03/02 20:42:28
>523
>DSで扱うデータが64k超えてるメモリモデル全般でDS!=SSじゃなかったっけ?
違うよ。
コメント1件

526
ナイコンさん[]   投稿日:2016/03/02 20:54:32
>517
ノーウェイトといっても実際にはFastPageModeでRASが同一でCASだけを
変更できる場合に限られていたような。
RASが変わるならウェイトが入ってしまうので
RASも含めての完全なノーウェイトって当時あったっけ?

527
ナイコンさん[]   投稿日:2016/03/03 06:18:52
メモリモデルのラージ、ヒュージはDS!=CSだね。

528
ナイコンさん[sage]   投稿日:2016/03/03 06:41:03
>525
DS==SSが成り立つのはMS-Cのデフォルトの場合でTurbo-CだとDS!=SSだったりする。
またMS-Cもオプションで変更することは可能。
つまり処理系依存。

529
ナイコンさん[sage]   投稿日:2016/03/03 10:23:45

530
ナイコンさん[]   投稿日:2016/03/03 12:30:21
>529
ぐっじょぶ!
ミディアムとコンパクトを逆に覚えてた。

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

531
ナイコンさん[sage]   投稿日:2016/03/03 17:58:48
ぼくにはまだセグメントは早すぎるかもしれない。

532
ナイコンさん[sage]   投稿日:2016/03/03 18:51:12
80286のアセンブリ言語に挫折した僕でも68000なら3日で覚えられました

533
ナイコンさん[]   投稿日:2016/03/03 19:17:55
286で挫折ってことは、プロテクトモードがらみ?
だとすると・・・ ナムー、成仏しろよ

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

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

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

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

535
ナイコンさん[]   投稿日:2016/03/04 08:09:53
そう言えば、68kしかアセンブラ知らない奴がWindowsの仮想メモリ理解できなくて逆ギレしてたなー。

536
ナイコンさん[sage]   投稿日:2016/03/04 19:06:34
68kをSHARP X68kで使っていたのならありえる話かもな。
MacはたしかSystem7でサポートしていたはずだから。

537
ナイコンさん[]   投稿日:2016/03/04 19:16:47
プロテクトモードを直にさわるなんて勉強でしかやったことないなぁ。
途中で投げ出したし。
そのかわりVCPIの使い方を覚えた。
コメント1件

538
ナイコンさん[]   投稿日:2016/03/04 20:12:46
NetBSD/x68k…

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

539
ナイコンさん[sage]   投稿日:2016/03/04 20:20:33
X68kに載っていたCPUで仮想メモリ(スワップファイル)実現できるの?
68000は当然無理だし68030もMMU無しのECだったと思うんだが。

540
ナイコンさん[sage]   投稿日:2016/03/04 20:28:47
NetBSDは要MPU乗せ替え

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

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

542
ナイコンさん[]   投稿日:2016/03/05 08:30:04
System7だと90年だっけ? 91年だっけ? 
ぐぐったらコンパック386+Windows/386が86年、規格のEMS 4.0が87年、EMM386.SYSが89年。
仮想メモリまわりに関しちゃ、IBM-PC系が先行してんのね・・・
リアルモードのままじゃメモリ狭くてやってらんないから当然といえば当然だけど。

543
ナイコンさん[]   投稿日:2016/03/05 13:06:14
シャープのアレって「ワークステーションもどき」だったんだな・・・

544
ナイコンさん[sage]   投稿日:2016/03/05 13:52:12
ミニコン・ワークステーションに採用されているCPUと同じものを搭載したPCという感じだったかな
ワークステーションは68020になってたしメガドライブがすぐ後に出たりして68000自体はすぐにリーズナブルになった感じだけど

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

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

545
ナイコンさん[sage]   投稿日:2016/03/05 15:11:36
シェアみるとNTサーバが一気に普及して、PC-UNIXが既存UNIXの代替になっていったかんじ。

546
ナイコンさん[sage]   投稿日:2016/03/05 20:43:23
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
ナイコンさん[]   投稿日:2016/03/05 21:50:14
x86が多機能高性能化でトータルなコストが高くなってる、という背景もあってだろう、組込みやポータブルデバイスだとARMの伸びがすごいね。
Androidのお陰もあるだろうけど。

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

548
ナイコンさん[sage]   投稿日:2016/03/05 22:06:25
ARM64が出てきてようやくx86に敵うようになったからなインテル強すぎ
あれは金にいわせて天才の群れで手作業で最適化してるんだろうか

549
ナイコンさん[]   投稿日:2016/03/05 22:15:08
ARMの面白いところは条件コードだったんだけどな・・・

550
ナイコンさん[]   投稿日:2016/03/05 22:49:05
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に触れた
> 人は皆「変態命令セット」って言ってるし(笑)。
コメント1件

551
ナイコンさん[sage]   投稿日:2016/03/05 22:56:22
> 何がひどいか? RISCなのに汎用レジスタが16本しかない、

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

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

552
ナイコンさん[sage]   投稿日:2016/03/05 23:03:47
AMDもARMも微細化、高速化できるのは、
すべてはインテルのセミコン業界への莫大な再投資によるおこぼれだということを忘れてはいけない。

553
ナイコンさん[]   投稿日:2016/03/06 00:14:24
恩着せがましい自社の利益のための投資だろ覚えとく必要性も特に感じない

554
ナイコンさん[sage]   投稿日:2016/03/06 00:22:23
自社の利益のために再投資しなかった68kだけは忘れないで・・・
コメント1件

555
ナイコンさん[]   投稿日:2016/03/06 00:35:19
x86では条件コードはCMOV命令で十分と判断しちゃったからな。
もっともPentium4時代は実行速度は遅くメリットが得られたのはCore以降かな。

556
ナイコンさん[]   投稿日:2016/03/06 01:06:45
>554
自社の利益のためと言うより負債で資産を切り売りしなければいけない状況だったんだが。

557
ナイコンさん[]   投稿日:2016/03/06 09:24:35
確かにARMのレジスタが15本だからコンパイラが効率が言いコードが吐けないとか言い切るのは無知、無勉強の証拠だわね。
レジスタの数が多いのが正義ならレジスタの数が半減するThumbモードは世間から拒否されたのにねー。

558
ナイコンさん[]   投稿日:2016/03/06 11:12:28
x86もレジスタ少ないからだめだったなAMD64ですごく速くなった
普通に68kが進歩してれば結構な性能差をつけて勝てたのではと思う
コメント1件

559
ナイコンさん[]   投稿日:2016/03/06 11:21:25
このスレッド内だとレジスタ数が多いのが正義という考えに無条件に同意する人は結構いると思うよな

560
ナイコンさん[sage]   投稿日:2016/03/06 11:44:05
何個くらいあればまあ十分という線はあるしあればあるほど良いという馬鹿もそうはいないんじゃない。
68kについてはアドレスレジスタがスタックポインタを含めて8個というのは持て余し気味だったし
データレジスタが8個ではもうちょっと欲しいという感じだったな。
アドレスレジスタとデータレジスタを別にするデザインはあんま筋の良いものではなかったと思う。
コメント1件

561
ナイコンさん[]   投稿日:2016/03/06 11:48:55
バランス悪いx86でRISCをシバき回したインテルを見ると
大事なのはレジスタ数より再投資である

562
ナイコンさん[sage]   投稿日:2016/03/06 16:21:08
AMD64で大して速くなってないし。
コメント1件

563
ナイコンさん[]   投稿日:2016/03/06 16:23:47
汎用レジスタがAX、BX、CX、DXのx86はレジスタ少なすぎ、ってか SS:[BP+n]がレジスタの変わりだからなー。
いちいちスタック経由なのがなー。

564
ナイコンさん[sage]   投稿日:2016/03/06 16:28:41
SIとDIもあるぞ
コメント1件

565
ナイコンさん[]   投稿日:2016/03/06 16:39:10
>564
SIとDIは一応インデックスレジスタの扱いじゃぁ・・・

実際のところ、汎用性はAX>DX>BX>CX>SI>=DIだって教わった。

566
ナイコンさん[sage]   投稿日:2016/03/06 17:16:04
多少レジスタ増やしたところで、処理によっては簡単に溢れる。C言語とか書くときレジスタ数意識しないし。
結局、データバスの帯域増やして、一次キャッシュ増やして、mov eax, dword[ebp+n]を高速化したほうがトータルではお得。
そうやって高速化済みだからAMD64でレジスタ増やしても大して速くならなかった。

567
ナイコンさん[sage]   投稿日:2016/03/06 17:36:37
> 一次キャッシュ増やして、mov eax, dword[ebp+n]を高速化したほうがトータルではお得。

いまどきのx86プロセッサでは当たり前にやってるアウトオブオーダー実行には
メモリアクセスは障害になるので誤り。

568
ナイコンさん[sage]   投稿日:2016/03/06 17:51:09
今時のx86は、スループット0.5clockでアクセスできる。それとも32kb/4の数の汎用レジスタ用意しろと言ってるのか?
RISCであろうとメモリアクセスが一番のボトルネックだからこそ、結局そのアプローチが正解だったのだ。

569
ナイコンさん[sage]   投稿日:2016/03/06 17:56:48
>560
> アドレスレジスタとデータレジスタを別にするデザインはあんま筋の良いものではなかったと思う。
汎用レジスタ×16 にするとあの命令ビット数に収まらんよ

570
ナイコンさん[sage]   投稿日:2016/03/06 18:09:01
変にレジスタ増えるとスレッドコンテキストの切り替えが大変。

571
ナイコンさん[]   投稿日:2016/03/06 18:13:49
x86だろうがなんだろうがノイマン型であるかぎりメモリアクセスは永遠にボトルネックだろ・・・

SS:[EDP+n]って触るのはぶっちゃければほとんどCPUだからキャッシュがフラッシュされるケースは少ない。
割り切ってキャッシュの読み書きを高速化するほうが余程に現実的だろう。
頭打ちになってる気はしないでもないが。

572
ナイコンさん[]   投稿日:2016/03/06 18:21:34
アウトオブオーダー実行ってのはコンピュータの「逐次処理」って原理と言うか原則にケンカ売る技法だからなぁ。
根本的な解決手段ではなくてあくまでも「CPUの空き時間を減らす」ための小細工でしかないんだよな。

573
ナイコンさん[]   投稿日:2016/03/06 18:28:08
>558
x64でのレジスタの使われ方を見ているとCの関数の引数が
スタック渡しからレジスタ渡し(VCで4,gccで6個)に
変わってメモリアクセスが減少する効果はあるだろうけど
贅沢な使い方をしているなという印象が。

こう考えるとレジスタ数の制限が厳しい8086を対象にした
LSI-C86が引数レジスタ渡しを実現していたのは驚異的だった。

574
ナイコンさん[sage]   投稿日:2016/03/06 18:32:06
単に __fastcall 指定するだけじゃ・・・

575
ナイコンさん[]   投稿日:2016/03/06 18:50:21
PowerPCでも引き数のレジスタ渡しは4つまでだったからな。

576
ナイコンさん[sage]   投稿日:2016/03/06 19:35:18
LSIC-86はちっこい関数をコンパイルすることしか想定してないから
レジスタの使い方が巧く見えるのもそういう条件に限るんだよなあ。

577
ナイコンさん[]   投稿日:2016/03/06 19:46:16
もともとのLSIC-80でもレジスタ渡ししてた、
というか8080の貧弱な命令セットでスタックフレームにアクセスすると、
かなり大変なことになるから、実用性を考えるとレジスタ渡しは必然だったと思う。

578
ナイコンさん[]   投稿日:2016/03/06 20:39:40
スタックとか操作が無駄だからポインタ使って丸ごとテーブル渡しがいいとおも

579
ナイコンさん[]   投稿日:2016/03/06 21:26:36
テーブルコピーってのはENTRY/LEAVE命令のことか?

580
ナイコンさん[]   投稿日:2016/03/06 23:16:15
>562
お前が32bitOSしか使った事がないならそう感じるかもな

581
ナイコンさん[sage]   投稿日:2016/03/07 00:15:11
各種ベンチの通りだが大して速くなってない。
AMD64はなんちゃって64bitで、中身はx86を流用してるのだから当然。
8080→8086、286→386みたいな性能Upはしない。

582
ナイコンさん[sage]   投稿日:2016/03/07 02:17:21
ベンチマークテストの結果も提示せずに早くないと言っても
何のテストをしたのかわからないから主張に説得力は全くないよ。
せめて結果を示しているHPのURL程度は記載した方が良いんじゃね。

583
ナイコンさん[sage]   投稿日:2016/03/07 02:33:14
よほど悔しかったのか知らんけど、だれも早くないなんて言ってないよ^^

584
ナイコンさん[]   投稿日:2016/03/07 06:49:31
アプリもマルチスレッド上等な時代だからねー。
コア数多いほうがトータルな性能かせげるからなー。

585
ナイコンさん[]   投稿日:2016/03/07 08:10:33
64ビットOSはメモリ多く使えるからってのが「速い」の大きな要因でプロセッサ性能はあまり寄与してない。

586
ナイコンさん[]   投稿日:2016/03/07 10:22:40
32bitだって4G積める全部認識はしないが。つうか使ったこと無いのか妄想で書くなよ
コメント2件

587
ナイコンさん[sage]   投稿日:2016/03/07 10:29:27
>586
4GB積んでも4GB以上の仮想メモリを使おうとするとアドレッシングが面倒臭い

588
ナイコンさん[]   投稿日:2016/03/07 11:10:18
64bitでも4Gしか積んでなけりゃ仮想のお世話になるよな
同じメモリー量積んだ年代の近いIA32とAMD64で全然速さが違う

589
ナイコンさん[]   投稿日:2016/03/07 12:18:03
ぜんぜん違う、は言い過ぎ。

590
ナイコンさん[]   投稿日:2016/03/07 12:31:31
全然違うってどれぐらい?
0.1%? それとも0.01%?

591
ナイコンさん[]   投稿日:2016/03/07 12:45:24
それがわかってないのにいちゃもんつけてたの?レス乞食かようざいから消えろ

592
ナイコンさん[]   投稿日:2016/03/07 13:17:00
「全然速さが違う」とか言ってた馬鹿が具体的な数字も説明もできないで逆切れw

593
ナイコンさん[]   投稿日:2016/03/07 13:32:24
レス乞食には教えてあげないお前は永遠にバカでいればいい

594
ナイコンさん[]   投稿日:2016/03/07 14:15:14
無職には見つけられないベンチマークの結果まとめたサイト見てるから問題ないんだがな。

595
ナイコンさん[]   投稿日:2016/03/07 14:20:09
論拠は主張する側が提示するものという常識も知らないのかw職務経験のない奴はこれだからw

596
ナイコンさん[sage]   投稿日:2016/03/07 14:32:13
健全でない言葉が含まれているため表示しません 内容を確認する
コメント1件

597
ナイコンさん[]   投稿日:2016/03/07 15:28:25
全然速いとか言い出した時に具体的な数値出してれば妄想扱いされないのにねー。

598
ナイコンさん[]   投稿日:2016/03/07 15:29:24
健全でない言葉が含まれているため表示しません 内容を確認する

599
ナイコンさん[]   投稿日:2016/03/07 15:33:37
>446
お前笑われてんぞ?

【Renesas】ルネサス総合 part9 /電気・電子板-
> 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
ナイコンさん[sage]   投稿日:2016/03/07 15:35:39
コードによってはAMD64は10%弱ぐらい速くなってるが、SSE+SSE2が基本命令として組み込まれたのが大きい。
コメント1件

601
ナイコンさん[]   投稿日:2016/03/07 15:51:10
何と比較して

602
ナイコンさん[sage]   投稿日:2016/03/07 16:01:02

603
ナイコンさん[]   投稿日:2016/03/07 16:28:40
600よお前は何と何を比較したんですか

604
ナイコンさん[]   投稿日:2016/03/07 17:21:20
実務経験ないのがそんなに悔しいなら仕事すれば良いのに。

605
ナイコンさん[]   投稿日:2016/03/07 17:30:21
HEWの奴はなにしたいの?
バカにするなら自分の経験とスキルで正面からバカにすれば良いのに。

606
ナイコンさん[]   投稿日:2016/03/07 17:32:10
怒ってる怒ってるププ

607
ナイコンさん[]   投稿日:2016/03/07 17:35:52
馬鹿が晒されて逆切れw

608
ナイコンさん[]   投稿日:2016/03/07 17:52:51
健全でない言葉が含まれているため表示しません 内容を確認する

609
ナイコンさん[]   投稿日:2016/03/07 18:00:12
http://kotowaza-allguide.com/hi/hitonofundoshi.html
>人の褌で相撲を取る
>【読み】ひとのふんどしですもうをとる
>【意味】人の褌で相撲を取るとは、他人のものを利用したり、他人に便乗したりして、利益を得ること。

違うんじゃない

610
ナイコンさん[]   投稿日:2016/03/07 18:06:34
んなことより600よお前は何と何を比較したんですか

611
ナイコンさん[]   投稿日:2016/03/07 18:16:26
他人のモノを利用する、が何となくそれっぽいとは思う。
利用できてないけど。

612
ナイコンさん[sage]   投稿日:2016/03/07 18:18:04
600みたいな奴は仕事もできない典型

613
ナイコンさん[]   投稿日:2016/03/07 18:27:27
何と戦ってんだろ、コイツ…

614
ナイコンさん[]   投稿日:2016/03/07 19:05:25
どうした600元気ないぞ拾い食いしてお腹壊したか

615
ナイコンさん[sage]   投稿日:2016/03/07 19:06:28
AMD64の速度Upについて言ってるんだから比較元は明確だけれども

616
ナイコンさん[]   投稿日:2016/03/07 19:12:05
じゃあはよ答えろクソ

617
ナイコンさん[]   投稿日:2016/03/07 19:12:46
明言しないことで明確にしないテクニック

618
ナイコンさん[sage]   投稿日:2016/03/07 19:14:01
>602
AMDもAMD64の速度低下の一番の要因は無駄にでかいアドレスポインタなんてのは分かってたんだから、
初めからそういうモード容易しときゃよかったのにな。
コメント2件

619
ナイコンさん[]   投稿日:2016/03/07 19:15:14
モードじゃないけどね

620
ナイコンさん[sage]   投稿日:2016/03/07 19:16:07
容易じゃないけどね

621
ナイコンさん[]   投稿日:2016/03/07 19:18:35
ちなみに命令セットのことなんだけどねわかんないか

622
ナイコンさん[sage]   投稿日:2016/03/07 19:19:37
いやモードの話をしてるんだけど。

623
ナイコンさん[]   投稿日:2016/03/07 19:23:42
602のリンク先で説明されてるのはABIなんだけど。

624
ナイコンさん[sage]   投稿日:2016/03/07 19:25:34
いま馬鹿は一所懸命ABIを検索してます

625
ナイコンさん[sage]   投稿日:2016/03/07 19:26:32
なぜそういうABIを用意したと思ってるんだ。

626
ナイコンさん[sage]   投稿日:2016/03/07 19:31:19
モードw 命令セットw 馬鹿ばっかりだなw

627
ナイコンさん[]   投稿日:2016/03/07 19:36:27
>なぜそういうABIを用意したと思ってるんだ。

英語読めないの??

628
ナイコンさん[sage]   投稿日:2016/03/07 19:36:38
アフィカスがまた暴れてるのか。

629
ナイコンさん[sage]   投稿日:2016/03/07 19:38:42
64bitでもnearポインタとかfarポインタとかを定義しておけばよかっただけ

630
ナイコンさん[]   投稿日:2016/03/07 19:42:10
600のミラクルバカをおちょくってるのでネタバレ禁止

631
ナイコンさん[]   投稿日:2016/03/07 19:50:51
いかにgoogle先生が賢くても600ほどの馬鹿だと救いようがないな

632
ナイコンさん[sage]   投稿日:2016/03/07 19:50:54
>618
5-8%高速化してるってことは、x64はそれだけx86より遅くなってたということだな。

633
ナイコンさん[sage]   投稿日:2016/03/07 19:59:39
>618
確かにそういうモードがあればなぁ。4GB以上使うアプリなんてほとんどないからな。
ポインタこねくりまわすアプリは32bitコードのほうが速いけど、レジスタも増えてSSEも標準で使えればさらに速くなるし。

634
ナイコンさん[]   投稿日:2016/03/07 20:00:51
恥隠しに自演始めたw

635
ナイコンさん[sage]   投稿日:2016/03/07 20:05:20
汎用レジスタが64bitって使い道があまりない。数を数えるには大きすぎる。
なので高速化する場面があまりにも限られてる。研究者には必須なのだろうけど。
コメント2件

636
ナイコンさん[]   投稿日:2016/03/07 20:11:04
答えちまったほうが楽だったと思うがな元気でなチンパン600

637
ナイコンさん[sage]   投稿日:2016/03/07 20:17:22
自演もなにも今時アンカーのつけ方すら知らない馬鹿はおまえだけだから分りやすいw

638
ナイコンさん[sage]   投稿日:2016/03/07 20:29:25
64bitレジスタに即値代入だと32bitレジスタより遅くなる64bitCPUばかり。

639
ナイコンさん[sage]   投稿日:2016/03/07 20:29:29
>635
16bit環境用に4TB超えのATAドライバ書いた時は面倒くさかったぞ

640
ナイコンさん[]   投稿日:2016/03/07 20:39:53
AMDx64か。
プリフィックスの塊みたいなもんだしなぁ。

641
ナイコンさん[]   投稿日:2016/03/07 20:44:05
>635
っ 80ビット浮動小数点演算ユニット

642
ナイコンさん[]   投稿日:2016/03/07 21:07:04
同じクロックなら、というタラレバでx86とx64比べたら大体10〜15%ぐらいx64が優速になるのかな?

意外に遅いのねx64。

643
ナイコンさん[sage]   投稿日:2016/03/07 21:51:44
ググればベンチ結果いっぱい落ちてるだろ。

大して速くなってない。

644
ナイコンさん[sage]   投稿日:2016/03/07 22:06:51
レジスタ幅が倍になったから速度が倍になるわけではないからな。

ただ単純な思考実験で言うが例えば64Bit長の乗算を考えれば
64BitCPUでは1命令ですむものが32BitCPUでは4命令+αになるから
コードによってレジスタ幅の効果は大きく変わってしまう。
レジスタ数の増加も同様に32BitCPUではレジスタを使いきってしまう
状況下では64BitCPUの効果が発揮されてくる。

古典的なCPUのベンチマークになるドライストーン値の結果を
示したものだとこんな結果になるようだ。

http://news.mynavi.jp/special/2005/compiler/013.html
コメント2件

645
ナイコンさん[]   投稿日:2016/03/07 22:30:29
大原雄介みたいな素人が書いた記事が何かの参考になるかな?
コメント1件

646
ナイコンさん[]   投稿日:2016/03/07 22:39:39
大原雄介ってこういう記事書く人ね。

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では問題が出てくる
> かもしれないが。
コメント2件

647
ナイコンさん[]   投稿日:2016/03/07 22:43:29
こんな記事も。

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倍以上の性能差になるわけだ。
コメント3件

648
ナイコンさん[]   投稿日:2016/03/08 00:07:23
http://kei-sakaki.jp/2013/09/19/oohara-386-pipeline-in-nikkei-winp...
> 大原雄介さんの連載「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
ナイコンさん[]   投稿日:2016/03/08 02:23:54
>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
ナイコンさん[sage]   投稿日:2016/03/08 03:25:14
>645-648
CPUの評価にドライストーンベンチマークが不適切というならば
不適切である理由を論理的に明示して批判すれば良いものを、
直接的には関係しない著者の過去の記事を持ってきて素人同然との
印象操作で結果の否定を試みる努力を見ているとどれだけ必死なのかと思ってしまうな。
コメント4件

651
ナイコンさん[sage]   投稿日:2016/03/08 03:41:46
> リスト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
ナイコンさん[]   投稿日:2016/03/08 03:48:43
> 直接的には関係しない著者の過去の記事を持ってきて素人同然との

えっ?! 過去の記事??

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-winp...
> 日経WinPC 2013年10月号 P.136より引用

…むしろここ数年の最近の記事では??

653
ナイコンさん[]   投稿日:2016/03/08 03:51:36
>650
> CPUの評価にドライストーンベンチマークが不適切というならば

誰もそんなこと言ってないじゃんw

素人ライターの記事では32ビット64ビットの比較になってないって嗤ってるだけww

654
ナイコンさん[sage]   投稿日:2016/03/08 03:54:36
>650
>直接的には関係しない著者の過去の記事を持ってきて素人同然との
>印象操作で結果の否定を試みる努力を見ているとどれだけ必死なのかと思ってしまうな。

コンピュータの性能について筆者はそれを語るだけの知識を有してないって批判のどこが「直接的には関係しない」の?

655
ナイコンさん[sage]   投稿日:2016/03/08 03:55:34
レジスタ数増えて、スレッド切り替えコストが増えて、APIのポインタ渡しもサイズが倍に増えて、
32bitOSに比べて64bitOSはなんかもっさり感があるよな。

656
ナイコンさん[]   投稿日:2016/03/08 03:59:37
> リスト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
ナイコンさん[]   投稿日:2016/03/08 04:01:45
>CPUの評価にドライストーンベンチマークが不適切というならば
>不適切である理由を論理的に明示して批判すれば良いものを、
>直接的には関係しない著者の過去の記事を持ってきて素人同然との
>印象操作で結果の否定を試みる努力を見ているとどれだけ必死なのかと思ってしまうな。

↑コイツ素人ライターの大原じゃね?

658
ナイコンさん[]   投稿日:2016/03/08 04:09:32
>550とか>644とかを見ると日本のPC関連を紹介してるメディアの酷さが良く分かるなw

659
ナイコンさん[]   投稿日:2016/03/08 04:15:18
>つhttp://news.mynavi.jp/special/2005/compiler/013.html

こんな糞記事を誇らしげに挙げる神経がわからんw

660
ナイコンさん[sage]   投稿日:2016/03/08 04:16:15
ジョブスがパソコンとマウスを発明したってテレビで言ってた。

661
ナイコンさん[]   投稿日:2016/03/08 04:25:58
>650
お前、>646 >647 がどれだけ馬鹿な内容か理解してないだろw

662
ナイコンさん[sage]   投稿日:2016/03/08 04:56:49
> Arduino Uno 所要時間約44秒
> Galileo   約1秒未満(一瞬)

RISC vs CISC  実際、20年前に起きたことがまた繰り返されただけ。とうとうAtmelは買収されてしまった。
コメント2件

663
ナイコンさん[]   投稿日:2016/03/08 05:04:18
> > Arduino Uno 所要時間約44秒
> > Galileo   約1秒未満(一瞬)
>
> RISC vs CISC  実際、20年前に起きたことがまた繰り返されただけ。とうとうAtmelは買収されてしまった。

馬鹿がまた一人。出鱈目な記事なのになんで疑問のひとつも抱かないの?
コメント2件

664
ナイコンさん[]   投稿日:2016/03/08 05:05:58
>662
お前、>646 >647 がどれだけ馬鹿な内容か理解してないだろww

665
ナイコンさん[sage]   投稿日:2016/03/08 05:08:49
>663
詳しく。何がデタラメなんですか?
コメント2件

666
ナイコンさん[]   投稿日:2016/03/08 05:23:24
健全でない言葉が含まれているため表示しません 内容を確認する
コメント1件

667
ナイコンさん[]   投稿日:2016/03/08 05:43:39
健全でない言葉が含まれているため表示しません 内容を確認する

668
ナイコンさん[sage]   投稿日:2016/03/08 06:54:42
>663
何が出鱈目なのか教えてください。
コメント1件

669
ナイコンさん[]   投稿日:2016/03/08 10:33:56
>668
> これは81億回の足し算を500回繰り返すものだが、

という説明に違和感覚えないようでは重症だぞ?
81億回*500回=4兆5百億回の足し算を16MHzや400MHzのプロセッサが
数十秒や1秒未満で実行できると思うか? ライターが処理内容を
把握してないのは明白。

670
ナイコンさん[sage]   投稿日:2016/03/08 10:52:44
#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 で実行する内容同じだし無駄なループはサックリ削除されるかもなあ、
ライター馬鹿じゃね? 何を比較してるつもりなんだ??
コメント3件

671
ナイコンさん[sage]   投稿日:2016/03/08 12:03:08
>586
32bit だと、仮想メモリーつかっても、プロセス当たりのメモリ空間は4Gしか取れない。

672
ナイコンさん[]   投稿日:2016/03/08 12:20:28
>662>665-668みたいな記事見ても内容理解しないボンクラ読者ばっかりだから
ライターもこんな糞記事書いて食えていけてるんだろうな。
コメント1件

673
ナイコンさん[]   投稿日:2016/03/08 12:26:25
記事の内容が適切だったと仮定しても

> > Arduino Uno 所要時間約44秒
> > Galileo   約1秒未満(一瞬)
>
> RISC vs CISC  実際、20年前に起きたことがまた繰り返されただけ。とうとうAtmelは買収されてしまった。

この結論はないわなあ。8bitのAVRと32bitのQuarkじゃ本来の用途や価格からして違う別のカテゴリの製品でぶつかるもんじゃないのに。
コメント1件

674
ナイコンさん[sage]   投稿日:2016/03/08 12:38:50
> これは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%...;src=typd

675
ナイコンさん[]   投稿日:2016/03/08 12:46:27
インテルが振り返る「ムーアの法則」誕生から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
ナイコンさん[]   投稿日:2016/03/08 16:22:11
>672
ボンクラ連中は>647の記事のおかしいとこもわかってないんだろうw

677
ナイコンさん[]   投稿日:2016/03/08 17:15:57
まあ、たかだか10%、多目に見ても15%が全然速いとか言い切っちゃう低レベルだから仕方ないよね。

678
ナイコンさん[]   投稿日:2016/03/08 17:56:49
>650
> 直接的には関係しない著者の過去の記事を持ってきて素人同然との
> 印象操作で結果の否定を試みる努力を見ているとどれだけ必死なのかと思ってしまうな。

そうですか。

679
ナイコンさん[]   投稿日:2016/03/08 18:00:41
>600
何との比較?

680
ナイコンさん[]   投稿日:2016/03/08 18:15:51
>673
記事のとおり、Arduino互換ボードとしての比較だから、用途はArduino用途として同じカテゴリですよ。
それに今、8bit Arduinoから、32bit Arduinoの移行が進んでるから、性能比較して当然ですね。
8bit avr でパワーが足りなかったためにカメラ関連等諦めてたArduio用途に対してGalileoは使えそう。興味のある記事です。
Avr32がコケて買収された以上、歴史の繰り返しでパワー用途ではRISCよりCISCになるのは同意。
コメント3件

681
ナイコンさん[]   投稿日:2016/03/08 18:19:45
> 記事のとおり、Arduino互換ボードとしての比較だから、用途はArduino用途として同じカテゴリですよ。

で、AVRはQuakeに負けてAtmelは買収されることになったんだ? バカかw

682
ナイコンさん[sage]   投稿日:2016/03/08 18:20:45
訂正:
誤)Quake
正)Quark

683
ナイコンさん[]   投稿日:2016/03/08 18:22:30
>8bit avr でパワーが足りなかったためにカメラ関連等諦めてたArduio用途に対してGalileoは使えそう。興味のある記事です。

インテルが諦めたGalileoを今から「使えそう」って何週遅れだよw

684
ナイコンさん[sage]   投稿日:2016/03/08 18:26:30
>680
>それに今、8bit Arduinoから、32bit Arduinoの移行が進んでるから、

選択肢は増えてはいるが移行は進んでないんじゃないかな。
プログラム開発終わったらArduinoからマイコン抜いて自作の基板に挿し換えるお手軽さを代替するものは存在しないし。
コメント1件

685
ナイコンさん[]   投稿日:2016/03/08 18:29:40
>680
> Avr32がコケて買収された以上、歴史の繰り返しでパワー用途ではRISCよりCISCになるのは同意。

ATMEL ARMもやってるし買収先のMICROCHIPの上位マイコンはMIPSなんだけど何言ってんの?

686
ナイコンさん[sage]   投稿日:2016/03/08 18:30:31
訂正:
誤)何週遅れ
正)何周遅れ

687
ナイコンさん[sage]   投稿日:2016/03/08 18:31:03
>670
どうでもいい処理が残ってるのは単にサンプルスケッチコピペしただけだろう。
ソース乗せてる以上、下らない揚げ足とりだな。これでキレてたらOracleやMSのバギーなサンプルなんて読めないよ。

ソースを見れば単に32bit変数の足し算性能を比較するためなんてPGなら誰でも分るだろう。
コメント4件

688
ナイコンさん[]   投稿日:2016/03/08 18:32:31
>680
>記事のとおり、Arduino互換ボードとしての比較だから、用途はArduino用途として同じカテゴリですよ。

お前さあ、インテルがArduino互換ボードの為にQuark出したと思ってんの?
コメント1件

689
ナイコンさん[]   投稿日:2016/03/08 18:33:40
>687
「どうでもいい処理」ってどこのこと? 具体的にご指摘PLZ
コメント1件

690
ナイコンさん[sage]   投稿日:2016/03/08 18:34:43
>684
Lチカの軽い用途も多いからすべては移行しないけど、
これからAVRチップの入手性がどうなるか読めない。ディスコンも覚悟しなきゃならない。

691
ナイコンさん[sage]   投稿日:2016/03/08 18:35:40
>688
おいおいおまえは何を勘違いしてるんだ?

692
ナイコンさん[]   投稿日:2016/03/08 18:36:02
「これは81億回の足し算を500回繰り返すものだが、性能面では勝負にならないほどGalileoが高速だった。」と記事にはあるから少なくとも繰り返し部分は「どうでもいい処理」ではないな。>687の回答に期待。

693
ナイコンさん[]   投稿日:2016/03/08 18:36:51
>おいおいおまえは何を勘違いしてるんだ?

質問に答えられない馬鹿↑

694
ナイコンさん[]   投稿日:2016/03/08 18:38:45
>687
>ソースを見れば単に32bit変数の足し算性能を比較するためなんてPGなら誰でも分るだろう。

最適化で削除されるかもしれない処理で性能なんて計れないよ?

695
ナイコンさん[sage]   投稿日:2016/03/08 18:41:11
>689

もう指摘したでしょ。 >670
コメント1件

696
670[]   投稿日:2016/03/08 18:43:46
>695
お前の言う「どうでもいい処理」ってどこのこと? 具体的にご指摘PLZ

697
ナイコンさん[sage]   投稿日:2016/03/08 18:47:36
Lチカの判定だろw。このスレってほんとレベル低いなw この記事書いた本人じゃないのww 馬鹿すぎwww

 if(num) digitalWrite(13, LOW);
 else  digitalWrite(13, LOW);
コメント1件

698
670[]   投稿日:2016/03/08 18:50:55
>697
俺の考える「サックリ削除されるかも」な部分はループ部分全体なんで、それを削除されるとプログラム全体は

void setup()
{
 pinMode(13, OUTPUT);
}

void loop()
{
 delay(1000);
 digitalWrite(13, HIGH);
 digitalWrite(13, LOW);
 while(1);
}

と同等となり何も計れないという主張なんだが?

699
ナイコンさん[sage]   投稿日:2016/03/08 18:52:04
どうだろう。gccはかなり馬鹿だからな。加算ループ削除させないためにnumを無理やり使ったのだろう。

700
ナイコンさん[sage]   投稿日:2016/03/08 18:53:39
つまり >670 の負けだな。

701
sage[]   投稿日:2016/03/08 18:57:09
>加算ループ削除させないためにnumを無理やり使ったのだろう。

加算ループ削除させないためにはnumの値が如何様でも

> digitalWrite(13, LOW);

するロジックじゃダメなんだよなあ。せめて

 if(num) digitalWrite(13, LOW);
 else  digitalWrite(13, HIGH);

とかするべきだし、そもそも定数回繰り返しの加算なんかは定数式に
置き換えもされることもあるからプログラム自体ナンセンスなんだわ。
せめてプログラムコンパイル後にオブジェクトを逆アセンブルして
同じロジックでコード出力されてることを確認しないと意味ない。

702
670[sage]   投稿日:2016/03/08 18:57:42
おっと名前欄間違えた。

703
ナイコンさん[]   投稿日:2016/03/08 18:58:17
同じメモリー量積んだ年代の近いIA32とx64で全然速さが違う

704
670[sage]   投稿日:2016/03/08 19:01:23
ちなみに、「サックリ削除されるかも」と書いたが当時のGalileo専用の
Arduino IDEでこのプログラムをコンパイルするとループ部分がサックリ
削除されることは確認済みだから。

> Galileo   約1秒未満(一瞬)

って当たり前なんだよな。プロセッサの比較になんてなってないんだよ。

705
ナイコンさん[sage]   投稿日:2016/03/08 19:02:23
そもそもif(num)がなくて測れなくて、if(num)追加したら測れたのでそこで仕事が終わっただけだろう。
ループでウェイトなんてマイコンじゃ当たり前の処理を削除する馬鹿gccが原因。正直どうでもいい揚げ足取りだわ。
コメント1件

706
ナイコンさん[]   投稿日:2016/03/08 19:04:27
>687
>ソースを見れば単に32bit変数の足し算性能を比較するためなんてPGなら誰でも分るだろう。

「81億回の足し算を500回繰り返す」テストがどれだけナンセンスなものか理解してないなw

707
ナイコンさん[]   投稿日:2016/03/08 19:06:55
>705
>そもそもif(num)がなくて測れなくて、if(num)追加したら測れたのでそこで仕事が終わっただけだろう。

ちょっと何言ってるかわからんですね。

>ループでウェイトなんてマイコンじゃ当たり前の処理を削除する馬鹿gccが原因。

削除されないようループ変数volatileにしたり普通するけどね、プログラム書いた奴が素人だったことが原因。

708
ナイコンさん[sage]   投稿日:2016/03/08 19:10:36
マイコンでコンパイラの最適化なんてするほうが馬鹿

709
ナイコンさん[sage]   投稿日:2016/03/08 19:11:21
せめてこうだったらループも削除されなかったかもなあ。

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
ナイコンさん[sage]   投稿日:2016/03/08 19:12:53
これArduinoだから素人、学習者が使うものやで。ifやloop削除したらあかん用途や。

711
ナイコンさん[sage]   投稿日:2016/03/08 19:13:15
> マイコンでコンパイラの最適化なんてするほうが馬鹿

コンパイラの最適化を理解できない素人プログラマーではそう言う人は一定数いるね。

712
ナイコンさん[]   投稿日:2016/03/08 19:14:42
> これArduinoだから素人、学習者が使うものやで。

いまのArduino言語はvolatileも仕様に入ってるの知らない人かな?
コメント1件

713
ナイコンさん[sage]   投稿日:2016/03/08 19:20:43
>712
無駄なループ、無駄な判定、無駄な計算は実行しないと言語仕様にあるのかね?
仕様外の結果を出す糞gccのために追加された仕様ではないのかね?
コメント1件

714
ナイコンさん[sage]   投稿日:2016/03/08 19:21:22
>これArduinoだから素人、学習者が使うものやで。ifやloop削除したらあかん用途や。

素人の用途程度には使える時間待ち関数が標準で提供されてるよ。

715
ナイコンさん[sage]   投稿日:2016/03/08 19:22:48
現に二つのarduinoの処理系で違う結果が出てるじゃん。
gccのバグ以外の何ものでもねーじゃん。
コメント1件

716
ナイコンさん[]   投稿日:2016/03/08 19:26:07
>713
Arduinoのリファレンスに無駄なループで時間待ちができるという記述があるのかねw

717
ナイコンさん[]   投稿日:2016/03/08 19:28:17
>715
「gccのバグ」ってどこのことを言ってんの?
ターゲットのアーキテクチャもコンパイラのバージョンも違うんで同一のコードが出力されるわけもないが。

718
ナイコンさん[sage]   投稿日:2016/03/08 19:29:06
gccがよく速いコードを出すという話があるが実は必要な処理まで削ってる可能性が高い。

gccのせいで飛行機が落ちませんように-人-

719
ナイコンさん[]   投稿日:2016/03/08 19:31:39
> 無駄なループ、無駄な判定、無駄な計算は実行しない
> 仕様外の結果を出す糞gcc

いまどきのコンパイラはすべて糞って主張かな?
…まあ昔のPC板だし最適化もろくにしない何十年前のツールしか知らない人がいても不思議はないが。
コメント1件

720
ナイコンさん[sage]   投稿日:2016/03/08 19:32:04
javaを思いだすね。JVMの挙動が処理系によって全然違う。

721
ナイコンさん[]   投稿日:2016/03/08 19:33:29
コンパイラの最適化がONにできるとか、ぬるい仕事してんのね・・・
制動系(車のブレーキとかが代表的かね)や電話の中継器、交換機とか消防司令システムとかやってると、正直コンパイラのバグが怖くて最適化ONになんかできねぇ。
コメント1件

722
ナイコンさん[sage]   投稿日:2016/03/08 19:35:41
>正直コンパイラのバグが怖くて最適化ONになんかできねぇ。

コンパイラの挙動理解してない素人はそういうこと言うね。
コメント1件

723
ナイコンさん[sage]   投稿日:2016/03/08 19:38:13
>719
VSではそんな経験ないな。PGの希望通りの動きをする。それに比べてgccは斜め横の最適化する。
コメント2件

724
ナイコンさん[]   投稿日:2016/03/08 19:39:28
>722
挙動理解してるから言ってんだよ。
人の命預かるシステムを軽く見るんじゃねぇよド素人が。
コメント1件

725
ナイコンさん[]   投稿日:2016/03/08 19:41:56
>正直コンパイラのバグが怖くて最適化ONになんかできねぇ。

最適化OFFだとコンパイラのバグには平気になるのかな? 不思議な思い込みだな。最適化有効にしたほうがコンパイラがデータフロー解析まじめにやってくれるし出力コードも読みやすくなるのにな。最適化OFFでどうやって信頼性を担保してるのかすごい不思議。
コメント1件

726
ナイコンさん[]   投稿日:2016/03/08 19:43:34
>721
最適化させなければコンパイラは信用できる、
ってもんでも無いと思うんだが…

てか、逆にその程度の認識しか無い奴が
そんな重要なコードを書いてることのほうがよほど恐ろしいんだがw

727
ナイコンさん[]   投稿日:2016/03/08 19:50:04
>725
コンパイラのバグの多く、というか「問題のあるコードが出力される原因」のほとんどが最適化にあるの知らんのか?
同じソースから最適化なしでコンパイルしただけでどれだけ不安要素がなくなるか知らないだろ、お前は。

ブレーキの反応速度が10%向上します。でも1万回に1回効かなくなる可能性があります。とういうなら10%遅いほうを選ぶ。
人の命が懸かる製品をつくるってのは、そう言うことだ。

728
ナイコンさん[sage]   投稿日:2016/03/08 19:51:00
普通に信頼度は、 最適化するほど下がると思うけど。
現にPGの意図を無視して最適化してるのが今回の例。
処理速度を測るために加算ループコード書いたのに、削除してる。
そして削除させないために必死に無駄なコードを追加。
今度は処理系の違いで挙動が変わってきた。

ここまで来るともう害しかないわ。
5分で終わるシンプルなことにいらんトラブルで何時間かけさせるつもりだよ。

729
ナイコンさん[]   投稿日:2016/03/08 19:52:53
>正直コンパイラのバグが怖くて最適化ONになんかできねぇ。

某マイコンメーカーの人から、ユーザーからのコンパイラのバグだという
苦情で一番多いのがvolatileつけ忘れ、というかそれ以前にvolatileを
理解してないプログラマによるバグって話は聞いたことあるなあ。
この人もなんかそんな感じですねw
コメント2件

730
ナイコンさん[]   投稿日:2016/03/08 19:53:34
「最適化されても機能が実現できる書き方できないヘボが悪い」と、現実知らないお坊ちゃまは言いますよ。
コメント1件

731
ナイコンさん[]   投稿日:2016/03/08 19:53:42
>現にPGの意図を無視して最適化してるのが今回の例。

わかってないプログラマがツールのせいにしてるだけw

732
ナイコンさん[]   投稿日:2016/03/08 19:55:30
糞記事書いた素人ライターでもあるまいに今ここでgccを非難してる馬鹿の意図がわからんw

733
ナイコンさん[]   投稿日:2016/03/08 19:57:04
> 普通に信頼度は、 最適化するほど下がると思うけど。
> 現にPGの意図を無視して最適化してるのが今回の例。
> 処理速度を測るために加算ループコード書いたのに、削除してる。
> そして削除させないために必死に無駄なコードを追加。
> 今度は処理系の違いで挙動が変わってきた。

分かってない典型w こういう馬鹿とプロジェクト組む人は不幸だなあw
コメント1件

734
ナイコンさん[sage]   投稿日:2016/03/08 19:57:45
>729
コンパイラのリビジョンヒストリーを見ると
最適化がらみのバグの修正が意外と多いw
コメント2件

735
ナイコンさん[]   投稿日:2016/03/08 19:59:01
>729
最初に疑うだろ、volataile付けわすれって。
つか普通に解析ツールが警告するだろ・・・

736
ナイコンさん[]   投稿日:2016/03/08 19:59:18
> 処理速度を測るために加算ループコード書いたのに、

「実行時間」は保証されていない副作用でしかないことを理解してないw

737
ナイコンさん[]   投稿日:2016/03/08 20:00:46
>733
君と組まされるほうがよほどに不幸だよ。
「わかってるつもりで何も判ってない馬鹿」と回りは見るからね。

738
ナイコンさん[sage]   投稿日:2016/03/08 20:01:44
安心してください。

時代の流れは脱gccです。FreeBSDも脱gcc果たしました。gccはオワコンです。
コメント1件

739
ナイコンさん[]   投稿日:2016/03/08 20:09:38
以前、原因不明のバグを調査して行ったら、結局リンカがバグってたことがあったw

740
ナイコンさん[]   投稿日:2016/03/08 20:15:36
>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;
}
コメント2件

741
ナイコンさん[sage]   投稿日:2016/03/08 20:23:33
>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

普通に無駄ループ削除してるね。
コメント4件

742
ナイコンさん[sage]   投稿日:2016/03/08 20:26:26
なんだ糞記事のどこが糞か理解できなかった馬鹿が暴れてんのかw

743
ナイコンさん[]   投稿日:2016/03/08 20:28:39
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言語はそういう系統の言語だと割り切ったほうが良いかもな。
コメント1件

744
ナイコンさん[]   投稿日:2016/03/08 20:28:56
>741
すばらしく綺麗なコードになったなー。
思わず笑っちゃったわ。

745
ナイコンさん[]   投稿日:2016/03/08 20:29:58
>730
「最適化されても機能が実現できる書き方できないヘボが悪い」と
「複数人で構成されるプロジェクトではヘボに合わせる他ない」ってのは
相反するものではないし「ヘボが悪い」事実は変わらない。
コメント1件

746
ナイコンさん[sage]   投稿日:2016/03/08 20:30:08
>740
vcは削除されなかった。さすがMSだ。

747
ナイコンさん[]   投稿日:2016/03/08 20:36:04
>745
現実を知ってるならわざわざ言わないでしょ?

748
ナイコンさん[sage]   投稿日:2016/03/08 20:38:21
>741
普段使ってるコンパイラだとこうなったぞ


  push   ebp
  mov    ebp,esp
  xor    eax,eax
@1:
  inc    eax
  cmp    eax,10000
  jle    short @1
  xor    eax,eax
  pop    ebp
  ret
コメント1件

749
ナイコンさん[sage]   投稿日:2016/03/08 20:39:51
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
コメント1件

750
ナイコンさん[sage]   投稿日:2016/03/08 20:40:52
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
ナイコンさん[]   投稿日:2016/03/08 20:41:10
>748
それでも
n += i;
はばっちり削除されてんね。
コメント1件

752
ナイコンさん[]   投稿日:2016/03/08 20:41:29
実際のところ、クリティカルな部分はアセンブラで書くのが一番信用できるんだよな。

753
ナイコンさん[sage]   投稿日:2016/03/08 20:42:16
>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
}
コメント1件

754
ナイコンさん[sage]   投稿日:2016/03/08 20:43:23
>751
nはコンパイル時にwarning出る

755
ナイコンさん[sage]   投稿日:2016/03/08 20:58:21
>743
PGの意図を汲めないKYなコンパイラgcc。

そもそも|| は orであって、英語のorには排他の意味もあるからそれが自然。
コメント1件

756
ナイコンさん[sage]   投稿日:2016/03/08 21:01:42
> そもそも|| は orであって、英語のorには排他の意味もあるからそれが自然。

| も orであってどっちも評価されるがそれは不自然なのか?

757
ナイコンさん[sage]   投稿日:2016/03/08 21:08:11
論理演算子とビット演算子の区別くらいしろw

758
ナイコンさん[sage]   投稿日:2016/03/08 21:09:14
|はビット演算子だから、数学的でないと。排他的論理和 ^ もちゃんと容易されてるしちゃんと区別しなさいってことだな。

perlでも open() or die();

英語的に自然だろ?
コメント1件

759
ナイコンさん[]   投稿日:2016/03/08 21:17:29
>758
andだとおかしく無いか?
コメント1件

760
ナイコンさん[]   投稿日:2016/03/08 21:36:39
結論として「最適化はプログラマの意図しないコードを吐く」が正解ってことだね。

761
ナイコンさん[]   投稿日:2016/03/08 21:53:14
>755
gccなんて昔からボロクソに悪く言われてたから今更だよ。

762
ナイコンさん[sage]   投稿日:2016/03/08 21:54:08
最適化をオフにしたらプログラマの意図した通りに動く以上、
volatileがあるから最適化は言語仕様内と言うのは無理があるよ。
コメント2件

763
ナイコンさん[sage]   投稿日:2016/03/08 22:01:26
>759
open(OUT,xx) and print OUT xx

自然じゃないか?

764
ナイコンさん[]   投稿日:2016/03/08 22:07:52
>762
最適化「してもいいよ」で「しなくてはいけない」じゃないからねー。
volatileやregisterも仕様としてはめっちゃ後出しだしね。

765
ナイコンさん[]   投稿日:2016/03/08 22:14:08
registerはK&R初版からあった気がする。

766
ナイコンさん[]   投稿日:2016/03/08 22:15:59

767
ナイコンさん[sage]   投稿日:2016/03/08 22:17:51
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
ナイコンさん[]   投稿日:2016/03/08 22:19:31
>registerも仕様としてはめっちゃ後出しだしね。

馬鹿発見w

769
ナイコンさん[sage]   投稿日:2016/03/08 22:26:44
>issues of optimization

おれの英語力じゃよくわからが最適化に問題があるのか。

>are irrelevant.

勝手にやってろ。巻き込むなと言ってるわけだな。

770
ナイコンさん[]   投稿日:2016/03/08 22:30:26
書いたコードそのまんまって、突き詰めると、
a=1+2+3+4+5+6+7+8+9+10;

a=55;
にするのは反則で、
ちゃんと9回の足し算と1回の代入をしてくれなくちゃヤダってことなるよね、
そうなることを期待してベンチマークコードを書いたのかもしれないし。

771
ナイコンさん[]   投稿日:2016/03/08 23:00:46
http://kikakurui.com/x3/X3010-2003-01.html
> 5.1.2.3 プログラムの実行 この規格における意味規則の規定では,
> 最適化の問題を無視して抽象計算機の動作として記述する。
>  ボラタイルオブジェクトへのアクセス,オブジェクトの変更,ファ
> イルの変更,又はこれらのいずれかの操作を行う関数の呼出しは,
> すべて副作用(side effect)と呼び(11),実行環境の状態に変化を
> 生じる。式の評価は,副作用を引き起こしてもよい。副作用完了点
> (sequence point)と呼ばれる実行順序における特定の点において,
> それ以前の評価に伴う副作用は,すべて完了していなければならず,
> それ以降の評価に伴う副作用が既に発生していてはならない。(副
> 作用完了点の要約を附属書 C に示す。)
>  抽象計算機では,すべての式は意味規則で規定するとおりに評価
> する。実際の処理系では,値が使用されないこと,及び(関数の呼
> 出し又はボラタイルオブジェクトのアクセスによって起こる副作用を
> 含め)副作用が必要とされないことが保証できる式は,評価しなくて
> よい。

772
ナイコンさん[sage]   投稿日:2016/03/09 01:20:23
registerは初期の頃のCにコンパイラ開発者によって追加された。
どの変数をレジスタに割り当ててればいいかの実装が面倒なので追加されたらしい。
つまり、プログラマに高速化するための手段として用意したわけではなく、
コンパイラの実装を楽にするための機能として追加された。

773
ナイコンさん[sage]   投稿日:2016/03/09 01:40:04
〜という妄想だったとサ。

774
ナイコンさん[sage]   投稿日:2016/03/09 01:43:21
あってるよ。妄想で否定するなよ。

775
ナイコンさん[sage]   投稿日:2016/03/09 02:10:56
>766
> 副作用が必要とされないことが保証できる式は,評価しなくてよい。

プログラマは副作用を必要としてるわけだから、評価しなくちゃいけないってことだな。
コメント1件

776
ナイコンさん[]   投稿日:2016/03/09 03:01:39
>775
プログラマが副作用を必要とするならvolatile修飾子等でコンパイラに指示する必要があるってことだよ。
暗黙的には「副作用を必要としていない」とみなされる。

777
ナイコンさん[sage]   投稿日:2016/03/09 03:47:20
なるほど。さっぱり分らん。

778
ナイコンさん[]   投稿日:2016/03/09 04:11:01
> 評価しなくて良い

「評価してはいけない」じゃないからね。
コンパイラに最適化禁止のオプションがあるのは何のためか。
コメント1件

779
ナイコンさん[]   投稿日:2016/03/09 05:38:27
最適化しないと性能だせないとかだったらどんだけ無駄なソースかいてるのって話しだな。
しかしIA-32でregister修飾子が有効になるケースなんてあるンかね?
めっちゃ小さい関数でないと無効化される気がする。
コメント1件

780
ナイコンさん[]   投稿日:2016/03/09 06:48:13
>778
C言語の仕様では
・どうやって最適化をするか
・最適化をしないとはどういうことか
等は全く規定されていないでしょ、なので最適化とは全く関係ないレベルの話になる。

つまり、
「値が使用されない」及び「副作用が必要とされない」ことがコード的に明白な式については、
コンパイラは評価しても良いし、しなくても良い。
逆にプログラマ側から見ると評価されるかも知れないし、されないかも知れない
というのがC言語の仕様。

781
ナイコンさん[]   投稿日:2016/03/09 07:06:12
>779
最適化無しだと>753なコードになるんだぞ?
変数のレジスタ割り当てすらされてない、
ソースの書き方とかそういうレベルの話ではないよ。
コメント1件

782
ナイコンさん[]   投稿日:2016/03/09 07:41:15
>781
処理が遅いなら遅いなりに性能出す書き方があるでしょ。
トータルで性能満たせば良いわけだし。
ループの高速化が性能確保の肝で最適化しない限り仕様を満たさない、というようなケースがそんなに有るとは思わんし。
ただ、そういうケースほど要求の優先度高かったりするんよね。
コメント1件

783
ナイコンさん[sage]   投稿日:2016/03/09 07:56:49
> プログラマ側から見ると評価されるかも知れないし、されないかも知れない
> というのがC言語の仕様。

池田信夫かよ。

784
ナイコンさん[]   投稿日:2016/03/09 08:22:35
>782
> 処理が遅いなら遅いなりに性能出す書き方があるでしょ。

配列でのアクセスを避けてポインタ、中間ポインタを多用したりとか、
極端な例だと、インライン関数が展開されないなら、自力でソースに展開しちゃえば良いじゃない。
とか、可読性も保守性も下がるしその分バグも増えるしで、あんまり良くない。

> トータルで性能満たせば良いわけだし。
コードの効率はそのままCPUタイムや消費電力に直結するから、効率は良ければ良いほど良いってのはある。
コメント1件

785
ナイコンさん[sage]   投稿日:2016/03/09 08:25:44
速度と消費電力は反比例。クロック落として電圧下げたほうが消費電力低下に直結ですよ。
コメント1件

786
ナイコンさん[]   投稿日:2016/03/09 10:24:11
>784
大前提として、マトモに動いて、と言うのがあってこそだけどね。
741みたいな例は極端たけど、期待する動作しないコード吐かれたって意味ないし。

787
ナイコンさん[sage]   投稿日:2016/03/09 11:43:07
意図されない最適化をされると動かなくなるから最適化禁止って要は
コンパイラの挙動を理解してないってことなんだよなあ。
Cってプロがアセンブラ代わりに使うものなんで、素人はPascalでも
使ってなさいってこった。
コメント2件

788
ナイコンさん[]   投稿日:2016/03/09 12:25:01
>785
その通り。つまりコードの効率が良ければ、
低電圧、低クロックで動作する低速、低消費電力のCPUで十分になるし、
同じCPUでも、実行時間が短くなれば、その分CPUがHALTしてる時間が増えて
消費電力も少なくなるんだよね。

最近じゃとても重要な要素だと思うんだがなぁ…

789
ナイコンさん[]   投稿日:2016/03/09 12:25:12
意図しない最適化ってなんのことだ?
誰かそんな話し、してる?
コメント1件

790
ナイコンさん[]   投稿日:2016/03/09 12:36:58
最近のスマホは電話機じゃないからなー。
フリーズとか、通信機器として致命的なバグでも放置だからなー。
治しようがないから仕方ないけど。

791
ナイコンさん[sage]   投稿日:2016/03/09 12:41:38
>787
キミの知ったかはいつまで続くのでしょうか?

792
ナイコンさん[sage]   投稿日:2016/03/09 12:52:05
>789

> 現にPGの意図を無視して最適化してるのが今回の例。
> 処理速度を測るために加算ループコード書いたのに、削除してる。

793
ナイコンさん[sage]   投稿日:2016/03/09 12:58:05
> 処理速度を測るために加算ループコード書いたのに、

ププ! コイツC言語解ってねぇw

794
ナイコンさん[]   投稿日:2016/03/09 13:01:10
>787
コンパイラの挙動というか本質的にはC言語を理解してないんだと思うね。
大前提として、Cはアセンブラのような低級言語ではなく、抽象化された高級言語でしかないから、
言語仕様の範囲内で最適化(場合によっては反最適化w)されても、プログラマは全く文句を言える立場に無い。

(C言語的に適切に)最適化されたら動かなくなるコードとかぶっちゃけ潜在的なバグと言っても良いくらいで、
それを最適化OFFで長年動かしてると、そのコードが「実績のあるコード」として信頼され、
ビルド環境や処理系が変わったときに、致命的な問題を引き起こしたりするのが一番怖い。

795
ナイコンさん[sage]   投稿日:2016/03/09 14:09:13
「人の命預かるシステム」とか「人の命が懸かる製品」とか偉そうに
言ってるのが解ってない奴ってのがね…。

796
ナイコンさん[sage]   投稿日:2016/03/09 16:13:57
最適化を切る理由は>734でいいんじゃねリスク低減なんだろ
コメント1件

797
ナイコンさん[sage]   投稿日:2016/03/09 16:17:21
> 現にPGの意図を無視して最適化してるのが今回の例。
> 処理速度を測るために加算ループコード書いたのに、削除してる。

こんなこと言う奴の書くプログラムってどんなんだろ? 怖いもの見たさでちょっと気になるな。

798
ナイコンさん[]   投稿日:2016/03/09 16:19:38
>796
>734の言う製品がそうだというだけの話じゃね? 実在するものかも分からんけどさ。

799
ナイコンさん[sage]   投稿日:2016/03/09 17:33:37
そこら辺は知らないがプラットホームを跨ぐ場合もあるだろうし地雷よけなんでしょ

800
ナイコンさん[sage]   投稿日:2016/03/09 17:56:36
> ループでウェイトなんてマイコンじゃ当たり前の処理を削除する馬鹿gccが原因。

こういうこと言う奴がいるプロジェクトならそりゃもうそこらじゅう地雷だらけだろうなw

801
ナイコンさん[sage]   投稿日:2016/03/09 18:03:23
割込あれば良いけど…CPU以外の物とタイミングを合わせる場合は?

802
ナイコンさん[sage]   投稿日:2016/03/09 18:08:44
> ループでウェイトなんてマイコンじゃ当たり前の処理

コンパイラが吐いたコードに合わせてループ回数でウエイト時間調整すんのかな?
こんなコードがあちこちに紛れてりゃそりゃ最適化なんてできんわなあw

803
ナイコンさん[sage]   投稿日:2016/03/09 18:30:56
マイコンの入門書はほぼすべてループでWaitですよ。

804
ナイコンさん[sage]   投稿日:2016/03/09 18:36:29
世の中に数多あるであろうマイコンの入門書をほぼすべて読みつくしたとはスゴイ

805
ナイコンさん[]   投稿日:2016/03/09 18:40:05
ループを用いないで速度計測するのも難しそうだ

806
ナイコンさん[sage]   投稿日:2016/03/09 18:43:30
ベンチ作ったらgccに計算全部削除されてました、へへ

807
ナイコンさん[sage]   投稿日:2016/03/09 18:47:25
volatileも使えない奴がC言語でループWAITが必要なコードなんか書くな

だいたい今どきのCPUはそもそも命令実行クロック数が一定じゃない
(キャッシュヒットや分岐予測によるパイプラインの乱れ等で実行速度が可変する)

CPUの差し替えによる高速化はおろか動作状況にすら依存するようなコードは本来書くべきじゃないし
書かざる得ないなら高級言語や一般的な開発環境に頼るな

入門書の目的はI/O WAITを教える事じゃないからとりあえず一番簡単な方法として必要な箇所にループWAITを書いてあるだけで
まともにやる場合は割り込みを待つなりI/Oの応答信号をポーリング監視するなりしてタイミングを計るもんだ
コメント1件

808
ナイコンさん[sage]   投稿日:2016/03/09 18:55:54
話は"マイコン"の場合だよね…

>命令実行クロック数が一定じゃない
そういうCPUを使うかな?
>高級言語や一般的な開発環境に頼るな
わかる
>割り込みを待つなりI/Oの応答信号をポーリング監視
周辺チップがそのような機能をサポートしていな場合があるよね

809
ナイコンさん[sage]   投稿日:2016/03/09 19:07:35
>807
今回は avr と quark の話なんですけどw

同じプラットフォーム、同じコードなのに、avrは削除されず、quakは削除された。

さっきから一人ズレすぎですよw
コメント1件

810
ナイコンさん[sage]   投稿日:2016/03/09 19:09:49
> 今回は avr と quark の話なんですけどw

ブレーキがどうこう、人の命を預かる云々とか言ってる馬鹿もいるし
とっくに話は変わってるだろw

811
ナイコンさん[]   投稿日:2016/03/09 19:11:31
> 同じプラットフォーム、同じコードなのに、avrは削除されず

馬鹿発見www

812
ナイコンさん[]   投稿日:2016/03/09 19:11:31
x86と68kのスレでマイコンの時点で・・・

813
ナイコンさん[]   投稿日:2016/03/09 19:12:52
タイミング調整をループでなんて20年前に廃れただろ。
コメント1件

814
ナイコンさん[sage]   投稿日:2016/03/09 19:12:59
どっちもマイコンじゃねーか。

815
ナイコンさん[]   投稿日:2016/03/09 19:13:04
> 同じプラットフォーム、同じコードなのに、avrは削除されず、quakは削除された。

16MHzのAVRで81億回の加算を500回繰り返して数十秒? マジで??
コメント3件

816
ナイコンさん[sage]   投稿日:2016/03/09 19:13:40
>813
Linux、FreeBSDのコード見てみな。
コメント1件

817
ナイコンさん[]   投稿日:2016/03/09 19:16:09
>815
マジです。
ただし、「C言語のソースでは」ですよ!

818
ナイコンさん[]   投稿日:2016/03/09 19:17:08
>816
具体的にファイル名と関数名プリーズ。
そしたら見るわ。

819
ナイコンさん[]   投稿日:2016/03/09 19:25:27
gccなんてゴミは言いすぎだがクソなコンパイラ使うしかない時点でお察しだよな。

820
ナイコンさん[sage]   投稿日:2016/03/09 19:27:18
>815
確かに計算が合わない。
avr はadd は1クロックかかる。しかも8bitレジスタ。quarkは32bitレジスタで0.5クロックのはず。

このスレで常駐しているコンパイラの挙動に詳しい人がAVRではどういうコードが吐かれたか詳しいらしい。ぜひ説明してもらおう。
コメント1件

821
ナイコンさん[]   投稿日:2016/03/09 19:37:34
>820
え?? 説明してくれるのは「avrは削除されず」って主張してる>809でしょ?
コメント1件

822
ナイコンさん[sage]   投稿日:2016/03/09 19:48:46
>821
申し訳ございません。私の勘違いでした。
vc++では削除されないので、まさかデフォルト設定で平気で削除する処理系がこの世に存在するとは思いもよりませんでした。
大海を知りながら、井の中を知らずと恥じるばかりです。ですのでavr環境ではどのようなコードを吐かれたのかご教授願います。

823
ナイコンさん[sage]   投稿日:2016/03/09 19:51:14
>挙動理解してるから言ってんだよ。
>人の命預かるシステムを軽く見るんじゃねぇよド素人が。

コンパイラの挙動理解してるプロっぽいこの人↑に説明してもらいたい

824
ナイコンさん[]   投稿日:2016/03/09 19:52:03
コンパイラのスペシャリストが居るみたいだからたぶんさくっと説明してくれるだろうwww

825
ナイコンさん[sage]   投稿日:2016/03/09 20:11:01
>どうでもいい処理が残ってるのは単にサンプルスケッチコピペしただけだろう。
>ソース乗せてる以上、下らない揚げ足とりだな。これでキレてたらOracleやMSのバギーなサンプルなんて読めないよ。
>
>ソースを見れば単に32bit変数の足し算性能を比較するためなんてPGなら誰でも分るだろう。

この人プログラム見るの得意そう。ぜひこの人に解説してもらいたい。

826
ナイコンさん[sage]   投稿日:2016/03/09 20:14:16
>これArduinoだから素人、学習者が使うものやで。ifやloop削除したらあかん用途や。

Arduinoに詳しいですね。ぜひ>815について説明して下さい。

827
ナイコンさん[sage]   投稿日:2016/03/09 20:46:42
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
ナイコンさん[sage]   投稿日:2016/03/09 20:47:49
あれ? 連続する空白が圧縮されて見辛いか。

829
ナイコンさん[sage]   投稿日:2016/03/09 21:00:36
loop() の逆アセンブルが90行近くあって分割して貼るのが面倒臭くなったので貼るのヤメ。

出力コードの内容は、
・データはすべてレジスタに割付られてる
・ソースでは3重ループだが、コードでは最内側のループが定数式に変換され2重ループになってる
・最外側のループがソースでは unsigned long の変数(4バイト)を使って処理されているが、コードでは 2バイトのデータで繰り返し処理されている
・演算結果のnumを評価しており、その結果で digitalWrite(13, LOW) か digitalWrite(13, LOW) を実行している

未確認だが、Arduino と Galileo で IDE から呼び出される際の最適化レベルが違う感じ。
コメント1件

830
ナイコンさん[sage]   投稿日:2016/03/09 21:03:55
訂正:
誤)IDE から呼び出される際の最適化レベル
正)IDE からコンパイラが呼び出される際に指定される最適化レベル

831
ナイコンさん[sage]   投稿日:2016/03/09 21:13:48
>・最外側のループがソースでは unsigned long の変数(4バイト)を使って処理されているが、コードでは 2バイトのデータで繰り返し処理されている

C++の型推論とかなしにこの最適化をするのはちょっとびっくり。

832
ナイコンさん[sage]   投稿日:2016/03/09 21:51:56
最新、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
ナイコンさん[sage]   投稿日:2016/03/09 21:53:21
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
ナイコンさん[sage]   投稿日:2016/03/09 21:54:59
ああ、違うか。
digitalWrite(13, HIGH) と digitalWrite(13, LOW) の間の時間を計ってるのか。

835
ナイコンさん[sage]   投稿日:2016/03/09 21:59:29
gccの最適化はほんと酷いな。バージョンによってこんなに違うコード吐くのかよ。
コンパイラの挙動を把握とか言ってる奴は大嘘つきだろ。できるわけがない。gccの品質が低すぎる。

836
ナイコンさん[sage]   投稿日:2016/03/09 22:10:52
使ってるコンパイラの挙動くらい把握してて当たり前。

> コンパイラの挙動を把握とか言ってる奴は大嘘つきだろ。できるわけがない。

馬鹿はあらゆるアーキテクチャに移植されたgccすべての挙動を把握するとかって話と勘違いしてるんだろう。

837
ナイコンさん[]   投稿日:2016/03/09 22:12:00
>724
お前、大嘘つきだってよw

838
ナイコンさん[sage]   投稿日:2016/03/09 22:14:25
やっぱ貼っとくか。

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
コメント2件

839
ナイコンさん[sage]   投稿日:2016/03/09 22:14:47
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
ナイコンさん[sage]   投稿日:2016/03/09 22:15:19
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
ナイコンさん[sage]   投稿日:2016/03/09 22:17:08
正直、いちいち逆アセしてチェックしないととても業務では恐くて使えないレベルのコンパイラだな、gccは。
あと、 >829 の説明ではよく分らんわ。結局、numを正しく計算できるコードなのかね?

> 最内側のループが定数式に変換
コメント1件

842
ナイコンさん[]   投稿日:2016/03/09 22:19:06
>841
> 正直、いちいち逆アセしてチェックしないととても業務では恐くて使えないレベルのコンパイラだな、gccは。

え? お前、人命が信頼性がどうこう言っててコンパイラの出力コード確認しないの??
コメント1件

843
ナイコンさん[sage]   投稿日:2016/03/09 22:22:11
>842
それは別人だが、おれはMSに完全の信頼を置いてるからな。GNUはライセンスからして胡散臭かろう。ウイルスと変わらん。
コメント1件

844
ナイコンさん[]   投稿日:2016/03/09 22:27:09
>843
> それは別人だが、おれはMSに完全の信頼を置いてるからな。

ああ、自分が使ってるコンパイラの挙動も把握しない>723の素人か。スマン人違いだったか。
コメント1件

845
ナイコンさん[sage]   投稿日:2016/03/09 22:32:43
>844
だからVCは削除しないと言ってるだろう。みんな大嫌いgccのはハミゴコンパイラの挙動を把握してなかっただけだよ。
しかもバージョン違うと最適化処理が全く違うってほんと斜め横の最適化www そりゃJVMもまともに動かないはずだわ。
コメント1件

846
ナイコンさん[]   投稿日:2016/03/09 22:39:16
>845
> だからVCは削除しないと言ってるだろう。
>741
>749
コメント1件

847
ナイコンさん[sage]   投稿日:2016/03/09 22:41:52
>846

>740 のソースね。

848
ナイコンさん[]   投稿日:2016/03/09 22:45:10
1重の無駄ループは削除して3重の無駄ループは削除しないって、
そりゃコンパイラの最適化機能がクソダサイだけじゃんw

849
ナイコンさん[sage]   投稿日:2016/03/09 22:47:23
川俣晶って人が
「CPUにとって直交性は重要じゃ無い、むしろ無い方が優れてる」
「レジスタ数は少ない方がいい、なぜならサブルーチンを呼ぶときに全レジスタを退避しなければならず、無駄が多くなるから」
って言ってたんだけど、そうなの?
コメント1件

850
ナイコンさん[sage]   投稿日:2016/03/09 22:50:41
サブルーチン呼び出しで全レジスタを退避なんて普通はしない。
全レジスタの退避/復帰が問題になるのは普通はコンテキスト切り替えの場合。

851
ナイコンさん[]   投稿日:2016/03/09 23:33:29
>849
サブルーチン自身が使う(壊す)分のレジスタだけ退避すれば良いけど、
片っ端から変数をレジスタに割り当てまくるとかして、
全部使い切ちゃうなら、当然全部退避しなければならなくなるね。
コメント1件

852
ナイコンさん[sage]   投稿日:2016/03/10 00:12:14
>851
>全部使い切ちゃうなら、当然全部退避しなければならなくなるね。

お前はちょっと↓でも読んで勉強するべき。
https://en.wikipedia.org/wiki/Calling_convention
https://en.wikipedia.org/wiki/X86_calling_conventions
コメント2件

853
ナイコンさん[]   投稿日:2016/03/10 01:19:18
>852
よく分からないな。どこが間違ってるか言ってくれ。

854
ナイコンさん[]   投稿日:2016/03/10 04:37:02
gcc使うなんてwww

855
ナイコンさん[]   投稿日:2016/03/10 04:39:39
>852
お前こそ日本語の勉強しろよ・・

856
ナイコンさん[]   投稿日:2016/03/10 06:44:07
レベル低いな、お前ら。
日本のプログラマーの95%がゴミクズって言われるのが良く判るわ。

857
ナイコンさん[]   投稿日:2016/03/10 06:48:55
と無職が申しております

858
ナイコンさん[]   投稿日:2016/03/10 07:32:54
偏屈無職祭り

859
ナイコンさん[]   投稿日:2016/03/10 07:52:11
実際、無職にまでバカにされるレベルだから仕方ない。
使い物にねらねーのばっかだし。

860
ナイコンさん[]   投稿日:2016/03/10 10:03:12
> 人の命預かるシステムを軽く見るんじゃねぇよド素人が。

ワラw

861
ナイコンさん[]   投稿日:2016/03/10 10:26:44
リコールとか多いしな。
どんだけ全体のレベル下がってんだってな。
エアバックとか、エンストとか信じられん。

862
ナイコンさん[]   投稿日:2016/03/10 12:57:04
98%は居る意味ゴミだから、日本人のプログラマは。

863
ナイコンさん[sage]   投稿日:2016/03/10 22:00:52
以前のArduino 11秒
Arduino IDE 1.0.5 44秒
Arduino IDE 1.6.7 1秒未満

gccの品質は全く安定してないな。恐くて使えないわ。

864
ナイコンさん[sage]   投稿日:2016/03/10 22:18:09
以前のArduino 11秒
Arduino IDE 1.0.5 44秒

↑と↓でボードが違うことも理解できない池沼かな?

Arduino IDE 1.6.7 1秒未満
コメント1件

865
ナイコンさん[sage]   投稿日:2016/03/10 22:37:36
>864
同じだが。

866
ナイコンさん[]   投稿日:2016/03/10 22:41:15
最適化オプションが違うんだろうな。Arduino IDEってその辺隠されてた気がするし。

867
ナイコンさん[]   投稿日:2016/03/10 22:42:25
VCって3重の無駄ループは削除できないってマジ??

868
ナイコンさん[sage]   投稿日:2016/03/10 23:17:15
avrも随分とクセがあるな。 >838-840
即値加算がなくて、unsinged longなのに負値にして引き算とか、
+1するだけなのに、incでキャリが動かんから、FF引き算したり、大変だなw
あちらこちらで r1 使ってるのも0固定でしょ?

869
ナイコンさん[sage]   投稿日:2016/03/11 03:53:37
r1はr1:r0レジスタペアにして8Bit乗算命令の上位結果をストアするのに
使われるから0レジスタと言うわけでは無いと思うけど。
>838-840を見ると即値が第1バイトに下位4Bit,第2バイトに上位4Bitが
入っているのがはっきり判るな。
おそらくレジスタ指定フィールドに分割して入れているんだろうね。

870
ナイコンさん[sage]   投稿日:2016/03/11 04:10:15
r1を0に設定して使ってないという意味ではないので。
cpcがおそらくキャリー付き比較命令だと思えるが特異かなと。
x86あたりだと比較−条件分岐を上位から順に4個並べてしまうからね。

871
ナイコンさん[sage]   投稿日:2016/03/12 21:14:20
RISCのアセンブラは平易に書くと性能でないとか昔どこかに書いてあったけど
最近は良くなったのだろうか最適化

872
ナイコンさん[sage]   投稿日:2016/03/12 22:13:19
x86のバイナリが汚いと言ってた馬鹿がいかに浅はかかが分る。

873
ナイコンさん[sage]   投稿日:2016/03/12 22:53:19
性能と汚いかどうかは別の話だし、x86のバイナリが汚いのは誰もが認める事実だしな。

874
ナイコンさん[sage]   投稿日:2016/03/12 23:39:16
綺麗にすると性能が落ちる。これは既に分かってること。

875
ナイコンさん[sage]   投稿日:2016/03/13 05:41:44
そもそも今時バイナリなんて見ないし

876
ナイコンさん[sage]   投稿日:2016/03/13 11:00:47
x86のアセンブラは短く書くと速くなるとかどこかに書いてあった

877
ナイコンさん[sage]   投稿日:2016/03/13 12:34:13
日本のソフトウェア技術が如何に低いかがわかるスレ

878
ナイコンさん[]   投稿日:2016/03/13 15:18:42
便所の落書きにレベル云々が間違ってんぜ

879
ナイコンさん[]   投稿日:2016/03/13 18:59:09
言ってる本人が馬鹿で頑固で使い物になんねー無職って所が笑う所?

880
ナイコンさん[sage]   投稿日:2016/03/13 20:01:39
RISC派がなぜ負けたのか未だ理解してなくて笑えるw
コメント1件

881
ナイコンさん[sage]   投稿日:2016/03/14 00:43:14
多様なアドレッシングのほうがスループットを上げやすい。

882
ナイコンさん[]   投稿日:2016/03/14 06:26:16
x86以外にRISCより速いのってあるのか?

883
ナイコンさん[sage]   投稿日:2016/03/14 06:46:05
処理性能/消費電力という指標でいえばarmはX86を上回るという話。
万個なマルチCPUスパコン作るならarmということらしい。

alchimedesの末裔の64bit-ARMがintelキラー。胸熱だね。
コメント1件

884
ナイコンさん[sage]   投稿日:2016/03/14 06:47:50
alchimedes >> Acorn Archimedes

885
ナイコンさん[sage]   投稿日:2016/03/14 07:06:16
理研のスパコン京の後継機にARMプロセッサをという案があるみたいだから
パフォーマンスを出せればスパコンのx86からARMへのシフトが増えるかも。

886
ナイコンさん[sage]   投稿日:2016/03/14 07:15:19
>883
まじか。ソースくれ。

887
ナイコンさん[sage]   投稿日:2016/03/14 07:35:48
F1と軽自動車を比べて軽のほうが燃費がいいと自慢してるようなものだな。
そういうコンセプトで設計されてるにすぎない。同じモバイル向けでもノートPC向けとスマホ向けはまた違ってくるだろう。

888
ナイコンさん[sage]   投稿日:2016/03/14 10:10:07
処理性能/消費電力という指標は、プロセスルールやクロックで消費電力変わるから、
アーキテクチャの指標としてはかなり不適切だな。

889
ナイコンさん[sage]   投稿日:2016/03/14 12:21:01
x86からARMへパラダイム・シフトは現在進行形だよね。
移行組の主力はApple。iPhone/iPadだけなく、Macintoshも近々
3度目のCPUアーキテクチュア変更するらしいね。今度はARM。
しかも自社設計のCPUコア。開発用の言語ソフトウェアも
powered gcc からclang-Swift/llvmへとすでに移行しつつあるし。

MSもWindowsRTとかで準備しているんじゃないの?ってこっちは
コンペチばかりの未踏領域だからMSが成功するかは未知数。

http://itstrike.biz/apple/mac/15831/

890
ナイコンさん[sage]   投稿日:2016/03/14 12:25:41
Z80 → 80186 → 68000(及び系列) → intelのなんだっけ?(とPowerPC@ゲーム機) → ARM … って感じかな

891
ナイコンさん[sage]   投稿日:2016/03/14 12:28:33
ARMコアとx86コアを同等に扱うAMDのCPU戦略
http://pc.watch.impress.co.jp/docs/column/kaigai/20140730_660030.html

892
ナイコンさん[sage]   投稿日:2016/03/14 13:01:18
RTは既に失敗したんですが。

893
ナイコンさん[sage]   投稿日:2016/03/14 16:47:17
32bitもエミュレーションだからな
x86に拘る必要がない

894
ナイコンさん[]   投稿日:2016/03/14 17:41:04
x86一強の時代が終わるか。
行き詰まりに来てるしなx86。

895
ナイコンさん[sage]   投稿日:2016/03/14 17:54:23
ノイマン型が終わって早く新世代のコンピュータが登場して欲しい。

896
ナイコンさん[sage]   投稿日:2016/03/14 21:55:35
ARMって 1clock当たりじゃx86の1/4程度の性能なのにデスクトップ、サーバ部門で勝てるのか。
Appleはパクるのは得意だけど、Appleが注力して開発するとほとんど失敗してるぞ。
コメント1件

897
ナイコンさん[sage]   投稿日:2016/03/14 23:07:42
アーキテクチャーの優劣なんて誤差レベル。
最先端のファブで作ったプロセッサーが、最強の性能と省電力性を誇るってのが、現状での結論ではないのか。

898
ナイコンさん[sage]   投稿日:2016/03/14 23:14:03
素人はものごとを自分の理解できる単純な話にしたがるから馬鹿なんだよ。

899
ナイコンさん[sage]   投稿日:2016/03/14 23:41:20
インテルは省電力のために電圧レギュレータすらCPU内に取り込んでるというのに。

900
ナイコンさん[]   投稿日:2016/03/15 02:16:11
んな無理して延命しないでさっさと逝ってほしい
LLVM上でx86エミュとかサクサク動いてたらいいな

901
ナイコンさん[]   投稿日:2016/03/15 02:24:52
>880
往生際が悪いのが生きのこる秘訣ですね

902
ナイコンさん[]   投稿日:2016/03/15 04:26:38
Itaniumの二の舞になったりしてなー

903
ナイコンさん[]   投稿日:2016/03/15 05:55:47
ARMがインテルを倒す?
20年位かかるな。

904
ナイコンさん[sage]   投稿日:2016/03/15 06:16:23
>896
1クロック当たりで比べても優劣付かないだろ。

クロック当たりの処理を単純化すれば、
周波数上げやすい
ゲート規模を小さく出来る
パイプラインや、キャッシュ組みやすい
コメント1件


905
ナイコンさん[]   投稿日:2016/03/15 06:36:20
チカラワザで高クロックで動いてるx86に勝ててるARMがどれぐらいあるの?
同じ周波数ならx86のが処理能力高いんでしょ?

906
ナイコンさん[sage]   投稿日:2016/03/15 07:16:02
RISC勢の台頭がx86のCRISC化を、互換CPUとの競合がx86の強化を進めたように
ARMとの対抗がx86の新たな進化を生み出すのならばいいのだけどね。
まあ単純に消費電力の軽減という方向に行くならば面白みはないが。

907
ナイコンさん[]   投稿日:2016/03/15 07:56:35
ARMがx86超えるのは当分有りそうにないのか。
コメント1件

908
ナイコンさん[sage]   投稿日:2016/03/15 09:39:43
>904
20年前の知識だなw この板だから許されるだけでw

909
ナイコンさん[]   投稿日:2016/03/15 12:09:56
危機感もったインテルがARM買収で潰しにかかる、とか外道やらずに真っ正面からぶつかる方が未来は明るい。
コメント2件

910
ナイコンさん[sage]   投稿日:2016/03/15 12:22:58
一世を風靡したxscaleは手放しちゃったじゃん

911
ナイコンさん[]   投稿日:2016/03/15 12:29:18
デスクトップやサーバーでARMがx86に代わる日は来ないよ。
絶対的に非力すぎる。
コメント1件

912
ナイコンさん[sage]   投稿日:2016/03/15 12:39:57
>909
Intelの利益の源泉は特許独占。セカンドソース拒絶。独禁法的に合法だが極悪w
Armの利益の源泉はオープン・セカンド・ソースで無制限許諾なライセンス。
intelの技術革新はIntel一社の単独努力によるオナニーマスター井のベーション。
Armの技術革新はオープンマーケットで参加各社競合競争状態な乱痴気お祭りショー

観ている分には乱痴気騒ぎの方が面白そうだな。

913
ナイコンさん[sage]   投稿日:2016/03/15 12:46:35
>911
かつてDECのオルセンもそんなこと言ってcpuのLSI化を拒んだが倒産。
Intelはムーアの法則でDECを蹴散らしたが、ムーアの法則の限界行き詰まりで停滞。
足踏みしたまんまのウサギは亀に追い抜かれるものだ。

914
ナイコンさん[sage]   投稿日:2016/03/15 13:06:35
ん? DECがAlphaやってた頃はインテルよりパフォーマンス上だったろ。
その後コンパックに買われたのはAlphaが原因ではないだろうし。何言いたいんだかわからんな。
コメント1件

915
ナイコンさん[sage]   投稿日:2016/03/15 15:23:53
さらに買収したhpも今ヤバイんだっけ。

916
ナイコンさん[sage]   投稿日:2016/03/15 17:27:21
>909
かつてAMDとクロック競争をやってた時にIntelはNetBurstアーキテクチャに走って
Prescott以降の爆熱CPUを生み出してしまった過去があるから道を誤る危険性も。

>907,911
ARM社の主張ではハイエンドのCortex-A72でIntelと戦えるとのことだが。
まあ実機が出てきてみないと実際のところはわからないけどね。

917
ナイコンさん[sage]   投稿日:2016/03/15 18:26:04
>914
アルファの登場って92年頃でしょ確か。関ヶ原に遅刻到着した徳川家忠みたいなもん。手遅れ。
486/66とかWIN3.1の頃で特許係争明けのAMDもパソコン市場参戦してきた頃。PCの隆盛に
飲み込まれるようににWSベンチャーは軒並み倒産とか買収で姿消してATARIも倒産
commodoreも虫の息。コンパックに吸収されたのが96年か。Intelのロードマップ商売が
華々しく輝いていた頃だな。

オルセンが叩かれたのは80年代初頭までVAXのLSI化を計画推進する頭がなかった事。386が
リリースされた80年代中頃ダウンサイジングという考え方が流行りだした頃に8600/8800とかの
売価億単位なメインフレーマを目指して逆噴射じゃねとか。同時期アルファのまえのmicorVAX
でとりあえずLSI化はしたけど低速非力で評価ガタ落ち。そんな感じ。半導体技術が大躍進した
80年代に無策無作為を続けた結果。企業消滅。

918
ナイコンさん[sage]   投稿日:2016/03/15 18:38:02
Alphaの魂はAthlon・OpteronになってIntelを苦しめた
コメント1件

919
ナイコンさん[sage]   投稿日:2016/03/15 18:38:32
LSI化されたMicroVAXが1984年だが80386よりは先行してたし

>オルセンが叩かれたのは80年代初頭までVAXのLSI化を計画推進する頭がなかった事。

というのは事実と違うのでは。

920
ナイコンさん[sage]   投稿日:2016/03/15 18:50:12
>918
AMDが手に入れたAlphaの技術はEV6バスだけだろ。
Alpha自身はCompaqを経てIntelに知的資産が移った。
コメント1件

921
ナイコンさん[sage]   投稿日:2016/03/15 19:02:05
>920
バスとエンジニア

922
ナイコンさん[]   投稿日:2016/03/15 19:41:22
インテルに追い付けるかも知れない。
だけど追い抜くのは無理ゲーだな。

923
ナイコンさん[sage]   投稿日:2016/03/15 21:29:09
インテルはPCのマーケットのでかさで莫大な研究開発コストを捻出できてたんだし、
今後のPCのマーケットの縮小次第によってはどうなるかわからんと思う。

924
ナイコンさん[]   投稿日:2016/03/15 22:28:12
DECは高価格帯向けだったからSGIと一緒に低価格帯PCに負けて敗退したんだろう

925
ナイコンさん[]   投稿日:2016/03/16 00:42:55
ARMの64bitなら同クロックのC2D並らしいじゃんもうちょいだね

926
ナイコンさん[sage]   投稿日:2016/03/16 00:59:01
http://arstechnica.com/gadgets/2015/04/arm-details-its-new-high-end-...

Cortex A72とインテルのCore Mってのと比べてるけどこれ http://ark.intel.com/ja/products/85234/Intel-Core-M-5Y10c-Processo... タブレット用だな。C2D相当はまだ先じゃね。

927
ナイコンさん[]   投稿日:2016/03/16 01:46:24
インテル4W ARM 1W未満 性能はどっこい省電力は圧勝だな

928
ナイコンさん[sage]   投稿日:2016/03/16 01:57:04
性能/消費電力でインテルは勝負できないよ。あんな薄利多売したら、微細化投資の金が捻出できない。
つまりインテルがコケたら、セミコン業界がコケる。Appleが儲けたら、メモリや液晶メーカーが傾いたみたいに。

929
ナイコンさん[]   投稿日:2016/03/16 02:12:13
ああ98がこけたら日本の半導体産業もアボンしたみたいな嫌な連鎖はあるかもね
でもまあシリコン半導体の進歩も限界だし逝っていいんじゃないでしょうかね

930
ナイコンさん[sage]   投稿日:2016/03/16 08:27:46
PCの出荷台数はここ4年連続で減少している。という話なのでこういう状態がずっと続けば
巨額投資に見合う収益が減り続け借入金返済や新規投資は徐々に難しくなるかもね。
Intelがあのシャープほど債務を抱えるとは思わないが、盛者必衰の理発動で、終わるかもね。

931
ナイコンさん[]   投稿日:2016/03/16 10:44:12
市場的なブレイクスルーなければパソコンは終わるか。
かつてのワークステーションが消えたようにタブレットやスマホに押されて消えるのかね。

932
ナイコンさん[sage]   投稿日:2016/03/16 11:37:13
消える事は無いよ
タブレットのソフトウェアキーボードでプログラミングや文章作成とか有りえん
家電量販店での売り場スペースが減るだけだろう
コメント2件

933
ナイコンさん[sage]   投稿日:2016/03/16 11:40:18
>932
プログラムや文章作成の時だけブルートゥース接続のキーボードでいいんじゃ?

934
ナイコンさん[]   投稿日:2016/03/16 12:29:00
>932
ウチの会社、Amazonクラウドに開発環境置いてノートで開発とかやってんだわ。
社外での応急的な処置だけどね。
その延長でタブレットで、というのも考えてる。
パソコンだけでクローズしてる開発なら置き換え可能だとおもうぞ。

935
ナイコンさん[]   投稿日:2016/03/16 13:52:09
うちは個人開発でdropboxにソース上げてクラウドごっこしてるが
スマホの入力補完が効いて案外便利必要記号もテンキーに載ってるし
猿みたいにキー叩くことは稀で思考してるほうが多いから問題ない

936
ナイコンさん[]   投稿日:2016/03/16 18:52:21
シンクライアントからファットクライアントへの揺り戻しが来るまで持ちこたえたらインテルにも目はある。

937
ナイコンさん[]   投稿日:2016/03/18 08:09:25
Winタブしかインテルの生き残る道は無いだろ。

938
ナイコンさん[sage]   投稿日:2016/03/18 12:05:34
インテルは製造技術だけでも抜きん出てるからARMが天下取ったとしても生きていけるだろ

939
ナイコンさん[sage]   投稿日:2016/03/18 13:02:59
売れる半導体商品がある内はだね。日本の半導体産業の歴史を思えば、
半導体業界で生き残るのは至極の技だという事がわかるはず。
特にCPUとメモリは描線技術を最先端で維持できないと、競争脱落は必至。
血を吐きながら続けるマラソンのようなもの。振り返れば脱落死企業の屍あまた。

940
ナイコンさん[sage]   投稿日:2016/03/18 13:14:32
インテルがXScale捨てたのはx86と心中する覚悟なのかなあ?
インテル最新の製造技術で作られたARMプロセッサてのも見てみたい気はするが。

941
ナイコンさん[sage]   投稿日:2016/03/18 13:29:17
日本のセミコン業界はデフレ円高政策で自民が潰しただけで歴史として参考にはならない。

942
ナイコンさん[sage]   投稿日:2016/03/18 14:34:50
×自民
○民主
コメント2件

943
ナイコンさん[sage]   投稿日:2016/03/18 14:42:12
>942
ネトウヨってほんと馬鹿だなw

944
ナイコンさん[sage]   投稿日:2016/03/18 14:44:35
チョンw

945
ナイコンさん[sage]   投稿日:2016/03/18 14:50:41
>942
為替チャート見ろ、馬鹿www

946
ナイコンさん[sage]   投稿日:2016/03/18 15:04:53
おまえこそ、2009ー2012年の為替推移を他の時代と比較して見ろ。バカ
エルピーダを潰したのは民主・白川日銀は定説。

947
ナイコンさん[sage]   投稿日:2016/03/18 15:09:22
これがネトウヨか。半端ない馬鹿だなw
そもそもデフレ時に金融引締め始めたの安倍だろう。
コメント1件

948
ナイコンさん[sage]   投稿日:2016/03/18 15:37:15
>947
安倍というより、独自裁量の日銀な。安倍一次を潰したのは日銀。
民主の罪は超円高を無策のまま誘導放置し続けたことは通説。

949
ナイコンさん[]   投稿日:2016/03/18 17:48:01
市民の視線からの失敗は、ミンシュの成功だから仕方ないよね。

950
ナイコンさん[]   投稿日:2016/03/18 19:14:43
高い国産半導体で出来てた98がコケたら他も全部全部コケたんだよ
中台韓AT互換機が日本製を採用する必要もないしな
コメント1件

951
ナイコンさん[sage]   投稿日:2016/03/18 21:39:51
9801で使用されていた半導体って外国製がすげー多い。
CPUが日本製なのはvm2まで。それ以降は全てIntel製
国産デバイスって漢ROMとメモリGDCくらいなものだろう。
スーパー301の標的だったし。ある意味典型的な売国パソコン。
コメント1件

952
ナイコンさん[sage]   投稿日:2016/03/18 21:43:39
アメリカよりも韓国や台湾がシリコンウェハーや製造装置を内製に切り替えてここ数年で急速にシェアを失いつつあるな

953
ナイコンさん[sage]   投稿日:2016/03/18 21:53:38
>951
9801って何の面白みもないゴミみたいな作りのパソコンだったな。
コメント1件

954
ナイコンさん[sage]   投稿日:2016/03/18 21:55:22
vx2で80286を採用決定したのは米国商務省の貿易摩擦圧力があったから。
痛3にほだされた関本の鶴の一声で決定。同時にNECオリジナルのVシリーズは終了。
玉川矢向電子デバイスのエンジニアは泣いていた。もう一つオマケでVシリーズ標準に
なるはずだったTRON-OSも出る芽がなくなった。米国商務省側のロビイストの親玉は
Intel創業者のロバートノイス。Intel-j社内ではドクターノイスと呼ばれていて尊敬の対象
だった。一度お目にかかったことあるが、細身で眼光鋭いインテリ・ヤクザ。彼ほど
日本の半導体会社を脅しに回った玄人もいない。なにせプレーナー特許保持者だからね。

三菱も富士通も8086作っていたがIntelの訴訟が怖くて製品に乗せることなかった。
NECは訴訟起こされ和解。NEC製の8087は結局市場で日の目を見なかった。

955
ナイコンさん[sage]   投稿日:2016/03/18 22:54:38
>950
あのときもドル円が140円以上から90円台まで円高が進んだんだよな。
98が10万割るとか考えもしなかったわ。

956
ナイコンさん[sage]   投稿日:2016/03/18 23:03:30
いつの話?

957
ナイコンさん[]   投稿日:2016/03/18 23:03:31
>漢ROMとメモリGDCくらいなものだろう。

マザボの主要機能大方じゃん電源やら拡張ボード周辺機器やらもで
国産半導体の天下だった

958
ナイコンさん[sage]   投稿日:2016/03/18 23:12:07
売りは漢字テキストVRAMなんだけど。漢字ROMなんて8bitPCでも載ってたから。
コメント1件

959
ナイコンさん[sage]   投稿日:2016/03/18 23:28:18
>958
初代9801は漢字ROMは別売りオプションだったけどな。

960
ナイコンさん[]   投稿日:2016/03/19 03:56:17
>953
他の日本のメーカーはその「ゴミみたいな」パソコン以下のクズしか作れなかったんだよねwww

961
ナイコンさん[sage]   投稿日:2016/03/19 08:28:58
ゴミ以下のクズがはしゃいでるなぁ……

962
ナイコンさん[sage]   投稿日:2016/03/19 09:08:04
98が素晴らしかったはのx86を採用したからだ。
68kを採用してたから国民機になったはFM-TOWNSだったろう。
コメント1件

963
ナイコンさん[sage]   投稿日:2016/03/19 09:28:43
>962
日立じゃあるまいし、98が68Kを採用することはあり得なかった。
ただし8086/V30系からV60/70へ転換するロードマップはあった。
DOSは86互換だけで286/386へ行くはずではなかった。
コメント2件

964
ナイコンさん[sage]   投稿日:2016/03/19 09:33:01
NEC も EWS では 68K 使ってたんだが...

965
ナイコンさん[sage]   投稿日:2016/03/19 10:49:56
>963
V60の出荷は1986年だが既に85年に286を搭載したハイレゾ系のXAを
出荷しているからそのロードマップには疑問がある。
ちなみにV60自身はPC-UX用にPC9801-32という型番の拡張ボードで
販売された。

966
ナイコンさん[sage]   投稿日:2016/03/19 11:16:57
ロードマップの話は84年ごろV60/70の設計管理者のM氏とその周辺から直に聴いた話。
286のIntelのプレゼンは82年に聴きに行った。古い話だ。

967
ナイコンさん[]   投稿日:2016/03/19 16:49:29
シャープはX68030出すのが遅すぎ、92年とかもう時代はDOS/V+Windows目前の、最後のあがきレベルに遅いわ。
信者レベルのユーザーでなきゃ正直「ふ〜ん」とか「もうイラネ」の時代だよ。
コメント1件

968
ナイコンさん[]   投稿日:2016/03/19 16:58:48
NECは烏合の衆というか寄り合い所帯みたいなモンだからなー・・・
パソコンとワークステーションが足並み揃わないのも当然で・・・
別組織が開発して、それぞれが別の工場に作ってクレーとお願いしてるわけで、販路も別だったし・・・

969
ナイコンさん[]   投稿日:2016/03/19 17:51:20
>963
関本がアホだったのさ。
コメント1件

970
ナイコンさん[sage]   投稿日:2016/03/19 18:22:17
>967
自ら5年間仕様変更しないという縛りをかけたからなぁ。
開発者達はDog Yearという単語を知らなかったのだろうか。

971
ナイコンさん[sage]   投稿日:2016/03/19 18:33:13
V30は286の半分の速度しかない。
V33で速度だけは286並だったが、メモリ空間は8086並の1Mバイトしか無い。
メインメモリが高速で無いとV33の高速性を発揮できない縛りもある。

98がVシリーズを捨ててインテルを選んだのは圧力ではなく必然だろう。
V60、70、80を積んだ国産OSマシンなんて誰も欲しがらんしな。
コメント1件

972
ナイコンさん[sage]   投稿日:2016/03/19 20:23:43
>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年だったなと思うね。

長文ですまん
コメント1件

973
ナイコンさん[sage]   投稿日:2016/03/19 21:06:20
>969
そそ。関本はアホ。というか、286の採用は大阪城の堀埋めのようなもの。
Vシリーズが真田丸に相当するなら、関本は内外堀埋め承認の大野治長というところか。
Intelは国家安康とかで無理なイチャモン恫喝して天下を奪取した家康みたいな狡猾な狸。

ま、その後98は金儲けの種となって三田のタワーの原資になったけれどもね。今は昔。
コメント1件

974
ナイコンさん[sage]   投稿日:2016/03/20 07:35:20
>972
日米半導体摩擦時の外国産シェア目標は30%ではなく20%だったはず。
1992年になんとか目標値をクリアさせた。
コメント1件

975
ナイコンさん[sage]   投稿日:2016/03/20 07:42:43
ついでにWindows 3.1の286対応に関して9801版及びDOS/V版については正しいが
米国PC/AT版は普通に対応していた。

976
ナイコンさん[sage]   投稿日:2016/03/20 08:19:15
>974
↓の論文に詳細があるね。20%強。

日米半導体摩擦における 「数値目標」 形成過程
https://www.jstage.jst.go.jp/article/nenpouseijigaku1953/48/0/48_0_155/_pd...

977
ナイコンさん[]   投稿日:2016/03/20 08:25:15
インテルといいクァルコムといい、黒船からずっとアメリカはやること外道だな。

978
ナイコンさん[sage]   投稿日:2016/03/20 10:08:51
NTは286でも対応していたよね?3だか3.5までだったと思う。
勿論日本語版は否対象だったけどね。

979
ナイコンさん[sage]   投稿日:2016/03/20 10:54:17
NTは32bitOSだから最初から386以降必須で、286には対応してないよ。

980
ナイコンさん[sage]   投稿日:2016/03/20 11:34:39
:::::::::::/           ヽ::::::::::::
:::::::::::|  ば  じ  き  i::::::::::::
:::::::::::.ゝ か   つ   み  ノ:::::::::::
:::::::::::/  だ  に  は イ:::::::::::::
:::::  |  な。       ゙i  ::::::
   \_         ,,-'
――--、..,ヽ__  _,,-''
:::::::,-‐、,‐、ヽ. )ノ      _,,...-
:::::_|/ 。|。ヽ|-i、      ∠_:::::::::
/. ` ' ● ' ニ 、     ,-、ヽ|:::::::::
ニ __l___ノ     |・ | |, -、::
/ ̄ _  | i     ゚r ー'  6 |::
|( ̄`'  )/ / ,..    i     '-
`ー---―' / '(__ )   ヽ 、     >973
====( i)==::::/      ,/ニニニ
:/     ヽ:::i       /;;;;;;;;;;;;;;;;

981
ナイコンさん[]   投稿日:2016/03/20 11:36:55
NTはRISC版が286をエミュレートしてWin16アプリ動かすことができたから情報が交錯したんじゃないのけ?

982
ナイコンさん[]   投稿日:2016/03/20 12:14:27
日本は今でもアメリカの属国だし。
ホワイトハウスから来る紙切れ1枚の命令に従うしかないのが現実だから。

983
ナイコンさん[]   投稿日:2016/03/20 12:28:36
半導体と自動車で自動車を選び、
半導体もCPUとメモリでメモリを選び、
そういう選択の結果だからね、仕方ないね。

984
ナイコンさん[sage]   投稿日:2016/03/20 12:41:48
1980年代を通して半導体売上ランキング第一位は日本電気だった。
半導体貿易摩擦で大騒ぎした直後の1987年でさえIntelは第10位。弱小企業だった。
それが1992年に日本電気を抜いて1位。大躍進。
たった5年で訴訟ヤクザ企業Intelが本懐遂げたというわけだ。トランプ怖いw

半導体売上ランキング
https://ja.m.wikipedia.org/wiki/半導体メーカー売上高ランキング

985
ナイコンさん[sage]   投稿日:2016/03/20 13:11:18
ヤクザも何も、
勝手に海賊版CPUを製造・販売してて、
内部のマイクロコードを盗用してたのはNECじゃないかと。

986
ナイコンさん[sage]   投稿日:2016/03/20 13:18:12
最終判決は盗用してないだったけど
更新情報
・スレッド一覧ページで過去ログのタイトル検索・一覧表示ができるようになりました(2016/1/20)
NGワード登録
登録する
スレッド内検索

昔のPC板 タイトル検索

このスレッドが人気です(実況系)
第99回全国高校野球選手権大会 第9日★198 (730)NHK実況
ほぼほぼライブ ミヤネ★3 (647)NTV実況
NHK総合を常に実況し続けるスレ 136918 (820)NHK実況
朝鮮ライブパチンコ屋★3 (391)NTV実況
[再]コード・ブルードクターヘリ緊急救命 #10 (229)フジ実況
実況 ◆ TBSテレビ 28283 (894)TBS実況
実況 ◆ テレビ朝日 48885 カイトくん (177)テレ朝実況
実況 ◆ フジテレビ 84151 (827)フジ実況
このスレッドが人気です(ニュース系)
【芸能】ウーマン村本「愛国心って言うなら愛するに足る国になれ」「国のために死を覚悟してる人がいることにゾッとした」★4 (565)音楽・芸能ニュース
【芸能】ウーマン村本「愛国心って言うなら愛するに足る国になれ」「国のために死を覚悟してる人がいることにゾッとした」★3 (1001)音楽・芸能ニュース
【ネット】「牛乳石鹸」広告が炎上、「もう買わない」の声 「意味不明」「ただただ不快」批判殺到 制作意図は答えず★6 (375)ニュー速+
【ネット】「牛乳石鹸」広告が炎上、「もう買わない」の声 「意味不明」「ただただ不快」批判殺到 制作意図は答えず★5 (1001)ニュー速+
【芸能】ウーマン村本「愛国心って言うなら愛するに足る国になれ」「国のために死を覚悟してる人がいることにゾッとした」★2 (1002)音楽・芸能ニュース
【詐欺師】YouTuberヒカルがインサイダー疑惑で炎上 疑似株式サービスVALU(バリュー) ★14 (796)音楽・芸能ニュース
【個人価値売買売り逃げ】YouTuberヒカルらの「VALU」大量売却問題、運営会社「新たなルール作る」 (1001)ニュー速+
【悲報】中国で日本人の新たな蔑称「韓人那」広がる その意味は韓国人の偽物 (27)ニュー速
昔のPC板の人気スレ
パソコンミニ ネクスト次章[レトロパソコンモドキ] (579)
【クリーン】MZ-80K/C/1200シリーズ part4【アルゴ号】 (515)
こうやま Part.2 (89)
PC-8801mkII SR以降 Part23 (179)
2017: DarkGDKを極めるスレ (821)
PC-9821/9801スレッド Part81 (101)
X1/turbo/Z 総合スレ21 (117)
PCエミュレーター統合スレッド Part8 (542)
栄光のPC-8001 Ver 1.5 Copyright 1979 (C) by (ry (824)
【懐古趣味】ワンボードマイコン総合スレ 第二章 (969)
MSXスレッド Part 46【安全】 (924)
今でもX680x0ユーザー全員集合 Part 73 (124)
68k v.s. x86 Round 2 (986)
夢を叶えた俺らのPC-8801mkII SR以降 Part23 (505)
MSXスレッド Part 46 (739)
橋本環奈について語る (567)
FMシリーズを語るスレ Part 14 (774)
PCエミュレータの決定版 和製MESS Part.2 (923)
OSと言えばコレでしょ!CP/Mスレ ver.3 (919)
68k v.s. x86 Round 4 (322)
8086 vs. Z80 vs. 6809 vs. 6502 その13 (235)
スプライト 3本目 (952)
愛と幻想のHP200LX -Part12- (997)
栄光の30年 疾走する知性 聖女東瑠利子の世界  (605)
☆198X年ソフトレンタルショップがあった場所★ (325)
EPSON 98互換機 Part5 (746)
【富士通】FM TOWNS 18代目【FUJITSU】 (70)
パピコンと間違えてPHC-25買っちゃった奴の数→ (770)
8ビットCPUでC言語?ないないありえないっしょ!Part2 (480)
PC-8001mk2SRってどうよ その2 (920)
このサイトについて
このサイトは2ちゃんねるからデータを取得し、表示するサービスです。
画像のインライン表示機能について
画像のURLの後ろにある[画像をインライン表示]をクリックすると、URLの下に表示します。
表示される画像は横幅100pxに縮小されていて、クリックすると原寸で表示します。
このサイトの特徴
1)スレッド内検索ができます
2)レス(「>>1」など)のポップアップができます
3)不適切な言葉を含む投稿を表示しません
4)ページ内で画像を直接表示できます
5)2ch他スレッドへのリンクはタイトル・板名つきでリンクします
6)すっきりとしたデザインで表示します
7)最新スレや前スレをチェック・一覧表示します
8)NGワード機能の搭載でイヤな言葉が目に入りません
9)荒らしを自動チェックします
10)スレッド内・同一IDの書き込みだけ表示できます
11)レスの返事をレスされた発言の下に表示する「まとめビュー」が利用できます
12)シリーズ化したスレッドの一覧を表示します
13)最新のスレッドがある場合はお知らせします
削除について
こちらをご覧ください
機能要望について
現在機能要望受付中です。
問い合わせについて
こちらのページからどうぞ
広告


首都圏の方、ソフトバンク光オススメですよ


このサイトは2ch.scからデータを取得・表示しています。削除などについてはこちらをご覧ください。 アクセスモード:差分取得 - 新着書き込みなし(304)