[Mono-list] CLI and devices

[Sergey Chaban]

> How useful is that, though? Why call it a CLR without GC and with all that
> limitations? I assume the CLDC J2EE profile has similar limitations.

The main idea (I believe) is to reuse existing skills, and use better development tools
than is normally available for such environments.
It's important that bytecode is immediately portable, because there are dozens of
different MCUs/CPUs/OSes.
For smartcards, there is no much use for GC or threads, all code is in ROM, and it is
programmed to do one single task.
At the same time CLDC has support for GC, threads etc. (floats are optional) -
it targets devices with more resources. Still, existing implementations are quite
compact (less than 1 Meg).
Another important factor is that extra safety provided by sandbox environment,
so that you wouldn't reboot your phone very often :-)

> It would be nice to have mono run on small embedded devices, but
> while we try to be resource-conscious, we're not targeting that small;-)
> Unless, of course, someone pays for it :-)

Paolo, I totally agreed :-)
In fact, my idea is that Mono is not suited for devices that small (like Legos).
So if someone interested in such implementation, it would be better to start from
scratch (considering those limitations from the very beginning).
Even then, mindstorms seem too small for the task :-)

> I just compiled a static mint: it's 1160 KB. Take away the 380 KB glibc
> imposes even on an empty program and you get 780 KB. Add about 700 KB from
> corlib and you have the current featured mono at 1.5 MB.

Actually, compiled for some other CPU it may be even smaller (for example, Thumb
code is quite compact). Also using different libc for the target platform may reduce size etc.


> Note 1) Collections.Hashtable uses float types in the interface: does
> that mean that it should not be included in the Kernel profile?

I believe that ctors with float loadFactor are not part of the ECMA specs
(not present in their XML file). So it's Microsoft specific.


Some info about the size of the CompactFramework:
Actual size may vary depending on the target CPU, but it's approx. 2MB
for the whole thing.
    mscorlib.dll is approx. 370 KB
    mscoree.dll for SH4 CPU (for example) approx. 330KB

CompactFramework seems quite limited in some areas (but it's not a Kernel
profile implementation either).
For example strings are not enumerable - so you cannot foreach on them (hey Dan! :-)
However, current version is Beta1, so maybe something will be changed.
Generally, writting code that would work on both .NET and Compact.NET
requires some special care (just like with J2SE vs. J2ME).

Sergey