C言語なら俺に聞け 161

2023/04/21(金) 14:05:20.18

!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C17
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C23 最新ドラフト
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

※前スレ
C言語なら俺に聞け 160
https://mevius.5ch.net/test/read.cgi/tech/1672191630/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2023/09/27(水) 11:23:26.71

昔のトラブルの癖で1Mバイト以上の領域、配列が必要ならmallocで確保するようにしてる・・・。

2023/09/27(水) 11:53:58.81

mallocは64KBまでだろ……

2023/09/27(水) 12:26:49.33

・・・16bit？オフセットアドレス範囲？

2023/09/27(水) 13:10:05.87

8086の時代だろ
EMSのページング

2023/09/27(水) 15:08:08.13

いやそれ以前のCPUの仕様

2023/09/27(水) 16:10:06.49

それ以前だと本体メモリでも64kBフル積んでるの少なくないか

2023/09/27(水) 16:12:57.75

8086積んでた当時のPCは128程度は積んでたと思うが
64でフルになるのはZ80のような8ビットPCでの話

2023/09/27(水) 16:25:12.39

それ以前のそれに8086を含んでるなら矛盾はしない

2023/09/27(水) 16:26:45.84

8086でフルに積むメモリの意味が分からん

2023/09/27(水) 16:44:44.21

この場合の「フル」はメモリ空間いっぱいのことなんじゃないの。
バンク切り換えまで含めたらいくらでも拡張の余地はあるけど
malloc でバンクを跨ぐわけにはいかんし。

2023/09/27(水) 17:00:48.31

8086のアドレスバスは20ビットだから、1MB実装できる

2023/09/27(水) 18:45:56.76

勉強になります

2023/09/27(水) 19:57:19.01

勉強と言ってももう40年近く昔の知識だぞ
今どき役に立つことなんかあるか？

2023/09/27(水) 21:07:16.75

>>731
すいません、ないです。ただ知的好奇心が非常に満たされます。

2023/09/27(水) 22:18:54.45

レトロコンピュータの資料は探せばいくらでもあるが
面白いところだけ選んで読むというわけにはいかんからな。
読む前にどれが面白いのか判断できるわけもないし、
相互に関連があるので一部の資料だけ見ても意味がわからん。
話題に関連する形で昔の話が出てくるのは
それなりに興味深いということもあるんだろう。

2023/09/27(水) 23:14:28.73

ITの歴史を知ることは為になる
温故知新

2023/09/28(木) 00:01:49.83

スレ違いだったら申し訳ない
c言語でコンパイルした実行ファイルってosのAPIを使用してなければ別々のosで動かせますか？
cpuアーキは同じ前提です。

2023/09/28(木) 00:29:26.06

>>735
そもそも実行環境自体がos依存だろ

2023/09/28(木) 00:42:44.54

CPU同じならセットアップの問題とIO関係のクリア出来てたらそこそこは動くんじゃないか

2023/09/28(木) 00:47:13.64

割とマジで試したいなら
Bochs とか QEMU とかで
OS 無しで動かしてみたら良い

2023/09/28(木) 00:55:43.32

スタートアップ辺りにOS依存が有りそう

2023/09/28(木) 01:27:51.60

>>735
原則としては無理。
実行ファイルをメモリに展開して準備するローダがOSの一部だからOS の上で実行するならOSの機能は呼ばれることになる。
実行ファイルの形式が linuxとかだとelf が標準だけどwindowsではpeで、全く互換性はない。

ただ、複数のOSで動く実行ファイルを作るトリックは存在する。
https://justine.lol/cosmopolitan/index.html

2023/09/28(木) 06:25:35.94

>>735
大前提が違ってたな
コンパイルしただけでは実行ファイルは造られない
リンカとローダーを通して初めて実行可能なファイルになる

2023/09/28(木) 07:43:47.93

>>735
質問者さんは下記の概要を知ると、参考になるかもです

「組み込み開発でベンダーロックを避けるためにマルチハードにしたい開発チームが、対象ハードごとのgccをビルドして用意する手順」

ややこしいし大変なので、ザッとで十分です

参考までに私が買った本（全部読んだとは言ってない）
「LINUX組み込みシステム」
クレイグ・ホーラボウ
ピアソンエデュケーション

2023/09/28(木) 08:41:31.76

PC-98用のDOSアプリをTOWNSやAT互換機のDOSで動かしてはいたなぁ。
BIOSコールや各ハード特有機能を使わないアプリに限定されるけど。

2023/09/28(木) 09:51:32.79

>>743
OSが同じなら動くのが当然
MS-DOSがアレだから普通は動かないけどｗ

2023/09/28(木) 10:01:07.42

MS-DOSのシステムコールって機種によらず共通でしょ

2023/09/28(木) 10:02:25.23

TOWNSはTownsOSだろ

2023/09/28(木) 10:04:03.81

NHKでタマにやってる「我が社の黒歴史」で
FM-TOWNSを取り上げて欲しいな

2023/09/28(木) 10:15:55.20

TownsOSはMacOSみたいなGUIを提供してたんだよな
今やWindows到来って時代にだ

2023/09/28(木) 10:16:51.88

TownsOSはMS-DOSを拡張したものだし、
チャレンジ精神を評価する事はあっても
黒歴史とするのはあんまりだ

2023/09/28(木) 10:20:51.20

>>749
番組見たら考え方変わるよw

2023/09/28(木) 10:24:22.26

「我が社の黒歴史」ってやるなら、
是非NHK自身をネタにしてください
ライブドア事件の時、
ニュースに飛びついたNHK社員が
一斉にインサイダー取引で株売買してました
家族にも教えてたそうです
弁護士による内部調査を実施しましたが
社員の多くが調査拒否してましたよ
どんだけ暇なんだろうって思いました

2023/09/28(木) 10:32:23.32

あの番組は、黒歴史があるから今の発展がある
みたいなノリの番組だから、後がない企業は扱わないよw

2023/09/28(木) 10:41:58.54

TownsOSのこと言うならWin3.1も大して変わらないと思う
どちらもMS-DOSの上で動くGUIシェルの中のひとつ

2023/09/28(木) 10:42:15.16

当時のTownsは386採用し、MS-DOSを拡張して32ビットアクセスを実装してました
DOSが64Kの壁を越えられない時代にギガ単位のメモリをリニアに使える環境を実現
これを使ったゲームが人気でしたね
今から見れば当たり前のことで、何それって時代になってしまいましたが
DOS上のゲームでもこの方式を独自に採用したのがありました
DESCENTが有名だったかな

https://ja.wikipedia.org/wiki/DOSエクステンダ

2023/09/28(木) 10:51:11.28

富士通の公式サイトに富士通の歴史の一部として Towns の記述はあるよ。
結果的に廃れたけど黒歴史ということはない。当時はそれなりにユーザもいた。

2023/09/28(木) 10:56:41.79

>>751
NHKはまだ産まれ変わってないから「わが社の黒歴史」に出る資格が無い

2023/09/28(木) 10:59:08.38

スレチですね

2023/09/28(木) 11:02:35.02

>>755
この前はYAMAHAのFM音源が「わが社の黒歴史」に出てたよ

2023/09/28(木) 11:04:12.36

16ビットの制約で64キロバイトメモリしか確保できない時代から
一気に4GBメモリがリニアにアクセスできるようになった時は感動しましたよ
64ビットでは、あんまり感動はなかったな、なんでだろう

2023/09/28(木) 12:06:18.28

勉強してなかったからテストの点数が心配だなーﾁﾗｯﾁﾗｯ

みたいな番組なわけだな。

2023/09/28(木) 12:09:23.54

>>759
64KBを超える事より4GBを超えることの方が圧倒的に少ないからだな

2023/09/28(木) 12:44:49.42

ちょっと本気でプログラム組みだせばコードサイズ64KBなんてすぐ超える
一方1MBなんて集団でごちゃごちゃやってないかぎり超えない

2023/09/28(木) 12:53:02.94

アセンブラで組めばそんな大量のデータサイズにならんよ

2023/09/28(木) 13:56:12.11

データじゃなくてコードサイズの話なんだけど
ちょっと凝った仕様を入れようとすると６４Kbくらいは簡単に超える
泣く泣く削るか無理して分割ロードにするか
８ビット時代はそんな感じだったな

2023/09/28(木) 14:22:46.10

コード領域の自己書き換えでやりくりやりくり

2023/09/28(木) 14:40:53.17

昔のPRGとかメニュー開くとCDアクセス始めるゲームとかあったなぁ。
メモリー足りず、フィールド、戦闘、メニュー毎にプログラム読み直してるのかと思った。

2023/09/28(木) 15:31:33.20

Turbo C++ の MS-DOS 版にダイナミックロードを補助するライブラリが付いてなかったっけ？
うろおぼえだけど。

**デフォルトの名無しさん** (ｽﾌｯ Sdaa-TrDt) · 2023/09/28(木) 18:41:56.40

あったよ
うろ覚えだけど

2023/09/28(木) 19:15:05.82

>Turbo C++
TurboがC++だった頃なんてあったかな

2023/09/28(木) 19:19:34.33

あった
＞1990年5月、ボーランドは Turbo C から Turbo C++ へと移行し、アマチュア向け・ローエンド製品を
＞Turbo C++、プロ向け・ハイエンド製品を Borland C++ として2系統に展開した。

https://ja.wikipedia.org/wiki/Turbo_C

2023/09/28(木) 20:46:13.07

DOSでも増設メモリに32bitレジスタでアクセス出来たのなら・・・

2023/09/28(木) 22:44:00.88

それがDOSエクステンダだろ
GO32には世話になった

2023/10/02(月) 02:12:15.10

X68000 もよろしく

2023/10/05(木) 17:17:30.86

黒歴史度はFM-TOWNSとX68000とどっちがどっち？

2023/10/05(木) 19:38:38.95

何が黒歴史だ
どっちも国産パソコンに革命起こしたんだよ

2023/10/05(木) 19:43:14.40

TOWNSやX68000の話というのは、
PCやOSの話題にはなってもC言語の話題ではない

2023/10/06(金) 19:26:21.98

>>775
パソコンでありながらゲームしか宣伝してなくて当時発達著しかったゲーム機に負けただけで革命もクソもねえｗ

2023/10/06(金) 19:35:07.48

ゲーム機とPCで切磋琢磨してたんだろ
ゲーム機にだって栄枯盛衰はあぅたよ
そういえばプレステにLinux入れてアプリ作って動かしてた人いたなあ
プレステは高性能すぎて、特定国への輸出が規制を受けてた

2023/10/06(金) 19:43:43.15

PlayStation3に採用されたCPUはCell、ソニーとIBM、東芝の共同開発だった。
この辺もWikiを読むと面白い

2023/10/07(土) 05:34:11.31

あー。沢山繋げてスパコンみたいな。知らんけど。

2023/10/07(土) 12:37:19.06

>>778
PCがグラフィックボードに力を入れだすのはウィンドウズ普及以降になる
ゲーム機にはニンテンドー６４のRDRAMとかセガサターンのシンクロナスDRAMとかアーケードやシリコングラフィックCGマシンから取り入れられた新技術が投入されX68000やタウンズのかなう相手ではなかった

2023/10/07(土) 12:51:58.85

X68やTOWNSはMD/SFCとの争い・・・
・・・PS1 ジャンピングフラッシュの元になったゲームはX68で作られたんだっけ？あとワイヤーフレームのスターウォーズも。

2023/10/07(土) 13:51:13.10

（それって昔のPC板やレトロゲー板の範疇だからそろそろやめてくんないかなここはC言語スレ・・・）

2023/10/07(土) 14:41:36.91

年寄りは人の話を聞かないからな

2023/10/07(土) 15:09:15.52

68000は素晴らしい。8086のようなセグメントのあるCPUはクソだ。

と当時は思ったものです。

2023/10/07(土) 15:34:43.34

むしろ、そう言う話に持って行きたかった

2023/10/07(土) 15:55:47.74

X68000は素でgccが動いてうらやましかった。
一方86はgo32で無理矢理動かしてた。
Cに戻してみた。

2023/10/07(土) 15:58:51.83

レジスター数は羨ましかったな
あんだけあればレジスターだけでプログラム動かせそう、とか

2023/10/07(土) 16:46:51.81

アセンブラやるとね、バイトの並びが上位桁が先に来るので人間に分かり易くて良い、みたいな話もあった。
68000 だけじゃなく 6809 とか 6800 とかの 8 bit CPU の頃からいわゆる68系はそうだったな。
Sun の Sparc もそうか。

2023/10/07(土) 16:55:51.01

なんでリトルエンディアンになるの？

2023/10/07(土) 17:19:33.66

80系は昔からリトルエンディアンだったな。アドレスの小さい方が桁の小さい方にした方がコンピュータ的には自然だと考えたのかも知れない。

2023/10/07(土) 17:30:29.12

リトルエンディアンは同じアドレスから読み取ると
１６ビットデータを８ビットレジスタで読んでもちゃんと下位８ビットが読める
ビッグエンディアンは上位８ビットが読み込まれてしまう
さらに68000は１６ビット以上は奇数アドレスから読み込めないという制限があるのでハマることもある

2023/10/07(土) 17:36:03.54

リトルエンディアンの場合は、図を描くときに右から左、下から上に番地が増えるようにすると合理的なのよね

ダニーコーエンの、エンディアンの語源になった文書にもそんな図があったと思う。アスキーアートだけど

https://ja.m.wikipedia.org/wiki/ダニー・コーエン_(計算機科学者)

2023/10/07(土) 17:36:48.91

8bitCPUの頃のCPUの加算器は16bit+16bitしかできなかった、32bitの加算は分割してやるしかない
加算を分割してやる時は下の桁からやる
上の桁からやると、下の桁で繰り上がりが発生したら上の桁に戻って繰り上がり処理することになるから
下の桁が前にあるのがリトルエンディアン、こっちの方が自然だと思う
ビッグエンディアンはデータを後ろから前にアクセスしていくことになる、それだけだって言えばそうだけど

2023/10/07(土) 17:43:26.56

キャストしやすさもあるな。
メモリ上にある int 型のデータを char にキャストするみたいなとき
リトルエンディアンなら単にその場所から 1 バイトを読みだせばいいだけだが、
ビッグエンディアンだとアドレスをずらして読みだすか
読みだしてからマスクするかになる。

まあそのへんは効率的に処理できる命令があったりするんだろうけど
そんなこと最初から考えずに済むならそのほうがいい。

2023/10/07(土) 18:12:07.87

まあでもネットワークバイトオーダーはビッグエンディアンになっちゃってるんだよね。
これはこれで理由があるのかも知れないが、とにかく80系CPUだとひっくり返さねばならなくなった。
結局C言語だとそういったCPUの違いを吸収するために htonl(), ntohl() のようなマクロまたは関数を使うことになると。

2023/10/07(土) 18:15:49.27

それは、そういう風に決めないと、処理出来ないからだろう

2023/10/07(土) 18:24:53.16

通信系はなぁ……。結局は通信相手と同じ規約を使うしか仕方がないから
個々のコンピュータ (アーキテクチャ) にとっては不自然になることもある。

モダンなプロトコルはリトルエンディアンを採用している事例もそれなりにあるよ。

2023/10/07(土) 18:45:29.52

そのエンディアン変換が68000は面倒で
例えばZ80なら16ビットを上位バイト下位バイトレジスタ間で３命令で交換できるのに
68000はメモリに16ビット書き込み、8ビットシフト、メモリから8ビット読み出しという手順をしなければならない(確か)
万能のCPUなんてないものだと思ったよ

2023/10/07(土) 19:39:28.37

「インディアン」は何かの差別用語に該当しないのな
戦争に負けるとはこういう事だぞお前ら

2023/10/07(土) 19:41:36.75

由来はガリバー旅行記

2023/10/07(土) 19:50:37.92

アメリカ発見したとき（これも本当はおかしいことなんですが）、
そこがインドだって思いこんた白人がつけた呼び方だから
本当は間違いなんですけどね
そのインディアンと、エンディアンは別の言葉です

2023/10/07(土) 21:15:26.02

算用数字もリトルエンディアンだとよかったなあ

2023/10/07(土) 21:15:43.32

算用数字もリトルエンディアンだとよかったなあ

2023/10/07(土) 22:44:07.58

>>799
68000で16bitのd0.wの値をエンディアン変換
ror.w #8,d0

68000で32bitのd0.lの値をエンディアン変換
ror.w #8,d0
swap d0
ror.w #8,d0

2023/10/08(日) 00:21:50.43

そういや Oh! X が復刊するんだってよ。(単発で1冊出すだけだとは思うが)。
https://kibidango.com/project/2285/action/17185?ui_source=action&ui_campaign=177822&ui_medium=email

X68000Z 用のソフトを付けるそうだが8800円と妙に高い。完全にマニア向け(というか信者向け)の本だな。

2023/10/08(日) 10:00:50.20

SJISがBEじゃないのはなんでだろうね
MSはアホだったのか？

2023/10/08(日) 10:01:26.67

間違えた
SJISがLEじゃないのはなんでだろうね
漏れがアホだった

2023/10/08(日) 10:27:48.16

質問の意味が分からなかったんだが
2バイト文字の上位、下位の順番のことかな？

2023/10/08(日) 10:44:57.38

もともと日本メーカー(多分NEC)が策定したような気がする

2023/10/08(日) 11:24:23.52

JIS コードでの概念としては第一バイトが区、第二バイトが点に対応するようには設計されてる。
２バイト整数の上位と下位ではなく「第１バイト(区)」「第２バイト(点)」の組なんだよ。

Shift_JIS はアスキーコードと共存できるように JIS の配置をずらした。 (だから Shift と名前がついてる。)

2023/10/08(日) 12:24:35.99

分かったから他のスレ行けよ

2023/10/08(日) 13:05:45.22

ここはCを知り尽くした老害の集いとみなせ
常に話題に新鮮さが求められる
流れを変えたくば新鮮なC言語の話を振ればよい

2023/10/08(日) 13:16:39.02

wchar_t は何bit？

2023/10/08(日) 14:46:20.48

>>814
処理系定義。

2023/10/08(日) 16:18:18.23

>>813
新鮮なCの話なんて、あるのか？w

2023/10/08(日) 16:26:29.67

C23 の話題なら……。
今回の変更は割とデカいし。

2023/10/08(日) 18:52:25.18

C11も大して使われてる気がしないところでC23なぁ

2023/10/08(日) 19:56:42.76

いつだったかコミケの第何回かの略称と紛らわしかった思い出