> > Code size is pretty important for this project. If you don't think
> > this constraint is real or interesting, you can stop reading
> > now. :-)
> Is you main constraint in ROM, or in RAM? If the former, you need to
> store programs compressed and MIPS-16 (at any rate) becomes irrelevant.
Both are major constraints, as is secondary storage, if present at all.
Compressing program code in ROM may or may not make sense (I'm more
concerned about performance, that will take some experimenting to
determine), but if we can get a big portion of the benefit by going to
MIPS16 instead, we get both smaller footprint and the ability to execute
code from ROM (which in turn saves RAM).
This does tend to turn some of the desktop assumptions on their ear. I keep
reading about how bloaty _init code in the kernel is no big deal because it
gets freed up after kernel boot. Well, it's a big deal to us, we don't have
an 8GB hard drive to store this stuff on.
> Actually, I think MIPS-16 is probably not a good idea anyway; WinCE
> doesn't use it so this class of system will only offer it by chance.
You could say the same thing about MIPS in general - not all WinCE devices
use MIPS. While it's true that not all MIPS chips in these things have
MIPS16 support (my Freestyle Associate doesn't), and I don't want to rely on
it too heavily for that reason, it does seem the bulk of newer MIPS-based
handhelds are being based on NEC Vr41xx series CPU, all the newer versions
of which do support it. Given that, the additional 30-40% code size
improvement is a hard advantage to pass up.