Re: [libsecondlife-dev] LSO & CIL compiler

[Jonathan]

The Java discussion might have caused some confusion, yet no. From a top-down or bottom-up perspective, my perspective is bottom-up from native to CIL executable, so that doesn't include any preference for C#, Java, or such. The implementation would have only one VM, which I have already written and is fully functional. The VM uses a RISC style object-oriented machine code. The machine code of this VM can not be written as flat bytecode due to the dynamic structures and interfaces created when a compilation occurs; hence, it is object based instead of type based. There are some predefined typed based instructions for optimization. Also, the VM allows for dynamic extension to the instruction set at runtime, which exists mainly for optimization and will help remove any need to predefine any type based instruction. The CIL executable would not be executed directly, so logically it appears to be a second VM on top of another. That is not the case. The VM compiles/reinterprets the CIL further into its machine code, as noted above. The only execution engine is the one that exists in the VM, and the CLS runtime environment is also being further compiled/reinterpreted directly from that bytecode. It does not use the VM of a CLR implementation (like .NET's VM or Mono's VM), but with CLS compliance it can use their framework. This idea isn't new. Intermediate languages, like CIL, have been designed by standardization to allow for this kind of further abstraction and division. [EMAIL PROTECTED] wrote: Perhaps I am misunderstanding what you just said.  Are you actually suggesting running  the .Net CLR (.Net’s virtual machine) on top of a Java VM, thus giving us two nested virtual machines on top of the native OS?   -Samuel Vincent   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jonathan Sent: Wednesday, November 01, 2006 4:20 PM To: Development list for libsecondlife Subject: Re: [libsecondlife-dev] LSO & CIL compiler   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 Personally, I use C and my own VMs  for most development. This is the most easiest. Eclipse has excellent customer support ability. Items I've entered into the tracker have been implemented. Ryan Gahl wrote: Also, Java sucks :D Indeed. C# = Java + common sense + ease of use.   _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/   --     _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/   -- _______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/ --

_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
http://www.libsecondlife.org/