#コンパイラ
何故 ARM だと char が unsigned になるのか
タイトル通りです。
signed char ではなく
unsigned char でもなく
プレーンで char 型を使ったときに
何故 ARM だと unsigned で展開されるのか
従来、C言語では、
『unsigned も signed も指定しない場合、 signed である』
というのが一般的でした。
unsigned も signed も指定しないプレーンな char を使用し
【C言語】char が signed とは限らなかったという話 （C言語のおおらかな仕様に右往左往する日々）
発端こちらの記事でご指摘頂いたことが始まりでした。
ご指摘内容は、次のコードが無限ループになっているというもの。
char c;for (c = 1; c < 0x80; ++c)
char の範囲が
-128 ～ 127
であるとするならば、それは常に
0x80 = 128
よりも小さくなります。
このため、次の条件は必ず真であり、偽になることがありません。
c < 0x80
ただ、
C言語コンパイラ依存した話の続編「clang はどうコンパイルするのか」
こちらの記事の延長戦です。
というわけで（どういうわけ？）、 clang コンパイラが吐き出したアセンブラを解析してみました。
結論から言うと、clang コンパイラの場合は次のようになります。
引数 i 、 j は三項演算する前に待避しておく。
「j--」（後置デクリメント）は、 j-- する前の値を別のレジスタに待避する。
まず、clang が出力したアセンブラを見てみます。スマホ版
【C言語】コンパイラが何をしているのか、ちょっとのぞいてみよう その３ コンパイル
C言語のコンパイラというのは、次の4つのステップで成り立ちます。
(1)プリプロセッサ
(2)コンパイル
(3)アセンブル
(4)リンク
前回は「(1)プリプロセッサ」について記載しました。
次は「(2)コンパイル」について書いてみましょう。
コンパイルは、C言語を翻訳してアセンブリコードを出力します。
アセンブリコードはCPUによって異なります。このため、いろいろなCPUに対応したいろ
