8ビットCPUでC言語? ないないありえないっしょ! 3

1ナイコンさん2018/06/07(木) 00:31:12.73
【前スレ】
8ビットCPUでC言語? ないないありえないっしょ! [無断転載禁止]©2ch.net

Part.2 http://matsuri.5ch.net/test/read.cgi/i4004/1470913460/
Part.1 http://hanabi.2ch.net/test/read.cgi/i4004/1468652612/

     ♪    /.i   /.i  /.i
   ♪     ∠__ノ ∠__ノ ∠__ノ   
        〈,(・∀・;)ノ・∀・;)ノ・∀・;)ノ
         └i===|┘i===|┘.i===|┘  
           〈__〈 〈__〈 〈__〈

2ナイコンさん2018/06/07(木) 00:36:17.27
8ビットCPUでC言語? ないないありえないっしょ! 3
http://matsuri.5ch.net/test/read.cgi/i4004/1528299072/

次スレ立てる場合はスレタイ同一がお約束。なんでここは派生スレね。
以後、テキトーにどうぞ。

3ナイコンさん2018/06/07(木) 00:45:33.28
なんでここは派生スレね → なんでここが次スレね

4ナイコンさん2018/06/07(木) 02:03:07.80
『信長の野望・全国版』...前作『信長の野望』はBASIC言語で作られていたが、本作はC言語で開発された。
https://ja.wikipedia.org/wiki/信長の野望・全国版

ということなので、88版のDISK IMAGEから文字列をバイナリエディタで舐めてみた。容量552AF。
有意な文字列ほとんど無いが僅かながら"DISK I/O ERROR"みたいなエラーメッセージが24H($)で区切られて
いるので基本はたぶんCP/Mベースだろう。CP/MのOSファイルは無い。実際のところDOS自体はオリジナル。
”YDOS Ver2.2(58.5K) 15-Feb-85 I.YODA”というクレジットがある。この文字列は24Hなし。

5ナイコンさん2018/06/07(木) 11:37:40.10
wikipediaは嘘も多いからなんとも言えないけど
88版だと「%s様が病気になりました」なんかの文字列があるね
解析するとメモリの1183h〜あたりがprintfの処理かなぁ
LD HL, n
ADD HL, SP
ってコードが多いのがC言語っぽいけど
IXやIYがあまり使われてなさそうなのがコンパイラっぽく無いとも感じる
引数制限してるかグローバル変数使いまくりなんだろうか

6ナイコンさん2018/06/07(木) 22:47:16.58
88版なら漢字コードがJISかもしれないなぁ。
昔々すぎて詳細忘れたけどN88BASICで漢字のフォントデータ読み出す処理を書いたときにSJIS(N88BASICがSJISなので)からJISに変換したような覚えがなんとなくある。

7ナイコンさん2018/06/07(木) 22:48:12.50
>>6
あ、すまん、%s様が〜ってみえてるのか。
ならSJIS使ってるね。

8ナイコンさん2018/06/07(木) 23:39:37.17
> IXやIYがあまり使われてなさそうなのがコンパイラっぽく無いとも感じる

当時Z80の命令吐くコンパイラがどんだけあったと思ってる?

9ナイコンさん2018/06/08(金) 00:11:13.28
えすぷれっそまっすぃーーん

10ナイコンさん2018/06/08(金) 03:19:58.85
変態実装のprintf()はいくらメモリ食うと思ってんだ。
DOS時代でさえputs()使いましょうだったのに。

11ナイコンさん2018/06/08(金) 04:12:15.95
>>5
サンクス。HEXダンプして見ていたので、シフトJISダンプするの忘れていたわ。
FDイメージを単純にシフトJIS表示させると以下↓のごとくごそごそ出てきたわ。

蛎崎 津軽 南部 葛西 秋田 伊達 最上 結城 葦名 上杉 佐竹 宇都宮 里見 北条 ・ 嵩c 畠山 神保 姉小路
木曾 今川 本願寺 朝倉 斉藤 徳川 堀 c 北畠 浅井 六角 一色 波多野 足利 筒井 三好 堀内 山名 別所 尼子
宇喜多 毛利 十河 細川 河野 長宗・ 苺・一条 城井 竜造寺 大友 阿蘇 伊東 島津 明智 羽柴 柴田 慶広
為信 晴政 晴信 愛季 輝宗 義守 晴朝 盛氏 謙信 義重 広綱 義尭 氏政 信玄 義綱 氏張 自綱 義昌 義元 光佐 義景
義竜 家康 信長 具教 長政 義賢 義道 秀治 義昭 順慶 長 慶 氏善 豊国 長冶 晴久 直家 元就 存保 晴元 通宣
元親 兼定 鎮房 隆信 宗麟 惟将 義祐 貴久 光秀 秀吉 勝家 sコxココ・村仄本国 商業国

兵がおりまへん 兵がおらん 兵がおりもさん ;ニJニ[ニjニ{ニ竿僻民がおりやせん 民がおらんがいね 民がおりませぬ
民がおりゃあせん 民がおりまへん 民がおらん 民がおりもさん イト7ナエナ-ニセニフニムニヨニロニ猗衄・ニ地図表示区分
全国 東北 北陸 関東 中部 近畿 中国・四国 九州 ヌヌ&ヌ %ヌ.ヌ5ヌ属領地への
ありません。 可能国 菴・スス セセ一揆軍 一向宗 延暦寺派 海賊 キリシタン 謀反軍 第%d国 %d.%s

------
漢字コードがシフトJIS。ということは、シフトJISで対応のFEPとエディタ、コンパイラで開発していたことを意味する。
シフトJISの仕様策定は1982年らしいが、同年に9801が出荷開始されている。LSI Cは1984年には出荷されていたという話。
ジャストのATOKやメガソフトのMIFESは1985-86年には出そろっている。ということみたいだから、
1986年版の信長の野望全国版の8801版は9801のクロス環境で開発されていた。と考えるのが自然な推定であるような気がする。

12ナイコンさん2018/06/08(金) 04:52:53.96
>IXやIYがあまり使われてなさそうなのがコンパイラっぽく無いとも感じる

LSI-Cに限らず8bit対応C言語がどんなコードを吐き出すか俺は知らないのでなんとも言えないが、
CP/Mという世界は基本8080の世界でZ80とは実はあまり密接な関係には無いのね。というのも、
CP/Mはインテル謹製の8080/85開発装置のためにインテルから依頼されたコンサルのキルダールがインテルの金で
開発したOSで奇しくも非採用になったためにインテルから版権を得てキルダールが市販しはじめたもの。なので
バインドされていたASM.COMとかDDTや別売りのMAC/RMACみたいなDRIのアセンブラ類もインテルニーモニック対応。
インテルシンパなキルダールがザイログ軽視していたのはそのへんの「ビジネス」絡みだったのかも。
ここら辺がDRIが商売下手なところで、MACRO-80のMSにつけいる隙を与えてしまった。唯一の例外はZSIDくらい。
なので、CP/M80専用ソフトにZ80固有アーキテクチャのIX/IYに冷淡なコンパイラとかがあっても不思議は無いのね。
79年なBDS CがIX/IY無視バイナリでも不思議無いかもね。

それと、CP/M向けの言語とかエディタにはAND 7Fでサインビットをマスクして無理矢理7bitASCII対応していた
ソフトがけっこうあった。結果半角カナが扱えない。そういうソフトをDDTでディスアセンブルしてAND 7FHを探しだし
処理フローを類推しながらAND FFHとパッチして無理矢理カナを扱えるようにするみたいなことをやった覚えがある。

シフトJIS処理された信長の野望全国版のDOSが独自なYDOSベースなのはこのサインビット処理・シフトJIS対応の故なのだろうね

13ナイコンさん2018/06/08(金) 05:15:05.40
LSI-Cの開発者森公一郎氏はすでに他界されているが、
https://srad.jp/story/15/01/22/0423242/

東のLSIジャパンに対して、西のペンギンソフトみたいなところがある。84-85年頃、
京都のペンギンソフトがペンギンCなるものインタフェース誌で広告出して売り出していた。
それが何であるか長年謎だった。当時武蔵小杉近辺の某LSI開発者に86的C言語を探していた
オッサンがいて、彼に京都まで行ってみれば?と話したことがあったから。

と、そのペンギンCはどうやら6301対応のCコンパイラだったらしい。開発者は小窓次郎氏。
また公知販売の仕掛け人はペンギンの筒井氏。この筒井氏は超有名人。10年の後、
YahooBBのADSL網を推進完成させたSB中興の人。東大工学部→京大医学部卒。

小窓氏のブログでは6301用のCコンパイラのDOS版ソースとバイナリなどが公開されている。要リスペクト。
オリジナルの開発はDECのVAXとBSD。そういう時代だったですなあ。先端エンジニアはDEC使い。みたいな
当時開発言語それ自体を開発するためにVAXを使う。というのは。ちなみにCP/MやPL/MはPDP8。

Cコンパイラ開発顛末記
http://www.techno-web.org/e_techno/1999/11/03/cyyoynyyeeaeouaei/

小窓氏のブログは2011年で止まっている。世代的に70手前くらいか。ちょっと心配。

14ナイコンさん2018/06/08(金) 05:27:30.06
ちなみに、筒井氏が率いていたペンギンソフトは9801用スクリーンエディタであるペンギンエディタを
開発販売したていたことでも知られている。広告出していたからね。俺も知っている。
ファイル名がSEDだったかな。ワードマスターみたいなESCシーケンスエディタに慣れたユーザには
目鱗ものの高速エディタだった。これが後のMIFES,REDなどの原型。というのもペンギンソフト解散時に
エディタの開発者がそれぞれ著作権利ありと継続したのがMIFESとか諸々。らしい。伝聞だからね。

あの84-86年頃の関西は9801移行で名を馳せた会社がたくさん合ったが、人脈の源流は京都ペンギンなのだろうね。
カノープス:神戸 メガソフト:大阪 岩崎技研:京都 京都マイクロコンピュータ:京都

15ナイコンさん2018/06/08(金) 05:53:19.28
PC88のCP/M 2.2のDDT自体は8080のコードで書かれたらしいがZ80の命令を解釈してたなぁ。
パソコンだと8080よりZ80のが使われてたからデジタルリサーチも8080に拘る愚はしないでZ80対応するのが自然でしょ。
NECが自社のPC向けにローカライズしてたのかもしれないけど。

16ナイコンさん2018/06/08(金) 06:16:11.98
>>5
> IXやIYがあまり使われてなさそうなのがコンパイラっぽく無いとも感じる
IX, IYを使う命令は遅いからアセンブラで組む時もあまり使わない

17ナイコンさん2018/06/08(金) 10:26:37.12
IX,IY
ビット命令
裏レジスタ

使うと笑われるZ80の3大機能

18ナイコンさん2018/06/08(金) 11:15:59.55
HLと等価なら使い勝手良かったのにね

19ナイコンさん2018/06/08(金) 11:38:58.71
川鉄のやR800だと使わないほうが遅いかもしれん

20ナイコンさん2018/06/08(金) 12:52:44.71
>>17
適材適所だろ。
インデックスレジスタは、データ構造の作り方で不要に出来る場合が多いけど、使い所はある
裏レジスタも処理を整理していけば要らない場面が多々あるけど、やっぱり欲しい時あるじゃん
そんなこと言ってたら、X1の様なGRAMのアクセス方法だって邪道

21ナイコンさん2018/06/08(金) 19:17:53.43
>>20
だから適所が少なかったって話な
アセンブラでカリカリチューニングするならまだわかるけど当時のコンパイラにそこまで要求するのはものを知らなさすぎ

22ナイコンさん2018/06/08(金) 19:26:48.45
>>13
筒井氏開発のは南極ペンギンC なのね。86用。 6301用のC3POとは別。

23ナイコンさん2018/06/08(金) 19:30:46.77
> IX,IY
> ビット命令
> 裏レジスタ
>
> 使うと笑われるZ80の3大機能

笑ってるのは適所を理解せず脊髄反射してる馬鹿ってことだよなあ。

24ナイコンさん2018/06/09(土) 01:11:34.24
exxで裏レジスタを使って2コア相当のパフォーマンスですよ

25ナイコンさん2018/06/09(土) 18:55:35.97
float a = 0.0;
printf("%f",a);

これでバイナリサイズはいくらになりますか?

26ナイコンさん2018/06/09(土) 19:02:46.39
>>25
知りたきゃ手前で確認しろやカス

27ナイコンさん2018/06/09(土) 19:14:15.01
7KBでした。

28ナイコンさん2018/06/09(土) 22:18:35.34
光栄ソフトは開発言語、マニュアルに書いてなかったっけ?

29ナイコンさん2018/06/09(土) 23:01:44.53
載ってたわ8ビットは
LSI-C/イントロール・クロスCらしい

30ナイコンさん2018/06/10(日) 03:31:33.82
>>27
うそつけ。

31ナイコンさん2018/06/10(日) 12:27:05.34
で、floatとprintfでどれぐらいバイナリは膨れ上がるんだ?

32ナイコンさん2018/06/10(日) 12:29:36.88
というか、mallocはまともに使えるサイズなのか?

33ナイコンさん2018/06/10(日) 13:38:03.38

34ナイコンさん2018/06/10(日) 18:28:43.30
使い物にならない例ばかりだしやがって

35ナイコンさん2018/06/10(日) 20:26:53.11
【またカミカゼ暴走、群馬のスーパー、重傷9人】 放射能が原因だけど、国防上、トップシークレット?
http://rosie.5ch.net/test/read.cgi/liveplus/1528627781/l50

36ナイコンさん2018/06/11(月) 05:51:10.02
>>30
無料公開されたCP/M版のHI-TECH Cでコンパイルすると7168バイトになるね

37ナイコンさん2018/06/11(月) 06:08:10.26
ちなみに下記コードを同じHI-TECH Cでコンパイルしたら384バイトだった
(ただ、hogehogeを出力するだけのコード)

#include <cpm.h>
int main(int argc, char **argv) {
bdos( 9, "hogehoge\r$");
return 0;
}

38ナイコンさん2018/06/11(月) 06:12:33.96
同じく下記コードだと4224バイト

#include <stdio.h>
int main(int argc, char **argv) {
int a = 1234;
printf("%d",a);

return 0;
}

39ナイコンさん2018/06/11(月) 11:37:29.18
LSI C-80は、8080用コンパイラだから、オブジェクトで
IX,IYが使われないのは当たり前。

HI-TECH CはZ-80用コンパイラで、多分コード生成部以外は
他のCPU用と共用と思われるため、過剰とも思えるほど
インデックスレジスタを多用したコードを吐く。

40ナイコンさん2018/06/11(月) 12:00:07.44
現在のLSI C-80はIX使いまくりだから、はっきり8080コードを指定しないと遅くなりそうだ
https://www.lsi-j.co.jp/official/products/02/other/lsic80

41ナイコンさん2018/06/11(月) 15:53:42.16
>>38
ボクのMSXは8KBとしかメモリがありません。

42ナイコンさん2018/06/11(月) 17:22:47.39
39800円のMSX-CはLSI-Cのサブセット。
19800円のα-CはBDS-Cのサブセットとかいう噂らしいけど。
信長ってクロスのLSI-Cなんでそ?
プロの開発で8bitCPUでコンパイルはなかったのかね?

43ナイコンさん2018/06/11(月) 18:13:58.99
標準printfなんて馬鹿みたいにデカいからな

44ナイコンさん2018/06/11(月) 18:17:35.98
コンパイラ使っても結局生成コード確認してたし
(バグとか結構あったから)
BASE80とかの方が生産性高かったなぁ

45ナイコンさん2018/06/11(月) 20:23:34.62
それでもアセンブラでシコるよりC使ったほうが生産性が高かった。

8ビットでもインタプリタが載せられるようなリッチ?なシステムで仕事したかったわw

46ナイコンさん2018/06/11(月) 21:23:13.92
> 現在のLSI C-80はIX使いまくりだから、はっきり8080コードを指定しないと遅くなりそうだ

8080知らない人は面白いこと言うw

47ナイコンさん2018/06/11(月) 22:52:13.05
>>40 のリンクにある tarai 関数を 8080 にある命令をザイログニモニックで
吐く MSX-C 1.2 用に書き換えてコンパイルしてみた。
int
tarai(x, y, z)
int x;
int y;
int z;
{
if (x > y)
return tarai(
tarai(x - 1, y, z),
tarai(y - 1, z, x),
tarai(z - 1, x, y)
);
else
return y;
}

48ナイコンさん2018/06/11(月) 22:53:08.97
MSX.M-80 2.00 11-Jun-18 PAGE 1



; MSX-C ver 1.20p (code generator)

0000' cseg

0000' tarai@:
0000' E5 push hl
0001' D5 push de
0002' C5 push bc
0003' E5 push hl
0004' EB ex de,hl
0005' D1 pop de
0006' CD 0000* call ?CPSHD
0009' D2 0091' jp nc,@0
000C' E5 push hl
000D' 21 0002 ld hl,2
0010' 39 add hl,sp
0011' 71 ld (hl),c
0012' 23 inc hl
0013' 70 ld (hl),b
0014' E1 pop hl
0015' 4D ld c,l
0016' 44 ld b,h
0017' C5 push bc
0018' D5 push de
0019' CD 0000* call ?saut6
001C' D1 pop de
001D' 21 0002 ld hl,2

49ナイコンさん2018/06/11(月) 22:53:39.63
0020' 39 add hl,sp
0021' 4E ld c,(hl)
0022' 23 inc hl
0023' 46 ld b,(hl)
0024' 21 FFFF ld hl,65535
0027' 09 add hl,bc
0028' E5 push hl
0029' 21 0004 ld hl,4
002C' 39 add hl,sp
002D' 71 ld (hl),c
002E' 23 inc hl
002F' 70 ld (hl),b
0030' E1 pop hl
0031' C1 pop bc
0032' E5 push hl
0033' 21 0006 ld hl,6
0036' 39 add hl,sp
0037' 73 ld (hl),e
0038' 23 inc hl
0039' 72 ld (hl),d
003A' E1 pop hl
003B' CD 0000' call tarai@
003E' E5 push hl
003F' 21 0006 ld hl,6
0042' 39 add hl,sp
0043' 4E ld c,(hl)
0044' 23 inc hl
0045' 46 ld b,(hl)
MSX.M-80 2.00 11-Jun-18 PAGE 1-1

50ナイコンさん2018/06/11(月) 22:54:05.87
0046' 21 0002 ld hl,2
0049' 39 add hl,sp
004A' 5E ld e,(hl)
004B' 23 inc hl
004C' 56 ld d,(hl)
004D' D5 push de
004E' CD 0000* call ?laut6
0051' D1 pop de
0052' D5 push de
0053' CD 0000* call ?saut6
0056' D1 pop de
0057' 2B dec hl
0058' E5 push hl
0059' 21 0008 ld hl,8
005C' 39 add hl,sp
005D' 71 ld (hl),c
005E' 23 inc hl
005F' 70 ld (hl),b
0060' E1 pop hl
0061' E5 push hl
0062' 21 0004 ld hl,4
0065' 39 add hl,sp
0066' 73 ld (hl),e
0067' 23 inc hl
0068' 72 ld (hl),d
0069' E1 pop hl
006A' CD 0000' call tarai@
006D' E5 push hl
006E' 21 0004 ld hl,4
0071' 39 add hl,sp

51ナイコンさん2018/06/11(月) 22:54:37.11
0072' 4E ld c,(hl)
0073' 23 inc hl
0074' 46 ld b,(hl)
0075' C5 push bc
0076' 21 0008 ld hl,8
0079' 39 add hl,sp
007A' 5E ld e,(hl)
007B' 23 inc hl
007C' 56 ld d,(hl)
007D' 21 000A ld hl,10
0080' 39 add hl,sp
0081' 4E ld c,(hl)
0082' 23 inc hl
0083' 46 ld b,(hl)
0084' 21 FFFF ld hl,65535
0087' 09 add hl,bc
0088' C1 pop bc
0089' CD 0000' call tarai@
008C' D1 pop de
008D' C1 pop bc
008E' CD 0000' call tarai@
0091' @0:
0091' C1 pop bc
0092' C1 pop bc
0093' C1 pop bc
0094' C9 ret
MSX.M-80 2.00 11-Jun-18 PAGE 1-2

52ナイコンさん2018/06/12(火) 15:56:56.92
IX,IY便利だよ、ポインタ2セット抱えてINC L DEC Lちまちまやるのはただのアホ

53ナイコンさん2018/06/12(火) 18:59:25.98
ケースバイケース
>>52みたいに状況判断ができない奴が一番使えない

54ナイコンさん2018/06/12(火) 19:33:01.87
>>53
どんなケースでポインタ操作でIX、IYが不便になるんですか?

55ナイコンさん2018/06/12(火) 20:33:14.13
インデックスレジスタはでかくて遅いみたいに思うけど、
構造体っぽいデータをランダムアクセスしたい場合なんかは
HL や DE を駆使するより効率的だったな。
シーケンシャルな連続アクセスなら HL, DE レジスタの方がいいだろうけど。

56ナイコンさん2018/06/12(火) 20:43:38.16
>>54
実際にやってみればいろいろわかると思うよ
https://electrelic.com/electrelic/node/474

57ナイコンさん2018/06/12(火) 21:03:30.46
逃げたか。

58ナイコンさん2018/06/12(火) 21:17:24.43
リンク先も読めないバカ?

59ナイコンさん2018/06/12(火) 21:20:20.70
自分の言葉で説明せずに他人に○投げしたら「逃げた」と言われてもしかたないね。
実際逃げてるんだしw

60ナイコンさん2018/06/12(火) 21:59:27.29
とにかくバグを出さずそれなりに早く、そして8bit機なので省メモリなら何でもいいわ
遊びならアセンブラで組めよ。
仕事なら要件通り作れよってなる

61ナイコンさん2018/06/12(火) 21:59:56.70
>>56
Z80の特性理解しないでレジスタの扱いヘタクソなジジイがあれがダメこれがダメ言ってるだけのゴミ記事。

62ナイコンさん2018/06/12(火) 22:10:29.02
ダメ出しなんて馬鹿でもできるからな。
不可能を可能にするノウハウにこそ価値がある。

63ナイコンさん2018/06/12(火) 22:11:54.53
>>59
えっ?
俺がやるより分かりやすく説明してるから貼ってるんだけど
具体例出されたから反論できずに困ってる? w

64ナイコンさん2018/06/12(火) 22:12:40.69
>>61
はいはい w

65ナイコンさん2018/06/12(火) 22:41:15.86
>>63
>ADD IX,BC
>はできても
>ADD IX,HL
>はできないのです。

EX DE,HL
ADD IX,DE
EX DE,HL
とかやり様だしなあ、こんなんで「分かりやすく説明してる」ってアホかw

66ナイコンさん2018/06/12(火) 22:44:59.58
>未定義命令を使わない場合、よく使われたのは
>
>PUSH BC
>POP IX
>とスタックを経由する方法でした。これならHLからIYへの転送等も可能ですが、スタック(メモリ)を経由するのがちょっと気になります。

スタック使うのが気になるなら
LD IX,0
ADD IX,BC
とかするだけだがなあ、自分で提示した方法にケチつけることに何の意味があるんだろう?

67ナイコンさん2018/06/12(火) 22:49:47.21
>素直に書けばこんな感じになるでしょうか。
>
> 1: 0000 C5 PUSH BC
> 2: 0001 DDE5 PUSH IX
> 3: 0003 4F LD C,A
> 4: 0004 0600 LD B,0
> 5: 0006 DD09 ADD IX,BC
> 6: 0008 DD5600 LD D,(IX+0)
> 7: 000B DDE1 POP IX
> 8: 000D C1 POP BC

これはIX使うのが間違ってんだよなあ。
ADD A,L
LD L,A
ADC A,H
SUB L
LD H,A
LD D,(HL)

68ナイコンさん2018/06/12(火) 23:02:23.52
> 実際にやってみればいろいろわかると思うよ

わかってない奴が何偉そうにw

69ナイコンさん2018/06/12(火) 23:08:20.18
> えっ?
> 俺がやるより分かりやすく説明してるから貼ってるんだけど
> 具体例出されたから反論できずに困ってる? w

ワロタw

70ナイコンさん2018/06/12(火) 23:34:26.19
>>63
それを逃げって言うだろ、普通は。

71ナイコンさん2018/06/12(火) 23:35:21.32
>>65-66
> とかやり様だしなあ
> とかするだけだがなあ
そりゃそう言う言い方したらなんでもありありだわな
そう言うのは面倒だし、(当時は)コードサイズが膨れるのも嫌とかあるだろ

>>67
全然違うコードさらしてバカアピールか?

>>68-70
煽ることしかできないバカは黙っとけ

72ナイコンさん2018/06/12(火) 23:42:08.19
判りやすく説明するのが面倒だから他人に丸投げしました(キリッ!
ですね、立派な逃げです。

面倒から逃げるのはよくある事ですけど、逃げは逃げですw

73ナイコンさん2018/06/12(火) 23:54:52.86
具体例出されたら
逃げたー
しか言えなくなってて笑うわ

74ナイコンさん2018/06/13(水) 00:00:15.06
結局自分でコードも書けない素人だったというわけかw

75ナイコンさん2018/06/13(水) 00:04:53.96
>>74
自己紹介乙

76ナイコンさん2018/06/13(水) 00:05:17.42
他人様のページのアドレス貼って具体例と言ってドヤ顔かあ、ご立派なもんだなあ。

77ナイコンさん2018/06/13(水) 00:08:07.45
> 自己紹介乙

てめえが書いたコードも晒さずに何バカ言ってんだかw

78ナイコンさん2018/06/13(水) 00:29:56.38
なるほど。つまりC言語はスタック使いまくりだから使い物にならないのか。

79ナイコンさん2018/06/13(水) 00:31:36.30
8088や8086では簡単に出来ることをZ80では面倒なことをしないといけない
如何に8bit CPUが制限だらけかわかる

8088や8086はスタックアクセスにBPレジスタが用意されていて
スタック上のローカル変数へのアクセスが容易にできる
Z80は高級言語のことはあまり考慮されてないが
8088や8086は高級言語のことも考慮されてる設計

68000ならlink命令など、さらに高級言語が使いやすく出来てる

80ナイコンさん2018/06/13(水) 02:02:14.50
>>78
引数もローカル変数も使わずグローバル変数だけ使えば問題なし

81ナイコンさん2018/06/13(水) 02:38:14.82
>>78
ローカル変数を固定番地に配置すれば良い。関数の入り口でそれらをスタックに退避すれば再帰もできるし実行中のオーバーヘッドも小さい。

82ナイコンさん2018/06/13(水) 02:54:52.19
> 如何に8bit CPUが制限だらけかわかる

6809とか知らない人?

83ナイコンさん2018/06/13(水) 04:37:45.80
>>82
6809は出た時期が遅いからな
8086よりも後発で68000と同時期じゃなかったか?

84ナイコンさん2018/06/13(水) 04:42:15.86
8bit

85ナイコンさん2018/06/13(水) 04:45:00.82
8bit CPUはアドレスが16bitだからアドレッシングモードなどを贅沢にすると
当然、複数の16bitの加算、減算回路が必要になり
結局16bitCPUとトランジスタ数が変わらなくなるんじゃないの?
6809はかなりのトランジスタ数なんじゃないかな

86ナイコンさん2018/06/13(水) 05:04:53.80
ちょっと訂正
× 複数の16bitの加算、減算回路が必要になり
○ 複数の16bitの加算、減算が必要になり

遅くてもいいなら演算回路はどうにでもなるからね
6809のようなアドレッシングモードが高機能な場合、
データの演算そのものよりもアドレス計算の方が計算量が多くなってしまう

87ナイコンさん2018/06/13(水) 05:19:40.18
6809はレジスタ数を極小にしたからアドレッシングを強化できたと言える。

88ナイコンさん2018/06/13(水) 05:25:49.48
これは16bit CPUにも言えることで32bitレジスタが使えるような68000のような高機能な16bit CPUは
単純な32bit CPUと大差ないかまたはより多くのトランジスタ数を必要としたりする
32bitのARMのCortex-M3は3万3000ゲート、MIPSのM4Kは3万5000ゲートと言われてる
ワンチップマイコンでも高機能な16bitCPUは淘汰されて32bitに置き換わってる

89ナイコンさん2018/06/13(水) 06:09:53.45
>>85
そこを上手くこなしたのが6502のアドレス演算
Z80がボケーっとリフレッシュアドレス出してるデコード中に下位アドレス読み込んで次の処理を始めているのでムダがない

90ナイコンさん2018/06/13(水) 06:30:34.32
さらに6800や6809がアドレス計算でバスをボケーっと遊ばせている間に上位アドレス読み込んでそのまま試しに使ってみるのでインデクスレジスタの上位バイトも要らなくなって速い安い美味いCPUになっている

91ナイコンさん2018/06/13(水) 06:40:20.26
>>76-77
「逃げたー」の次は「他人様のー」かよ w
他人のコードだろうが具体例には違いないだろ、バカすぎるわ
色々おかしいとしても具体的なコードで反論してきた>>65-67の方が100倍マシだよ

92ナイコンさん2018/06/13(水) 06:54:00.92
>>79
> 8088や8086はスタックアクセスにBPレジスタが用意
> 68000ならlink命令
両方とも最適化が進んで使われなくなったけどねw
>>82も書いてるけどレジスタの問題よりアドレッシングモードの問題の方が大きい

93ナイコンさん2018/06/13(水) 07:20:19.05
>>91
> 色々おかしいとしても

具体的に指摘できないけどケチ付けたいのは解った。

94ナイコンさん2018/06/13(水) 07:36:32.91

95ナイコンさん2018/06/13(水) 11:28:35.03
IX、IY使って一番いいことはIX+dの'd'のところを構造体名で書けること
高速化は動くものができてから好きなだけやればいい
デバッガどころか文字出力もない環境でよくゲームなんか作ったもんだと今更ながら呆れる

96ナイコンさん2018/06/13(水) 12:08:06.34
>>94
「全然違うコード」ってトンチンカンな主張繰り返したいの??

97ナイコンさん2018/06/13(水) 12:22:50.89
>>96
HL使ったコードでどやられてもね
しかもHL壊してるし

98ナイコンさん2018/06/13(水) 18:09:48.24
「これはIX使うのが間違ってんだよなあ」の意味も理解できないし壊したくないレジスタにどうすればいいかもわからん素人さんかよ。
想像を遥かに超えた馬鹿だなw

99ナイコンさん2018/06/13(水) 18:39:17.89
LD D, (IX + A) ができないって話に IX 使うのが間違ってるとか前提変えてどや顔かよ w
しかも命令の代替の話だから D 以外を壊さないのは常識

100ナイコンさん2018/06/13(水) 18:53:31.69
俺は頭悪いしモノを知らないからMレジスタは知ってるがHLレジスタは知らない。

101ナイコンさん2018/06/13(水) 19:14:13.75
> 命令の代替の話だから D 以外を壊さないのは常識

ドヤ顔して貼った他人様のページのコードはフラグ壊してるから非常識って主張かよw

102ナイコンさん2018/06/13(水) 19:42:59.12
>>92
それがアドレッシングモードを含めてのBPレジスタという話だ
8086のレジスタをつったメモリアドレッシングは単純化するとこうなる

disp[reg1 + reg2]

reg1に指定できるのがBXとBPのみ
reg2に指定できるのがSIとDIのみ
reg1、reg2はどちらか一方を省略してもいい
dispは8bitもしくは16bitで、dispは一部を除いて省略可能
(reg1にBPで尚且つreg2を省略した時はdispを省略できない)

で、reg1にBPレジスタを指定した場合、暗黙的に使われるセグメントがスタックセグメントになる
だからBPレジスタは主にスタック上のデータを操作する目的で作られたといえる


ちなみにVC++で最適化でフレームポインタとしてBPレジスタを使わなくなったのはx64からだ
その代わりWidnowsのx64では関数の入り口と終りで
まとめてローカル変数や一時記憶領域をスタック上に確保、解放するようになり
プログラムの途中でpush、popのようなRSPの値を操作するようなことは禁止されてる
gccでは32bitでもEBPをフレームポインタとして使わなかったりする

まあ、x86は32bit化でアドレッシングモードが大幅に拡張されてるけどね
64bit化では32bitからほんの少しの改良しか行われてないけど

103ナイコンさん2018/06/13(水) 20:09:07.91
>>101
フラグとか必死すぎる w

104ナイコンさん2018/06/13(水) 20:14:58.78
>>102
> それがアドレッシングモードを含めてのBPレジスタという話だ
SP に適切なアドレッシングモードがつけばすむ話で BP 関係ない
デバッグする時にスタックフレームが追いかけやすいと言うメリットはあったけど

105ナイコンさん2018/06/13(水) 21:16:25.38
>>104
仮定の話なんてどうでもいい
8086、8088にはSP間接アドレッシングはないからな
32bit化された時にSPをベースレジスタとして使えるように拡張されたわけで
8086や8088でpush、pop以外でスタックのデータにアクセスしたければ普通はBPレジスタを使う

106ナイコンさん2018/06/13(水) 21:24:13.21
>>105
元々Z80の話なんだけど...

107ナイコンさん2018/06/13(水) 21:34:19.35
>>106
Z80で面倒な操作も16bit CPUの8086、8088なら簡単にできるという話だよ

108ナイコンさん2018/06/13(水) 21:37:21.15
後発のほうが高機能で便利になってるのは当たり前だけど、何を意図した比較なのかがよく分からない。

109ナイコンさん2018/06/13(水) 21:39:54.22
だからC言語はZ80には荷が重いということ

110ナイコンさん2018/06/13(水) 21:43:49.33
8086や286にだって荷が重いだろ。Cは8086のセグメントとの相性はよくない。

111ナイコンさん2018/06/13(水) 22:07:13.02
>>107
だからそれはBPレジスタのお陰じゃなくてアドレッシングモードのお陰って話な
8086 じゃなくても 6809 でも簡単って >>82 に指摘されてただろ

112ナイコンさん2018/06/14(木) 01:52:19.21
amd64は欠陥設計です。

113ナイコンさん2018/06/15(金) 19:52:49.86
>>111
だから、アドレスは8bit CPUでも16bitだから
アドレッシングモードを複雑にするとそれだけ複雑な16bitの演算が必要になる
それならいっそのこと16bit CPUにした方がいいからな

114ナイコンさん2018/06/15(金) 22:19:46.86
>>113
はあ?
頓珍漢過ぎて笑うしかないないんだが w
Z80 ですら ADD HL,rp で 16bit 演算してたから単純にアークテクチャの問題だよ
ただ、念のために言っとくけど当時はスタックに変数を置くと言う概念は一般的ではなかったから 8080 や Z80 のアーキテクトがおかしいと言う訳じゃない

115ナイコンさん2018/06/16(土) 02:07:30.87
当時のCPU開発にどれだけトランジスタ数に制限があったかは知りませんが、
複雑なアドレス演算ってただの全加算器ですよね。

116ナイコンさん2018/06/16(土) 04:32:37.88
>>115
6809には乗算命令があるがZ80には乗算命令すらないぞ

6809のdisp16のインデックスト・アドレッシングや
Dレジスタを使ったアキュムレーター・オフセット・インデックスト、
16bitオフセットのプログラムカウンタ・レラティブ・アドレッシングは
アドレス計算のために16bitの加算が必要なわけ
8bitの演算をするために16bitの演算が必要な時点で、アドレス計算の方が負荷が大きい

117ナイコンさん2018/06/16(土) 05:52:34.45
6809は8bit CPUとしてはかなり高機能なアドレッシングモードを持ってるが
その分、トランジスタ数も16bit CPU並みに多いと思うぞ

118ナイコンさん2018/06/16(土) 06:57:57.18
ちなみに8086でレジスタオペランドの16bit MULが118-113クロック
68000のMULSやMULUは70クロック以下
286だとレジスタオペランドの16bit MULが21クロック
386だとレジスタオペランドの16bit MULが9-22クロック
486だとレジスタオペランドの16bit MULが13クロック

必要なクロックから推定するとおそらく8086や68000の乗算命令は
専用の乗算回路はなくてマイクロコードで実装されてると思われる

119ナイコンさん2018/06/16(土) 07:14:22.89
>>114
つまり、8080やZ80はそもそもC言語に適してない設計なんだよ
自分で認めてるじゃないか

120ナイコンさん2018/06/16(土) 07:31:48.61
ちなみに1990年のトランジスタ技術に載ってる若松通商の広告の価格
(小売価格なのであまり参考にならないかも)

Z80A 4M    210円
HD6809P    800円
HD68A09P  800円
HD68B09P  900円

80186 5M    500円
80186 8M    1000円
68008P-8    1900円
68000RC8    5400円
68000RC10   6000円
68000P16    4800円
80286-10    6000円

121ナイコンさん2018/06/16(土) 07:48:05.98
自論を曲げるつもりない書き込み
ちょっとアレだね・・・

コテハンにしてくれたらNGするんだが・・・

122ナイコンさん2018/06/16(土) 07:54:27.08
6809が5MHzの80186より高いんじゃな

123ナイコンさん2018/06/16(土) 08:01:55.72
高級言語に適したCPUの設計とは何か。

124ナイコンさん2018/06/16(土) 08:12:28.95
>>119
はあ?
Z80や8080がC言語に適してるって言ってた奴なんていないだろ
ただそれとこれらのCPUでC言語を使ってたかどうかとは別の話
ハードウェアスタックポインタを持たない汎用機でもC言語は動くしな

125ナイコンさん2018/06/16(土) 08:19:32.82
いくら6809が究極の8bit CPUとはいえ、8088と比べたら8088の方がずっと高機能

http://www.st.rim.or.jp/~nkomatsu/mc68k/MC68008.html
> 1979年、Motorola社は究極の8 bitと呼称されるMC6809と
> 16 bitプロセッサとしては破格の機能を持つMC68000を発表します。
> 同年、Intel社は8086の8 bitデータバス版の8088を発表します。
> さて、8088は命令体系は16 bitアーキテクチャですが、
> ハードウェア面から見るとそれ以前の8 bitマイクロプロセッサである8085と似せてあります。
> さすがに量産の立ち上がり時には8088は高価ではありますが量産が行われれば安価になる見込みがありますし、
> それ以外の周辺回路は8085用のものを多少修正するだけで16 bit CPUのパワーを手に入れられる、
> トータルコストでは比較的安価なマイクロプロセッサでした。
> さて、ここはMC68008の紹介をするはずの場所です。
> なぜ8088の紹介が先にきたかといえば、Intel社は8088のハードウェア面の特徴から、
> 高性能8 bit CPU扱いをして、MC6809やZ80 CPUとのベンチマークテストの結果を公表して売り込んだのです。
> そういった比較資料は、たとえば「iAPX88ブック」に詳しく記載があります。
> Z80 CPUは8086アーキテクチャの2年前の8 bit CPUですし、MC6809は8088と同時代のプロセッサといえ、
> あくまで8 bit CPUの枠内での高性能を目指していたため、メモリ空間も64 KByteしかなく、
> 16 bit演算も加減算くらいしか許されず、8088と比較されては不利であることは否めません。
> 「iAPX88ブック」に含まれる『ベンチマーク・テスト・リポート Intel iAPX88 vs Motorola MC6809』では、
> 5 MHzクロックの8088の方が2 MHzクロックのMC6809より約2倍高速であるとされています。
> 5 MHzクロックの8088と2 MHzクロックのMC6809と比較しては不公平であると思われるかもしれませんが、
> バスサイクルに何クロック必要かがプロセッサアーキテクチャによって異なりまして、
> このクロック周波数比でほぼ同じメモリアクセススピードとなるため、それほど悪い比較ではありません。
> このベンチマーク・テスト・レポートは1981年に作成されています。

126ナイコンさん2018/06/16(土) 11:49:38.43
そりゃ6809と8088ではトランジスタ数が3倍以上違うから・・・
その辺の違いで製造の難易度、ひいては最終的な値段も大きく変わるので、
値段なのか性能なのか何を重視するかによって変わったわけさ。

127ナイコンさん2018/06/16(土) 12:01:12.79
6809のトランジスタ数って公開されてたっけ?
6800なら公開されてるようで、ググるとトランジスタ数が5000と出る
8080がトランジスタ数が6000
Z80がトランジスタ数が8200
6809は6800からかなり強化されてるからトランジスタ数も多いと思うが

128ナイコンさん2018/06/16(土) 12:21:26.56
まあ、8088のトランジスタ数が6809の3倍以上というのは異論があるが2倍以上はあるだろうな

129ナイコンさん2018/06/16(土) 12:23:57.17
6809もググったら9000って出てくるぞ

130ナイコンさん2018/06/16(土) 12:26:02.54
>>128
8088/8086 → 29000個
6809 → 9000個

ググったら普通に出てくる

131ナイコンさん2018/06/16(土) 12:30:50.86
ごめん、英語版のwikipediaに9000個って書いてあったわ

132ナイコンさん2018/06/16(土) 21:08:06.29
元々BASICだったソフトをC言語に移植するのはなんとかなるが、
オールアセンブラのソフトをCで移植するときは、速度、メモリとも厳しいだろうな。

133ナイコンさん2018/06/16(土) 21:48:43.76
同じCPUで移植するならそうだけど、CPUの性能上がったからアセンブラ⇒C言語への移植をお願いって案件は結構あったよ

134ナイコンさん2018/06/16(土) 22:13:49.16
WindowsではMeまでアセンブラコードに依存してたこと考えると、
Pen2ぐらいでやっとCの遅さを実用になるレベルまでカバーできるようになったと言えるな。

135ナイコンさん2018/06/16(土) 23:22:52.36
>>134
アセンブラだったのはどの処理だったのかね?

コンパイラの進化も凄いよね。
VC4くらいだと、混合モードでみる限りカウンタにECXとか使わないからloop命令使ってねーなーと突っ込んでいたわ

136ナイコンさん2018/06/17(日) 02:50:53.26
90年代、オールアセンブラのVzエディタが爆発的に売れたことから考えると、
少なくともPentium以前ではC言語はまだまだ実用的でなかったと言える。

Vzを日頃使ってると、EWS4800で使うviが非常に遅いと感じた。
MIPSの設計もまたC言語に向いてなかったのだろうな。

137ナイコンさん2018/06/17(日) 03:17:25.25
EWS4800が遅かったのよソレ
UNIXはHDDに依存しすぎだし

138ナイコンさん2018/06/17(日) 03:49:44.42
Vz使ってたのはV30マシン。R3000がV30より遅いということはないだろう。

139ナイコンさん2018/06/17(日) 06:19:11.74
UNIXはハードウェアを直接いじれないからな
しかもviは端末に依存しないように作られてるから余計に遅くなる
32bit以降のCPUでC言語の実装を考慮してないCPUなどないでしょ

MIPSはスタンフォード大学のRISCの研究から生まれたCPUでいきなり出てきたわけじゃないからな
その研究から生まれたMIPS-Xがあって、それを改良して実用的にしたのがR2000やR3000
C言語に向いてなかったらそもそもUNIXマシンで採用されるわけがない
MIPSの命令セットはC言語を実装するための最低限の単純な命令の命令セットという感じ

140ナイコンさん2018/06/17(日) 06:44:48.26
MIPSはフラグレジスターがなくて、
多倍長の加算するのに加算した後の数が加算する前より小さければ桁あふれが発生
とかのトリック的なことをかなり使ってるからMIPSアセンブラの定石を知らない人には
アセンブラで組むのは難しいかも
イミディエイト値を読み込む場合に%hi()や%lo()といった演算子が用意されているんだが
lui $4, %hi(0x12345678)
addiu $4, $4, %lo(0x12345678)
こんな感じでロードするように%hi()、%lo演算子の値が補正されているので
lui $4, %hi(0x12345678)
ori $4, $4, %lo(0x12345678)
とやってはいけないとかいろいろある

141ナイコンさん2018/06/17(日) 09:55:24.05
MS-Word1.0のソースコードが公開されてたけど、アセンブラの部分もあったね

142ナイコンさん2018/06/17(日) 10:01:44.91
>>136
> Vzを日頃使ってると、EWS4800で使うviが非常に遅いと感じた。
それ画面描画の問題だろ

> MIPSの設計もまたC言語に向いてなかったのだろうな。
自分の狭い(かつ頓珍漢な)経験でアホな判断するなよ w

143ナイコンさん2018/06/17(日) 10:32:26.39
初期のCP/MとかMS-DOS、Photoshop、Word、Apple IIDOSなどのソースコードが公開されてるね
http://www.computerhistory.org/atchm/tag/source-code/

144ナイコンさん2018/06/17(日) 10:35:55.53
初期のPhotoshopはPascalとアセンブラで書かれてたんだなw

145ナイコンさん2018/06/17(日) 12:38:01.87
MIPSよりV30が速いということはナイナイ。

146ナイコンさん2018/06/17(日) 12:40:31.08
そもそもviはtelnetやssh経由からも使えるわけで
VZ Editorみたいにハードウェアを直接叩くんじゃなくて
UNIXの標準機能を使って作られてるから遅いんだろうね

147ナイコンさん2018/06/17(日) 12:43:09.03
MS-DOSでも、MS-DOS標準のエスケープシーケンスで画面表示してて
どのMS-DOSでも動作するエディタがあるがやっぱり遅いよ

148ナイコンさん2018/06/17(日) 12:58:11.06
それにEWS4800でR3000ということはもうX Windows Systemが広まってた時代だろうけど、
もしかしてX上のターミナルで使ってて遅いとか言ってない?

149ナイコンさん2018/06/17(日) 13:03:42.79
ちなみに6809が8bit最強というのもナイナイ。単なる都市伝説。

150ナイコンさん2018/06/17(日) 13:03:48.59
C言語の前はこのクラスの高級言語=Pascalの時代だったからね
短かったけど

151ナイコンさん2018/06/17(日) 13:06:50.73
>>149
そう言うのは6809よりつおいCPU出してから言わないと w

152ナイコンさん2018/06/17(日) 13:08:38.32
ま、それにviは今のLinuxで使っててもサクサク動作するとは言えないかもね
MS-DOSの頃のエディタの方が高速スクロールしてたと思う
VZ Editorは使ったことないけど
FinalとかV30や286のPC-9801でもスクロールが物凄く速かったよな

153ナイコンさん2018/06/17(日) 13:14:19.41
>>152
finalってスクロールだけ早かった印象がある
Vzは機能のバランスとスピードが一体になっていてとにかく洗練されてるし完成されてたね。
WindowsになってWzは作者違うし、秀丸がなんとなく後継だけども体へのフィット感が違うな(Vzで作ったFM-7のDUPキーを模したマクロとか秀丸に移植しなかったせいもあるけど)

154ナイコンさん2018/06/17(日) 13:42:36.24
MIPSはプレステにも使われてたけど別に遅いという印象はなかったけどな。
ていうか、性能が良かったから家庭用だけでなく日本のPCゲーム市場まで駆逐してしまったわけで・・・

155ナイコンさん2018/06/17(日) 14:23:56.64
今、注目されてるRISC-VもMIPSの焼き直しみたいなものだからね
RISC-VはフリーだしFPGA用のフリーの実装もあるのでFPGA界隈で注目されてるみたいだね

156ナイコンさん2018/06/17(日) 14:41:28.04
昔のUNIXや昔のUNIXのC言語を試してみたい人はこれを試してみるといいよ
PDP-11上のUNIX Version 7が試せる
C言語も入ってるよ

http://pcmemo.take-uma.net/simh/install_simh
http://pcmemo.take-uma.net/unixv7/install-v7-1

simhはLinux上でも動くし、Windows上のCygwinでもコンパイルして実行できた
simhのコンパイルは
解凍したsimhのディレクトリに移動して
make pdp11 USE_NETWORK=1
これで出来る
BINというディレクトリができてその中にあるpdp11が実行ファイル
(Cygwinだとpdp11.exeになる)

rootでログインできたらユーザやグループの追加は/etc/passwdや/etc/groupを直接編集する
エディタはviはないのでedで編集しないといけない
ホームディレクトリも自分で作成する

157ナイコンさん2018/06/17(日) 14:54:04.62
UNIXでのコンパイル方法はソースファイルがhogehoge.cだとすると
cc -O2 -o hogehoge hogehoge.c

アセンブラ出力は
cc -O2 -S hogehoge.s hogehoge.c
出力したアセンブラソースファイルは
cc -o hogehoge hogehoge.s
これで実行ファイルを作れる

-O2というのは最適化オプションでなくてもいいし-O1や-O3とかでもいい

158ナイコンさん2018/06/17(日) 15:18:05.38
追記
数学関数を使うなら
cc -O2 -o hogehoge hogehoge.c -lm
と最後に-lmオプションを付ける

159ナイコンさん2018/06/17(日) 15:21:54.05
>>135
インテル・アーキテクチャ最適化マニュアル
https://www.intel.co.jp/content/dam/www/public/ijkk/jp/ja/documents/developer/ia_opti.pdf
> 整数ブレンデッド・コードの最適化手法

> 複雑な命令
> 複雑な命令 (たとえば、enter、leave、loop)の使用を避け、単純な命令のシーケンスを使用する。

160ナイコンさん2018/06/17(日) 15:40:36.87
>>135
> コンパイラの進化も凄いよね。
> VC4くらいだと、混合モードでみる限りカウンタにECXとか使わないからloop命令使ってねーなーと突っ込んでいたわ

さあ突っ込めや↓
https://godbolt.org/g/3btzdU

161ナイコンさん2018/06/17(日) 15:47:23.81
VC++もあった方良かったかな
https://godbolt.org/g/WEuFqk

162ナイコンさん2018/06/17(日) 16:01:47.34
当時はネットもオープンソースもほとんど無かったけど
コンパイラやライブラリーも書き直せば良い物が出来そうよね
クロス環境で贅沢にメモリー使って最適化させたり

163ナイコンさん2018/06/17(日) 17:57:33.96
>>162
当時っていつ頃?
GNU-Cの登場は88年だけど、89-90年ごろには移植が進んで PCやアタリやアミガ版、
mac版などBBSとかでサーキュレートしてた。同時期にminixも紀伊国屋や丸善で書店販売されて、
91年にはLinux。16/32ビットOS自作が欧州ではブームだった。あの頃の洋雑誌は面白かったなあ

164ナイコンさん2018/06/17(日) 18:16:17.54
8bit全盛当時といえば80年代だけどその頃8bit用のフリーのコンパイラってあったの知らんなあ
まあ日本に住んでたし

165ナイコンさん2018/06/17(日) 19:14:30.45
>>142
MIPSはフラグレジスタがないという致命的な欠陥がある。キャリーフラグがないために桁あふれで例外を投げるため、
PSのソフトのいくつかはこの致命的な欠陥仕様のためにフリーズするものがあることがソフト解析で分かっている。
MIPSの仕様を知らず、Cの知識だけでコードを書くとこのようなバグを埋め込んでしまうのである。MIPSはCに向いてないと言えよう。

166ナイコンさん2018/06/17(日) 19:29:19.66
> MIPSの仕様を知らず、Cの知識だけでコードを書くとこのようなバグを埋め込んでしまうのである。MIPSはCに向いてないと言えよう。

Cの仕様では符号付整数のオーバーフローは未定義動作だしそんなプログラムを書く奴はCの知識はないだろw

167ナイコンさん2018/06/17(日) 19:38:07.83
>>165
C言語はunsignedだとキャリーは無視する仕様
MIPSはキャリーで例外を発生させない命令(adduとか)も持っててCコンパイラは例外を発生させない命令を使う

なんてことは常識やぞ

168ナイコンさん2018/06/17(日) 19:41:11.66
つまり、何かの理由でPSではアセンブラで書いてた人たちがいて、バグを埋め込んだということになるな。
アセンブラで書く理由なんて、Cは遅いから意外に思いつかない。

169ナイコンさん2018/06/17(日) 19:42:54.35
>>165
何言ってるんだ?
C言語ではオーバーフローで例外の発生するadd命令は使わないでaddu命令を使う
キャリーフラグはないが加算する前の数より、
加算後の数が小さければ桁あふれが発生したと考えられるので
これを利用して多倍長演算を行う

キャリーフラグがなくても、こんな感じで、桁あふれと桁借りを検出できる
http://d.hatena.ne.jp/tociyuki/20140906/1410012689

170ナイコンさん2018/06/17(日) 19:43:31.00
MIPSのトリッキーなコードの多さを見ると、ステータスレジスタがないのは欠陥と言わざるをえないだろう。
MIPS登場後、影響を受けて、ステータスレジスタを排除したアーキテクチャはないし。

171ナイコンさん2018/06/17(日) 19:47:01.83
>>167-169に書かれてることはMIPSのCコンパイラでアセンブラ出力したコードみればわかることなのに
知ったかぶりして>>165みたいなこと書くやついるのな

172ナイコンさん2018/06/17(日) 19:47:59.21
>>170
RISC-VはMIPSと同じでフラグはないぞ

173ナイコンさん2018/06/17(日) 19:48:13.70
判定が遅い → バイナリ見る → 変な処理が入ってる → よし、アセンブラで書いて直接削除してしまえ → バグ混入

174ナイコンさん2018/06/17(日) 19:49:50.77
MIPS信者がまた8bitCPUスレで暴れている。彼らは32bitスレでは暴れない。勝てないからだ。

175ナイコンさん2018/06/17(日) 19:56:13.09
>>171
キャリーフラグがないことで遅くしかならないことは明白だろう。欠陥は欠陥。
キミはそれを知ってるのに知らないフリをしている。

176ナイコンさん2018/06/17(日) 19:58:16.26
> キャリーフラグがないことで遅くしかならないことは明白だろう。欠陥は欠陥。

RISCの思想を理解してない無能↑

177ナイコンさん2018/06/17(日) 20:04:03.21
これは説明せねばなるまい。RISCの思想をご存知だろうか。端的に言うと手抜き。
当時は手書き設計だったがため、キャリーの配線するのが面倒だからという理由でキャリーは削除された。
面倒なことはコンパイラがやってくれるからCPU設計者には楽をさせろということだ。

自分が楽をするためであって、コンピュータが効率的に動作する目的ではない。それがRISCの思想。

178ナイコンさん2018/06/17(日) 20:06:08.92
>>170
>MIPS登場後、影響を受けて、ステータスレジスタを排除したアーキテクチャはないし。
IntelのItaniumは?
ADD,SUB等汎用レジスタ操作にフラグは無く、比較操作の結果をプレディケートレジスタprにという形だったはず。

179ナイコンさん2018/06/17(日) 20:07:08.75
RISCってコンパイラの使用が前提だからフラグは要らないって考えだよ。

180ナイコンさん2018/06/17(日) 20:13:05.59
プレディケートレジスタはステータスレジスタの一種だと思いますけど、
市場で失敗したアーキテクチャばかりという自虐ネタですね。意図は分かります。

181ナイコンさん2018/06/17(日) 20:20:42.13
Cコンパイラが出力した64bit加算($4:$2 = $5:$4 + $7:$6)
addu $2,$4,$6
sltu $8,$2,$4
addu $3,$5,$7
addu $4,$8,$3


Cコンパイラが出力した64bit減算($4:$2 = $5:$4 - $7:$6)
subu $2,$4,$6
sltu $8,$4,$2
subu $3,$5,$7
subu $4,$3,$8

182ナイコンさん2018/06/17(日) 20:31:03.19
add
adc
のほうが簡単だよな。Z80はMIPSより優れている。

183ナイコンさん2018/06/17(日) 20:55:41.06
RISC-Vもフラグがないからさほど問題ないんだろうな
64bit CPUが一般的になった今なら64bit演算を多用するなら64bit CPUを使えばいいわけだしな
128bit演算などあまり使わない
RISC-VもMIPSと同様に64bitアーキテクチャがあるしな

184ナイコンさん2018/06/17(日) 20:58:58.60
遅延スロットを廃した MIPS と言われるだけあって RISC-V も似たようなコードになるなあ
https://godbolt.org/g/h8jYdx

185ナイコンさん2018/06/17(日) 21:13:51.99
>>183
intelなんて前世紀に128bit演算追加してるというのに。今は512bit演算の時代ですよ。

あなた時代錯誤してますよね。あっ、私が時代錯誤してました。
ここ昔のPCスレでしたね。未来をバラしてすみません。

186ナイコンさん2018/06/17(日) 21:32:34.62
>>183
128bit演算いらないとか所詮教育用で実用目的じゃないのは明らかだな。
CPUがサポートし、今時のCコンパイラもint128をサポートしてるのに。
教育で欠陥設計を正しい設計と洗脳してるとなるとその害悪は相当なものだ。

187ナイコンさん2018/06/17(日) 21:47:45.49
> intelなんて前世紀に128bit演算追加してるというのに。

何の話かわからんがまさか↓の話をしてるんではないだろうなあ
https://ja.m.wikipedia.org/wiki/128ビット
> SIMD命令セットのSSEやAltiVecは、128ビットレジスタを、4つの32ビット値として並列演算し、一度に128ビットの演算ができる。128ビット長の数値を操作できるわけではない。

188ナイコンさん2018/06/17(日) 22:08:26.73
なんでMIPS屋はフラグ排除に拘ってんだ? 必要なときになければ遅くしかならないだろう。
ワイヤードロジック最強なんて常識じゃないのか。

>>181← これ意味分かるか? $4を壊してるし、フラグあれば2回で済む演算が4回になってる。遅くしかならない。

189ナイコンさん2018/06/17(日) 22:42:02.95
フラグはOoOの邪魔になるんだよ
依存関係の判断回路が複雑になる
そもそも32bit環境で64bit加減算の頻度は高くない

190ナイコンさん2018/06/17(日) 22:44:24.74
依存関係を減らすためにx86は別のフラグをキャリーの意味で使うような命令まで作っちゃった
複雑化の一途

191ナイコンさん2018/06/17(日) 22:45:46.41
>>188
> なんでMIPS屋はフラグ排除に拘ってんだ? 必要なときになければ遅くしかならないだろう。
パイプライン制御が面倒だからだよ
必要な時はそんなにないから必要な時だけレジスタに設定する方が全体は速くできる

> >>181← これ意味分かるか? $4を壊してるし、フラグあれば2回で済む演算が4回になってる。遅くしかならない。
壊してるのは$8だし、パイプラインを乱さないからそれほど遅くならない

192ナイコンさん2018/06/17(日) 22:46:33.65
フラグ排除もフラグを最大限に利用も
それぞれ一長一短
だから両方のアーキテクチャが存在する

193ナイコンさん2018/06/17(日) 23:38:21.94
SIMDの演算はフラグなんて使わない
フラグ無しの否定はSIMDの否定だ

194ナイコンさん2018/06/17(日) 23:43:03.02
>>191
> パイプライン制御が面倒だからだよ

やはり、面倒だからか。結局、MIPS設計は手抜きなんだよ。
だいたい今時128bit演算はしないとか、必要なときはそんなにないとか、全部キミの根拠のない妄想、期待であって、
実際は、C言語は例外的で、ほとんどの高級言語はOverflowをトラップするんだよ。つまり毎回二度演算してるということ。

> ($4:$2 = $5:$4 + $7:$6)
> addu $4,$8,$3

> 壊してるのは$8だし、

おまえの頭が壊れてる。

195ナイコンさん2018/06/17(日) 23:53:34.90
RISCとして普及してるAVRはステータスレジスタあるし、add、adc、lsl、rolも1clockで終わるのでパイプラインなんて乱れてません。
MIPS信者が勝手に言ってる戯言であって、RISCは関係ないので巻き込まないでくださいね^^

196ナイコンさん2018/06/17(日) 23:58:17.89
>>185
> intelなんて前世紀に128bit演算追加してるというのに。

>>186
> 128bit演算いらないとか所詮教育用で実用目的じゃないのは明らかだな。
> CPUがサポートし、今時のCコンパイラもint128をサポートしてるのに。

>>194
> だいたい今時128bit演算はしないとか、必要なときはそんなにないとか、全部キミの根拠のない妄想、期待であって、

↓見てどう思う?
https://godbolt.org/g/SxNKFS

197ナイコンさん2018/06/17(日) 23:59:48.57
>>195
> RISCとして普及してるAVRはステータスレジスタあるし、add、adc、lsl、rolも1clockで終わるのでパイプラインなんて乱れてません。

せめてOoO実行するアーキテクチャ挙げれや

198ナイコンさん2018/06/18(月) 00:10:00.75
>>194
> だいたい今時128bit演算はしないとか、必要なときはそんなにないとか、全部キミの根拠のない妄想、期待であって、
64bitはともかく128bit演算なんて何に使うんだよ...
具体例出してみ

> 実際は、C言語は例外的で、ほとんどの高級言語はOverflowをトラップするんだよ。つまり毎回二度演算してるということ。
何を言いたいのかわからん
トラップしたいならトラップする命令使えばいいだけ
そもそも「MIPSはCに向いてないと言えよう。」とか言ってたのに指摘されたらC言語は例外とか笑えるわ

> おまえの頭が壊れてる。
アセンブラ読めないなら無理すんなよ w

199ナイコンさん2018/06/18(月) 00:12:11.41
これ以上に、失敗したアーキテクチャを羅列しろと言うのか。

200ナイコンさん2018/06/18(月) 00:13:55.33
>>195
誰もパイプラインが乱れるなんて書いてないだろ w
そう書くこと自体がわかってない証拠
>>197の言うようにOut-of-Orderについて勉強してから出直してこいや

201ナイコンさん2018/06/18(月) 00:14:24.64
MIPSきのこスレの者です。同胞が迷惑かけてすみません。 >>198 おい、帰るぞ!!

202ナイコンさん2018/06/18(月) 00:26:41.11
>>200
> パイプラインを乱さないからそれほど遅くならない

> Out-of-Order

現実、IPC高いのはフラグレジスタ持つx86系なんだよね。MIPSはパイプライン設計も手抜きなだけです。
フラグあると命令数が増えます。事実です。人は自分の脳みそのキャパを超えると単純化、シンプルにしようとします。
でもそれは彼の限界であって合理的な結論ではありません。

ジョブスも以前、マウスボタンをひとつにしました。複数あるのは自分には複雑すぎるというのです。
しかしまた複数に戻しました。過ちを認めたのです。MIPS信者もジョブスの素直さを見習ってほしいものです。

203ナイコンさん2018/06/18(月) 00:32:09.70
> 現実、IPC高いのはフラグレジスタ持つx86系なんだよね。

内部で命令の変換やってるx86挙げて何言いたいのかサッパリわからんわw

204ナイコンさん2018/06/18(月) 00:54:27.79
頭の悪い奴だな。単純化しすぎて内部で命令変換とか使えないからMIPSは困ってるという話だよ。
さっきの例をOoOしても3clockだろう。Pentium、AVRは2clock。超えられない壁なんだよ。
OverflowのチェックならMIPSはもう一度同じ演算をする必要すらある。一方Pen、AVRは必要ない。2clockと1clockだ。

結論 : フラグレジスタ排除は遅くしかならない。そのようなアーキテクチャがあれば欠陥アーキテクチャである。

205ナイコンさん2018/06/18(月) 01:02:56.05
> 必要な時はそんなにないから必要な時だけレジスタに設定する方が全体は速くできる

Z80でフラグレジスタ禁止にしてみようぜ。

Σ(゚Д゚) 条件ジャンプができない!!!

206ナイコンさん2018/06/18(月) 01:05:38.75
> 必要な時はそんなにないから必要な時だけレジスタに設定する方が全体は速くできる

遅い例しか思い浮かばない。速い例を一つでも出してくれないか。

207ナイコンさん2018/06/18(月) 03:34:55.45
AVRスレでも暴れてたMIPS信者ならADC命令の存在を知らなかったから
キャリーの役割が何かすら全く理解していないよ。Z80アセンブラも知らないと思う。

208ナイコンさん2018/06/18(月) 03:45:44.99
>>197
R3000ってOoO実行なのか?

209ナイコンさん2018/06/18(月) 04:01:20.40
キャリーオーバーなきゃいいけど例外はペナルティでかすぎだわな
将来性的に嫌われるかもなRISC-Vは128の命令セット策定してるし
個人的にキリがいいのは256だと思うが

210ナイコンさん2018/06/18(月) 04:15:33.63
MIPS256ならフラグは要らない
つまりアーキのバス幅で脱皮していくみたいな設計思想ならフラグは要らないわな
今日の俺ふなっしーよりもキレキレかも いや今現在マルチスレッド関係のバグで
キレ気味なんだがな

211ナイコンさん2018/06/18(月) 04:19:02.50
>>188
アセンブラしかしらない人にはコンパイラの挙動は理解できないよ
使わないレジスタを壊して何が悪いんだろうか
MIPSで内容を壊してはいけないレジスタは$16-$23と$28-$31だよ
$26-$27はOS用のリザーブで$0はゼロレジスタ
コンパイラとアセンブラの併用をしたことないの?

212ナイコンさん2018/06/18(月) 04:26:46.51
ちなみに$4-$7は関数のパラメーターセット用のレジスタだが
後で使うパラメーターはメモリに保存しておいて
コンパイラはテンポラリなレジスタとしても多用してる

今時32bitや64bit CPUではコンパイラとアセンブラを併用するのが当たり前のなのに
コンパイラの関数呼び出し規約を知らないでプログラミングしてるとは驚きだ

213ナイコンさん2018/06/18(月) 04:31:42.71
質問には一切答えないところ見るとAVRスレで暴れてた人みたいだね。

214ナイコンさん2018/06/18(月) 04:32:51.65
>>207
今時、MIPSのアセンブラしかしらない人がどこにいるんだ?
たいていの人はアセンブラ覚えるのにx86あたりから入るか
MIPSのアセンブラから入ったとしてもx86のアセンブラくらい勉強するだろ
最近ならARMのアセンブラだって勉強するよな

215ナイコンさん2018/06/18(月) 04:36:11.35
MIPSアセンブラの定石も知らず、RISC-Vもフラグがないことを知らなかった
AVR屋が暴れてるのかな?
アセンブラしか知らずにC言語の常識も知らない
8bit屋にはやっぱりC言語は無理なのかな

216ナイコンさん2018/06/18(月) 04:37:42.54
ちなみに俺は4時に起きたわけで
夜中、寝ている間は別の人の書き込みだぞ
ひとりが書き込んでると思ってるみたいだが

217ナイコンさん2018/06/18(月) 04:40:22.47
>>214
MIPSスレにいる。AVRスレで暴れてた。
add
adc
と言ってもさっぱり理解しないで、ずっと >>211-212 みたいな感じで自分の知ってることだけ、
これは知らないのか?これはどうだ?という話続けてた。論法が同じなのでたぶん同一人物。

218ナイコンさん2018/06/18(月) 04:41:31.07
AVRスレなんていかないし
妄想が激しすぎてるぞw

219ナイコンさん2018/06/18(月) 04:43:36.46
お前ら朝はえーな 俺は寝るよ

220ナイコンさん2018/06/18(月) 04:44:10.46
add、adcなんてx86にもARMにもZ80にもあるから当たり前すぎだろw
ここに出入りしてる人でZ80のアセンブラ知らない人っているのかよ

221ナイコンさん2018/06/18(月) 04:49:12.53
>>215
質問をスルーするなよ。R3000ってOoO実行なのか?

222ナイコンさん2018/06/18(月) 04:50:17.89
MIPSを開発したのはスタンフォード大学の学長にもなったジョン・ヘネシー教授だからな
CPU界の偉大な功績者の一人だし、その人が考えた命令セットをただのアセンブラ屋がけなしてもどうにもならないよ
頭の堅い人には理解できないだけ

223ナイコンさん2018/06/18(月) 04:52:36.48
>>220
だから質問に答えろよ。キャリーがあると遅くなる例と、キャリ-がないと速くなる例だよ。
ご自慢のR3000でさ。

224ナイコンさん2018/06/18(月) 04:53:32.31
>>183以降の発言は俺じゃないからな
しかし、SSEやAVRが128bit整数や256bit整数の演算をしてると思ってたアホか?
AVRにはSIMD命令はないようだがな
CPUの命令セットを知らないのはどっちなんだろうなw

225ナイコンさん2018/06/18(月) 04:54:43.69
AVRスレのMIPS信者も質問には絶対答えなかったよ。
ここといい、AVRレスといい、8bit相手ばかりなんだよな。MIPSのライバルは8bitCPUなんだよ。
ARMやx86には全く勝てる気がしないのさ。

226ナイコンさん2018/06/18(月) 05:02:42.14
>>224
R3000の命令熟知してるんですよね。質問に答えて。

キャリーがあると遅くなる例と、キャリ-がないと速くなる例。これだけひっぱるんだから期待していいですよね。

227ナイコンさん2018/06/18(月) 05:05:42.23
>>223
俺は知らんよ
MIPSは16bitのイミディエイトロードでさえaddiu $4, $0, 0x1234やori $4, $0, 0x1234で代用するようなCPUだ
あまり使われないことに専用命令を用意するよりも少しでも命令数を減らしたかったんだろうな
MIPSが考案された当時は64bit演算なんてあまり使われなかったんだから
32bitのプログラミングでlong long intやint64_tはあまり使われないだろ?

228ナイコンさん2018/06/18(月) 05:05:43.26
ダッダッダッ MIPS信者は逃げ出した。

229ナイコンさん2018/06/18(月) 05:08:06.27
日本人は細かいことに気を使いすぎて全体が見えない人多いよな
8bit CPU使いが64bit整数の演算のことを気にするとはな
C言語の32bitプログラミングでlong long intやint64_tを多用することなんてないぞ

230ナイコンさん2018/06/18(月) 05:13:22.11
AVR信者はAVRを出してたAtmelがMicrochipに買収されて
そのMicrochipが出してるPICの32bit版のPIC32がMIPSコアを使ってるから
MIPSを必要以上に嫌ってるのかもしれないけどな

231ナイコンさん2018/06/18(月) 05:20:58.11
68020のトランジスタ数は約20万
68030のトランジスタ数は約30万
80386のトランジスタ数は27万5000
R3000のトランジスタ数は約11万
命令セットが単純な分、レジスタが多くても必要なトランジスタ数は少ないわけ

232ナイコンさん2018/06/18(月) 05:29:26.07
結局、MIPSがCに向いてる理由は何ひとつでなかったな。そしてフラグレジスタがないから速いという謎理論。
単に8bitCPUよりはCに向いてると言いたかっただけ。486が出てくれば逃げ出す他ない。

233ナイコンさん2018/06/18(月) 05:32:58.63
MIPSの組み込み向けコアのM4Kコアなんてゲート数3万5000だぞ

234ナイコンさん2018/06/18(月) 05:37:14.17
フラグレジスタがないから速いんじゃなくて、命令セットを可能な限り単純化したから
少ないトランジスタ数でマイクロコードを使わずにすべてハードワイヤードで設計できたんだよ
R3000の頃のRISCはハードウェアは可能な限り単純化して
コンパイラの最適化で性能を上げるものだったんだから

235ナイコンさん2018/06/18(月) 05:41:16.48
Cに向いてるCPU、なんて言い回しあんのかしら

236ナイコンさん2018/06/18(月) 05:46:06.70
>>232
486時代はMIPSが一番元気がいい時代だったぞ
マイクロソフトでさえACE (Advanced Computing Environment)イニシアチブという団体を作って
Windows NTとSCO UNIXをOSにして新しいパソコンのプラットフォームを作ろうとしてたくらいだ
コンシューマではPlaystationにR3000コア、NINTENDO64にR4300コアが使われた
MIPSは1993年にシリコングラフィックスに買収されてシリコングラフィックスのコンピュータに使われた
シリコングラフィックスのコンピュータがCG映画に使われて注目されて、MIPSが一番輝いてた時代

237ナイコンさん2018/06/18(月) 05:50:01.24
x86がRISCを駆逐したのはPentium ProやPentium II辺り
Pentium ProでRISCに性能で追いついたからな
1995年まではRISCの勢いがすごかったが1996年あたりから急激にしぼんだのはそのせい

238ナイコンさん2018/06/18(月) 05:52:54.13
PSがいけなかった。MIPS信者に見てはいけない夢をみさせてしまった。
コンシューマなんて実はCPUは別になんでも良かったんだ。68kでもPen3でもpowerPCでもARMでも。
実際、多くのメーカーが機種変するたびに変更される。重要なのは解析されないことだから。

239ナイコンさん2018/06/18(月) 05:59:15.12
3Dゲームの世代だったからな
当時、3Dで先頭を走ってたのはシリコングラフィックスで
そのシリコングラフィックスがMIPSを使ってたから
3Dゲームを売りにしたPlaystationやNINTENDO64の時代にMIPSを採用するのは自然なこと

240ナイコンさん2018/06/18(月) 06:07:18.72
3DO REALがARMを採用してたな
SEGA SATURNはSH-2
PC-FXは自社製のV810

241ナイコンさん2018/06/18(月) 06:12:25.57
> 32bit以降のCPUでC言語の実装を考慮してないCPUなどないでしょ

> MIPSはスタンフォード大学のRISCの研究から生まれたCPUでいきなり出てきたわけじゃないからな
> その研究から生まれたMIPS-Xがあって、それを改良して実用的にしたのがR2000やR3000
> C言語に向いてなかったらそもそもUNIXマシンで採用されるわけがない

やはりMIPSはCに向いてると言ってる。

242ナイコンさん2018/06/18(月) 06:16:16.95
C言語に向いてるCPUという表現はどうか知らないが
明らかにC言語に向いてないCPUは存在する
その代表格がPIC
8080やZ80もあまりC言語に向いてないCPUではある

243ナイコンさん2018/06/18(月) 06:29:07.99
32bitのマイクロプロセッサでC言語に向いてないプロセッサを俺は知らない

244ナイコンさん2018/06/18(月) 06:30:17.78
関数コール用のスタックフレームの生成とか
sparcのレジスタウインドウみたいなのも
C言語向けとかなんとか

まあスレタイの8bitの話にもどりましょうよ みたいなw
アセンブラの代わりー ぐらいのノリで8bit-Cはあってもいいはず

6502はスタックのアレでCやらPascalやらは引数スタックみたいの別に
用意してたとかなんとか

245ナイコンさん2018/06/18(月) 06:51:12.71
>>226
add
adc
これパイプラインストールするでしょ
MIPSのIの意味を調べたら君の疑問は解けると思う
理解力があればだけど

246ナイコンさん2018/06/18(月) 06:53:46.05
>>243
Java Chipとかかなw

247ナイコンさん2018/06/18(月) 07:13:09.46
>>201
勝手に一人で逝っとけ、ボケ

>>202
> 現実、IPC高いのはフラグレジスタ持つx86系なんだよね。
時代が違うもの比較してどうする
当時のトランジスタ数で命令変換できるならやってみなよ
まあジョブズとか話し逸らしはじめたから劣勢は意識してるのかもな w

248ナイコンさん2018/06/18(月) 07:22:30.88
x86がRISCに追いついたPentium ProやPentium IIは内部でμOPに変換してるんだよな
もう、MIPSの話を蒸し返すのはやめようぜ

249ナイコンさん2018/06/18(月) 07:22:49.74
>>245
> MIPSのIの意味を調べたら君の疑問は解けると思う

add、adcってMIPSの話じゃないですよね。パイプラインがストールって何のCPUの話ですか?
なぜいつも説明がないんですか? 相手の理解力は関係ないですね。何も説明しないで逃げてばかりですから。

250ナイコンさん2018/06/18(月) 07:24:13.45
>>247 ←こいつです。いつも8bitスレでMIPSの布教活動して論破されてる馬鹿は。

251ナイコンさん2018/06/18(月) 07:28:07.11
>>239
一度築いたシェアが簡単に奪われたのだから、やはり致命的な欠陥があったんだろうな。

252ナイコンさん2018/06/18(月) 07:29:39.84
そもそも8bitのこのスレでMIPSが遅いとかMIPSがC言語に向いてないとかいう
独自の持論を展開してのは>>250じゃねえの?

253ナイコンさん2018/06/18(月) 07:31:15.70
>>245 >>252
説明まだ? 一体何のCPUの話かぐらい言わないと。Z80も8086もAVRも最新Xeonもその命令持ってるんですよ。

254ナイコンさん2018/06/18(月) 07:33:40.31
>>252
いつもMIPS信者が暴れだす。たぶん同じ奴。しかも8bitスレ限定。
ARMやx86スレでは暴れない。どう足掻いても勝てないから。

255ナイコンさん2018/06/18(月) 07:47:02.14
>>249
> add、adcってMIPSの話じゃないですよね。
当たり前だろ、何を言ってるんだよw

> なぜいつも説明がないんですか? 相手の理解力は関係ないですね。何も説明しないで逃げてばかりですから。

だから調べてこいよ
キャリーが確定するのは演算の最後
そのキャリーを次の演算で使うのは難しいケースがあるって話し
ADD, ADC程度なら通常大丈夫だけど、ADD側のアドレッシングモードが複雑な場合などで間に合わなくてストールしてしまう場合がある
分岐はもっと深刻で分岐命令の早い段階でフラグを参照するからフラグを更新する命令と連続するとほぼ確実にストールする
遅延スロットとかでググれ

>>250
煽るしかできないバカは出てくんな、ウザいわ

256ナイコンさん2018/06/18(月) 07:54:59.81
>>136,>>165あたりからMIPSディスり発言してるのがいるな
以前PICのスレで>>165と全く同じような発言をしてMIPSの定石を知らないだけと
論破されてた人が居たが同じ人か

>>251
ファブレスの限界だったのでは?
シリコングラフィックスがMIPSからIteniumに移行してからMIPSの製造から東芝やNECは撤退した
最近ではスマホの影響でARMが大量に使われて
そのおかげでTSMCやサムスンなどのファウンドリが急成長してIntelに製造技術で追いついてきたけどね

257ナイコンさん2018/06/18(月) 08:00:27.07
ARMはARM7TDMIでThumbという命令の長さが16bitの命令セットを実装したことで
ノキアに採用され携帯電話向けで大躍進
携帯電話で多く採用されたことからiPhoneやAndroidにも採用されさらに大躍進した経緯がある
x86もIBM PCに8088が採用されたのがきっかけ
x86もARMも性能面で優れてたから普及したわけじゃないんだよな

258ナイコンさん2018/06/18(月) 08:04:00.79
この記事はCQ出版の記事のサンプルだがARMの歴史が簡単にまとめてある

ARMの歴史―ARM1からARM7まで
http://www.cqpub.co.jp/hanbai/books/33/33291/33291_pro.pdf

259ナイコンさん2018/06/18(月) 08:08:30.94
>>253
バカなの?
Z80にパイプラインなんてないし8086のパイプラインはなんちゃってだよ
(まともなパイプラインは80386から)
AVRは知らんけど最新のXeonとか時代が違うって何度も言わせるなよ

>>254
技術的な話についてこれないなら黙ってろ

260ナイコンさん2018/06/18(月) 08:12:44.44
>>256
PICスレで暴れてたMIPS信者がなんでこんなとこにいるんだよ?
MIPS信者はウザイからPIC32はスレ分けろで結論出てただろ。
ほんとこいつ最悪だよな。いつも下位CPUのところで暴れやがる。

261ナイコンさん2018/06/18(月) 08:13:24.17
>>251
ニュースとか見ないのか?
お前、なんで東芝がメモリー事業を売るはめになったかも理解できてないだろw
半導体ってモノのデキより資金力の方が重要だったりする

262ナイコンさん2018/06/18(月) 08:15:38.22
>>259
まただよ。いくら質問しても言わず、どのCPUか全く言わないからいくつか例を挙げたら全否定して、これだのパターン。

典型的無能学者のマウンティング。少しは恥を知れ、カス。朝生じゃねーんだよ、ここは。

263ナイコンさん2018/06/18(月) 08:16:25.27
>>261
また質問からかよ。おまえは先にすべての質問に答えろ。

264ナイコンさん2018/06/18(月) 08:33:06.54
>>205
> Z80でフラグレジスタ禁止にしてみようぜ。
>
> Σ(゚Д゚) 条件ジャンプができない!!!

Z80知らないんだな。DJNZ命令で条件ジャンプできるぞ。

265ナイコンさん2018/06/18(月) 08:34:35.51
>>255
この人、全く分かってないね。キャリーだからストールするだったのに、アドレッシングが複雑だからになってるよ。
add、adcのただの組み合わせ回路の話が、分岐の話にもなってる。
しかも一回演算のキャリーでは遅延し、二回演算のMIPSでは遅延しないというオカルト論理。どうみても前者のほうが高速。

つまり調べたらキャリーは全く関係ありませんでしたってことだよね。
AVRで結論でてるでしょ。add、adcで2clockで終わるって。キャリーでストールするんじゃなかったんですか?

結局R3000だとその代替の4命令で何clockかかるんですか? 2clockじゃとても終わりませんよね?

266ナイコンさん2018/06/18(月) 08:48:04.55
よくもまあ、32bitのプログラミングであまり出てこない多倍長演算の問題や64bit演算の問題で盛り上がってるね
逆に言えば、MIPSの突っ込みどころはキャリーフラグがないことだけってことかな

ARMは組み込み向けではThumbに32bit長の命令を追加したThumb-2のコード密度が高いことが評価されてる
組み込み向けのCortex-MではARM命令は実装されずにThumb-2のみになってる

267ナイコンさん2018/06/18(月) 08:57:05.22
MIPSもMIPS16eやmicroMIPSという命令セットで組み込み向けのARMに対抗してて
PIC32ではMIPS16eを使ったM4KコアやmicroMIPSが使えるmicroAptivコア、M5150コアが使われてる

268ナイコンさん2018/06/18(月) 08:59:00.06
教育関係がウザイのは商業的に失敗してもあるいは失敗は明らかなのに研究を辞めないところだな。

269ナイコンさん2018/06/18(月) 09:31:39.33
> 結局R3000だとその代替の4命令で何clockかかるんですか?

なんで答えないんだろう? これがキャリーを排除すれば速くなるというMIPSアーキテクチャの成果だよね。

270ナイコンさん2018/06/18(月) 11:39:26.86
なんでR3000だと〜なんて訊いてるかというとMIPSでもスーパースカラやOoO実行される例を挙げられると都合が悪いからだしなあ、相手にする奴もおらんだろ

271ナイコンさん2018/06/18(月) 12:02:51.72
486より古いR3000を持ち出して遅い遅いと大騒ぎかあ、馬鹿じゃね?

272ナイコンさん2018/06/18(月) 12:32:16.90
>>262
いやいや、スレの内容理解してたらパイプラインを持たないCPUとかR2000/3000と時代が全く異なるCPU挙げてもバカって言われるのはわかるだろ w
>>259にも書いたけど80386まではまともなパイプラインを持てなかった
その時代にパイプラインストールを避けるためのひとつの手段だよ
当然お前らみたいにそんなもん速くなるわけねーだろって奴等もいたけど議論の上採用したってこと

273ナイコンさん2018/06/18(月) 12:35:54.76
R3000と同時代前後の80386や80486を例にしてどれだけ速かったか語って欲しいもんだわw

274ナイコンさん2018/06/18(月) 12:37:27.12
>>263
> また質問からかよ。
それ質問ちゃうで、単にバカにしてるだけ
ひょっとして気づかなかったの? w
ちな、答は最下行な

275ナイコンさん2018/06/18(月) 12:43:05.95
>>265
わかってないのはお前さんの方だよ
アドレッシングモードの話は演算タイミングが違うようになるからストールの可能性か発生するって話しな
なんでRISCは単純なアドレッシングモードしかサポートしないのかもわかってないでしょ
分岐の話しはアホにもより分かりやすくしたつもりなんだけど想像以上にレベルが低かった w

> AVRで結論でてるでしょ。
そのAVRの型番は?
まさかと思うけど全然世代が違うとかないよね?

276ナイコンさん2018/06/18(月) 12:59:02.30
いまどきのx86の速度を重視したプログラミングを理解してたらフラグは足かせになってることぐらいわかりそうなもんだがなあ、つーか明らかにソッチ方面の知見ない奴には何言っても無駄だよなあ。

277Artane. ◆1o3c8RYIzjU0 2018/06/18(月) 14:20:47.88
>>186
組み込み用なんかだと、128ビット演算は殆ど使わない(ここ大事)ので、
必要に応じてソフトでやる。とか、普通にある気がしますけど。
センサーのデータ取り込みとか、工業用機械のサーボ動作とか。
消費電力の少なさやリアルタイム性が大事で、ややこしい計算は、別にあるコンピュータでやらせるって、今時は特にふつうだと思いますよ。

278ナイコンさん2018/06/18(月) 16:32:01.52
分岐の手がかりだけなら要らねえかもしれんがCフラグは無いと困る
ローテートも無いと困る

279ナイコンさん2018/06/18(月) 16:57:35.12
128演算て何用だろうね多桁電卓?横長だなビックデータとかか
例外処理じゃなくてキャリーオーバーで分岐とかできなかったんかしら
それか例外出さない命令のあとに大小比較か最上位ビット見て分岐

280ナイコンさん2018/06/18(月) 18:13:04.98
>>279
MIPSでオーバーフローで例外が発生するのはaddとsubでadduとsubuは例外は発生しない
加算、減算は符号付、符号なしで結果は同じになるので
MIPSのCコンパイラではaddやsubは一切使わず、adduやsubuしか使ってない
多倍長演算の時のキャリーやボローの検出は>>181のやり方でやってる

281ナイコンさん2018/06/18(月) 18:14:06.93
アセンブラは8086で卒業しちまった俺には、マニアックすぎて付いてけねぇ話題が続いてるなぁw
そんな素人の考えだけどフラグ反映させる必要が無くて処理速度ほしいなら、それ用の命令作ればいいじゃね?
いくらRISCだっても、その程度の命令をつくるぐらいの余裕はあるとおもうんだがねぇ。

プログラマが(コンパイラが、かもしれんけど)わざわざ判定のために最上位ビット見るコードを書いてそれを走らせるとか無駄な気がする。
判定のためのコードを入れるぐらいならフラグ確定まで遅延させても大差ないだろうし、遅延しても「プログラマ(コンパイラ)が書いた判定のためのコード」を実行させるより効率はいいと思うんだよな。


で、いつになったら俺がついていけそうな8ビットの話題に戻るのかな?

282ナイコンさん2018/06/18(月) 18:34:15.12
MIPS64でCコンパイラが出力した128bit加算($4:$2 = $5:$4 + $7:$6)
daddu $2,$4,$6
sltu $8,$2,$4
dext $8,$8,0,32
daddu $3,$5,$7
daddu $4,$8,$3


MIPS64でCコンパイラが出力した128bit減算($4:$2 = $5:$4 - $7:$6)
dsubu $2,$4,$6
sltu $8,$4,$2
dext $8,$8,0,32
dsubu $3,$5,$7
dsubu $4,$3,$8

283ナイコンさん2018/06/18(月) 19:06:28.09
>>281
>いつになったら俺がついていけそうな8ビットの話題に戻るのかな?

もともとキチガイの隔離スレだぞ、何言ってんの?

284ナイコンさん2018/06/18(月) 19:21:44.79
>>283
キチガイもいちおう「8ビットじゃC言語有りえねぇ!」って8ビットには言及してたからね。
64ビットだのRISCだのは、まったく着いていけねぇんで疎外感バリバリなのよ、おじちゃんはw

285ナイコンさん2018/06/18(月) 21:20:01.65
えっ、マジでAVRの型名きいただけで黙ちゃったの?w

>>281
> そんな素人の考えだけどフラグ反映させる必要が無くて処理速度ほしいなら、それ用の命令作ればいいじゃね?
それ専用の命令が stu な
お前の考える程度のことを誰も思い付かないとか思っちゃった? w

286ナイコンさん2018/06/19(火) 05:07:14.69
なんか急にアンチMIPSが増えたよな。

287ナイコンさん2018/06/19(火) 05:11:57.47
>>285
stuじゃなくてsltuだろ

あと
dext $8,$8,0,32
これは$8に入ってる32bitの値を64bitの値にゼロ拡張する命令

288ナイコンさん2018/06/19(火) 05:17:15.71
あとsltuはキャリーやボロー検出の専用命令じゃなくて
sltu $8,$2,$4
の場合、$2と$4を比較して$2が小さければ$8に1がセットされ
それ以外の時は$8に0がセットされるという命令

加算した後の値が加算前の値より小さければ桁あふれが発生してることを利用してる

289ナイコンさん2018/06/19(火) 05:17:39.27
>>282

> Cコンパイラが出力した64bit加算($4:$2 = $5:$4 + $7:$6)
> addu $2,$4,$6
> sltu $8,$2,$4
> addu $3,$5,$7
> addu $4,$8,$3

これ、R3000では何クロックで終わるんですか?

290ナイコンさん2018/06/19(火) 05:21:58.98
減算は減算前の値が減算後の値より小さければ桁借りが発生してることを利用してる

291ナイコンさん2018/06/19(火) 05:23:42.93
>>288

> Cコンパイラが出力した64bit加算($4:$2 = $5:$4 + $7:$6)
> addu $2,$4,$6
> sltu $8,$2,$4
> addu $3,$5,$7
> addu $4,$8,$3

これ、R3000では何クロックで終わるんですか?

292ナイコンさん2018/06/19(火) 05:32:10.33
8bitのCPUだと16bitや32bitとよく使われる変数を計算するのに
多倍長計算が頻繁に行われるかもしれないが
32bitのプログラミングで64bit変数などあまり使われない
同じように64bitのプログラミングで128bitの変数などあまり使われない

8bit、16bitCPUと32bitCPU、64bitCPUとでは多倍長計算の重要度が違う

293ナイコンさん2018/06/19(火) 05:32:28.71
>>290
ここはMIPS詳しい人ばかりなのになんで教えてくれないんですか?

> Cコンパイラが出力した64bit加算($4:$2 = $5:$4 + $7:$6)
> addu $2,$4,$6
> sltu $8,$2,$4
> addu $3,$5,$7
> addu $4,$8,$3

これ、R3000では何クロックで終わるんですか?

294ナイコンさん2018/06/19(火) 05:35:15.20
答えられないからダヨ!

295ナイコンさん2018/06/19(火) 05:35:29.13
>>286
   / ̄ ̄\
 /   _ノ  \
 |    ( ●)(●)
. |     (__人__)  MIPS信者がスレチで荒らすから増えたんだろ・・・
  |     ` ⌒´ノ 
.  |         }  常識的に考えて……
.  ヽ        }
   ヽ     ノ        \
   /   く  \        \
   |     \   \         \
    |    |ヽ、二⌒)、          \

296ナイコンさん2018/06/19(火) 05:43:12.24
AVR信者が噛み付いてるだけだよ
それに答えてるだけ
荒らしてるのはAVR信者

297ナイコンさん2018/06/19(火) 05:45:09.28
>>296
   / ̄ ̄\
 /   _ノ  \
 |    ( ●)(●)
. |     (__人__)  質問に答えればいいだけだろ・・・
  |     ` ⌒´ノ 
.  |         }  常識的に考えて……
.  ヽ        }
   ヽ     ノ        \
   /   く  \        \
   |     \   \         \
    |    |ヽ、二⌒)、          \

298ナイコンさん2018/06/19(火) 05:46:52.94
>>296
嘘つかないでください。何度質問しても誰も答えてくれてません。

> Cコンパイラが出力した64bit加算($4:$2 = $5:$4 + $7:$6)
> addu $2,$4,$6
> sltu $8,$2,$4
> addu $3,$5,$7
> addu $4,$8,$3

これ、R3000では何クロックで終わるんですか?

299ナイコンさん2018/06/19(火) 05:51:17.46
ダッダッダッまたMIPS信者は逃げ出したw

300ナイコンさん2018/06/19(火) 05:51:24.30
速度というならAVRで32bitの加算、減算に何クロックかかるでしょうか?
32bitの乗算、除算は?

それとARMにもADC命令があるというけど、ARMの場合、
Cortex-A9とそれ以前のARMには除算命令がないが
プログラムで除算を実現するより、除算命令があった方が早いのが現実

301ナイコンさん2018/06/19(火) 06:02:39.92
質問返しは荒れるので質問に答えてからにしましょう。
しかもAVRの加算命令クロックは既出です。32bitなら4命令で4clockです。

302ナイコンさん2018/06/19(火) 06:16:45.16
SPARCもV8で乗除算命令が追加されたが、V7までは除算命令はなく、乗算命令もステップ乗算命令しかない

303ナイコンさん2018/06/19(火) 06:18:00.38
答えれないということはMIPSご自慢のR3000は実は相当遅かったんだろうな。
上のほうでもEWS4800は異常に遅いという話も出てたし。
意味不明にストール、ストール言ってるからMIPSには致命的な欠陥があってとにかくストールばかりしてるんだと思う。

304ナイコンさん2018/06/19(火) 06:19:50.55
>>301
R3000なら1クロックだろ
R3000は基本命令は1クロックで実行だから64bit加算だって4クロックだろうな

305ナイコンさん2018/06/19(火) 06:21:12.80
>>303
なんでMIPSがUNIXワークステーションで普及したかわかるか?
当時の68030やSPARCよりも高性能だったからだぞ

306ナイコンさん2018/06/19(火) 06:31:10.72
単にライセンスの囲い込みがなかったからでは

どこでも出しますよーみたいな

307ナイコンさん2018/06/19(火) 06:34:10.85
>>306
ネットに上がってるベンチマークを見てみろよ
SPARCや68030より速いから
当時のSuperASCIIを持ってるが載ってるベンチマークを見るとSPARCや68030よりも速い
MIPSの登場で680x0のUNIXワークステーションは駆逐された

308ナイコンさん2018/06/19(火) 06:36:21.23
やっと質問に答えてくれました。

> Cコンパイラが出力した64bit加算($4:$2 = $5:$4 + $7:$6)
> addu $2,$4,$6
> sltu $8,$2,$4
> addu $3,$5,$7
> addu $4,$8,$3

R3000なら4clockで終わるとのことです。>>304 ←ソース。

結論は出ましたね。キャリーがないと無駄に実行命令が増えて遅くなる。

309ナイコンさん2018/06/19(火) 06:39:55.92
32bitのプログラムの中で64bitの整数なんてどれだけ出てくるんだろうね
それ以前に、当時のCコンパイラだと64bit整数をサポートしてないものも多いぞ
おそらくパソコン向けのCコンパイラは全滅だろうな

310ナイコンさん2018/06/19(火) 06:42:10.54
そもそもAVRのCコンパイラって64bit整数がサポートされてるのか?

311ナイコンさん2018/06/19(火) 07:00:37.86
ストール連呼してたのは64bit整数構造体も知らない子だったのか。
実務でコードを全く書いたことがありませんってことだな。

312ナイコンさん2018/06/19(火) 07:06:33.06
構造体を使わないと64bit整数も使えない時代に64bit演算が早くても意味ないだろうな
だって、演算も関数コールでやるわけだろ?
関数コールの方が64bitの加算、減算よりもずっとクロックは余計にかかるよ

313ナイコンさん2018/06/19(火) 07:12:15.91
わかった、わかった。8bitCPUでC言語? ないないありえないっしょ!!!

314ナイコンさん2018/06/19(火) 07:16:50.43
AVR信者ってまさに木を見て森を見ずだな

315ナイコンさん2018/06/19(火) 07:18:04.82
>>308
なあなあ、
https://godbolt.org/g/RLYRJg

これ↑どっちが速いと思う?

316ナイコンさん2018/06/19(火) 07:20:52.82
MIPSの欠陥が明らかになったことで、
今度はその欠陥は使われない!!!ということを強調したいらしいが、安心してほしい。
MIPSはもう使われないからいくら欠陥があっても何も問題は出ない。

PIC32がエラッタだらけ? ノープロブレム。メジャーな代替CPUはいくらでもある。

317ナイコンさん2018/06/19(火) 07:23:07.43

318ナイコンさん2018/06/19(火) 07:26:00.54
>>316
ああ、PICスレでエラッタ、エラッタ連発して荒らしてるのってAVR信者だったのか

319ナイコンさん2018/06/19(火) 07:28:04.53
>>315
答えを知ってるなら答えを書いて説明してはいかがだろうか。
自分が知ってることをいちいち質問するのは時間の無駄だ。

分からないならそういう上から目線ではなく教えてくださいだろう。
キミのその高圧的な態度は無知な教師によくいるが甚だ不快だ。

320ナイコンさん2018/06/19(火) 07:32:25.56
>>319
> 答えを知ってるなら答えを書いて説明してはいかがだろうか。

なんで?? オマエがどっちが速いと思うか訊いてるのに。

321ナイコンさん2018/06/19(火) 07:36:04.68
なあなあってまさにチンピラの絡み方だな。完全論破されてマジギレしてると思う。スルーしたほうがいい。

322ナイコンさん2018/06/19(火) 07:37:48.46
>>185
> intelなんて前世紀に128bit演算追加してるというのに。今は512bit演算の時代ですよ。

へーそーなんだスゴイネ
参考までにどういうコードになるのか>>315みたいに曝してクレクレ

323ナイコンさん2018/06/19(火) 07:39:07.43
インテル信者は嘘吐きかもの知らずだなw

324ナイコンさん2018/06/19(火) 07:41:32.30
>>317
すごいコードだな
さすがにAVRで64bit加算はつらいか

325ナイコンさん2018/06/19(火) 07:44:30.44
MIPSが8ビットCPUと比べられる程度の存在だってのが良く判りますねw

326ナイコンさん2018/06/19(火) 07:45:19.78
>>323
インテル信者が自分の信仰するCPUについての知識がないわけがないだろ

> intelなんて前世紀に128bit演算追加してるというのに。今は512bit演算の時代ですよ。
これを書いたのはAVR信者だろうな
ろくにx86の知識もない

327ナイコンさん2018/06/19(火) 07:45:36.49
同時に比べられてるi386は目に入らないとかwwww

328ナイコンさん2018/06/19(火) 07:47:48.63
>>326
ここで暴れてるインテル信者はマイクロプロセッサの知識もプログラミングの知識も碌にないよ

329ナイコンさん2018/06/19(火) 07:49:57.93
このスレでIntel信者って暴れてたっけ?

330ナイコンさん2018/06/19(火) 07:51:29.48
都合が悪くなるとすっとぼけるタイプ

331ナイコンさん2018/06/19(火) 07:54:10.60
> 8ビットCPUでC言語? ないないありえないっしょ!

これで一番キレてるのがAVR信者ってことだな
AVRはArduinoで採用されて有名だがArduinoはC++モドキの言語使ってるからな
ろくにアセンブラの知識もないんじゃね?

332ナイコンさん2018/06/19(火) 08:09:42.61
インテル信者 vs MIPS信者

どっちが高速かなんて市場で答えでてるのにこの構図は卑怯じゃないのか。

333ナイコンさん2018/06/19(火) 08:13:04.43
Arduinoの採用CPUは、AVR、ARM、x86です。致命的な理由でMIPSは除外されました。

334ナイコンさん2018/06/19(火) 08:19:26.50
8bitCPU vs MIPS のほうが卑怯だろう。

335ナイコンさん2018/06/19(火) 08:22:47.78
ググったらこんなの出てきたw

http://www.denshi.club/pc/arduino/esp8266iot1-blink.html
> ESP8266はライセンス料金が割安だといわれているMIPSアーキテクチャのCPUを搭載しています。
> ArduinoはこのCPUのコンパイラにも対応しました。

336ナイコンさん2018/06/19(火) 08:24:14.38
>>308
あのー、はしゃいでるところ申し訳ないけど80386も4clockかかるよ
まさか1命令1clockとか思ってないよね? w
https://pdos.csail.mit.edu/6.828/2017/readings/i386/ADC.htm

>>311
煽りしかできないバカは出てくるなって言っただろ

337ナイコンさん2018/06/19(火) 08:25:20.51
>>333
Arduinoにx86はない。Arduino 101で動作してるのはARCだし。
インテルがx86載せた互換機出してたが致命的な問題を解決できずに終了した。

338ナイコンさん2018/06/19(火) 08:26:36.08
>>335 ←あっちこっちで暴れてるESP厨とここで暴れてるMIPS信者が同一人物だと特定されました。

339ナイコンさん2018/06/19(火) 08:30:13.18
結局、暴れてる奴はいつも同じ人物。この世界は狭いなぁ。
昔、自作板で暴れてたARM厨も同じやつだろう。

340ナイコンさん2018/06/19(火) 08:31:36.94
Arduinoなんて詳しくないし、>>335はググったら出てきただけ
煽ってるのはAVR信者

341ナイコンさん2018/06/19(火) 08:32:31.04
よし聞いてみよう。

>>335

おまえ昔、そうやって、自作板でスレチのARMのコピペしまくって荒らしてただろう?

342ナイコンさん2018/06/19(火) 08:42:44.04
匿名掲示板なのに特定とか言うやつ稀にいるけど会話無理タイプよね

343ナイコンさん2018/06/19(火) 08:45:26.57
ググってみたがArduinoはRISC-Vにも対応してるようだな

http://msyksphinz.hatenablog.com/entry/2017/03/10/020000

344ナイコンさん2018/06/19(火) 08:48:08.19
RISC-VもMIPSと同じでフラグがないんだよな

345ナイコンさん2018/06/19(火) 08:51:01.18
RISC-Vの64bit加算も>>184にあるようにMIPSとほぼ同じようなコードになるのか

346ナイコンさん2018/06/19(火) 08:51:46.43
断言するけど、ここでいくら暴れても絶対にPCもスマホもMIPSに置き換わらないから。

347ナイコンさん2018/06/19(火) 09:17:42.19
>>342
図星かよw

348ナイコンさん2018/06/19(火) 09:39:46.29
やっぱ会話無理タイプだわ全然関係ない第三者ですよ

349ナイコンさん2018/06/19(火) 11:28:04.10
>>316
え?MIPSは今でも普通に現役で使われてるけど?
キミ、モノ知らなすぎでしょ

350ナイコンさん2018/06/19(火) 11:32:44.50
まだMIPSの話をするの? スレチどころか板違いですよ?

351ナイコンさん2018/06/19(火) 11:37:50.46
論破されて顔真っ赤にしながらMIPSの話題を出すなと言い出す池沼w

352ナイコンさん2018/06/19(火) 11:39:50.71
MIPSを貶そうと知ったかぶったは良いものの、返り討ちに遭って
顔真っ赤にしながら、MIPSの話題はスレチだから!は、流石にみっともない

353ナイコンさん2018/06/19(火) 11:58:13.58
>>350
MIPSは昔のPCでもないからな。相手にするから粘着して暴れるわけで、MIPSはNG推奨だな。

354ナイコンさん2018/06/19(火) 12:17:38.97
>>350
そう言うのは>>136に言えよww

355ナイコンさん2018/06/19(火) 12:19:41.80
>>353
MIPS(笑) NGなら見えてないはずw

356ナイコンさん2018/06/19(火) 12:24:49.30
(1)荒らし目的のAVR信者がMIPSをディスって挑発

(2)空気の読めないMIPS信者が荒らし目的のAVR信者にマジレス

これの繰り返し

もう、挑発に乗らないでスルーしろよ

357ナイコンさん2018/06/19(火) 12:54:04.26
> もう、挑発に乗らないでスルーしろよ
オマエモナー

358ナイコンさん2018/06/19(火) 20:11:06.44
x86とRISCと比べるなら386までだよねー
486と比べると優位性が無くなってしまうからw

359ナイコンさん2018/06/19(火) 20:47:53.87
ソフトかハード、どちらかで過去の資産でMIPS縛りがなけりゃARMかx64だろ、使うCPUは。

360ナイコンさん2018/06/19(火) 22:58:50.57
>>358
まあ、120万トランジスタも費やしてるからねえ
ちなみにR3000は11.5万トランジスタ
FPUは外付けなのでそれを加えても30万トランジスタにも満たない

361ナイコンさん2018/06/20(水) 00:23:19.53
R3000みたいに古臭いCPUの話はやめて
そろそろR10000の話をしようぜ。

362ナイコンさん2018/06/20(水) 01:11:41.50
NECがかわいそう。

363ナイコンさん2018/06/20(水) 05:30:37.49
黒歴史だったか。

364ナイコンさん2018/06/20(水) 07:34:35.37
C言語にはキャリーもボローないから、コンパイラ使う前提のCPUならキャリーもボローも要らないだろ。

という単純なことも理解できないおバカなAVR信者がMIPSに噛み付いてるってことかな?

365ナイコンさん2018/06/20(水) 10:06:50.61
>>364 ← この人だ。AVRスレでキャリーが何か全く知らなかった人だ。

366ナイコンさん2018/06/20(水) 10:55:47.58
なんといろいろ勘違いしてるよな。こういう奴が大学で研究してるから碌な成果が出ない。

367ナイコンさん2018/06/20(水) 11:14:08.48
AVRのビットコピー便利だよ
Cの貧弱な文法じゃ使いようが無いけど

368ナイコンさん2018/06/20(水) 11:17:12.78
>>364
ここまでキャリーが何か分からない奴はCなんてとても無理だろう。

369ナイコンさん2018/06/20(水) 12:21:02.07
どこが8ビットの話なんだよ^^;

370ナイコンさん2018/06/20(水) 16:09:53.98
>>368
( ´,_ゝ`)プッ

371ナイコンさん2018/06/20(水) 18:39:19.04
今時、MIPSのアセンブラしか知らないやつがいるわけないけどな
AVR信者がキモチワルすぎ
AVR信者はAVRしか使わないのかって話
さすがにAVRしか使わないって人いないだろ
それと同じことでMIPSしか使わない人などいない

372ナイコンさん2018/06/20(水) 19:32:16.67
>>366
世の中RISC CPUだらけなのにその先駆けの一つのMIPSを全否定とか
2大RISC CPU研究の一つのスタンフォード大学のRISC CPUの研究を否定するマイコン大先生か
AVRだってRISCベースのCPUのはずなのに
ちなみにMIPSを開発したジョン・ヘネシーはスタンフォード大学の学長にまでなった人だ

もう一方のUCBの最新のRISC CPUのRISC-Vは、UCBなのにSPARCではなく
MIPSにそっくりと言っていいくらいの命令セットで
MIPSと同じようにフラグもない
RISC-VとMIPSの命令セットを比べてみるといい、かなり似てるから

RISC-Vの概要
https://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/files/docs/RISCVGreenCardv8-20151013.pdf

MIPS32 Instruction Set Quick Reference
https://www2.cs.duke.edu/courses/fall13/compsci250/MIPS32_QRC.pdf


グーグル、オラクル、HPEなどがRISCプロセッサのオープンな命令セットを開発する「RISC-V」参加へ
http://www.atmarkit.co.jp/ait/articles/1601/05/news090.html

海外で急激に盛り上がる新CPU命令アーキテクチャ「RISC-V」
https://pc.watch.impress.co.jp/docs/column/kaigai/1094808.html

373ナイコンさん2018/06/20(水) 19:37:51.29
俺はPICもAVRも使ったこと無いんだよなぁ。

だってンなチンケなプアCPU使う必要ないんだもんw

374ナイコンさん2018/06/20(水) 19:54:49.60
AMDとIntel以外がCISCの命令セットの研究なんてやってもカネにならんからなー。
大学はじめRISCでがんばってAMDとIntelを蹴落とそうと努力するしかないわけですよw
しかし、RISC-Vってもどの程度の成果がでるのかねぇ?

375ナイコンさん2018/06/20(水) 23:18:55.54
>>371
( ´,_ゝ`)プッ adc命令知らなかったじゃんw

376ナイコンさん2018/06/20(水) 23:20:18.18
>>372
いつものMIPS信者だw

普及活動のために必死にコピペするからすぐわかるw

377ナイコンさん2018/06/20(水) 23:24:42.65
>>375
( ´,_ゝ`)ププッ

378ナイコンさん2018/06/20(水) 23:32:29.21
>>377
( ´,_ゝ`)プププッ ほんと笑えますよね

379ナイコンさん2018/06/20(水) 23:43:47.15
( ´,_ゝ`) MIPS(笑)

380ナイコンさん2018/06/20(水) 23:50:39.78
PICを出してる競合相手のMicrochipにAtmelを買収されてAVR信者哀れ

381ナイコンさん2018/06/20(水) 23:52:50.13
( ´,_ゝ`) プププッ  エラッタだらけのPIC32

382ナイコンさん2018/06/21(木) 00:02:16.01
しかし、欠陥アーキテクチャを大学で教えるのはやめてほしいね。
勘違いした学生が大勢市場に出て困る。

383ナイコンさん2018/06/21(木) 00:07:35.99
> 科学技術計算に特化したR8000は高価ということもあってあまり売れなかった

> それまでMIPSアーキテクチャのマイクロプロセッサを手がけていたIDTなどの半導体企業はR10000を製造しなかった。

> 2008年初め、ミップスはプロセッサ事業部門の28人の従業員を解雇した。
> 2008年8月13日、会計年度の第4四半期が1億850万ドルの赤字となり、さらに従業員の15%を解雇することになると発表。

( ´,_ゝ`) 大変でつね

384ナイコンさん2018/06/21(木) 01:05:32.46
大学でアセンブラ教えるなら、
8bitなら、Z80かAVR、32bitならx86とARMにしてほしいわ。

385ナイコンさん2018/06/21(木) 01:10:12.47
CASL一択

386ナイコンさん2018/06/21(木) 03:32:18.54
RISCは同一単一マシンサイクルで駆動する変態マシン語で、
その変態ブリを高級言語でラップして使うものという流れだったような。

80年代末のarconのARM1搭載した32ビットパソコンのアルキメデスの
OS、RISC-OSには開発ツールの中にARM用のアセンブラがあって、
今でもラズパイ1用にポートされたRISC-OS下で使える。

387ナイコンさん2018/06/21(木) 04:44:11.68
RISC OS
https://ja.wikipedia.org/wiki/RISC_OS
> 後方互換
> 新たなバージョンのOSやハードウェアへの移植性は高くない。
> BBC BASIC で書かれたプログラムは比較的移植が容易だが、
> デスクトップアプリケーションやゲームには深刻な後方互換問題がある。

388ナイコンさん2018/06/21(木) 04:53:15.03
ARMはARM命令とThumb-2という大きく分けて2つの命令セットがある
ARMのCortex-M3、M4、M7はARM命令が実装されず、Thumb-2しか実装してないが
Raspberry Pi A+やB+、Zeroに使われてる ARM1176JZF-SはThumb-2に対応してない

また、ARM命令の場合、32bitイミディエイト値を読み込む場合、
他のRISC CPUのような2命令では読み込めず、リテラルプールから読み込まないといけない
Thumb-2では他のRISC CPUのように2命令で32bitイミディエイト値を読み込める

389ナイコンさん2018/06/21(木) 06:47:16.92
もうMIPSの件は>>352で決着したし、そろそろウザいんでRISC談義は他所でやって貰えませんかね?

390ナイコンさん2018/06/21(木) 07:36:57.23
ほんと。何百スレもすっとぼけて答えず逃げ続けてたけど、 >>308 で決着はついた。

391ナイコンさん2018/06/21(木) 07:44:22.54
ステータスレジスタをもつRISC CPUであるAVRの存在がMIPS信者の言ってることが嘘だということの証左でしかないからな。
即レスでadcって言われて話は終わってた。無駄に低脳馬鹿を相手したAVR信者が悪い。

392ナイコンさん2018/06/21(木) 07:59:03.95
確かに>>308は「痛恨の一撃」で終わったよなww

393ナイコンさん2018/06/21(木) 09:17:16.62
終わったなら黙ってスルーすれば良いのに。
どうしても勝利宣言しちゃいたいとか。どこかのお国の方みたいw

394ナイコンさん2018/06/21(木) 09:32:06.84
ずっとスレチの話してる奴かがいるんで、
8bitCPUの話に戻すとAVRはC言語に向いてると言えるな。

395ナイコンさん2018/06/21(木) 12:14:09.98
>>394
AVRは板違いではないか?

396ナイコンさん2018/06/21(木) 17:39:53.02
AVR信者の上から目線の発言がきもい
所詮8bitだし、AVRやってると勘違いした人になるのかもな
専門学校などの8bit CPUを題材に使ってるのは時間が限られてるし
8bit CPUは簡単で短時間の授業で教えられるからだぞ

397ナイコンさん2018/06/21(木) 19:23:45.87
この板の人ならアセンブラならZ80か8086から入った人が多いからな
ADC命令でドヤ顔されても当たり前の話すぎて笑える
ADC命令を知らない人がいるってことにしないとドヤ顔できないから困るんだろうな

398ナイコンさん2018/06/21(木) 19:49:06.32
>>392
( ´,_ゝ`)プッ

399ナイコンさん2018/06/21(木) 20:30:58.27
>>393
>>390-391に言ってやれよw

400ナイコンさん2018/06/21(木) 20:41:15.29
4ビット単位の桁上がり桁下がりをフラグに反映するプロセッサも有るんですよ!


あったよね?

401ナイコンさん2018/06/21(木) 20:46:38.50
クロックアップ性能アップ競争したら先に死ぬのはフラグがある方ってことでしょ
AVRとかハエが止まるようなクロックで動いてるマイコンならフラグで問題ない

402ナイコンさん2018/06/21(木) 20:49:28.61
>>398
反撃するならちょっとはまともなこと書けよ
まあできないからそのレスなんだろうけどww

403ナイコンさん2018/06/21(木) 21:02:41.55
>>401
x86やx64はフラグ有りますが?

トランジスタ数が文字通り桁ちがいなので比べるのはアンフェアかもしれんが、現実は現実だからね。

404ナイコンさん2018/06/21(木) 21:07:37.42
前の方に書いてあったじゃんそれらもフラグの存在を邪険にしてるとさ
おれはそこら辺の細かいことは知らんけどさ

405ナイコンさん2018/06/21(木) 21:11:30.41
フラグなんてオーバーフローとサイン(マイナス)とゼロの3種類あれば充分だろ、RISCなら。

406ナイコンさん2018/06/21(木) 21:18:06.17
でもARM64はフラグあるっぽいし大した足枷じゃないのかそれともRISC-Vにぶち抜かれるか
延々と改良やめない所が勝つから読めないねぇ

intel?逝ってよし

407ナイコンさん2018/06/21(木) 22:03:08.97
物量作戦でμOps並べかえて実行する
コンパイラが頑張ってRISC命令を並び替える

どっちもメリット/デメリットあるからどっちかが優れてるとか言ってる奴は単なるアホ

408ナイコンさん2018/06/21(木) 23:07:19.25
>>400
BCDのためだが。

409ナイコンさん2018/06/21(木) 23:10:32.42
>>397
大学でMIPSから入った人が暴れてるんでしょ。
未だにMIPSアセンブラ教えてる大学が諸悪の根源。

410ナイコンさん2018/06/21(木) 23:12:48.24
>>401
クロック上げに失敗したのがMIPSだけなんだよ。

411ナイコンさん2018/06/21(木) 23:18:17.88
RISC-Vは失敗確実だろう。Z80をライバル視してるレベルだからな。

412ナイコンさん2018/06/22(金) 00:10:51.31
>>407
まるでIntelコンパイラが頑張ってないみたいな言い方だな。
コンパイラもCPU実装も手抜きしたのがMIPS。どっちも頑張ったのがIntel。
だから天地ぐらいの差がついた。未だに現実が見えない奴は真性のアホ

413ナイコンさん2018/06/22(金) 00:23:10.18
>>412
なんでこういう頓珍漢なアホっていつまでもいなくならないんだろう...
物量作戦の意味もわかってないんだろうな w

414ナイコンさん2018/06/22(金) 00:29:07.38
>>413
へーMIPSは物量作戦使ってないのか。また捏造する気?

415ナイコンさん2018/06/22(金) 00:36:31.90
AVR 20MHz
R3000 30MHz

AVRは蝿が止まれるclockと言ってるが、MIPSはAVRを馬鹿にできるほど全然速くない。
前の例でAVRは2clockで、R3000は4clockかかるらしいから、なんと実はAVRのほうが速い。

416ナイコンさん2018/06/22(金) 00:42:22.21
>>402
( ´,_ゝ`)ププッ

417ナイコンさん2018/06/22(金) 00:43:13.39
>>414
命令制御にはたいして使ってないよ
まさかそんなことも知らんのか?

418ナイコンさん2018/06/22(金) 00:44:12.24

419ナイコンさん2018/06/22(金) 00:45:08.83
>>417
では教えてほしい。そんなにシンプルにしたのになぜclockが上がらなかったんだ?

420ナイコンさん2018/06/22(金) 00:53:00.35
MIPSのスレってないの? (調べてないけど

riscなんて無制限にクロック上げていけるのかと思ったw
製造プロセスレベルで作りこむとこがライセンスしなかったから?

421ナイコンさん2018/06/22(金) 01:04:17.14
clockの話を聞くとなぜか逃げ出すのがMIPS信者。

422ナイコンさん2018/06/22(金) 01:10:12.50
Intelのすごさがどんどん明らかになるね!!!

423ナイコンさん2018/06/22(金) 01:15:55.48
クロックも上がらない、IPCも上がらない、消費電力は下がらない、価格も下がらない、
これでどうやってIntelに勝てというのだ。

424ナイコンさん2018/06/22(金) 02:33:34.30
>>415
> 前の例でAVRは2clockで、R3000は4clockかかるらしいから、なんと実はAVRのほうが速い。

マジかよAVRマジハンパねぇな。
https://godbolt.org/g/u7XHj8

425ナイコンさん2018/06/22(金) 03:12:18.07
>>424
なぜシンプルなのにMIPSはクロックが上がらなかったんですか?

426ナイコンさん2018/06/22(金) 04:36:01.32
>>411
WD、2019年からNAND/HDDのコントローラを順次RISC-Vベースに移行
https://pc.watch.impress.co.jp/docs/news/1128863.html
> WDは2017年11月に、自社製品にRISC-Vアーキテクチャを採用していくことを発表している。
> 具体的には、現時点ではプロプライエタリのHDDやNANDコントローラを、
> オープンソースのRISC-Vに置き換えていくことを目指しており、
> 年間10億コア以上の採用を約束している。

427ナイコンさん2018/06/22(金) 04:55:19.97
>>419
普通にGHzの製品もありますが・・・

Imagination Technologies, Creator Ci20 コンピュータボード JZ4780 MIPS CPU
https://jp.rs-online.com/web/p/processor-microcontroller-development-kits/1253305/
> 1.2 GHzデュアルコアXBurst MIPS32 JZ4780 SoC、
> PowerVR SGX540 GPU及びFPU搭載 • GPUはMPEG-4、H.264、VP8、MPEG-2、RV9をサポート

428ナイコンさん2018/06/22(金) 05:03:54.32
一般向けに市販されてないものならこんなのあるぞ
これは主にネットワーク機器向けのプロセッサだが

Cavium社、48コアを搭載した2.5GHz駆動のOCTEON IIIを発表
https://tech.nikkeibp.co.jp/dm/article/NEWS/20120216/204850/

429ナイコンさん2018/06/22(金) 05:07:24.16
4Gとかは無理だったのか・・・

430ナイコンさん2018/06/22(金) 05:36:42.26
4GHz超えはさすがにx86_64以外はスパコン向けかハイエンドサーバ向けしかないな
x86_64以外はSPARC64 XII、POWER7、8、9、メインフレームのZ13、Z14くらいしかない

431ナイコンさん2018/06/22(金) 05:48:20.17
逆に言えば、4GHz以上のCPU作ってるのってIntel、AMD、IBM、富士通の4社だけじゃないのかな

432ナイコンさん2018/06/22(金) 05:51:15.35
OracleのSPARC M7も4GHzこえてるな
それくらいじゃないかな

433ナイコンさん2018/06/22(金) 06:48:18.42
SoCでMIPSは速くなったとでも言いたいのだろうか。恥を知れと言いたい。

434ナイコンさん2018/06/22(金) 07:58:18.52
> 恥を知れと言いたい。
スレチの話を延々続ける粘着君に言われてもなぁw

435ナイコンさん2018/06/22(金) 08:14:22.86
よし、ボクもAlteraの14nmFPGAにMIPS入れちゃうゾー

436ナイコンさん2018/06/22(金) 08:17:20.49
( ´,_ゝ`)ププッ

437ナイコンさん2018/06/22(金) 09:29:04.25
>>434
まだ質問に答えてくれてませんよ。また何週間も答えないつもりなんですか?

> なぜシンプルなのにMIPSはクロックが上がらなかったんですか?

438ナイコンさん2018/06/22(金) 12:07:05.30
生い立ちが悪い
運が悪い
客に恵まれてない
敵に恵まれてた

439ナイコンさん2018/06/22(金) 12:39:52.54
>>437
ビジネス的に必要ないと判断したんだろ
全ての車メーカーがスポーツカー売る訳じゃないのと同じ

440ナイコンさん2018/06/22(金) 13:59:00.56
>>438
> 生い立ちが悪い
> 運が悪い
> 客に恵まれてない
> 敵に恵まれてた

そだね〜。一つ付け加えれば、インテルは半導体屋でMIPSを買収したsgiは鯖屋。
鯖屋では半導体屋のような畑仕事ができず、かといって新たな荒畑な日電では高速IC
作るの無理ポだった。鯖屋のDEC、Sunもシリコン畑仕事できないオッサン会社だったから
MIPS@sgi同様に没落したよね。

441ナイコンさん2018/06/22(金) 16:28:19.79
新たな荒畑 → 4/8ビットワンチップマイコン栽培が精一杯な古臭い畑

442ナイコンさん2018/06/22(金) 19:12:18.05
今は、車載向けにがんばってるようだけどどうなんだろうね
MIPSはハードウェアマルチスレッドという特殊な仕組みを導入してるコアがあるが
一応デンソーはこれに注目してMIPSと提携して新しいプロセッサーを開発してる模様
Intelが買収したMobileyeのEyeQシリーズに一応MIPSコアが使われてる

443ナイコンさん2018/06/22(金) 20:30:07.81
当時のRISCでハイエンドで残ってるのはPOWERとSPARCだけ
DECのAlpha、PA-RISC、Intelのi860、AMDのAm29000、モトローラのMC88000、ApolloのPRISM
これらは全部消えた

444ナイコンさん2018/06/22(金) 20:51:21.79
組み込みなんて安いARMで十分なんですけどね。

445ナイコンさん2018/06/22(金) 21:28:24.14
ヴェトロニクスは簡単に「安いARMで良いや」って訳にいかないんだよなぁ・・・
主として組織的な問題で・・・

446ナイコンさん2018/06/22(金) 23:12:13.16
枯れてないのを使うのはリスクがでか杉。WDも莫大な損失を出さなければいいが。

447ナイコンさん2018/06/23(土) 01:36:28.93
MSXでC言語をやったっけな。
並行してMZでPASCALやLOGOをやったっけ。
8ビットでBASICとマシン語以外の言語、全然ありえたよ。

448ナイコンさん2018/06/23(土) 01:42:55.56
友達から借りたMSXはテープ内蔵でプログラムを保存できました。
起動するとBASICが使えましたが、Cは使えませんでした。

449ナイコンさん2018/06/23(土) 02:01:20.66
PC-6001でROMのBASICコンパイラあったな

ROMのCコンパイラってないのか
あまり意味はないが

450ナイコンさん2018/06/23(土) 02:36:02.04
MSXってほとんどの機種はFDDついてないよね。

451ナイコンさん2018/06/23(土) 06:46:40.44
カセットポンのゲーム機だから。MSX。

452ナイコンさん2018/06/23(土) 07:44:51.66
カセットポンで FDD つくよ。

453ナイコンさん2018/06/23(土) 07:50:09.33
>>447 ←こいつ大金持ちだろ

454ナイコンさん2018/06/23(土) 08:56:23.86
>>453
親がバブルにのって金回りが良かったんだろう、たぶん。

田舎だったんでバブルの恩恵あんまりなかったなー。
はじけた後は影響有りまくりだったが。

455ナイコンさん2018/06/23(土) 10:58:55.80
CP/Mはいくらぐらいしたんだろうな
X1用のCP/Mが安く売ってたという話をたしか聞いた覚えがあるが
PC8801用は?
ネットに落ちてた月刊I/Oの広告を見てたらZ80B用とMZ-2000用のCP/Mが3万5千円と載ってたが

456ナイコンさん2018/06/23(土) 11:07:29.68
MSX-C Ver1.1は定価19800円
MSX-Cを使うにはMSXDOS-TOOLSが必要でこれが定価14800円
なのでMSX-Cを使うには定価で3万4600円かかった

457ナイコンさん2018/06/23(土) 15:06:09.64
MSX-DOS + Small-C ならタダ同然で使えた

458ナイコンさん2018/06/23(土) 17:41:50.27
>>455
マイクロソフトウェアアソシエイツ(MSA)版CP/Mは6万5千円だったはず。
後日NECが販売したNEC版は4〜5万円ぐらいに値下げされてた。
(こっちは買ってないのでうろ覚え)

459ナイコンさん2018/06/23(土) 17:44:25.52
8bitのC言語で名前が挙がるのってlong型もfloat型も使えないようなサブセットばかりじゃん

460ナイコンさん2018/06/23(土) 18:19:30.24
> 8bitのC言語で名前が挙がるのってlong型もfloat型も使えないようなサブセットばかりじゃん

だから何? ケチつけたいだけ??

461ナイコンさん2018/06/23(土) 22:08:43.68
ここはケチスレです。

462ナイコンさん2018/06/24(日) 00:00:42.91
多くは長いナイコン族を経てPCを手に入れるので、金持ちとは話題が合わないですね。

新着レスの表示
レスを投稿する