|
One thing to note, I didn't mention my perspective that would help
explain my interest. A CLS, like Mono, usually implements a runtime
environment directly on top of a native environment. Given that CIL is
well defined, this direct implementation is not needed and can be
divided again with a VM, so that the CIL executable is within a runtime
environment directly on top of a VM instead of a native environment.
This allows machine states to be stored, retrieved, distributed, and
networked across like or different native environments. Current
implementations of CLS (Mono and Microsoft alike) are limited in their
microthread abilities due to native entanglements. The VM will solve
that. It is expected this division will affect performance, where many
CLS implementers have touted native speed, at the trade of such native
speed in exchange for scalability and security. I'm sure it is nice to program in C# on Visual Studio, but it doesn't work well for low-level manipulation the VM needs. I don't expect to have an immediate contribution to libSL as for the LSL compiler, as libRL still has priorities. Thanks for the interest to help improve SL. Jonathan wrote: Java to CIL + C# to CIL = common sense -- |
_______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/
