[Mono-list] CLI and devices

[Paolo Molaro]

On 06/05/02 Pavel Tcholakov wrote:
> Ehm, not that I want to start a flamewar, but the CLDC J2EE profile runs on 
> devices with as little as 512k ROM and 128k RAM memory (and that includes all 
> needed libraries, JVM, class libraries, and program memory). Haven't looked 
> at the new Compact .NET for pocketpc's, but I guess it will be pretty similar 
> in its requirements.

On 06/05/02 Sergey Chaban wrote:
> Nonetheless, something like JavaCard may be possible:
> * Very limited libs;
> * No garbage collection;
> * No floating point;
> * No threads;
> * Modified binary format (with preprocessing);
> * interpreter coded in assembler;
> (With such restrictions, there are Java runtimes less than 50KB)
> 
> Take a look at the Kernel profile in the ECMA specs, it defines
> one such stripped-down version.

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.
Of course, if you strip enough features it will fit, but is that still a
CLR? 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 :-)

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.

Take away:
Reflection 	-200 KB
FP support(1)	-100 KB (or more depending on interpretation)
AppDomain 	-100 KB
Remoting 	-50 KB
Other misc features -100 KB

And with the kernel profile you get about 1 MB _with the current
codebase_. I consider that quite good.
That can be still called a CLR. However the kernel profile still
requires threads, GC and a host of other stuff.
If you want to build a system that uses < 256 KB with the same
featureset, you'll need to rewrite quite a bit of code and by the time
you're done the embeeded devices will have twice the memory:-)

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

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better