8ビットCPUでC言語？ ないないありえないっしょ！ [無断転載禁止]©2ch.net
Part.2
ttp://matsuri.5ch.net/test/read.cgi/i4004/1470913460/ Part.1 ttp://hanabi.2ch.net/test/read.cgi/i4004/1468652612/
♪ ／.i ／.i ／.i
♪ ∠__ノ ∠__ノ ∠__ノ
〈,(・∀・;)ノ・∀・;)ノ・∀・;)ノ
└i===|┘i===|┘.i===|┘
〈＿_〈 〈＿_〈 〈＿_〈
ttp://matsuri.5ch.net/test/read.cgi/i4004/1528299072/ 次スレ立てる場合はスレタイ同一がお約束。なんでここは派生スレね。
以後、テキトーにどうぞ。
ttps://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なし。
88版だと「%s様が病気になりました」なんかの文字列があるね
解析するとメモリの1183h～あたりがprintfの処理かなぁ
LD HL, n
ADD HL, SP
ってコードが多いのがC言語っぽいけど
IXやIYがあまり使われてなさそうなのがコンパイラっぽく無いとも感じる
引数制限してるかグローバル変数使いまくりなんだろうか
昔々すぎて詳細忘れたけどN88BASICで漢字のフォントデータ読み出す処理を書いたときにSJIS（N88BASICがSJISなので）からJISに変換したような覚えがなんとなくある。
あ、すまん、％ｓ様が～ってみえてるのか。
ならSJIS使ってるね。
当時Z80の命令吐くコンパイラがどんだけあったと思ってる?
DOS時代でさえputs()使いましょうだったのに。
サンクス。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のクロス環境で開発されていた。と考えるのが自然な推定であるような気がする。
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対応の故なのだろうね
ttps://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コンパイラ開発顛末記
ttp://www.techno-web.org/e_techno/1999/11/03/cyyoynyyeeaeouaei/ 小窓氏のブログは2011年で止まっている。世代的に70手前くらいか。ちょっと心配。
開発販売したていたことでも知られている。広告出していたからね。俺も知っている。
ファイル名がSEDだったかな。ワードマスターみたいなESCシーケンスエディタに慣れたユーザには
目鱗ものの高速エディタだった。これが後のMIFES,REDなどの原型。というのもペンギンソフト解散時に
エディタの開発者がそれぞれ著作権利ありと継続したのがMIFESとか諸々。らしい。伝聞だからね。
あの84-86年頃の関西は9801移行で名を馳せた会社がたくさん合ったが、人脈の源流は京都ペンギンなのだろうね。
カノープス：神戸 メガソフト：大阪 岩崎技研：京都 京都マイクロコンピュータ：京都
パソコンだと8080よりZ80のが使われてたからデジタルリサーチも8080に拘る愚はしないでZ80対応するのが自然でしょ。
NECが自社のPC向けにローカライズしてたのかもしれないけど。
> IXやIYがあまり使われてなさそうなのがコンパイラっぽく無いとも感じる
IX, IYを使う命令は遅いからアセンブラで組む時もあまり使わない
ビット命令
裏レジスタ
使うと笑われるZ80の3大機能
適材適所だろ。
インデックスレジスタは、データ構造の作り方で不要に出来る場合が多いけど、使い所はある
裏レジスタも処理を整理していけば要らない場面が多々あるけど、やっぱり欲しい時あるじゃん
そんなこと言ってたら、X1の様なGRAMのアクセス方法だって邪道
だから適所が少なかったって話な
アセンブラでカリカリチューニングするならまだわかるけど当時のコンパイラにそこまで要求するのはものを知らなさすぎ
筒井氏開発のは南極ペンギンC なのね。86用。 6301用のC3POとは別。
> ビット命令
> 裏レジスタ
>
> 使うと笑われるZ80の3大機能
笑ってるのは適所を理解せず脊髄反射してる馬鹿ってことだよなあ。
printf("%f",a);
これでバイナリサイズはいくらになりますか？
知りたきゃ手前で確認しろやカス
LSI-C/イントロール・クロスCらしい
うそつけ。
ttp://somn9.xyz/4 ttp://rosie.5ch.net/test/read.cgi/liveplus/1528627781/l50 無料公開されたCP/M版のHI-TECH Cでコンパイルすると7168バイトになるね
(ただ、hogehogeを出力するだけのコード)
#include <cpm.h>
int main(int argc, char **argv) {
bdos( 9, "hogehoge\r$");
return 0;
}
#include <stdio.h>
int main(int argc, char **argv) {
int a = 1234;
printf("%d",a);
return 0;
}
IX,IYが使われないのは当たり前。
HI-TECH CはZ-80用コンパイラで、多分コード生成部以外は
他のCPU用と共用と思われるため、過剰とも思えるほど
インデックスレジスタを多用したコードを吐く。
ttps://www.lsi-j.co.jp/official/products/02/other/lsic80 ボクのMSXは8KBとしかメモリがありません。
19800円のα-CはBDS-Cのサブセットとかいう噂らしいけど。
信長ってクロスのLSI-Cなんでそ？
プロの開発で8bitCPUでコンパイルはなかったのかね？
(バグとか結構あったから)
BASE80とかの方が生産性高かったなぁ
8ビットでもインタプリタが載せられるようなリッチ？なシステムで仕事したかったわｗ
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;
}
; 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
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
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
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
みたいに状況判断ができない奴が一番使えない
どんなケースでポインタ操作でIX、IYが不便になるんですか？
構造体っぽいデータをランダムアクセスしたい場合なんかは
HL や DE を駆使するより効率的だったな。
シーケンシャルな連続アクセスなら HL, DE レジスタの方がいいだろうけど。
実際にやってみればいろいろわかると思うよ
ttps://electrelic.com/electrelic/node/474 実際逃げてるんだしｗ
遊びならアセンブラで組めよ。
仕事なら要件通り作れよってなる
Z80の特性理解しないでレジスタの扱いヘタクソなジジイがあれがダメこれがダメ言ってるだけのゴミ記事。
不可能を可能にするノウハウにこそ価値がある。
えっ？
俺がやるより分かりやすく説明してるから貼ってるんだけど
具体例出されたから反論できずに困ってる？ w
はいはい w
>ADD IX,BC
>はできても
>ADD IX,HL
>はできないのです。
EX DE,HL
ADD IX,DE
EX DE,HL
とかやり様だしなあ、こんなんで「分かりやすく説明してる」ってアホかｗ
>
>PUSH BC
>POP IX
>とスタックを経由する方法でした。これならHLからIYへの転送等も可能ですが、スタック（メモリ）を経由するのがちょっと気になります。
スタック使うのが気になるなら
LD IX,0
ADD IX,BC
とかするだけだがなあ、自分で提示した方法にケチつけることに何の意味があるんだろう?
>
> 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)
わかってない奴が何偉そうにｗ
> 俺がやるより分かりやすく説明してるから貼ってるんだけど
> 具体例出されたから反論できずに困ってる？ w
ﾜﾛﾀｗ
それを逃げって言うだろ、普通は。
> とかやり様だしなあ
> とかするだけだがなあ
そりゃそう言う言い方したらなんでもありありだわな
そう言うのは面倒だし、(当時は)コードサイズが膨れるのも嫌とかあるだろ
全然違うコードさらしてバカアピールか？
煽ることしかできないバカは黙っとけ
ですね、立派な逃げです。
面倒から逃げるのはよくある事ですけど、逃げは逃げですｗ
逃げたー
しか言えなくなってて笑うわ
自己紹介乙
てめえが書いたコードも晒さずに何バカ言ってんだかｗ
如何に8bit CPUが制限だらけかわかる
8088や8086はスタックアクセスにBPレジスタが用意されていて
スタック上のローカル変数へのアクセスが容易にできる
Z80は高級言語のことはあまり考慮されてないが
8088や8086は高級言語のことも考慮されてる設計
68000ならlink命令など、さらに高級言語が使いやすく出来てる
引数もローカル変数も使わずグローバル変数だけ使えば問題なし
ローカル変数を固定番地に配置すれば良い。関数の入り口でそれらをスタックに退避すれば再帰もできるし実行中のオーバーヘッドも小さい。
6809とか知らない人?
6809は出た時期が遅いからな
8086よりも後発で68000と同時期じゃなかったか？
当然、複数の16bitの加算、減算回路が必要になり
結局16bitCPUとトランジスタ数が変わらなくなるんじゃないの？
6809はかなりのトランジスタ数なんじゃないかな
× 複数の16bitの加算、減算回路が必要になり
○ 複数の16bitの加算、減算が必要になり
遅くてもいいなら演算回路はどうにでもなるからね
6809のようなアドレッシングモードが高機能な場合、
データの演算そのものよりもアドレス計算の方が計算量が多くなってしまう
単純な32bit CPUと大差ないかまたはより多くのトランジスタ数を必要としたりする
32bitのARMのCortex-M3は3万3000ゲート、MIPSのM4Kは3万5000ゲートと言われてる
ワンチップマイコンでも高機能な16bitCPUは淘汰されて32bitに置き換わってる
そこを上手くこなしたのが6502のアドレス演算
Z80がボケーっとリフレッシュアドレス出してるデコード中に下位アドレス読み込んで次の処理を始めているのでムダがない
「逃げたー」の次は「他人様のー」かよ w
他人のコードだろうが具体例には違いないだろ、バカすぎるわ
色々おかしいとしても具体的なコードで反論してきたの方が100倍マシだよ
> 8088や8086はスタックアクセスにBPレジスタが用意
> 68000ならlink命令
両方とも最適化が進んで使われなくなったけどねw
も書いてるけどレジスタの問題よりアドレッシングモードの問題の方が大きい
> 色々おかしいとしても
具体的に指摘できないけどケチ付けたいのは解った。
高速化は動くものができてから好きなだけやればいい
デバッガどころか文字出力もない環境でよくゲームなんか作ったもんだと今更ながら呆れる
「全然違うコード」ってトンチンカンな主張繰り返したいの??
HL使ったコードでどやられてもね
しかもHL壊してるし
想像を遥かに超えた馬鹿だなｗ
しかも命令の代替の話だから D 以外を壊さないのは常識
ドヤ顔して貼った他人様のページのコードはフラグ壊してるから非常識って主張かよｗ
それがアドレッシングモードを含めての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からほんの少しの改良しか行われてないけど
フラグとか必死すぎる w
> それがアドレッシングモードを含めてのBPレジスタという話だ
SP に適切なアドレッシングモードがつけばすむ話で BP 関係ない
デバッグする時にスタックフレームが追いかけやすいと言うメリットはあったけど
仮定の話なんてどうでもいい
8086、8088にはSP間接アドレッシングはないからな
32bit化された時にSPをベースレジスタとして使えるように拡張されたわけで
8086や8088でpush、pop以外でスタックのデータにアクセスしたければ普通はBPレジスタを使う
元々Z80の話なんだけど...
Z80で面倒な操作も16bit CPUの8086、8088なら簡単にできるという話だよ
だからそれはBPレジスタのお陰じゃなくてアドレッシングモードのお陰って話な
8086 じゃなくても 6809 でも簡単って に指摘されてただろ
だから、アドレスは8bit CPUでも16bitだから
アドレッシングモードを複雑にするとそれだけ複雑な16bitの演算が必要になる
それならいっそのこと16bit CPUにした方がいいからな
はあ？
頓珍漢過ぎて笑うしかないないんだが w
Z80 ですら ADD HL,rp で 16bit 演算してたから単純にアークテクチャの問題だよ
ただ、念のために言っとくけど当時はスタックに変数を置くと言う概念は一般的ではなかったから 8080 や Z80 のアーキテクトがおかしいと言う訳じゃない
複雑なアドレス演算ってただの全加算器ですよね。
6809には乗算命令があるがZ80には乗算命令すらないぞ
6809のdisp16のインデックスト・アドレッシングや
Dレジスタを使ったアキュムレーター・オフセット・インデックスト、
16bitオフセットのプログラムカウンタ・レラティブ・アドレッシングは
アドレス計算のために16bitの加算が必要なわけ
8bitの演算をするために16bitの演算が必要な時点で、アドレス計算の方が負荷が大きい
その分、トランジスタ数も16bit CPU並みに多いと思うぞ
68000のMULSやMULUは70クロック以下
286だとレジスタオペランドの16bit MULが21クロック
386だとレジスタオペランドの16bit MULが9-22クロック
486だとレジスタオペランドの16bit MULが13クロック
必要なクロックから推定するとおそらく8086や68000の乗算命令は
専用の乗算回路はなくてマイクロコードで実装されてると思われる
つまり、8080やZ80はそもそもC言語に適してない設計なんだよ
自分で認めてるじゃないか
(小売価格なのであまり参考にならないかも)
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円
ちょっとアレだね・・・
コテハンにしてくれたらNGするんだが・・・
はあ？
Z80や8080がC言語に適してるって言ってた奴なんていないだろ
ただそれとこれらのCPUでC言語を使ってたかどうかとは別の話
ハードウェアスタックポインタを持たない汎用機でもC言語は動くしな
ttp://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年に作成されています。
その辺の違いで製造の難易度、ひいては最終的な値段も大きく変わるので、
値段なのか性能なのか何を重視するかによって変わったわけさ。
6800なら公開されてるようで、ググるとトランジスタ数が5000と出る
8080がトランジスタ数が6000
Z80がトランジスタ数が8200
6809は6800からかなり強化されてるからトランジスタ数も多いと思うが
8088/8086 → 29000個
6809 → 9000個
ググったら普通に出てくる
オールアセンブラのソフトをCで移植するときは、速度、メモリとも厳しいだろうな。
Pen2ぐらいでやっとCの遅さを実用になるレベルまでカバーできるようになったと言えるな。
アセンブラだったのはどの処理だったのかね？
コンパイラの進化も凄いよね。
VC4くらいだと、混合モードでみる限りカウンタにECXとか使わないからloop命令使ってねーなーと突っ込んでいたわ
少なくともPentium以前ではC言語はまだまだ実用的でなかったと言える。
Vzを日頃使ってると、EWS4800で使うviが非常に遅いと感じた。
MIPSの設計もまたC言語に向いてなかったのだろうな。
UNIXはHDDに依存しすぎだし
しかもviは端末に依存しないように作られてるから余計に遅くなる
32bit以降のCPUでC言語の実装を考慮してないCPUなどないでしょ
MIPSはスタンフォード大学のRISCの研究から生まれたCPUでいきなり出てきたわけじゃないからな
その研究から生まれたMIPS-Xがあって、それを改良して実用的にしたのがR2000やR3000
C言語に向いてなかったらそもそもUNIXマシンで採用されるわけがない
MIPSの命令セットはC言語を実装するための最低限の単純な命令の命令セットという感じ
多倍長の加算するのに加算した後の数が加算する前より小さければ桁あふれが発生
とかのトリック的なことをかなり使ってるからMIPSアセンブラの定石を知らない人には
アセンブラで組むのは難しいかも
イミディエイト値を読み込む場合に%hi()や%lo（）といった演算子が用意されているんだが
lui $4, %hi(0x12345678)
addiu $4, $4, %lo(0x12345678)
こんな感じでロードするように%hi()、%lo演算子の値が補正されているので
lui $4, %hi(0x12345678)
ori $4, $4, %lo(0x12345678)
とやってはいけないとかいろいろある
> Vzを日頃使ってると、EWS4800で使うviが非常に遅いと感じた。
それ画面描画の問題だろ
> MIPSの設計もまたC言語に向いてなかったのだろうな。
自分の狭い（かつ頓珍漢な）経験でアホな判断するなよ w
ttp://www.computerhistory.org/atchm/tag/source-code/ VZ Editorみたいにハードウェアを直接叩くんじゃなくて
UNIXの標準機能を使って作られてるから遅いんだろうね
どのMS-DOSでも動作するエディタがあるがやっぱり遅いよ
もしかしてX上のターミナルで使ってて遅いとか言ってない？
短かったけど
そう言うのは6809よりつおいCPU出してから言わないと w
MS-DOSの頃のエディタの方が高速スクロールしてたと思う
VZ Editorは使ったことないけど
FinalとかV30や286のPC-9801でもスクロールが物凄く速かったよな
finalってスクロールだけ早かった印象がある
Vzは機能のバランスとスピードが一体になっていてとにかく洗練されてるし完成されてたね。
WindowsになってWzは作者違うし、秀丸がなんとなく後継だけども体へのフィット感が違うな(Vzで作ったFM-7のDUPキーを模したマクロとか秀丸に移植しなかったせいもあるけど)
ていうか、性能が良かったから家庭用だけでなく日本のPCゲーム市場まで駆逐してしまったわけで・・・
RISC-VはフリーだしFPGA用のフリーの実装もあるのでFPGA界隈で注目されてるみたいだね
PDP-11上のUNIX Version 7が試せる
C言語も入ってるよ
ttp://pcmemo.take-uma.net/simh/install_simh ttp://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でログインできたらユーザやグループの追加は／ｅｔｃ／ｐａｓｓｗｄや／ｅｔｃ／ｇｒｏｕｐを直接編集する
エディタはviはないのでedで編集しないといけない
ホームディレクトリも自分で作成する
cc -O2 -o hogehoge hogehoge.c
アセンブラ出力は
cc -O2 -S hogehoge.s hogehoge.c
出力したアセンブラソースファイルは
cc -o hogehoge hogehoge.s
これで実行ファイルを作れる
-O2というのは最適化オプションでなくてもいいし-O1や-O3とかでもいい
数学関数を使うなら
cc -O2 -o hogehoge hogehoge.c -lm
と最後に-lmオプションを付ける
インテル・アーキテクチャ最適化マニュアル
ttps://www.intel.co.jp/content/dam/www/public/ijkk/jp/ja/documents/developer/ia_opti.pdf > 整数ブレンデッド・コードの最適化手法
> 複雑な命令
> 複雑な命令 (たとえば、enter、leave、loop)の使用を避け、単純な命令のシーケンスを使用する。
> コンパイラの進化も凄いよね。
> VC4くらいだと、混合モードでみる限りカウンタにECXとか使わないからloop命令使ってねーなーと突っ込んでいたわ
さあ突っ込めや↓
ttps://godbolt.org/g/3btzdU ttps://godbolt.org/g/WEuFqk コンパイラやライブラリーも書き直せば良い物が出来そうよね
クロス環境で贅沢にメモリー使って最適化させたり
当時っていつ頃？
GNU-Cの登場は88年だけど、89-90年ごろには移植が進んで PCやアタリやアミガ版、
mac版などBBSとかでサーキュレートしてた。同時期にminixも紀伊国屋や丸善で書店販売されて、
91年にはLinux。16/32ビットOS自作が欧州ではブームだった。あの頃の洋雑誌は面白かったなあ
まあ日本に住んでたし
MIPSはフラグレジスタがないという致命的な欠陥がある。キャリーフラグがないために桁あふれで例外を投げるため、
PSのソフトのいくつかはこの致命的な欠陥仕様のためにフリーズするものがあることがソフト解析で分かっている。
MIPSの仕様を知らず、Cの知識だけでコードを書くとこのようなバグを埋め込んでしまうのである。MIPSはCに向いてないと言えよう。
Cの仕様では符号付整数のオーバーフローは未定義動作だしそんなプログラムを書く奴はCの知識はないだろｗ
C言語はunsignedだとキャリーは無視する仕様
MIPSはキャリーで例外を発生させない命令(adduとか)も持っててCコンパイラは例外を発生させない命令を使う
なんてことは常識やぞ
アセンブラで書く理由なんて、Cは遅いから意外に思いつかない。
何言ってるんだ？
C言語ではオーバーフローで例外の発生するadd命令は使わないでaddu命令を使う
キャリーフラグはないが加算する前の数より、
加算後の数が小さければ桁あふれが発生したと考えられるので
これを利用して多倍長演算を行う
キャリーフラグがなくても、こんな感じで、桁あふれと桁借りを検出できる
ttp://d.hatena.ne.jp/tociyuki/20140906/1410012689 MIPS登場後、影響を受けて、ステータスレジスタを排除したアーキテクチャはないし。
知ったかぶりしてみたいなこと書くやついるのな
RISC-VはMIPSと同じでフラグはないぞ
キャリーフラグがないことで遅くしかならないことは明白だろう。欠陥は欠陥。
キミはそれを知ってるのに知らないフリをしている。
RISCの思想を理解してない無能↑
当時は手書き設計だったがため、キャリーの配線するのが面倒だからという理由でキャリーは削除された。
面倒なことはコンパイラがやってくれるからCPU設計者には楽をさせろということだ。
自分が楽をするためであって、コンピュータが効率的に動作する目的ではない。それがRISCの思想。
>MIPS登場後、影響を受けて、ステータスレジスタを排除したアーキテクチャはないし。
IntelのItaniumは？
ADD，SUB等汎用レジスタ操作にフラグは無く、比較操作の結果をプレディケートレジスタprにという形だったはず。
市場で失敗したアーキテクチャばかりという自虐ネタですね。意図は分かります。
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
adc
のほうが簡単だよな。Z80はMIPSより優れている。
64bit CPUが一般的になった今なら64bit演算を多用するなら64bit CPUを使えばいいわけだしな
128bit演算などあまり使わない
RISC-VもMIPSと同様に64bitアーキテクチャがあるしな
ttps://godbolt.org/g/h8jYdx intelなんて前世紀に128bit演算追加してるというのに。今は512bit演算の時代ですよ。
あなた時代錯誤してますよね。あっ、私が時代錯誤してました。
ここ昔のPCスレでしたね。未来をバラしてすみません。
128bit演算いらないとか所詮教育用で実用目的じゃないのは明らかだな。
CPUがサポートし、今時のCコンパイラもint128をサポートしてるのに。
教育で欠陥設計を正しい設計と洗脳してるとなるとその害悪は相当なものだ。
何の話かわからんがまさか↓の話をしてるんではないだろうなあ
ttps://ja.m.wikipedia.org/wiki/128ビット > SIMD命令セットのSSEやAltiVecは、128ビットレジスタを、4つの32ビット値として並列演算し、一度に128ビットの演算ができる。128ビット長の数値を操作できるわけではない。
ワイヤードロジック最強なんて常識じゃないのか。
← これ意味分かるか？ $4を壊してるし、フラグあれば2回で済む演算が4回になってる。遅くしかならない。
依存関係の判断回路が複雑になる
そもそも32bit環境で64bit加減算の頻度は高くない
複雑化の一途
> なんでMIPS屋はフラグ排除に拘ってんだ？ 必要なときになければ遅くしかならないだろう。
パイプライン制御が面倒だからだよ
必要な時はそんなにないから必要な時だけレジスタに設定する方が全体は速くできる
> ← これ意味分かるか？ $4を壊してるし、フラグあれば2回で済む演算が4回になってる。遅くしかならない。
壊してるのは$8だし、パイプラインを乱さないからそれほど遅くならない
それぞれ一長一短
だから両方のアーキテクチャが存在する
フラグ無しの否定はSIMDの否定だ
> パイプライン制御が面倒だからだよ
やはり、面倒だからか。結局、MIPS設計は手抜きなんだよ。
だいたい今時128bit演算はしないとか、必要なときはそんなにないとか、全部キミの根拠のない妄想、期待であって、
実際は、C言語は例外的で、ほとんどの高級言語はOverflowをトラップするんだよ。つまり毎回二度演算してるということ。
> ($4:$2 = $5:$4 + $7:$6)
> addu $4,$8,$3
> 壊してるのは$8だし、
おまえの頭が壊れてる。
MIPS信者が勝手に言ってる戯言であって、RISCは関係ないので巻き込まないでくださいね^^
> intelなんて前世紀に128bit演算追加してるというのに。
> 128bit演算いらないとか所詮教育用で実用目的じゃないのは明らかだな。
> CPUがサポートし、今時のCコンパイラもint128をサポートしてるのに。
> だいたい今時128bit演算はしないとか、必要なときはそんなにないとか、全部キミの根拠のない妄想、期待であって、
↓見てどう思う?
ttps://godbolt.org/g/SxNKFS > RISCとして普及してるAVRはステータスレジスタあるし、add、adc、lsl、rolも1clockで終わるのでパイプラインなんて乱れてません。
せめてOoO実行するアーキテクチャ挙げれや
> だいたい今時128bit演算はしないとか、必要なときはそんなにないとか、全部キミの根拠のない妄想、期待であって、
64bitはともかく128bit演算なんて何に使うんだよ...
具体例出してみ
> 実際は、C言語は例外的で、ほとんどの高級言語はOverflowをトラップするんだよ。つまり毎回二度演算してるということ。
何を言いたいのかわからん
トラップしたいならトラップする命令使えばいいだけ
そもそも「MIPSはCに向いてないと言えよう。」とか言ってたのに指摘されたらC言語は例外とか笑えるわ
> おまえの頭が壊れてる。
アセンブラ読めないなら無理すんなよ w
誰もパイプラインが乱れるなんて書いてないだろ w
そう書くこと自体がわかってない証拠
の言うようにOut-of-Orderについて勉強してから出直してこいや
> パイプラインを乱さないからそれほど遅くならない
> Out-of-Order
現実、IPC高いのはフラグレジスタ持つx86系なんだよね。MIPSはパイプライン設計も手抜きなだけです。
フラグあると命令数が増えます。事実です。人は自分の脳みそのキャパを超えると単純化、シンプルにしようとします。
でもそれは彼の限界であって合理的な結論ではありません。
ジョブスも以前、マウスボタンをひとつにしました。複数あるのは自分には複雑すぎるというのです。
しかしまた複数に戻しました。過ちを認めたのです。MIPS信者もジョブスの素直さを見習ってほしいものです。
内部で命令の変換やってるx86挙げて何言いたいのかサッパリわからんわｗ
さっきの例をOoOしても3clockだろう。Pentium、AVRは2clock。超えられない壁なんだよ。
OverflowのチェックならMIPSはもう一度同じ演算をする必要すらある。一方Pen、AVRは必要ない。2clockと1clockだ。
結論 : フラグレジスタ排除は遅くしかならない。そのようなアーキテクチャがあれば欠陥アーキテクチャである。
Z80でフラグレジスタ禁止にしてみようぜ。
Σ(ﾟДﾟ) 条件ジャンプができない!!!
遅い例しか思い浮かばない。速い例を一つでも出してくれないか。
キャリーの役割が何かすら全く理解していないよ。Z80アセンブラも知らないと思う。
R3000ってOoO実行なのか？
将来性的に嫌われるかもなRISC-Vは128の命令セット策定してるし
個人的にキリがいいのは256だと思うが
つまりアーキのバス幅で脱皮していくみたいな設計思想ならフラグは要らないわな
今日の俺ふなっしーよりもキレキレかも いや今現在マルチスレッド関係のバグで
キレ気味なんだがな
アセンブラしかしらない人にはコンパイラの挙動は理解できないよ
使わないレジスタを壊して何が悪いんだろうか
MIPSで内容を壊してはいけないレジスタは$16-$23と$28-$31だよ
$26-$27はOS用のリザーブで$0はゼロレジスタ
コンパイラとアセンブラの併用をしたことないの？
後で使うパラメーターはメモリに保存しておいて
コンパイラはテンポラリなレジスタとしても多用してる
今時32bitや64bit CPUではコンパイラとアセンブラを併用するのが当たり前のなのに
コンパイラの関数呼び出し規約を知らないでプログラミングしてるとは驚きだ
今時、MIPSのアセンブラしかしらない人がどこにいるんだ？
たいていの人はアセンブラ覚えるのにx86あたりから入るか
MIPSのアセンブラから入ったとしてもx86のアセンブラくらい勉強するだろ
最近ならARMのアセンブラだって勉強するよな
AVR屋が暴れてるのかな？
アセンブラしか知らずにC言語の常識も知らない
8bit屋にはやっぱりC言語は無理なのかな
夜中、寝ている間は別の人の書き込みだぞ
ひとりが書き込んでると思ってるみたいだが
MIPSスレにいる。AVRスレで暴れてた。
add
adc
と言ってもさっぱり理解しないで、ずっと みたいな感じで自分の知ってることだけ、
これは知らないのか？これはどうだ？という話続けてた。論法が同じなのでたぶん同一人物。
妄想が激しすぎてるぞｗ
ここに出入りしてる人でZ80のアセンブラ知らない人っているのかよ
質問をスルーするなよ。R3000ってOoO実行なのか？
CPU界の偉大な功績者の一人だし、その人が考えた命令セットをただのアセンブラ屋がけなしてもどうにもならないよ
頭の堅い人には理解できないだけ
だから質問に答えろよ。キャリーがあると遅くなる例と、キャリ-がないと速くなる例だよ。
ご自慢のR3000でさ。
しかし、SSEやAVRが128bit整数や256bit整数の演算をしてると思ってたアホか？
AVRにはSIMD命令はないようだがな
CPUの命令セットを知らないのはどっちなんだろうなｗ
ここといい、AVRレスといい、8bit相手ばかりなんだよな。MIPSのライバルは8bitCPUなんだよ。
ARMやx86には全く勝てる気がしないのさ。
R3000の命令熟知してるんですよね。質問に答えて。
キャリーがあると遅くなる例と、キャリ-がないと速くなる例。これだけひっぱるんだから期待していいですよね。
俺は知らんよ
MIPSは16bitのイミディエイトロードでさえaddiu $4, $0, 0x1234やori $4, $0, 0x1234で代用するようなCPUだ
あまり使われないことに専用命令を用意するよりも少しでも命令数を減らしたかったんだろうな
MIPSが考案された当時は64bit演算なんてあまり使われなかったんだから
32bitのプログラミングでlong long intやint64_tはあまり使われないだろ？
8bit CPU使いが64bit整数の演算のことを気にするとはな
C言語の32bitプログラミングでlong long intやint64_tを多用することなんてないぞ
そのMicrochipが出してるPICの32bit版のPIC32がMIPSコアを使ってるから
MIPSを必要以上に嫌ってるのかもしれないけどな
68030のトランジスタ数は約30万
80386のトランジスタ数は27万5000
R3000のトランジスタ数は約11万
命令セットが単純な分、レジスタが多くても必要なトランジスタ数は少ないわけ
単に8bitCPUよりはCに向いてると言いたかっただけ。486が出てくれば逃げ出す他ない。
少ないトランジスタ数でマイクロコードを使わずにすべてハードワイヤードで設計できたんだよ
R3000の頃のRISCはハードウェアは可能な限り単純化して
コンパイラの最適化で性能を上げるものだったんだから
486時代はMIPSが一番元気がいい時代だったぞ
マイクロソフトでさえACE （Advanced Computing Environment）イニシアチブという団体を作って
Windows NTとSCO UNIXをOSにして新しいパソコンのプラットフォームを作ろうとしてたくらいだ
コンシューマではPlaystationにR3000コア、NINTENDO64にR4300コアが使われた
MIPSは1993年にシリコングラフィックスに買収されてシリコングラフィックスのコンピュータに使われた
シリコングラフィックスのコンピュータがCG映画に使われて注目されて、MIPSが一番輝いてた時代
Pentium ProでRISCに性能で追いついたからな
1995年まではRISCの勢いがすごかったが1996年あたりから急激にしぼんだのはそのせい
コンシューマなんて実はCPUは別になんでも良かったんだ。68kでもPen3でもpowerPCでもARMでも。
実際、多くのメーカーが機種変するたびに変更される。重要なのは解析されないことだから。
当時、3Dで先頭を走ってたのはシリコングラフィックスで
そのシリコングラフィックスがMIPSを使ってたから
3Dゲームを売りにしたPlaystationやNINTENDO64の時代にMIPSを採用するのは自然なこと
SEGA SATURNはSH-2
PC-FXは自社製のV810
> MIPSはスタンフォード大学のRISCの研究から生まれたCPUでいきなり出てきたわけじゃないからな
> その研究から生まれたMIPS-Xがあって、それを改良して実用的にしたのがR2000やR3000
> C言語に向いてなかったらそもそもUNIXマシンで採用されるわけがない
やはりMIPSはCに向いてると言ってる。
明らかにC言語に向いてないCPUは存在する
その代表格がPIC
8080やZ80もあまりC言語に向いてないCPUではある
sparcのレジスタウインドウみたいなのも
C言語向けとかなんとか
まあスレタイの8bitの話にもどりましょうよ みたいなｗ
アセンブラの代わりー ぐらいのノリで8bit-Cはあってもいいはず
6502はスタックのアレでCやらPascalやらは引数スタックみたいの別に
用意してたとかなんとか
add
adc
これパイプラインストールするでしょ
MIPSのIの意味を調べたら君の疑問は解けると思う
理解力があればだけど
Java Chipとかかなw
勝手に一人で逝っとけ、ボケ
> 現実、IPC高いのはフラグレジスタ持つx86系なんだよね。
時代が違うもの比較してどうする
当時のトランジスタ数で命令変換できるならやってみなよ
まあジョブズとか話し逸らしはじめたから劣勢は意識してるのかもな w
もう、MIPSの話を蒸し返すのはやめようぜ
> MIPSのIの意味を調べたら君の疑問は解けると思う
add、adcってMIPSの話じゃないですよね。パイプラインがストールって何のCPUの話ですか？
なぜいつも説明がないんですか？ 相手の理解力は関係ないですね。何も説明しないで逃げてばかりですから。
一度築いたシェアが簡単に奪われたのだから、やはり致命的な欠陥があったんだろうな。
独自の持論を展開してのはじゃねえの？
説明まだ？ 一体何のCPUの話かぐらい言わないと。Z80も8086もAVRも最新Xeonもその命令持ってるんですよ。
いつもMIPS信者が暴れだす。たぶん同じ奴。しかも8bitスレ限定。
ARMやx86スレでは暴れない。どう足掻いても勝てないから。
> add、adcってMIPSの話じゃないですよね。
当たり前だろ、何を言ってるんだよw
> なぜいつも説明がないんですか？ 相手の理解力は関係ないですね。何も説明しないで逃げてばかりですから。
だから調べてこいよ
キャリーが確定するのは演算の最後
そのキャリーを次の演算で使うのは難しいケースがあるって話し
ADD, ADC程度なら通常大丈夫だけど、ADD側のアドレッシングモードが複雑な場合などで間に合わなくてストールしてしまう場合がある
分岐はもっと深刻で分岐命令の早い段階でフラグを参照するからフラグを更新する命令と連続するとほぼ確実にストールする
遅延スロットとかでググれ
煽るしかできないバカは出てくんな、ウザいわ
以前PICのスレでと全く同じような発言をしてMIPSの定石を知らないだけと
論破されてた人が居たが同じ人か
ファブレスの限界だったのでは？
シリコングラフィックスがMIPSからIteniumに移行してからMIPSの製造から東芝やNECは撤退した
最近ではスマホの影響でARMが大量に使われて
そのおかげでTSMCやサムスンなどのファウンドリが急成長してIntelに製造技術で追いついてきたけどね
ノキアに採用され携帯電話向けで大躍進
携帯電話で多く採用されたことからiPhoneやAndroidにも採用されさらに大躍進した経緯がある
x86もIBM PCに8088が採用されたのがきっかけ
x86もARMも性能面で優れてたから普及したわけじゃないんだよな
ARMの歴史―ARM1からARM7まで
ttp://www.cqpub.co.jp/hanbai/books/33/33291/33291_pro.pdf バカなの？
Z80にパイプラインなんてないし8086のパイプラインはなんちゃってだよ
（まともなパイプラインは80386から）
AVRは知らんけど最新のXeonとか時代が違うって何度も言わせるなよ
技術的な話についてこれないなら黙ってろ
PICスレで暴れてたMIPS信者がなんでこんなとこにいるんだよ？
MIPS信者はウザイからPIC32はスレ分けろで結論出てただろ。
ほんとこいつ最悪だよな。いつも下位CPUのところで暴れやがる。
ニュースとか見ないのか？
お前、なんで東芝がメモリー事業を売るはめになったかも理解できてないだろw
半導体ってモノのデキより資金力の方が重要だったりする
まただよ。いくら質問しても言わず、どのCPUか全く言わないからいくつか例を挙げたら全否定して、これだのパターン。
典型的無能学者のマウンティング。少しは恥を知れ、カス。朝生じゃねーんだよ、ここは。
また質問からかよ。おまえは先にすべての質問に答えろ。
> Z80でフラグレジスタ禁止にしてみようぜ。
>
> Σ(ﾟДﾟ) 条件ジャンプができない!!!
Z80知らないんだな。DJNZ命令で条件ジャンプできるぞ。
この人、全く分かってないね。キャリーだからストールするだったのに、アドレッシングが複雑だからになってるよ。
add、adcのただの組み合わせ回路の話が、分岐の話にもなってる。
しかも一回演算のキャリーでは遅延し、二回演算のMIPSでは遅延しないというオカルト論理。どうみても前者のほうが高速。
つまり調べたらキャリーは全く関係ありませんでしたってことだよね。
AVRで結論でてるでしょ。add、adcで2clockで終わるって。キャリーでストールするんじゃなかったんですか？
結局R3000だとその代替の4命令で何clockかかるんですか？ 2clockじゃとても終わりませんよね？
逆に言えば、MIPSの突っ込みどころはキャリーフラグがないことだけってことかな
ARMは組み込み向けではThumbに32bit長の命令を追加したThumb-2のコード密度が高いことが評価されてる
組み込み向けのCortex-MではARM命令は実装されずにThumb-2のみになってる
PIC32ではMIPS16eを使ったM4KコアやmicroMIPSが使えるmicroAptivコア、M5150コアが使われてる
なんで答えないんだろう？ これがキャリーを排除すれば速くなるというMIPSアーキテクチャの成果だよね。
いやいや、スレの内容理解してたらパイプラインを持たないCPUとかR2000/3000と時代が全く異なるCPU挙げてもバカって言われるのはわかるだろ w
にも書いたけど80386まではまともなパイプラインを持てなかった
その時代にパイプラインストールを避けるためのひとつの手段だよ
当然お前らみたいにそんなもん速くなるわけねーだろって奴等もいたけど議論の上採用したってこと
> また質問からかよ。
それ質問ちゃうで、単にバカにしてるだけ
ひょっとして気づかなかったの？ w
ちな、答は最下行な
わかってないのはお前さんの方だよ
アドレッシングモードの話は演算タイミングが違うようになるからストールの可能性か発生するって話しな
なんでRISCは単純なアドレッシングモードしかサポートしないのかもわかってないでしょ
分岐の話しはアホにもより分かりやすくしたつもりなんだけど想像以上にレベルが低かった w
> AVRで結論でてるでしょ。
そのAVRの型番は？
まさかと思うけど全然世代が違うとかないよね？
組み込み用なんかだと、128ビット演算は殆ど使わない（ここ大事）ので、
必要に応じてソフトでやる。とか、普通にある気がしますけど。
センサーのデータ取り込みとか、工業用機械のサーボ動作とか。
消費電力の少なさやリアルタイム性が大事で、ややこしい計算は、別にあるコンピュータでやらせるって、今時は特にふつうだと思いますよ。
ローテートも無いと困る
例外処理じゃなくてキャリーオーバーで分岐とかできなかったんかしら
それか例外出さない命令のあとに大小比較か最上位ビット見て分岐
MIPSでオーバーフローで例外が発生するのはaddとsubでadduとsubuは例外は発生しない
加算、減算は符号付、符号なしで結果は同じになるので
MIPSのCコンパイラではaddやsubは一切使わず、adduやsubuしか使ってない
多倍長演算の時のキャリーやボローの検出はのやり方でやってる
そんな素人の考えだけどフラグ反映させる必要が無くて処理速度ほしいなら、それ用の命令作ればいいじゃね？
いくらRISCだっても、その程度の命令をつくるぐらいの余裕はあるとおもうんだがねぇ。
プログラマが(コンパイラが、かもしれんけど)わざわざ判定のために最上位ビット見るコードを書いてそれを走らせるとか無駄な気がする。
判定のためのコードを入れるぐらいならフラグ確定まで遅延させても大差ないだろうし、遅延しても「プログラマ（コンパイラ）が書いた判定のためのコード」を実行させるより効率はいいと思うんだよな。
で、いつになったら俺がついていけそうな8ビットの話題に戻るのかな？
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
>いつになったら俺がついていけそうな8ビットの話題に戻るのかな？
もともとキチガイの隔離スレだぞ、何言ってんの?
キチガイもいちおう「8ビットじゃC言語有りえねぇ！」って8ビットには言及してたからね。
64ビットだのRISCだのは、まったく着いていけねぇんで疎外感バリバリなのよ、おじちゃんはｗ
> そんな素人の考えだけどフラグ反映させる必要が無くて処理速度ほしいなら、それ用の命令作ればいいじゃね？
それ専用の命令が stu な
お前の考える程度のことを誰も思い付かないとか思っちゃった？ w
stuじゃなくてsltuだろ
あと
dext $8,$8,0,32
これは$8に入ってる32bitの値を64bitの値にゼロ拡張する命令
sltu $8,$2,$4
の場合、$2と$4を比較して$2が小さければ$8に1がセットされ
それ以外の時は$8に0がセットされるという命令
加算した後の値が加算前の値より小さければ桁あふれが発生してることを利用してる
> 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では何クロックで終わるんですか？
> 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では何クロックで終わるんですか？
多倍長計算が頻繁に行われるかもしれないが
32bitのプログラミングで64bit変数などあまり使われない
同じように64bitのプログラミングで128bitの変数などあまり使われない
8bit、16bitCPUと32bitCPU、64bitCPUとでは多倍長計算の重要度が違う
ここは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では何クロックで終わるんですか？
／￣￣＼
／ _ノ ＼
| （ ●）（●）
. | （__人__） MIPS信者がスレチで荒らすから増えたんだろ・・・
| ｀ ⌒´ﾉ
. | } 常識的に考えて……
. ヽ }
ヽ ノ ＼
/ く ＼ ＼
| ＼ ＼ ＼
| |ヽ、二⌒)､ ＼
それに答えてるだけ
荒らしてるのはAVR信者
／￣￣＼
／ _ノ ＼
| （ ●）（●）
. | （__人__） 質問に答えればいいだけだろ・・・
| ｀ ⌒´ﾉ
. | } 常識的に考えて……
. ヽ }
ヽ ノ ＼
/ く ＼ ＼
| ＼ ＼ ＼
| |ヽ、二⌒)､ ＼
嘘つかないでください。何度質問しても誰も答えてくれてません。
> 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では何クロックで終わるんですか？
32bitの乗算、除算は？
それとARMにもADC命令があるというけど、ARMの場合、
Cortex-A9とそれ以前のARMには除算命令がないが
プログラムで除算を実現するより、除算命令があった方が早いのが現実
しかもAVRの加算命令クロックは既出です。32bitなら4命令で4clockです。
上のほうでもEWS4800は異常に遅いという話も出てたし。
意味不明にストール、ストール言ってるからMIPSには致命的な欠陥があってとにかくストールばかりしてるんだと思う。
R3000なら1クロックだろ
R3000は基本命令は1クロックで実行だから64bit加算だって4クロックだろうな
なんでMIPSがUNIXワークステーションで普及したかわかるか？
当時の68030やSPARCよりも高性能だったからだぞ
どこでも出しますよーみたいな
ネットに上がってるベンチマークを見てみろよ
SPARCや68030より速いから
当時のSuperASCIIを持ってるが載ってるベンチマークを見るとSPARCや68030よりも速い
MIPSの登場で680x0のUNIXワークステーションは駆逐された
> 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で終わるとのことです。 ←ソース。
結論は出ましたね。キャリーがないと無駄に実行命令が増えて遅くなる。
それ以前に、当時のCコンパイラだと64bit整数をサポートしてないものも多いぞ
おそらくパソコン向けのCコンパイラは全滅だろうな
実務でコードを全く書いたことがありませんってことだな。
だって、演算も関数コールでやるわけだろ？
関数コールの方が64bitの加算、減算よりもずっとクロックは余計にかかるよ
なあなあ、
ttps://godbolt.org/g/RLYRJg これ↑どっちが速いと思う?
今度はその欠陥は使われない!!!ということを強調したいらしいが、安心してほしい。
MIPSはもう使われないからいくら欠陥があっても何も問題は出ない。
PIC32がエラッタだらけ？ ノープロブレム。メジャーな代替CPUはいくらでもある。
されてるよ
ttps://godbolt.org/g/u7XHj8 ああ、PICスレでエラッタ、エラッタ連発して荒らしてるのってAVR信者だったのか
答えを知ってるなら答えを書いて説明してはいかがだろうか。
自分が知ってることをいちいち質問するのは時間の無駄だ。
分からないならそういう上から目線ではなく教えてくださいだろう。
キミのその高圧的な態度は無知な教師によくいるが甚だ不快だ。
> 答えを知ってるなら答えを書いて説明してはいかがだろうか。
なんで?? オマエがどっちが速いと思うか訊いてるのに。
> intelなんて前世紀に128bit演算追加してるというのに。今は512bit演算の時代ですよ。
へーそーなんだｽｺﾞｲﾈ
参考までにどういうコードになるのかみたいに曝してｸﾚｸﾚ
すごいコードだな
さすがにAVRで64bit加算はつらいか
インテル信者が自分の信仰するCPUについての知識がないわけがないだろ
> intelなんて前世紀に128bit演算追加してるというのに。今は512bit演算の時代ですよ。
これを書いたのはAVR信者だろうな
ろくにx86の知識もない
ここで暴れてるインテル信者はマイクロプロセッサの知識もプログラミングの知識も碌にないよ
これで一番キレてるのがAVR信者ってことだな
AVRはArduinoで採用されて有名だがArduinoはC++モドキの言語使ってるからな
ろくにアセンブラの知識もないんじゃね？
どっちが高速かなんて市場で答えでてるのにこの構図は卑怯じゃないのか。
ttp://www.denshi.club/pc/arduino/esp8266iot1-blink.html > ESP8266はライセンス料金が割安だといわれているMIPSアーキテクチャのCPUを搭載しています。
> ArduinoはこのCPUのコンパイラにも対応しました。
あのー、はしゃいでるところ申し訳ないけど80386も4clockかかるよ
まさか１命令1clockとか思ってないよね？ w
ttp://https://pdos.csail.mit.edu/6.828/2017/readings/i386/ADC.htm">ttps://pdos.csail.mit.edu/6.828/2017/readings/i386/ADC.htm ： ナイコンさん [] 2018/06/19(火) 08:25:20.51
Arduinoにx86はない。Arduino 101で動作してるのはARCだし。
インテルがx86載せた互換機出してたが致命的な問題を解決できずに終了した。
昔、自作板で暴れてたARM厨も同じやつだろう。
煽ってるのはAVR信者
おまえ昔、そうやって、自作板でスレチのARMのコピペしまくって荒らしてただろう？
ttp://msyksphinz.hatenablog.com/entry/2017/03/10/020000 図星かよw
え？MIPSは今でも普通に現役で使われてるけど？
キミ、モノ知らなすぎでしょ
顔真っ赤にしながら、MIPSの話題はスレチだから！は、流石にみっともない
MIPSは昔のPCでもないからな。相手にするから粘着して暴れるわけで、MIPSはNG推奨だな。
そう言うのはに言えよww
MIPS(笑) NGなら見えてないはずw
（２）空気の読めないMIPS信者が荒らし目的のAVR信者にマジレス
これの繰り返し
もう、挑発に乗らないでスルーしろよ
オマエモナー
486と比べると優位性が無くなってしまうからｗ
まあ、120万トランジスタも費やしてるからねえ
ちなみにR3000は11.5万トランジスタ
FPUは外付けなのでそれを加えても30万トランジスタにも満たない
そろそろR10000の話をしようぜ。
という単純なことも理解できないおバカなAVR信者がMIPSに噛み付いてるってことかな？
Cの貧弱な文法じゃ使いようが無いけど
ここまでキャリーが何か分からない奴はCなんてとても無理だろう。
( ´,_ゝ｀)ﾌﾟｯ
AVR信者がキモチワルすぎ
AVR信者はAVRしか使わないのかって話
さすがにAVRしか使わないって人いないだろ
それと同じことでMIPSしか使わない人などいない
世の中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の概要
ttps://www.cl.cam.ac.uk/teaching/1617/ECAD+Arch/files/docs/RISCVGreenCardv8-20151013.pdf MIPS32 Instruction Set Quick Reference
ttps://www2.cs.duke.edu/courses/fall13/compsci250/MIPS32_QRC.pdf グーグル、オラクル、HPEなどがRISCプロセッサのオープンな命令セットを開発する「RISC-V」参加へ
ttp://www.atmarkit.co.jp/ait/articles/1601/05/news090.html 海外で急激に盛り上がる新CPU命令アーキテクチャ「RISC-V」
ttps://pc.watch.impress.co.jp/docs/column/kaigai/1094808.html だってﾝなチンケなプアCPU使う必要ないんだもんｗ
大学はじめRISCでがんばってAMDとIntelを蹴落とそうと努力するしかないわけですよｗ
しかし、RISC-Vってもどの程度の成果がでるのかねぇ？
( ´,_ゝ｀)ﾌﾟｯ adc命令知らなかったじゃんw
いつものMIPS信者だw
普及活動のために必死にコピペするからすぐわかるw
( ´,_ゝ｀)ﾌﾟﾌﾟｯ
( ´,_ゝ｀)ﾌﾟﾌﾟﾌﾟｯ ほんと笑えますよね
勘違いした学生が大勢市場に出て困る。
> それまでMIPSアーキテクチャのマイクロプロセッサを手がけていたIDTなどの半導体企業はR10000を製造しなかった。
> 2008年初め、ミップスはプロセッサ事業部門の28人の従業員を解雇した。
> 2008年8月13日、会計年度の第4四半期が1億850万ドルの赤字となり、さらに従業員の15%を解雇することになると発表。
( ´,_ゝ｀) 大変でつね
8bitなら、Z80かAVR、32bitならx86とARMにしてほしいわ。
その変態ブリを高級言語でラップして使うものという流れだったような。
80年代末のarconのARM1搭載した32ビットパソコンのアルキメデスの
OS、RISC-OSには開発ツールの中にARM用のアセンブラがあって、
今でもラズパイ1用にポートされたRISC-OS下で使える。
ttps://ja.wikipedia.org/wiki/RISC_OS > 後方互換
> 新たなバージョンのOSやハードウェアへの移植性は高くない。
> BBC BASIC で書かれたプログラムは比較的移植が容易だが、
> デスクトップアプリケーションやゲームには深刻な後方互換問題がある。
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イミディエイト値を読み込める
即レスでadcって言われて話は終わってた。無駄に低脳馬鹿を相手したAVR信者が悪い。
どうしても勝利宣言しちゃいたいとか。どこかのお国の方みたいw
8bitCPUの話に戻すとAVRはC言語に向いてると言えるな。
AVRは板違いではないか？
所詮8bitだし、AVRやってると勘違いした人になるのかもな
専門学校などの8bit CPUを題材に使ってるのは時間が限られてるし
8bit CPUは簡単で短時間の授業で教えられるからだぞ
ADC命令でドヤ顔されても当たり前の話すぎて笑える
ADC命令を知らない人がいるってことにしないとドヤ顔できないから困るんだろうな
( ´,_ゝ｀)ﾌﾟｯ
に言ってやれよw
あったよね？
AVRとかハエが止まるようなクロックで動いてるマイコンならフラグで問題ない
反撃するならちょっとはまともなこと書けよ
まあできないからそのレスなんだろうけどww
x86やx64はフラグ有りますが？
トランジスタ数が文字通り桁ちがいなので比べるのはアンフェアかもしれんが、現実は現実だからね。
おれはそこら辺の細かいことは知らんけどさ
延々と改良やめない所が勝つから読めないねぇ
intel?逝ってよし
コンパイラが頑張ってRISC命令を並び替える
どっちもメリット/デメリットあるからどっちかが優れてるとか言ってる奴は単なるアホ
BCDのためだが。
大学でMIPSから入った人が暴れてるんでしょ。
未だにMIPSアセンブラ教えてる大学が諸悪の根源。
クロック上げに失敗したのがMIPSだけなんだよ。
まるでIntelコンパイラが頑張ってないみたいな言い方だな。
コンパイラもCPU実装も手抜きしたのがMIPS。どっちも頑張ったのがIntel。
だから天地ぐらいの差がついた。未だに現実が見えない奴は真性のアホ
なんでこういう頓珍漢なアホっていつまでもいなくならないんだろう...
物量作戦の意味もわかってないんだろうな w
へーMIPSは物量作戦使ってないのか。また捏造する気？
R3000 30MHz
AVRは蝿が止まれるclockと言ってるが、MIPSはAVRを馬鹿にできるほど全然速くない。
前の例でAVRは2clockで、R3000は4clockかかるらしいから、なんと実はAVRのほうが速い。
( ´,_ゝ｀)ﾌﾟﾌﾟｯ
命令制御にはたいして使ってないよ
まさかそんなことも知らんのか？
では教えてほしい。そんなにシンプルにしたのになぜclockが上がらなかったんだ？
riscなんて無制限にクロック上げていけるのかと思ったｗ
製造プロセスレベルで作りこむとこがライセンスしなかったから？
これでどうやってIntelに勝てというのだ。
> 前の例でAVRは2clockで、R3000は4clockかかるらしいから、なんと実はAVRのほうが速い。
マジかよAVRマジハンパねぇな。
ttps://godbolt.org/g/u7XHj8 なぜシンプルなのにMIPSはクロックが上がらなかったんですか？
WD、2019年からNAND/HDDのコントローラを順次RISC-Vベースに移行
ttps://pc.watch.impress.co.jp/docs/news/1128863.html > WDは2017年11月に、自社製品にRISC-Vアーキテクチャを採用していくことを発表している。
> 具体的には、現時点ではプロプライエタリのHDDやNANDコントローラを、
> オープンソースのRISC-Vに置き換えていくことを目指しており、
> 年間10億コア以上の採用を約束している。
普通にGHｚの製品もありますが・・・
Imagination Technologies, Creator Ci20 コンピュータボード JZ4780 MIPS CPU
ttps://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をサポート
これは主にネットワーク機器向けのプロセッサだが
Cavium社、48コアを搭載した2.5GHz駆動のOCTEON IIIを発表
ttps://tech.nikkeibp.co.jp/dm/article/NEWS/20120216/204850/ x86_64以外はSPARC64 XII、POWER7、8、9、メインフレームのZ13、Z14くらいしかない
それくらいじゃないかな
スレチの話を延々続ける粘着君に言われてもなぁw
まだ質問に答えてくれてませんよ。また何週間も答えないつもりなんですか？
> なぜシンプルなのにMIPSはクロックが上がらなかったんですか？
運が悪い
客に恵まれてない
敵に恵まれてた
ビジネス的に必要ないと判断したんだろ
全ての車メーカーがスポーツカー売る訳じゃないのと同じ
> 生い立ちが悪い
> 運が悪い
> 客に恵まれてない
> 敵に恵まれてた
そだね～。一つ付け加えれば、インテルは半導体屋でMIPSを買収したsgiは鯖屋。
鯖屋では半導体屋のような畑仕事ができず、かといって新たな荒畑な日電では高速IC
作るの無理ポだった。鯖屋のDEC、Sunもシリコン畑仕事できないオッサン会社だったから
MIPS＠sgi同様に没落したよね。
MIPSはハードウェアマルチスレッドという特殊な仕組みを導入してるコアがあるが
一応デンソーはこれに注目してMIPSと提携して新しいプロセッサーを開発してる模様
Intelが買収したMobileyeのEyeQシリーズに一応MIPSコアが使われてる
DECのAlpha、PA-RISC、Intelのi860、AMDのAm29000、モトローラのMC88000、ApolloのPRISM
これらは全部消えた
主として組織的な問題で・・・
並行してMZでPASCALやLOGOをやったっけ。
8ビットでBASICとマシン語以外の言語、全然ありえたよ。
起動するとBASICが使えましたが、Cは使えませんでした。
ROMのCコンパイラってないのか
あまり意味はないが
親がバブルにのって金回りが良かったんだろう、たぶん。
田舎だったんでバブルの恩恵あんまりなかったなー。
はじけた後は影響有りまくりだったが。
X1用のCP/Mが安く売ってたという話をたしか聞いた覚えがあるが
PC8801用は？
ネットに落ちてた月刊I/Oの広告を見てたらZ80B用とMZ-2000用のCP/Mが3万5千円と載ってたが
MSX-Cを使うにはMSXDOS-TOOLSが必要でこれが定価14800円
なのでMSX-Cを使うには定価で3万4600円かかった
マイクロソフトウェアアソシエイツ(MSA)版CP/Mは6万5千円だったはず。
後日NECが販売したNEC版は4～5万円ぐらいに値下げされてた。
（こっちは買ってないのでうろ覚え）
だから何? ケチつけたいだけ?？
できるだけだが。
なので、longやlong long intが無いと言うのは致命傷ではない。
多バイト長整数の演算ができるなら浮動小数点実数の演算はできる。
できるだけだか。
なので致命傷ではない。
サブセットだから何が悪いと言うことはない。
互換性に問題が出てくるじゃんintをbyteにリプレースすればいいだろうけどさ
x byte
o char
CP/Mは高かったんだな
int は最も効率よく処理できるサイズじゃなかったっけか。
なぜか 8 bit CPU でも int は 16 bit だったりするけど。
移植性が重要なら、int は使わないようにすべきだろうね。
なんでいちいち半角スペース挟むの？気持ち悪い
全角と半角間は1/4スペースを入れるのが見やすくていいんだがその代用として半角スペース入れてるんだろ
ないと詰まりすぎる
そういうダルダルなとこがいいんじゃないか！
適当に型名ふってプリプロセッサに任せればいいかうーん
↓曰く、ggrks だとよw
ttps://gcc.gnu.org/ml/gcc-help/2011-05/msg00144.html ttps://sourceforge.net/projects/z80gcc/ マジか あんノカ
さすがにねぇダロと思ってggrなかった ks
そもそもz80のｇｃｃの存在自体が無名あったのか・・・
avr-gccは結構実用的に使われてるよ
ちょっと見てみよう
やるぞ！ だけじゃん。実体のない空ファイルサイト。gcc/z80なんて存在してないのさ？
GCC toolchain for Z80 Source forge Z80/R800用はbinutilに組み込まれており、
GNUアセンブラ環境は通常のbinutilパッケージでビルドできる。
Cコンパイラは2013.5現在もリリースされてない様子。
計画倒れだよね!
AmstradCPC 向けのcコンパイラで検索してたら、sdccとかいうGPLなクロスコンパイラが
引っかかった。win/Mac/Linux 対応。z80のみならず、MCS51とかPIC版も進行中らしい。
ANSI準拠なのでlongやらfloatもサポートしているのだとか。
SDCC is a retargettable, optimizing Standard C (ANSI C89, ISO C99, ISO C11) compiler
suite that targets the Intel MCS51 based microprocessors (8031, 8032, 8051, 8052, etc.),
Maxim (formerly Dallas) DS80C390 variants, Freescale (formerly Motorola)
HC08 based (hc08, s08), Zilog Z80 based MCUs (z80, z180, gbz80, Rabbit 2000/3000, Rabbit 3000A, TLCS-90)
and STMicroelectronics STM8. Work is in progress on supporting the Microchip
PIC16 and PIC18 targets. It can be retargeted for other microprocessors.
ttp://sdcc.sourceforge.net 知らんのだろうなとか言わずにいられないぐらいだからよほどマウンティングしたいのだろうな
ですよねー
MSX-Cのセルフ開発で大変だったとアスキーネットに書いてた
自分はそんな規模のプログラムは書いたことないけど。
あんな感じの例外判定とか省いた専用ライブラリに差し替え
でコンパクトで速いバイナリー生成させるのも可能よね
ライブラリはともかく基本型の四則演算て差し替えられるかわからんけど
後発の6809はスタック操作が得意なのでC言語にも向くけど
そりゃスタックが２つあるんだからね
上にも書かれてるけどアドレッシングモードが充実してるのがでかい
6809はスタックポインタでインデックスレジスタと同じアドレッシングが使えるからね
そして6809はインデックスレジスタを使ったアドレッシングが強力
中途半端でもZ80のようにレジスタ多いほうが楽なんじゃないの？
6809は高機能なアドレッシングモードでメモリ主体の演算
プログラムの組み方が違う
6809はさらにバスを遊ばせまくっている
なんでダイレクトページにアイドルが入るんだ
まだそんなアホなこと言ってる爺は滅びればいいのに…
全くその通り。x86の爆速化の理由はこれ。
スタックに積んだローカル変数をレジスタ並の速度でアクセスできるようになった。
そのためにRISCのレジスタが多いというメリットはどうでもよくなった。
馬鹿発見ｗ
キャリーの実装を全く理解してなかったし。
> そのためにRISCのレジスタが多いというメリットはどうでもよくなった。
スーパースカラーは念頭にないんかな? 486時代で頭ン中止まってる人か
自分でこないだ暴れてた馬鹿だってバラしてどうすんのｗ
> キャリーの実装を全く理解してなかったし。
自信満々でドヤってたら一撃でフルボッコされたを苛めるのはそろそろやめて差し上げろ w
ttps://godbolt.org/g/pNu2u5 MIPS知らないで叩いてる君はこんなんで386が速いと思ってたんかｗ
> そのためにRISCのレジスタが多いというメリットはどうでもよくなった。
AMD64 以降もレジスタ数増え続けてること知らんのかな
むしろポインタ64bit化でキュッシュが実質半減したせいで遅くなる処理もちらほら。
現状認識がこんなんでなんか語るとかｗ
64bit化では全く同じようなアーキテクチャで64bit変数をほとんど使わない場合
通常64bitアプリの方が32bitアプリより遅くなる
実際にPowerPC時代のMacがそうだった
MIPSでも64bitアプリの方が遅くなる
しかし、x86はレジスタが増えたおかげで64bitアプリの方が数パーセント早くなった
ARMも同様にレジスタが増えたおかげで64bitアプリの方が数パーセントだけだが早くなる
たった数パーセントと馬鹿にする人がいるが、
ハイエンドのx86はクロックがたった数百MHzで価格が変わったりする世界だしな
だから関数呼び出しのオーバーヘッドは減る
高級言語は関数呼び出し規約に縛られて
最適化も関数呼び出し規約の枠内でしかできないからある程度はレジスタの数が多い方がいい
32bitのx86はスタックポインタを除くと実質レジスタが7本
これでは少なすぎた
32bitのARMもRISCのロードストアアーキテクチャなのに実質レジスタが13本なのは少なすぎ
(32bitのARMはR13はスタックポインタ、R14がリンクレジスタ、R15がプログラムカウンタ)
x86は64bitで遅くなる処理は限られてるからな
レジスタが増えなかった場合、
64bit演算をしないすべての64bitアプリで32bitアプリより遅くなったはず
多少ではあるがレジスタが増えた効果は出てるわけ
return a + b + c + d;
}
これをコンパイルすると
32bitだとこうなるが
mov eax, DWORD PTR [esp+8]
add eax, DWORD PTR [esp+4]
add eax, DWORD PTR [esp+12]
add eax, DWORD PTR [esp+16]
ret
64bitだとこうなる
lea eax, [rdi+rsi]
add eax, edx
add eax, ecx
ret
レジスタが増えるとはこういうこと
lea edx, [rdx+rcx]
add eax, edx
ret
スーパースカラー動作を期待すればこうなるべきだと思うがいまのコンパイラってまだこんなんなの
2: add eax, edx
3: add eax, ecx
だと eax に結果が出ないと次の加算ができないので順番に処理してくしかない
1: lea eax, [rdi+rsi]
2: lea edx, [rdx+rcx]
3: add eax, edx
だと 1 と 2 が同時実行できるかも。あるいは
1: lea eax, [rdi+rsi]
2: add ecx, edx
3: add eax, ecx
でも良い。
lea eax, [rdi+rsi+rdx+rcx]
ret
「・・・っしょ！」 って語尾がなんかイラッとくる
キャッシュって、ライトスルーキャッシュとライトバックキャッシュぐらいしかしらねー
データも読み込みン時に、命令先読みと同じように64バイトや256バイト単位で周辺メモリも読んでキャッシュしとくとかもあったっけ？
DMAでキャッシュフラッシュ・・・
MIPS32 24K / 1.51 MIPS / 2006
Intel Core i7 920 / 30.1 MIPS / 2008
シンプルな命令ばかりのRISCは並列化しやすくMIPSが高くなる傾向があり、クロックも挙げやすいからだ。
夏厨の書き込みに目くじら立てちゃダメだよ
荒らしが目的なんだから
Cortex-M0 0.9DMIPS/MHz
Cortex-M3、M4 1.25DMIPS/MHz
プログラム関数電卓のHP社HP50gは4bit CPUなのにCコンパイラがあるよ！
Ti社一番の売れ筋 Ti84 plusはZ80なのにCコンパイラあるよ！
HP50gはSaturn CPUだけど、4004にもCコンパイラ探せばあるかもね
（インタプリタだけど）
あれはCじゃない
> 4004にもCコンパイラ探せばあるかもね
ハードウェアスタックが３レベルしかないからかなり苦しい
引数３つめまではレジスタに、４つ目以降はスタックに積むコード吐いてたな。
ｱﾚがRISCかっていうと微妙な気がするが。
馬鹿はよくそういう勘違いする。
MIPSのクロック辺りの性能の低さは特筆すべきものがあるな。
たださえ重要な命令を端折って冗長なコードを書かねばならないのにこの遅さ。
しかもクロックも相当低い。
MIPS信者の敵が8bitPICやAVRである理由がよく分かる。競合する市場は8bitマイコンだからな。
なんてことをよく耳にするが現実の歴史は真逆だったんだよな。
MIPSは全く性能が上がらなかった。
彼らはまだこの事実を受け入れられてないから未だに昔のPC板にいるんだよ。
MIPS に親でも殺されたのか w
> CPUコアはなんでも良かった。
あの当時他の選択肢として例えば何があったという主張?
むしろMIPS厨はなんでいつも8bitスレで暴れてるんだ？ 逆恨みもいいかげんにしてもらいたい。
> MIPS32 24K / 1.51 MIPS / 2006
後発のくせにクロック当たりの性能で負けてるからじゃないかな
8bit級の32bitCPU
ということか
いきなりMIPSガーって言い出したをなんとかしてから言ってくれよ w
MIPSの話題禁止
と入れよう
> 90年代、オールアセンブラのVzエディタが爆発的に売れたことから考えると、
Vz以前からCで書かれたMifesが売れてたこと知らないのかな??
その１を立てた俺にとっては最高の賛辞だぜｗ
夏は2週間しかないからなぁ、北海道は。
あなたとは
MIPSに親でも殺されたんだろう
自分がいきなりMIPSの話を持ち出しておいて、MIPS信者が8bitスレで暴れてるとかわけわからない
MIPSの純正コアの話をすると性能重視のP-Classは人気がないんだよな
ワンチップマイコン向けのM-Classや
ハードウェアマルチスレッドに対応してるI-Classの方が人気がある
最近発表されたnanoMIPSを実装したI7200もI-Classのコア
＞MIPS信者の敵が8bitPICやAVRである理由がよく分かる。競合する市場は8bitマイコンだからな。
自己紹介しちゃってるなｗ
MIPSを目の敵にしてるMIPSに親殺された人は8bitPICやAVR使いだったのか
MIPSってどんな石なの？
スパロボのｽｰﾊﾟｰロボットに例えて教えてくれ。
なにせ、MS-CやLattice-Cが10万円くらいした時代に3万円以下でフルセットのCコンパイラが手に入ったからな
しかもANSIの仕様を先取りしてた
Turbo-Cはコンパイラ自体は機種に依存してなかったので
PC98用のTurbo-CでもPC98関連のライブラリが使えないだけで他のMS-DOSマシンでも使えた
デバッグも当時のMS-DOSに付属してたSYMDEBでソースコードデバッグもできた
「1バイトでも小さく、1クロックでも早く」が正義だった大昔ではなくて、バブルはじけた後、ソフト改修で古いハード使いまわそうって頃。
「わかり易い＝保守しやすい」が正義って時代。
80年代でもC言語使うところは使ってたけどね。
誰かそんな話してる?
キチガイが勝手に勘違いして暴れたところに、80年代にもC言語使ってたのが「俺使ってたシーｗｗｗ」って突っ込みいれてたら勝手に80年代縛りいれて「ありえねー！」ってファビョってるだけ。
ノブヤボがあったから最初から「ありえないはありえない」だったんだけどねｗ。
詭弁w
珍しくないのならいくつか書籍名を挙げてほしいわ。
「無くはない」だろ。
セルフかクロスか問わなきゃ「珍しくない」でも良いけど。
ノブヤボは2作目からC言語だったぞ。
デタラメ言うと日吉の連中が怒るぞｗ
そりゃ素人向けの書籍はそんなもんだろ。
敷居を低くしないと売れないし。
信長の野望は信長の野望だ。これはCではない。2作目は～とか意味不明な後出しされてもね。
シリーズは腐るほどあるんだからスマホ版はJavaかもしれないだろ。
一つもないのかよwww 一つぐらいあるだろ。探せよw 珍しくないんだろw
詭弁乙ｗ
その論でいえば「全てのコンピュータゲームは機械語で書かれている」になっちゃうぞ。
そうなるんだよ、詭弁くんの言い方だと。
論理の基本すら理解してないのか。十分条件、必要条件で挫折したタイプだな。
ほんと馬鹿だな。P⊃QのときQはPなのか？ 馬鹿杉なんだよ、おまえは。
理論以前の詭弁を振り回す奴に言えよｗ
まぁ「C言語ありえねぇ！」って嘘をいつまでも言う粘着が居るスレだから馬鹿が多いぐらい当たり前だろうけど。
＞「C言語ありえねぇ！」って嘘をいつまでも言う粘着
をつついて転がして遊ぶスレっしょココ
貧乏人だったんだろうなぁ。
珍しくもないなら、ネットのない時代、書籍や雑誌に8bitPC向けのCのソースが溢れてるはずでしょ。
ベーマガみたいな雑誌でもいいよ。MIPS信者じゃあるまいし、
アセンブラ本を素人向けだの言って誤魔化さないで質問に答えてよ。
OS-9ぐらいしかないだろ、8ビットだと。
こいつは自分が世界の中心だと思ってるタイプ。
出したら出したでまたケチ付けるの目に見えてるしなあ。
アホにエサやるのも飽きてきた罠。
珍しいいかどうかは知らんけど8bit CPU ターゲットでC言語が使われてた事実は変わらんよ ⇒
> ベーマガみたいな雑誌でもいいよ。
I/O や Oh!MZ が Small-C を記事にしてるしインターフェースやプロセッサで
8bit 用の C コンパイラなんて幾らも記事になってる。
> で、8bitPC向けのC言語のゲーム開発の書籍とか雑誌はないの？
あるけど何？
↑amazonで検索することもできないバカｗ
Amazonを検索する知恵もないお前に代わってちらっと探してきてやったぞｗ
これで全部でもないだろうけどいちお80年代縛りなｗｗ
BDS Cの使い方 単行本 – 1984/1/1 稲川幸則 渡辺修
ttps://www.amazon.co.jp/dp/476920129X/ Small‐Cハンドブック (I/O books) 単行本 – 1985/1 J.E.ヘンドリックス (著), 小野 芳彦 (翻訳)
ttps://www.amazon.co.jp/dp/4875930623/ Z80制御用マイコンのファームウェア技術―CプログラムのROM化 単行本 – 1986/5 風間 悦夫 (著), 宮下 俊幸 (著)
ttps://www.amazon.co.jp/dp/4526020397/ BDS Cプログラミング 単行本 – 1986/6 御手洗 毅 (著)
ttps://www.amazon.co.jp/dp/4769201540/ 学習BDS C・α‐C 単行本 – 1987/4 御手洗 毅 (著), 御手洗 理英 (著)
ttps://www.amazon.co.jp/dp/4769201648/ パソコンゲーム以外にコンピュータは無いのですｗｗ
そんな程度の認識なんだろうなぁ。
紹介記事の話じゃなくてさ、普通に使われてるならCのソースが大量にあったかって話なんだけどさ。
I/Oってダンプリストが大量にあった記憶があるけど、その中にCのソースも大量にあったかって話さ。
X1よりさらにマイナーなMZはさすがに読んでる奴はさらに少数派だろ。珍しくないという話なんだから
圧倒的多数派の88の話にしてくれよ。普通にとか珍しくないとか言う割りにいつも重箱の隅の話ばかりじゃねーか。
どんだけC言語嫌いなんだかｗｗｗ
見苦しくグダグダやってないで素直に負け認めたら？
解散
Oh!MZのTHE SENTINELはソース掲載がポリシーだったことも知らんとかｗ
> I/Oってダンプリストが大量にあった記憶があるけど、その中にCのソースも大量にあったかって話さ。
I/Oなら別冊でSmall-Cの全ソースリスト掲載と解説してる本出してるけど?
Oh!MZがどういう雑誌だったかも知らんド素人が何でこの板にいんの?
そしてまたマイナー機種を買ってしまうんじゃないかと買い換えるのが怖くなってずっと使い続けてしまう。
意を決して買うと決めても、どうしても前の疎外感を忘れられずNECが嫌で結局、TownsやX68Kを買ってしまう。
ﾜﾛﾀｗ
Oh!MZ時代からX1フツーに扱ってて後にOh!Xに誌名が変わったのも知らないお子ちゃまかあｗ
すべては、DOSに移行できなかったマイナー機種ユーザーの話だったなんて・・・
S-OS 本当の意味が分かったよ・・・
CP/Mみたいな都合の悪い話には耳を塞いでのいつものやり方ですなw
当時DOS使ってクロス開発するよりかS-OS使ったほうがレスポンスが良いという評があったことも知らない素人乙ww
見苦しいねぇｗｗｗ
まぁ、性格も人格も頭も悪いからしかたないかね、ありえないクンは。
なんでいちいち半角スペース挟むの？きもち悪いです
MSX-Cだって1.0は定価98000円
1.1は19800円だったけど14800円のMSX-DOS Toolsが必要
MSX-C Ver1.1のタイムスタンプは1987年8月
これだけ金を払ってlong型やfloat型が使えないサブセットのC言語しか手に入らない
下手すると8bitで中途半端なC言語をやるよりも少し奮発して中古のPC9801買って
Turbo-C買ったほうがトータルコストは安くなったかもな
8bitのCコンパイラの大半は一般的なC言語の入門書のソースコードがコンパイルできなかったりしたしな
なんせ、階層ディレクトリに対応してないからな
CP/MやMSX-DOSではディレクトリで整理することもできない
16bitパソコン用のMS-DOSなら階層ディレクトリに対応してるのでディレクトリで整理できた
Turbo-CはMS-CでコンパイルできるCならたいていそのまま使えたのでTurbo-Cも問題なかったよ
8bitのC言語は浮動小数点演算のfloatやdouble型が使えないのはまだいいとして
long型が使えないのが致命的だった
1986年、1987年、1988年頃はもう8bitパソコンの記事はほぼない状態
16bitパソコンの記事ばかりだったぞ
16bitのCもUNIXの教本通りに動かなかったぞ。int=32じゃないから。
使いにくい＝使われない ではない。
この板は昔のPC板だ
8bitといえば、8bitパソコンで8bitパソコンが現役だったのが80年代
90年代に入ると386SX、386、486の時代
特にMS-DOS5.0でメモリドライバでEMSのエミュレーションやUMB使うには
386SX以上のCPUが必須だったし、
PC98では286マシンでは使えなかったDPMI必須のソフトも出てきてた
こんなのでまともな実用ソフトを組めるわけがない
DPBの定義次第。ユーザカスタマイズも可能だから増やしたきゃ増やせる。
> CP/MやMSX-DOSでCコンパイラ使うのって面倒なんよな
> なんせ、階層ディレクトリに対応してないからな
CP/MのUSERコマンド知らない素人乙
CP/MやDOSとUnixとでソース使いまわしするような職場だったから余計にそう思ったのかもしれないけど。
それともパソコンソフト（）だと違うのかな？
printf("size=%d\n", sizeof(int));
これだとエラーになる
int i;
printf("size=%d\n", sizeof(i));
これならOK
8bitのC言語なんてそんなもん
システムコールをbdos関数で叩くと384バイト
16bitならshort、32bitならlongを使えばいいだけ
当時の8bitのCコンパイラはlong型(つまり32bitの演算)に対応してないものばかりだから
32bitのコンピュータと同じソースを使いまわすなんてことありえないが
MSX-C Ver1.1に入ってたヘッダーファイルはBDOSFUNC.HとSTDIO.Hだけだぞ
俺が手に入れた無料公開されてるBDS-Cに付属してたヘッダーファイルはCCONFIG.HとSTDIO.Hだけ
これでUNIXやMS-DOSのCコンパイラとソースを共有するなんてありえないだろ
知ったかぶるなよ
Version 7までのUNIXは16bitのミニコンで動作してたんだぞ
PDP-11とか有名だろ？
当然PDP-11用のUNIXのC言語のint型は16bitだぞ
それに当時はUNIXは高嶺の花だったので、
たいていの入門書はMS-DOS用のコンパイラを使ってた
PDP-11用のVersion 7はエミュレーターで触れるぞ
ttp://blog.livedoor.jp/corbie/archives/3444528.html 使いまわししてましたがなにか？
お前らは俺が勤めてた会社の社員でもなんでもないんだろ。
何も知らずに「できいない」「やらない」「ありえない」って決め付けるなってんだよｗ
池面コンビのISO主任＆貝係長、ハゲデブ（自称）のO部長って言って通じるなら同じ会社の社員だったぐらいは認めてやるけどさ。
今の8bitマイコン用のCコンパイラと80年代の8bit用のCコンパイラは
まるで別物の全く比較にならないものになってるな
おそらく、8bitのC言語が使えると言ってるやつは90年代から8bitのC言語を触り始めた人だろうな
はあ
PDP-11とか現物見たことないです。使ってたんだすごいね。６０代？
VAX-11からなんで。
＞一般的なC言語の入門書のソースコードがコンパイルできなかったりしたしな
からの32bit-int暗黙が16bit-intで動かないんだから
8bit-intと16bit-intも許せよぐらいの意味っすな。
ANSI Cより前のC言語のバイブルとされたThe C Programming Language （K&R）は1978年出版
Version 7は1979年リリース
> 使いにくい＝使われない ではない。
使いにくい = 使わない。 だね。 仕方なしに使うということもやりたくないからやらない。
見たことないけど
わざわざ当時は特殊だったUNIX向けの入門書を使うのも意味不明だよな
結局、90年代にC言語を学んで、8bitの時代なんて全く知らない人なんだろう
Cの専門誌が出たのはC89以降だろ。
その分、本体にお金をかけて16bitパソコン使ってるよな
8bitパソコンでC言語使うより16bitパソコンでBASIC使った方が速かったんじゃないかな
客がターゲット指定してきて環境も貸し出して
くれるんなら選ぶ権利ないっしょ
みんな信長の野望の開発の話してたじゃん？
趣味の話なら、一人でもＣ使ってたら「ないない」
「いや俺使ってた」で終わりじゃん
FA用のPC98もあったよな
当時の8bitのCコンパイラ自体が他の処理系のCコンパイラとの互換性が低いから汎用性はない
溢れてたっけ？
8bitでC言語使える派からは出てこないよね
本当に使ったことある人ならどういう仕様かよく知ってるはずなんだけど
信長の野望の2作目がC言語で書かれたというのもWikipediaに書かれてるのを見ただけなのでは？
どのくらいの部分が、C言語で書かれてたかもかかれてないしね
1986年、１９８７年頃は書店の棚を埋め尽くすようにC言語の入門書が並べられてた
そのほとんどが実際に使用してた処理系はMS-DOSのMS-Cだったぞ
だれもC言語が主流だったとは言ってないんだけどｗ
誇張癖がおありですね
ナイコン族の貧乏人が個人でやってなかったからってC言語使われてないと決め付けてる馬鹿が居るだけなんだよな。
C言語の本が一番目に付くところにあったぞ
一太郎などのワープロのハウツー本と同じようにたくさん出版されてて人気もあった
1987年、1988年頃にはもうBASICの本はあまり人気なかったしな
すべて16bitパソコンの話だけどね
本当はフルセットのTurbo-Cが使いたいのに我慢してサブセットの8bitのC言語使ってただけだろ
一番詳しくて役に立ったのはCP/Mのマニュアルだったという落ちが付くけど。
α-Cが2万8000円かよ
Small-Cは9800円で別途M80、L80が必要
M80、L80がない人用にSmall-Macパッケージがあってこれが9800円
こんなに金払ってサブセットのCいか使えなかったんだねｗ
TURBO PASCAL買った人の方が多かったんじゃね？
16bitパソコンはそこまで高くないぞ
Turbo-Cなら2万7800円くらいだったはず
しかし、まぁ、予想以上に8ビットでC言語使ってる奴が居てちょっと驚きだわ。
つっても俺は会社で使ってたLSI-C80だけしかやってないからαもBSDも使ったことは無いんだけどさ。
8bitマシンでC言語は苦行だが、主記憶640KBなPC98あたりでクロス開発ならナシという程でもなくなる
ちょっとしたもんならPL/Iで十分すぎたし、Pascal環境のがずっとイケてた
という個人的印象 異論は認める
＞しかし、まぁ、予想以上に8ビットでC言語使ってる奴が居てちょっと驚きだわ。
どこに8bitパソコンでC言語使ってたという書き込みがあるんだ？
移植性云々って恒常的にライブラリ的に使う汎用性の高いもの以外だと、書き換え当然って考えだったから問題視すらされなかったな。
ライブラリ的な部分だと、どんなに酷くても担当者が1日がんばっておしまいレベルで済んじゃう程度だったし。
他の会社さんや個人じゃ違うのかもしれないけどｗ
ターゲットがパソコンならPascalやPL/Iを使う利点はあったんだろうけど、パソコンソフト作ってた訳じゃないからPL/I使おうって発想すらなかった。
＞
＞どこに8bitパソコンでC言語使ってたという書き込みがあるんだ？
どこにパソコンって単語がはいってるんだろう？
勝手に条件付けたしてるし。
嘘ついてまでC言語使ってなかったことにしたいんだね、ありえないクンはｗ
たとえ、C言語を開発で使っててもアセンブラも必ず使うからな
マイコンなら8bitで性能が低いなら16bitや32bitマイコン使えばいいわけで
8bitマイコンの性能を100%引き出す必要もない
8bitマイコンなんてフラッシュやRAM容量も少ないし
ペリフェラルをちょっと制御する程度に使えればいいだけだしな
C言語を使うならCortex-M0やCortex-M0+は8bit、16bitマイコンよりずっとC言語に向いている
C言語で1行、数秒ですむ処理を何倍あるいは何十倍もの時間かけて書かなきゃならん非効率な手法をわざわ採用して生産性下げる必要なんてどこにもない。
おまけにバグが混ざる可能性も高くなる。
パチ屋ぐらいだろ、アセンブラ縛りあるのは。
あれだって警察からの天下り団体がうるさいという政治的な理由で、技術的な要因でアセンブラにこだわってるわけじゃないし。
アセンブラだってライブラリやマクロを充実させれば
プログラム組むのにそれ程手間かからんよ
「それほど」っていっても埋められない溝というか越えられない壁があるよ。
どんなにライブラリやマクロ充実させてもね。
だから何？
が嘘つきなのは揺るがない
ttp://www.itmedia.co.jp/news/articles/1608/08/news066.html ＞人気再燃の理由についてTIOBEは、小規模システムの普及を挙げている。
＞いまや電動歯ブラシからコーヒーメーカーまで（とTIOBEは例を挙げているが、
＞どちらもPhilipsの代表的な製品だ）、マイクロコンピュータが使われている。
＞こうした、メモリと速度が厳しく制約された機器を効率よく動かすためには、
＞アセンブリ言語で書かれた機械語プログラムが不可欠というわけだ。
与太記事と言えそんなところからデータ引っ張ってくるとか、ITメディアも墜ちたなｗ
むしろ使わないのならなんでそんなもん作って売ってたのって話で。
あんな遅いコンパイラで大きなソースをいくつもコンパイルしてたら遅くて使い物にならない
MSX-Cは大きなソースをコンパイルできないことで有名だったしな
MSXのエミュでいいから無料公開されたBDS-CやHiTECH-Cでコンパイルしてみな？
8bitパソコン用のC言語なんてサブセットばかりだし
他の処理系で書かれたOSに依存しないようなC言語のプログラムでも大半はコンパイルが通らない
初めからそのコンパイラ用に書かれたC言語のプログラムしかまともにコンパイルが通らない
そんなのばかり
16bitのMS-DOS用のTurbo Cならフルセットだし
他の処理系で書かれたOSに依存しないCのプログラムも普通にコンパイルが通ったりするぞ
16bitパソコンならエディタやコンパイル環境も含めて使っていてストレスはあまりないが
8bitパソコンだと遅すぎてストレス溜まりまくり
エミュレータでもいいから当時と同程度のスピードで動作するもので
実際に使ってみるといいよ
8bitパソコンと16bitパソコンではそもそも扱えるメモリ容量もCPUの計算速度も全く違う
昔の本に載ってたBASICで書かれたPIの計算プログラムを
C言語でMSX-Cでコンパイルできるように移植して
MSXエミュとPC-98エミュで計算速度比較してみた
使ったコンパイラはMSXエミュではMSX-C ver 1.1、PC-9801エミュではTurbo C Ver 1.5
コンパイル速度じゃなくて計算速度の比較
bluemsx Z80 クロック3.579MHz
11分58.1秒
NekoProjectII PC9801VXクロック9.8304MHz
7.7秒
あと、今のワンチップマイコンの話は全く別な
いまどきの8bitのワンチップマイコンだと数十MHzとかで動作したりするので
昔の8bitパソコンよりずっと高性能
CとPascalで200行弱の同じ内容のプログラムを書いてMSXエミュでコンパイル速度を比較してみた
Hi-TECH C 約7分50秒
MT+Pascal 約4分20秒
TurboPascal v3.0(cp/m用) 約15秒
TurboPascalのコンパイル速すぎ
710 ：ナイコンさん [↓] ：2018/03/06(火) 20:46:49.98 ID:zTEgJ+dg0.net (2/2)
PC-9801エミュのnp21でCPUクロックを2.4576MHz×4の設定でHDDを使い
MS-DOS用のBorland C++でと同じC言語のプログラムをコンパイルしてみたら
Borland C++ Ver 3.1 約9秒
PC-9801とMSXでC言語のコンパイル速度が違いすぎ
日本でC言語が実用的になったのって、PC98でMSDOSの3.3あたりが出回ってた頃になってやっとだろ？
その頃ですら組み込み向けなんかはメモリ1バイトは血の一滴な時代なわけで
当時の肌感覚でいえば、C言語なんて今で言うメインフレームみたいな本物の電算機で扱うもので
オモチャみたいな性能の組み込み分野で使うような代物じゃなかったよ
サブセット？
だから使われてなかった？
80年代に8ビットパソコンでC言語つかって作られたソフトが市販されてるけど、それでも「8ビットでC言語はありえない」って嘘を言い張るわけね。
キチガイのやることは理解できんわｗ
16ビット機が普及したと言っていい1990年とかでも16ビット機より遥かに遅い8ビット機でパソコン通信に使ってたユーザーがいたなんて話は当時を知らないありえない君には信じられん話だろうなあ。
↑学校の課題を家の8ビット機使ってやる、とか想像もできないバカ
サヨク政権になると大地震
阪神は村山、東日本は菅
発生時刻は共通の４６分
自民政権は被災地に冷たい
その理由解明！
ロシア国防省『日本は地震を偽装した核実験を止めよ』
ttp://rosie.5ch.net/test/read.cgi/liveplus/1531966541/l50 パソコン通信なんて端末側はターミナルソフトを使った、ただのシリアル通信じゃん
モデムだって当時は1200bpsとか2400bpsで遅かったからたいして負荷高くないぞ
そこそこ大きなソフトのコンパイルには使い物にならないよ
CP/Mで使ってた人なんてほとんどいないのでは？
8bitパソコンで、昔のPCスレだとしても昔のパソコンの昔話に限定する必要は無く、クロス開発した最新のソフトを8bitPCで動作させるのはスレ違いではあるまい。
この板で8bitといえば8bitパソコンだよ
8bitパソコンの当時のことを知ってるのって50代、60代、それより若くても限りなく50歳に近い年齢のはず
90年辺りだと9600bpsはフツーだったよ何言ってんの？
いつくらいの話してるのかわからんけどLSI CにMS-DOS上で動くクロス版出たのってけっこう後だぞ。確か86版の後じゃなかったかな。そまではCP/M版しかなかった。
8ビット機での日本語表示の負荷や入力のストレスを知らない世代かあ。
90年には既にあったぞ
それ以前は知らん
8bitパソコン使ってパソコン通信してるやつがモデムは最新式なのかよｗ
AztecCっていうのがあったよね
たしかApple][版もあったよね
300～115200の範囲でってのが多かった。
ただし、モデム～ホスト間は9600に制限される、って感じで。
MNP圧縮のクラス5だとわりと速度でてたっけ。
でもまぁ、パソコン～モデムの間がどんなに早くても、電話回線がアナログでノイズノリまくると1200相当に落ちるなんて現象が珍しくない程度には起こって時代だしね。
ホストが5MHzや8MHzのV30でモデム連装（４回線や６回線程度でも）でレスポンス悪くなってるなんてのも結構あった。
そんな環境だから8ビットパソコンでも余力もって動いたね、通信端末として。
いかん。
「ただし半角文字に限る」ってのを入れ忘れたｗ
PC88でROMからフォントデータ読み出してグラフィックに描くって受信専用（送信は半角文字だけしかできなかったので）のソフト組んだことあるけど
9600bpsだと正直きつかった。
当時を知らないからそんなアホなレスができるんだよ
テレホーダイが出てくるまでは従量制だから2400bpsと9600bpsだと電話代もプロバイダ代も4倍違う
ヘビーユーザーだとモデム台を回収してもお釣りが来るレベル
要するに知ったかは黙っとけ
この板ではよく「当時」という語を皆が使うが、時間軸的にてんでバラバラで
話が噛み合っていない。たいていのばあい、各人それぞれの「当時」だからね
Aztec c はマルチCPUで^_^6502/z80/68k/8086などサポートしていたが
shみたいなUnixシェル下で走るコードしか書けなかった。機種依存なコードを
書くのは難しかったな。マニュアルは結構立派だったのでMac/amiga/st版を
手に入れたがコレクションしただけ。機種依存コードを書くなら他の処理系。
半角文字というと、頑なに半角を読まないvoid_no2氏を思い出すねえ。
ASCIIがpcsの試験版を公開し始めたのは確か1983年で9801登場の翌年。
買ったばかりの初代98に会社から持ち出した300bpsの音響カプラに自宅の
黒電話の受話器はめ込んでつなげたことがある。98本体のモニタモードだったかな。
専用ソフトもなく、ATコマンドも無かったなあ。
話の流れが読めないなら絡んでくるなよ…
> 90年辺りだと9600bpsはフツーだったよ何言ってんの？
FDがちゃがちゃいいながらコンパイルされるのを待っていた
今の感覚で考えちゃいかんのよ
MZなんかはBASIC起動すら数分まってたし
みんな遅いのはそんなもんだと思って使ってたんだよ
繰り返すけど今では考えられない貧弱な環境を当たり前のように使ってたんだよ
当時を知らない人の戯れ言ですな
おまえはほんとMZの話ばかりだな。
パソコン通信の話なのになぜプロバイダ？
インターネットと話が混乱してるのでは？
インターネットは1994年頃の話だよなｗ
Turbo-Cが普及した1988年頃だとHDDは20MBで10万円くらいだよ
もう、既にHDDは高嶺の花じゃなくなってた
ドライブ側より本体側の制限のほうが強かったけど。
「コンパイル始めたから仮眠とってくるわ（だいたい１～2時間）」が「コンパイル始めたから飯喰ってくるわ（それでも30分ぐらい）」になったぐらいにはコンパイル早くなったけど。
その頃にはC言語全盛になってたからな
1992年に情報処理試験にもC言語が出てきて、学校などでもC言語を教えるようになった時代だよな
1990年はまだ情報処理試験にC言語はなくて、まだCOBOLやFORTRANを教えてた時代で
UNIXワークステーションを導入してた専門学校でもまだFORTRANを教えてたｗ
1992年はIBMやDECが史上初の赤字を計上した年だし
1992年にPC9801FAが出てPC98のメインシリーズに486が初登場
1992年にコンパックが低価格でDOS/V機を売り出したコンパックショックが起きた
PC9821シリーズが発売されたのが1993年でWindowsがプレインストールされて
尚且つPC98で486マシンが手頃な価格で発売された年
1992年、1993年頃を境に全くコンピュータを取り巻く環境が変わった
その黎明期には8ビットでC言語使うケースもあったわけなんだけどねぇ。
アンチC言語のためには嘘つくのも平気なんだね、ありえないクンはｗ
BDS-Cだってオールアセンブラで書かれてたんだよ？
韓国人のように嘘をつき続けたら本当に成ると思ってるなら考えを改めろ。
だから、C言語使って開発されたなんてソフトの名前はほんの少ししか例が挙がらないじゃん
当時のこと全く知らない世代
「8ビットでC言語は無い」という自分の思い込みのためだけにうそ付いているってことは変わりが無いぞ。
嘘というのがいやならデタラメと言い換えてやってもいいけど「現実とは違っていることを、事実であったかのように主張する」行為は嘘をついていると言われても仕方ないぞ。
つまり、おまえさんは嘘つきってことさｗ
PC-88版はアセンブラでPC98版はBASICなんてソフトもあった
多くは雑誌や本を読んだだけの人が多かったのでは？
I/Oに載ってたプログラムリストだってBASICやアセンブラ、16進ダンプばかり
C言語のプログラムリストなんてほとんどないし、あっても16bit用だったりする
ああ、プロバイダじゃなくて商用BBSだったな
一時期 nifty serve 経由でインターネット使ってたから混同したわ
そうなん？
84年に学校に入ったが、必修がUNIX+Cだったけど。
FORTRAMとCOBOLは選択可で、それぞれ週２コマしかなかった。
Cは10コマぐらいあったような。
確かに試験にCはなかったが。
1984年にUNIX+Cはまだそうとう珍しいだろうな
UNIXワークステーションもまだそんなに普及してない時代だし
BASICの時代って意外にながかったのか？
高級言語はFORTRAN
そんな時代
8bitパソコンが衰退するまではBASIC全盛でしょ
逆に言えば、BASICが廃れると同時に8bitパソコンも廃れた
16bitのノートパソコンがこんな低価格で発売されたと
8bitパソコンはこのあたりで止めを刺されたのかも
1989年だとゲーム目的ならFDD付きのMSX2+が2万円くらいで販売されてたよな
VBはWindows用なのでVB全盛時代はWindowsが普及した時代だからな
日本でWindowsが普及したのは486の普及時期と一緒だったと思う
> 84年に学校に入ったが、必修がUNIX+Cだったけど。
どこの学校よ、そんなの聞いたことないわ
1990年に発売されたスーパーファミコンかもしれないけど
所詮、8bitパソコンはBASICとゲーム
ExcelVBAでさ。
脳内妄想歴史と現実が違うってことがわかってないね、ありえないクンはｗ
>>全盛期があるなら黎明期もあるんだけどねぇ。
>>その黎明期には8ビットでC言語使うケースもあったわけなんだけどねぇ。
8bitマシンの黎明期っていつのことだよ？ TK-80のころ？ｗ
70年代じゃ、FDDが利用できる8bit機つーのがほとんど無いのだが。
PC-8001+PC-8011+PC-8031でC言語走らせていたとかか？
90年以降の状況を語られてもなあ。遅れてキた青年の無残つーもんだろ
1982年頃に大学でPC-8001でUCSD p-System使ってたし、裕福な知人はApple ][ + FDDで遊んでたからC言語ぐらい使ってたやつが居ても不思議じゃない
> BDS-Cだってオールアセンブラで書かれてたんだよ？
Small-Cはセルフビルドできたしその辺は色々だね。
日本製のパソコンだと、78年ベーシックマスターで79年にPC8001か。
80年代には、店売りのハードとソフトだけで8ビットでC言語使えたって事実は曲げようが無いねぇ。
8ビットパソコン黎明期だと、十分8ビットパソコンでC言語は使える状態だったねｗ
FDDなしが168000円
FDD 1基のみが225000円
FDD 2基のが275000円
8bitでBASICとWindowsでVBの間にはMS-DOSでC全盛期があった
VB for DOSも一応あったけどね
さすがにその頃は8bit機では記憶媒体が非力すぎて実践した人は限られたと思うけど
それまでFDDは個人向けには高すぎて普及してないと思う
72年 C言語生まれる
76年 デジタルリサーチからCP/Mがでる
78年 シャープからMZが出る。
79年 K&R第１版出版される(事実上のC言語規格の役を担う)。 BSD-Cが出る。
81年 富士通からFM8が出る。 K&Rの日本語翻訳版がでる。
82年 富士通からFM7が出る。 NECからPC88、PC98が出る。
83年 シャープからX1でる（8ビット御三家が揃う)。LSIジャパンからLSI-C80でる（同社のHPには「誕生」としか書いてないが・・・）
85年 MS-CVer3（MSブランド初、K&R対応）でる。
86年 FM-7向けDOH-Cコンパイラ（TAPE版)でる。
87年 ボーランドからTurbo C出る（BSD-Cから8年、LSI-C80から4年）
88年 LSIジャパンからLSI-C86でる。
スレの上のほうに「8ビットでC言語するより中古の98買ってTurboC使う」って意見があったけど、時代がずれてるなぁ。
DOH-Cコンパイラはググル先生に聞いただけだけど、F-BASICから起動できたらしい供給メディアがTAPEのコンパイラとのこと。
在るか無いか半分半分で考えてたけど、実在してたのね。
俺は知らなかったけど。
6809はさすがに究極の8bitCPUと呼ばれただけはあってCコンパイラもそこそこ実用になってたんじゃないかな
ここの人は80系の人が多いのかなぜかDraco-C DOHCの名前がでなかったですが
1985年の1月号からC言語の連載が始まってるな
使ってるコンパイラはLattice C
OSはCP/Mと書かれてるけど、おそらくCP/M-86だろうな
Lattice-Cって8080/Z80版ってあったのかな？
FMシリーズ用Cコンパイラは15万といい値段したから個人で使ってた人はそんなにいなかった思うけど会社とか学校ならいたんじゃないかな
ttp://www.mindspring.com/~thasegaw/rpcg/os9.html ググってみたがDOS上で動くZ80用クロスコンパイラはあったようだけど、8bitパソコンで動作するのはないみたい
68000版のLattice Cもあったようだ
CP/M-86版のLattice Cのマニュアルはググったら出てきた
俺は、81年の冬に、青山の青学会館近くのマンションの一室で商売始めたMSA、
マイクロソフトアソシエーツで米国のDRIがリリースした直後のCP/M86を受け取りに
行ったことがある。インテル製のSBCと組み合わせて立ち上げやった。某社への
売り物だったけど。80年代初ではすでに興味は16bit機ネタだったね。個人的に。
なので今更8biit機に興味は湧かなかったな。以来、8bit 機でc言語なんて走らせたことはない。
ま、ここのオッさん連中でも82年ごろまでにcを8bit 機で走らせた経験を持つ先人はいないだろうなあ。
1985年に15歳だった人は今年48歳
1985年に20歳だった人は今年53歳
1985年に25歳だった人は今年58歳
1985年に30歳だった人は今年63歳
立ち上げた直後のMSAはアスキーマイクロソフトアソシエーツだったかな。後にアスキーの
名前が消えてMSA。80年代前半で米国製の言語ソフトを売っていた会社というと、
茨城方面の失念某社と新橋のメディセールス、横浜の工人舎。三田のライフボートとか
横浜のサザンパシフィックは80年代ん中頃から。MSは社内用にc言語開発してマルチプランとか
開発していたが8bit なcを外販したことはない。BDS-Cは79年というが、国内での入手は
上記の零細な小規模輸入業者経由か個人輸入しか方法が無かっただろうから
ユーザなんて多くて以下だったろうね。82年ごろでは。
9801登場以前にc言語使った経験のある奴がいるなら70過ぎだろうなw
TurboCも98版が出たのはそのまとめに書かれてる年よか後だった希ガス
そりゃお前さんが興味なかっただけのことで、世界にはお前しかいないわけじゃないからねぇ。
興味ある人はあったし仕事でやらにゃらんひともいたって事実はなくなりませんぜ？
1982年頃のPC-8001でCP/Mを走らせるためには以下のようなハードウェアが必要。
PC-8001 168000 + PC-8011 148000 + PC-8031 310000 + PC-8049 188000 = 814,000
定価ベースで81万。これにCP/MとCコンパイラを合わせれば100万円コースだね。
ふつうの大学生が自腹で100万を払えるはずがない。ユーザにそれなりの収入がある
中間管理職な会社員を想定すれば30歳超。今ならほぼ70歳超だろよｗ
定価ベースでも50万切るし、実売だと20万切れるかもってところか。
1年まてば高校生でも手が出る値段に落ちてるな。
いや1981年頃にC言語講座があったのよ
処理系指定はなく基本的な構文説明とかだったけど
そういう奴の所に入り浸ってたりしてた。
自腹で50万円出せる高校生@1983 とは剛毅だな。
83年当時のマクドのバイト時給っていくらよ？
そりゃあそうだ。
80年代前半は半導体プロセッサ関連の技術営業な仕事していて、
半導体メーカーにも津々浦々のプロセッサ利用な製品開発者にも知り合いがたくさんいたけど
8bit PCを仕事場に置いていたエンジニアはほぼ皆無だったですよ。例外はHEのあの人達ほど。
ま特殊な業界だから、他と常識に差異があっても不思議ないですけどね。
お前さんたちの視野が狭かっただけだろ。
世間知らずと言うか固定観念だけで物言ってる感じがするなぁ。
本当に営業だったのか？
ルートセールスという名の配達員もどきだったんじゃないの？
開発装置としてのCP/M機は沢山売りましたが、8bit パソコンは売れませんでしたね。16bit機ばかり
倉庫に不動在庫で山積み。で決算期にはアソコに流し処分してたりしてたですね。別課の彼氏が。
なんで個人限定なんだ？
1985年に会社のワークステーションでC言語使い始めた俺は57歳
> 1982年頃のPC-8001でCP/Mを走らせるためには以下のようなハードウェアが必要。
なんで市販品の定価で計算するかな。
その当時なら自作のマイコンにジャンク屋で買った8インチ1Sのドライブつなげて
CP/M動かしてた人もいたしコストなんて千差万別なのに。
PC-8001用のCP/Mってそんなしたっけ?
BDS Cは当時として安かったので5万ちょっとだった気がする。
> PC-8001 168000 + PC-8011 148000 + PC-8031 310000 + PC-8049 188000 = 814,000
もう1年待って本体をPC-8001mkIIに、FDDユニットをPC-80S31に、ディスプレイを
グリンモニタにすれば半額以下になるなｗ
MS-DOSでは相変わらず業務ではN88(86)-BASICばかりで、Vzのようにアセンブラも幅を利かせていた。
知名度は高いが難易度が他と比べて高いからCは今も昔も少数派。
そういう技術ある人がマクドで時給いくらでバイトって発想がすごい
バカ
N88BASICベースのソフトなんてPC98初期だけでMS-DOSが普及してからはほとんどCで開発したソフトだったよ
市販のアプリ、ゲームからパソコン通信で配布されてたフリーソフトまでほぼ全てCで開発されてたよ
そんななかオールアセンブラで軽く小さいってのが逆に売りになっていたのがVz
おまけにソフト2本で20万えんするかのようなぼった栗価格。
悪意しか感じない。
そういうデタラメというか嘘かさねてまで「なかった事」にしたいって病気だねｗ
市販アプリは業務アプリとは言わない。
8bitパソコンでC言語が広く使われてたことにしたいやつがいるんだな
> PC-8001 168000 + PC-8011 148000
1982年なら88買ったほうが安いだろｗ
だれも「広く」なんて言ってないけど？ w
当時を知らない奴は引っ込んでて
ttp://www.wheel.gr.jp/~dai/software/cpmkbios.html ＞のころ、友人が使っていたシャープのX1 turboでは、＞ CP/Mで日本語が扱えた
＞ （日本語の表示ができた&&単漢字変換で日本語入力ができた） のですが、
＞わたしの使っていたPC-8801のCP/M、PS88-104-2Wでは、
＞そのようなことができませんでした。
ttp://www.geocities.jp/retro_zzz/machines/nec/8001/mdl80.html ttp://www.geocities.jp/retro_zzz/machines/nec/8801/mdl88.html DDTでマスク値を7Fhから0FFhに書き換えて、SAVEコマンドで保存するって手順だったような・・・
ttp://www.geocities.co.jp/SiliconValley/3000/pc/pcs1011b.jpg ttp://www.geocities.co.jp/SiliconValley/3000/pc/pcs1011b.jpg テラ懐かしす！
芝のロケットビルで「赤いのは目立つからやめろ」ってTV局からクレーム付いて変えたんだったかな、尖ったロゴ。
ttp://radioc.web.fc2.com/column/pcad/ad/hdbc800.htm CP/M価格表
BUBCOM80 CP/M V2.2 \65,000
PC-8001 CP/M(MSA版) \65,000
PC-8001 CP/M(NEC版) \38,000
PC-8801 CP/M(MSA版) \65,000 但し、ミニ・フロッピィで提供
PC-8801 CP/M(MSA版) \65,000 但し、8インチ・フロッピィで提供
業務という狭い世界の話を全てに当てはめるなよ
NEC版のCP/Mは38000円だが日本語を扱えない
MSA版のCP/Mは65000円だが日本語が扱えた
この認識でOK？
ポインタで挫折したんですな
8bitパソコンでC言語がありえないという話
このスレに16bitパソコン、32bitパソコンでのC言語を否定してる人はいない
＞このスレに16bitパソコン、32bitパソコンでのC言語を否定してる人はいない
ついでにいえば、8bitCP/M用のC言語は市場に存在し売られていて使われていた。
という事実を否定する者もいないだろう。ただし実用的じゃないから使わなかったとか
費用対効果を考慮すると買うのがバカらしいから手を出さなかったというオッサンはいるよね。
メモリ空間のアドレスの基本的な知識があればポインタで躓くはずが無いんだけど。
事実は否定してないけど無視して「8ビットでC言語使うなんてありえねぇ」「8ビットでC言語なんて使われてねぇ」って嘘言いはるやつは居るねｗ
その認識でOK
もう少し詳細に説明すると2.2Bの出る前の無印の2.2は漢字不可で半角かな文字のみ対応。
2.2Bで漢字を使うときにはPC-8012-02拡張RAMメモリを追加してBANKバージョンにすると使用できた。
漢字入力はJISコード入力と関東電子(ロジテック）の漢字タブレット(RS-232接続）
を使用することが出来る。（2.2Bマニュアルより）
＞事実は否定してないけど無視して「8ビットでC言語使うなんてありえねぇ」
＞「8ビットでC言語なんて使われてねぇ」って嘘言いはるやつは居るねｗ
なにがなんでも、うそだときめつけたいのですねｗ
廉価版のα-Cもあったのにバカはどうしてこう自分に都合の良い話に飛びつくんだろう?
Small-Cもあったのに無視ですか
馬鹿が勘違いしてるｗ
Cで開発された市販のパッケジソフト突き付けられてもｱｰｱｰｷｺｴﾅｲ
> なにがなんでも、うそだときめつけたいのですねｗ
嘘でしょ？
悪意も他意もありませんよ。
嘘つきを嘘つきと呼んでるだけです。
PC98用のMS-DOSはVer 2.0が11000円または16000円、Ver 3.1が18000円
ttp://island.geocities.jp/cklouch/column/pc98bas/pc98dosver.htm ttp://radioc.web.fc2.com/column/pcad/ad/msdos20.htm PC-98版のMS-DOSはシェアを取った後もずっと安かったけどな
当初は同梱してた開発ツールを別パッケジにしたりしてたけどな。
たしかMS-DOS Ver 3.1からそれまで同梱されてたマクロアセンブラが別売になったんだよな
そう言うのは別にMSに限らないし使わない人にとってはバンドルされてるのは無駄だし
・Asm、Edit、Debugは別売りとなり価格が下がりました。
(\58,000→\30,000)
ttp://www.mindspring.com/~thasegaw/rpcg/os9.html 16bitでCは少数派などとほざいている人がいるんですが
おまえが知らない世界というだけで、業務PGの多くはBASIC使いだから
Windowsになったとき、VCではなくVBに移行した。
少数派だろう。IT業界にいればCの案件なんて組み込みとかドライバとかぐらい。
しかも大学で勉強しました程度のスキルじゃ使いものにならない。
16ビットの組み込み用マイコンで各半導体メーカーが提供してる開発ツールは
Cが普通、良くてC++が選べる、程度が現状だし分かってない人なんだろ
の言ってるPCの開発ツールについての
> 知名度は高いが難易度が他と比べて高いからCは今も昔も少数派。
なら妥当なこと言ってると思う。
組み込みに限らなければCより生産性が高くて安全な言語が選ばれるのは
今も昔も変わらん。
馬鹿はお前だよ
> C言語が難易度高いなんて誰も言ってない
が言ってるよ
> 知名度は高いが難易度が他と比べて高いからCは今も昔も少数派。
いまどきのコンパイラは未定義動作積極的に利用して最適化しようとしたりするので
Cの難易度はたとえばPCのCPUが16ビットだった頃の牧歌的な最適化しかしなかった
時代よか上がってると思う。
I/Oの1988年7月号のC言語の特集の中で出てくる
98版TURBO C 1.5を知らないバカはトンチンカンなこと言うなｗ
バカの特徴: 関係ない話を急に持ち出す
98版のアレがなんで批判されてたか分かってないんだろうなあバカだから
その程度の使い方しかしてなかったんだろう
IDE使えてた?
どっち版使ってた？
なんだうそかｗ
それは未定義なコードでも偶々動いてたってだけの話ででかいソフトになるとよくわからんバグの原因になって余計に面倒になってた
今時のコンパイラの方がまともな警告出すし楽になってると思う
そこまで言うなら問題を具体的に書けよ
> 今時のコンパイラの方がまともな警告出すし楽になってると思う
例えば↓みたいないコード書いて、
#include <stdio.h>
int main(void)
{
int n = 0;
for (int i = 1; i != 0; i += i) {
n++;
}
printf("n = %d\n", n);
}
gcc や clang で -Wall -Wextra 付けてコンパイルしても警告いっこも出ないよ。
だから何？
俺は全ての未定義動作を検出するとは言ってないよ
中身のないレスで口挟んだ気になってるバカ乙
問題なく使えてますよ
普段はエディタ使ってコマンドラインでコンパイルしてたからな
何かIDEに問題でもあるの？
なんか言いたいなら未定義動作を警告してくれる具体例のひとつでも挙げればいいのにｗ
98版の話なのにコマンドライン版使ってて
> 特に問題なく使えてましたが何か？
だってｗｗｗ
> 俺は全ての未定義動作を検出するとは言ってないよ
いまどきのコンパイラで問題となるコードの具体例挙げた投稿に対するレスがこれかよｗ
> 今時のコンパイラの方がまともな警告出すし楽になってると思う
とか抜かしたお前は今時のコンパイラが警告出す例挙げるのが筋だろうに。
> 何かIDEに問題でもあるの？
> 特に問題なく使えてましたが何か？
これは草不可避ｗｗｗ
コマンドライン版ってなんだよ
PC98版TURBO-Cの中にTCC.EXEという名前でコマンドラインのコンパイラも入ってるんだけど
TC.EXEを実行するとIDEが起動する
> PC98版TURBO-Cの中にTCC.EXEという名前でコマンドラインのコンパイラも入ってるんだけど
キチガイかな？
未初期化変数の警告とか見たことないのか？
知らないなら書くなよ
TURBO-Cシリーズはtcc.exeというコマンドラインのコンパイラも同梱されてる
IDEもコマンドラインでも両方とも使えるんだよ
MAKE.EXEも同梱されてるしね
なんかの反論のつもりかな？
悪いけど「PCのCPUが16ビットだった頃の牧歌的な最適化しかしなかった 時代」にもそんなのは警告出してたよ。
組み込みじゃなくて16bitPCでの話ですが
0875 ナイコンさん 2018/07/21 22:55:02
> TURBO-Cシリーズはtcc.exeというコマンドラインのコンパイラも同梱されてる
> IDEもコマンドラインでも両方とも使えるんだよ
コマンドライン版、統合環境版と呼ばれてたね。で？？
試しにIDEで簡単なプログラムをビルドしてみたが正常に動いたけど
普通にUNIXでCの仕事もやりましたしPC-98やDOS/V、J-3100、FM-RでCのしごともやってきましたよ
自分の知っている狭い範囲での話をIT業界全般にあてはめないように
↑の人は16ビットPCの頃には見たことなかった前提なんだろうか?
Cがメジャーじゃなかったらなにがメジャーなのか
やっぱりポインタで挫折して逆怨みしてるような
普通に仕事でCを使ってきたひとは沢山いるって
MS-DOSで趣味で使ってた人も沢山いるよ
ここの書き込みみてもわかるじゃん
> 悪いけど「PCのCPUが16ビットだった頃の牧歌的な最適化しかしなかった 時代」にもそんなのは警告出してたよ。
具体的なコンパイラ名とバージョンよろしく
フロー解析が必要だから8086/8088辺りのコンパイラでこの警告出すやつは見たことない
GCC 2.x.x 辺りが最初だったと思うが
PRJファイル書いてないからじゃないのかなｗ
だからWindowsではVBって書いてるでしょ
MS-DOS時代はCがメジャーだっていってるの
今時のコンパイラの方がまともな警告出すし楽になってると思う
> 未初期化変数の警告とか見たことないのか？
やっぱありえない君て馬鹿だなｗ
Cの保守やるとパッと見だけでバグだと分かるコードばかり。
C屋を募集してもまともなC技術者などまず来ない。Cが避けられてポインタのないJavaが流行るのは当然のこと。
おまえはアセンブラができないのにCできますなんて人を信用できるのか。
おまえはIT業界で碌に仕事してこなかったから日本にどれだけC屋、C++屋が少ないかを知らないのだ。
データフロー解析ならdatalight-c
やlsi cでもやってたしms-cもver.5.0辺りからやってたと思った
具体的に反論できないなら黙っとけ
> データフロー解析ならdatalight-c
> やlsi cでもやってたし
各々のバージョンは？
> ms-cもver.5.0辺りからやってたと思った
俺の記憶だと6.0 からだと思う
一応wikipediaにも6.0でglobal flow analysisが追加されたとあるし
junkの常連だね
自分も常連だった
pcsのユーザIDは今も別のメアドで使ってる
普及品が300の時代にAIWAの2400ボーのを使ってたよ
後になって文庫本サイズのオモチャみたいな56Kbpsのに買い替えた
今は、ノーブランドのFAXモデム付き28.8Kのを保存してる
なかったと思う
> 具体的なコンパイラ名とバージョンよろしく
話題のTurbo C の最初期の 1.01で試してやったぞ。
>type hogera.c
#include <stdio.h>
int main(void)
{
int n;
printf("n = %d\n", n);
}
>tcc -c hogera.c
Turbo C Version 1.0 Copyright (c) 1987 Borland International
hogera.c:
Warning hogera.c 5: Possible use of 'n' before definition in function main
Available memory 540360
>
> フロー解析が必要だから8086/8088辺りのコンパイラでこの警告出すやつは見たことない
GCC 2.x.x 辺りが最初だったと思うが
そうでちゅか
一応存在はする。
DOSでのgcc実行環境を提供したDJGPPのHPには8086をターゲットにしたgccが存在している。
ttp://www.delorie.com/djgpp/16bit/gcc/ またVectorにはMS-Cでコンパイルしたものがある。
ttps://www.vector.co.jp/soft/dos/prog/se014943.html まあgccは8Bitの6809なんかでも存在するので技術的には興味はあるが実用性には疑問符がつくものだ。
ところで16Bitのgccなどと脈絡の無い話題を振ってくるのにはどういう意味があるんだ？
＞ところで16Bitのgccなどと脈絡の無い話題
あっごめん
＞8086/8088辺りのコンパイラでこの警告・・・GCC 2.x.x 辺りが最初だったと思うが
があったものだから、gcc 16 bitってあったっけ？って思った。
良く見たら16bitというかMS-DOSとか関係ないなって思って。勘違い。
Turbo-C(DOS)とgcc(32bit)じゃ土俵違うかなと思って。
関係ないんでこれ以上アレだけど、djgppってdos-extenderで実質32bit実行だよね。
386以降じゃないと動かないよね。
> があったものだから、gcc 16 bitってあったっけ？って思った。
の発言があったからの疑問に至ったと。
どうも893,897は常人とは異なる時間の流れに生きている人間のようだなｗ
あ、時間の流れはどうでもいいけど、
gccは >> 883
の話が最初だよ
pcs民だったが、junk.testは危なくて近づけなかった。
今の2chの源流って感じだったね
> 具体的なコンパイラ名とバージョンよろしく
LSI C-86 Ver.3.30 試食版で試してやったぞ。
> A:\> lcc hogera.c
> hogera.c 5: Warning: 'n' used before set
> フロー解析が必要だから8086/8088辺りのコンパイラでこの警告出すやつは見たことない
「フロー解析」なんて用語は知ってるけど実務経験なしの頭でっかち君かな？
void氏はjunk.testのみならずfjとかnetの黎明期の有名人だったですね。ヘミ猫さん。
2001年にc言語の入門書を某社から出版したりしてc言語についてはdeepな人だったですね。
その翌年の2月ごろに2ちゃんに突如出没し、本名IDでマ板とかあっちこっちカキコして
随分と荒れたスレ多数だったな。2002年の獅子座大流星雨の夜、某スレでc言語と
スクリプトの優劣について一晩スレチャットしたことあるです。基本真面目な人で真摯で
楽しかったなあ。pcsのチャットルーム以来のご無沙汰だったから。
もう彼も還暦ちょい手前くらいかな。少年老い易く学成り難し。あの頃あそこらへんの人も
みないい歳になっているんだろうなあ。
調べようと書いた」風のソースは gcc や clang では最新の版でも
-O0(最適化レベル0) では期待通りの 32 が出力される。
-O2(最適化レベル2) では gcc だと
ttp://https://godbolt.org/g/KcF4t2">ttps://godbolt.org/g/KcF4t2での確認では ver. 4.1.2(February 13, 2007)では 32 が出力される
コードとなり、ver. 4.4.7(March 13, 2012)では無限ループとなる。
clang では
ttps://godbolt.org/g/dMnMir での確認では ver. 3.2(20 Dec 2012) では 32 が出力されるコードとなり、
ver. 3.3(17 Jun 2013) では 33 が出力されるコードとなる。
C の仕様の未定義動作とコンパイラの最適化による結果だが、
警告も出ないので ： ナイコンさん [sage] 2018/07/22(日) 15:38:49.31
> GCC 2.x.x 辺りが最初だったと思うが
> > ms-cもver.5.0辺りからやってたと思った
> 俺の記憶だと6.0 からだと思う
> 一応wikipediaにも6.0でglobal flow analysisが追加されたとあるし
GCC の 2.0 が 1992年で、
ttps://gcc.gnu.org/releases.html > 2.0 February 22, 1992
MS-C の 6.0 が 1989年かあ。
ttps://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B > C 6.0 released in 1989.
「GCC 2.x.x 辺りが最初だったと思うが」とか抜かしてるのは時系列で覚えてないから？
それか、web とかぐぐって知ってもいないことぱーぱー言ってるだけ？
君のようなアスペルガー君はずーっと◯まで寝ていれば良いのにw
何をいまさらｗ
スレその１のときからありえないクンがアスペルガーってバレバレだったじゃないか。
ありえないクンは言うことがコロコロ変わるのも最初からだし嘘つきまくるのも最初からだぞ。
そして発狂している、と。
最初から狂ってるようなもんだけどｗ
異論なんかでるわけがないんだよなぁ
当時の肌感覚ではありえない、それが史実
ソコに逆らって嘘をつくから、こんなことになるっていう
↓↓↓ ＜8bitにおいて＞ ↓↓↓
Ｃが主力
Ｃ他言語と混戦
Ｃわりと普及
Ｃいくらかは開発に使用 ←このへん？
Ｃ処理系は存在した ←このへん？
ここを主張→ Ｃ存在しない使われない
過去スレでおまえの捏造は既にバレてるのにまだ捏造するのか。
被害妄想が故にやたら誇張する。本当は使い物にならないレベルなのに普通に使えると言われてもね。
> 本当は使い物にならないレベルなのに普通に使えると言われてもね。
馬鹿は使えないってだけ。
あれはなんちゃってcだったけと
PICやAVRは板違いってこともわかってない
2.xx系もそうだった記憶がある
まぁ、嘘つきの末路なんてそんなもんだけど。
こいつ、バカだな。歳食ってもバカはバカ。バカは芯でも治らない。
おまけ居に類を見ない無知でもある。
「2018年の感覚で」使い物にならないから「１９８０年代でも」使われていたはずが無いっておかしなことを言ってるのに、自覚できないんだものね。
死んだほうが本人のためだし世の中のためになるんじゃないかな？
8bitPCでCが普通に使える → ありえない
だからな。
また、PC98版のTURBO-Cの統合環境が全く使い物にならないと嘘をつく
(おそらく、誰かからコピーしてもらったのをちょっと触っただけでマニュアルもろくに読まずに使えないと言ってる)
実際に80年代にC言語を使ってたのかも怪しい
ttps://vintagechips.wordpress.com/2012/05/09/small-c%E3%81%AE%E5%A4%A7%E3%81%8D%E3%81%AA%E5%88%B6%E7%B4%84/ 最悪のコンパイラとして念頭にあるのはSmall Cだ。
以前これで8080のアセンブラ/ディスアセンブラ付きモニタを作ったことがあって、
構造体を使えないことはわかっていて、それは何とか切り抜けた。
配列も1次元だけで、文字列の配列が作れないのは痛いが、
アセンブリ言語を埋め込むことで対応しようと思う。
リカーシブコール(関数の中からその関数を呼び出すこと)はできるのだろうか。
これはもう数式のパースで使ってしまったから、できないということになると大問題だ。
ttp://kha-in.info/retro-computer/11-small-c-handbook/ Small-Cについて
Small-Cは、広く使われるプログラミング言語であるC言語の、サブセット版。
簡単に言えば、8ビットパソコンで使える小さいC言語です。
Small-Cの発表が1980年、この本に載っているのは、バージョン2.1とのこと。
フルセットのC言語（ただし、ANSIで規格化される前の、旧い仕様）と比べて、
異なるところはいろいろありますが、目に付いたところだけ取り上げてみます。
データ型
Small-Cで使える型は、intとcharのみ。intは16ビットのshort int相当。
signedとunsigned、浮動小数点数のfloatやdouble、void、32ビットのlong intなどはありません。
配列
配列は、多次元配列はなく、1次元配列のみ。
関数の戻り値
関数の戻り値は、intのみ。
フルセットのCにない記法
例えば、256()と書いた場合、アドレス256にあるサブルーチンがコールされます。
まあでも、概ね、普通のC言語感覚でプログラミングできそうです。
> 構造体を使えないことはわかっていて、それは何とか切り抜けた。
構造体や、floatが拡張された版もあるけどね、Small-Cの意義を理解してない人が書いた文章かな
ttp://www.z80.eu/c-compiler.html 異なるところはいろいろありますが、目に付いたところだけ取り上げてみます。
> データ型
> Small-Cで使える型は、intとcharのみ。intは16ビットのshort int相当。
> signedとunsigned、浮動小数点数のfloatやdouble、void、32ビットのlong intなどはありません。
ANSIで規格化されたvoidやsigned挙げるバカっぷりｗ
「intは16ビットのshort int相当」もかなり恥ずかしいゾ
特定の処理系に合わせた記述をしないとコンパイルが通らないできそこないのコンパイラばかり
ANSI以前からvoidはあるよ
PDP-11のエミュ上で走らせたVersion 7 UNIXのCコンパイラでも
関数のパラメータのところにvoidが使える
つに自分の発言まで捏造し始めたか、やっぱりありえないクンは根っからの嘘つきだねぇｗ
> ANSI以前からvoidはあるよ
「ANSIで規格化される前の、旧い仕様」は当時としてK&Rだけどもそれにはない独自拡張挙げるってアホ？
> また、PC98版のTURBO-Cの統合環境が全く使い物にならないと嘘をつく
国会図書館逝って当時のザベのバックナンバー参照されることオススメ
相変わらず馬鹿が連呼しているなぁ。
実際には8BitでもフルスペックのWhitesmith-Cが存在しているのにね。
まあ俺は1983年当時CP／M上でのC処理系を検討したが国内PC事情で最終的にBSD-Cを選択したけどね。
> C言語によるTinyBASICの書き直しは、
> 最悪のコンパイラとして念頭にあるのはSmall Cだ。
Small-Cより単純なTinyBASICを書くのにSmall-C自身でセルフビルドされたSmall-Cを「最悪の〜」と宣うこの人の頭の中はどうなっているのか？
×BSD-C
○BDS-C
それと＞＞939が戯言と言われるのも嫌なので検討した時の資料をUPしとくわ。
ttps://dotup.org/uploda/dotup.org1593104.jpg MS-C6のpwbもそうだ。
mifesかVzで熾烈な論争があった頃。
日本語使えたの？
ざべでのTCがらみに話というとVer.1.5のO野氏のSPL批判(1988年7月号）と
SPL片山氏の反論記事(同8月号)が印象に深いけど統合環境を批判した記事の記憶は無いな。
ざべのこの時期ならなら国会図書館に行かなくても自炊したBNがあるから是非掲載号を教えて欲しいな。
（こう書いて教えてくれる人間が少ないのも判っているが）
C言語はCPUが見えないレベルまできっちりマクロを組んだマクロアセンブラ。
僕は授業でそう学んだ。
だからあながち間違いじゃないと思う。
次スレまでもつれ込むのか！
乞うご期待！
Word Star like がウリだったから
デバッガも良かった
Wikipedia見た感想だとどう見てもCISC やね
ttp://www.st.rim.or.jp/~nkomatsu/miscproc/VM8600.html もっとも複雑なアドレッシングモードでは、任意の32 bit汎用レジスタのひとつをベースレジスタに、もうひとつをインデックスレジスタとして扱い、
インデックスレジスタに1, 2, 4, 8のいずれかのスケーリングファクタを乗算したものをベースレジスタに加算し、さらに32 bitの定数をディスプレースメントとして加算したものが実効アドレスになります。
68020辺りからみたらドヤる程のことはないけど
いまどき↑みたいな時代遅れなこと言ってるやつがみたいなソース書いてコンパイラのバグだと大騒ぎすんだよなあ
> フロー解析が必要だから8086/8088辺りのコンパイラでこの警告出すやつは見たことない
> GCC 2.x.x 辺りが最初だったと思うが
とか抜かしてたやつは嘘吐くにも躊躇がないねｗ
> 俺は全ての未定義動作を検出するとは言ってないよ
ﾌﾟｰｸｽｸｽ
一目瞭然だな。8bit環境ではCはまともに使えない。
8bitCPUでコード書いたことあるなら馬鹿でも分かるよね。
例えばdoubleなんて使い物になるスピードが出ないこととか。
他のコンパイラは8bitCPUでは使いものにならない、longやfloatは普通に端折ってる。
あれもこれもと指示した無能な上司を持ったWhitesmithsCのPGが不憫でならない。
合理的判断の結果でなんら非難の対象になりえないということだな。
C言語が使われだしたのはANSI以後→大嘘でした。
8ビットのC言語は使い物にならない→大嘘でした。
8ビットでC言語使うぐらいなら中古のPC98でTurbo-C使う→大嘘でした。
「最初から8ビットで普通にC言語と言っている」→大嘘でした。
80年代後半までずっとMZの世界はテープがメインだった珍しい8bitパソコン。
ソフトを出しても売れるのはテープ版。それがMZ。
だれも言っていないことを平気で捏造できるのがありえない君の特徴
それが使い物にならないレベルだった
にはそんなこと書かれてないなー
「だれも言っていないことを平気で捏造できるのがありえない君の特徴」てのはやはり真実だな
もしかしてキミはCプログラマではなくソフトバンクの関係者ではないのか？
ttp://rosie.5ch.net/test/read.cgi/liveplus/1532569537/l50 地震多すぎ！ 日本は地震大国だから、は大ウソだった！ ほら吹きの安倍が、地下核実験をやっている！
見てもマンセーとかしてる風ではないし相変わらずありえない君は嘘ばっかだなあ
脳内妄想を他人に押し付けてまで「C言語使われてなかったんじゃﾜﾚｪ！」ってやりたいのかよｗ
少しでもOh!Mzをマイナーだとﾃﾞｨｽると知ってるのが常識とばかりに叩いてるこのアホどものことだよ。
へぇ。
Disるって嘘でたらめ並べることを言うのかぁ、初めて知ったなぁ。
知りもしないで「紹介記事しかない」「ソース掲載されてない」って決め付けるという嘘をついたから反発されただけじゃんｗ
Oh!Mz読者ってMIPS信者なの？
えっMIPS信者ってマジかよ
徹底的に叩き潰すしかないな
8ビットCPUでC言語？ないないありえないっしょ！ 4
ttp://matsuri.5ch.net/test/read.cgi/i4004/1532613479/ MZの場合はCよりPASCALでは？
ミニFORTRANもあったみたい
ループ系？
立て直せ
