AVRは大きく分けてクラシックとモダンの2世代に分類されます。 クラシックAVRはATmega8やATmega328Pのように成熟した製品ラインを持ち、 ATtiny2313Aのように小さなメニューでも対応できるシーンがあることはよく知られています。
モダンAVRのラインナップを見ていると妙にコードフラッシュのサイズが大きいことに気が付きます。 クラシックなAVRはATmega328Pのように32KB品あたりが標準ですが、 モダンなAVRはAVR64DD28のように64KB品あたりが標準です。 この差はどこから来るのか。 単なる技術革新による恩恵なのか、というとそうでもありません。 ChatGPTからもたらされた情報によれば、 モダンAVRはクラシックAVRに比べてコードサイズが肥大する傾向にあり、 最善でも1.2倍程度、最悪で2倍程度に膨れるということなのだそうです。 実際のところはコードを移植してみて比較して評価することになりますが、 2倍になるかもしれないという触れ込みは、心の準備となる情報ではあるでしょう。
ATtiny1616であれば16KBのフラッシュがあります。 GPIO等の差異を除けばATmega8と同程度のことはできるだろうと読むことができます。
久々にM32Cのツールチェーンのビルドを試みました。 結果から言えばかなり面倒くさい道のりでした。 M32Cをサポートする最後のコンパイラは、私が知っている限りでは gcc 4.7.4 です。 この古いgccをモダンなコンパイラでビルドできれば、とりあえず目的は達成されることになります。
config.guessが誤った結果を返す問題は、中身を修正すれば対処できます。 これはNetBSD固有の問題なので他のプラットフォームでは気にしない問題でしょう。 古いgccのソースコードに若干のパッチをすることでビルドを完了させます。
今後あと何年間ビルド可能かはわかりません。 NetBSD 10が現役である間は大丈夫でしょうが、NetBSD 10もいずれ終わりが来ます。 そろそろ、M32Cをどうこうするのは諦めたほうが良いかもしれません。
PIC32MX110/210はフラッシュメモリ容量が少ないため、 開発環境としてのサポートが厳しい状況にあります。 それでも16KBというフラッシュメモリ容量は4000ワード程度の機械語を収めることができ、 これはATmega8の40000ワード程度に匹敵するのです。 小さすぎるといって切り捨てるのには惜しい気がするのですが、 世間的に人気がないというのは、MPLAB Xにサンプルコードがないということの意味を物語っているような気がします。