[Mono-dev] JaCIL Project

Eyal Alaluf eyala at mainsoft.com
Mon May 22 05:04:28 EDT 2006

We are now in the middle of a rewrite and in this rewrite we are using Cecil and ASM
(via IKVM). The version of the converter in the product was written in C++.

On Mon, 22 May 2006, Jb Evain wrote:

> Date: Mon, 22 May 2006 10:08:22 +0200
> From: Jb Evain <mono at evain.net>
> To: Eyal Alaluf <eyala at mainsoft.com>
> Cc: Zac Bowling <zac at zacbowling.com>,
>     Andreas Nahr <ClassDevelopment at a-softtech.com>,
>     Mono Developers <mono-devel-list at lists.ximian.com>
> Subject: Re: [Mono-dev] JaCIL Project
> Hi Eyal,
> Are you guys still using Cecil to read the CIL code?
> Jb
> Eyal Alaluf wrote:
>> Hi, all.
>> Just regarding feasibility and practicality - there is already a product 
>> implementing
>> this idea.
>> Not coincidently, the product is implemented by my company (Mainsoft) and 
>> is called
>> Grasshopper. You can access our DevZone at <http://dev.mainsoft.com>
>> As the guy who already implemented the conversion from .Net byte code to 
>> JBC, I
>> can tell you that all the managed opcodes of .Net are implemented in our 
>> converter.
>> The product implements .Net 1.1 and We are currently working on .Net 2.0 
>> (i.e. Generics).
>> As for performance, it's not a slam dunk but we managed to get comparable 
>> performance
>> with .Net on large customer projects (ISV ASP.Net projects of > 100K 
>> lines).
>> Eyal.
>> On Sun, 21 May 2006, Zac Bowling wrote:
>>> Date: Sun, 21 May 2006 20:03:03 -0500
>>> From: Zac Bowling <zac at zacbowling.com>
>>> To: Almann T. Goo <almann.goo at gmail.com>
>>> Cc: Andreas Nahr <ClassDevelopment at a-softtech.com>,
>>>     Mono Developers <mono-devel-list at lists.ximian.com>
>>> Subject: Re: [Mono-dev] JaCIL Project
>>> This might be off the radar but what about translating internal members 
>>> and attribute data?
>>> ----
>>> Zac Bowling <zac at zacbowling.com>
>>> http://www.zacbowling.com/
>>> Almann T. Goo wrote:
>>>> On 5/21/06, *Andreas Nahr* <ClassDevelopment at a-softtech.com 
>>>> <mailto:ClassDevelopment at a-softtech.com>> wrote:
>>>>     The hard part is likely that CIL has lots of construcs that Java
>>>>     bytecode does not have. Just to name a few common/important ones:
>>>>     Generics, Pointers and Pointer arithmetic, unchecked exceptions,
>>>>     events, delegates, ...
>>>> Just a note, from the JVM point of view, all exceptions are unchecked. 
>>>> The JVM "has" checked exceptions in the same way that it "has" 
>>>> generics; they are represented as meta-data in the class file but 
>>>> actually are not used by the JVM itself.  It is only the compiler that 
>>>> deals with this. And a lot of exceptions in the Java are unchecked, 
>>>> the whole "Error" and "RuntimeException" hierarchy for instance.
>>>>     How are you planning to solve that problem?
>>>> The simple answer is that I'm not--at least not right now.  I am 
>>>> trying to keep the scope maintainable and as such have explicitly laid 
>>>> out what minimal set of CLI features that I am supporting in my 
>>>> project proposal. Now, despite bowing out of implementing such 
>>>> features right now, I have given such things considerable thought and 
>>>> I have no doubt that most of them can be implemented--it is the cost 
>>>> of implementation that is probably the big question.
>>>> Let me address you question a little more specifically, it is a good 
>>>> one.
>>>>     * Generics will be tough, I hate to cop out and type erase like
>>>>       Java does, but that could be one implementation option.
>>>>     * Regarding un-managed pointers, there are ways you can emulate
>>>>       this, but because of the JVM programming model, it will come at
>>>>       a cost.
>>>>           o Others have dealt with this by doing things like paging
>>>>             with arrays--NestedVM (IVME '04), does this for the memory
>>>>             model of a MIPS R2000 ISA which it emulates.
>>>>           o This is not in my radar yet, because I think it would be a
>>>>             huge win just to support the verifiable subset of CIL. 
>>>> Un-managed pointers are not in this subset.
>>>>     * Regarding managed pointers, I will likely employ a boxing
>>>>       technique to do this.  Managed method pointers could be handled
>>>>       by using reflection.
>>>>           o These will of course take a performance hit (especially if
>>>>             reflection is involved), but at least we can have it.
>>>>     * Delegates are classes with methods from the programming model
>>>>       point of view  (there are CLI rules with regard to what can be
>>>>       in a delegate's definition, however).
>>>>           o With regard to the run-time provided method
>>>>             implementations in a delegate, one approach could be to
>>>>             actually emit the implementation of the delegate methods.
>>>>     * Events and properties are really just meta-data "sugar", there
>>>>       are no CIL instructions associated with them specifically and
>>>>       they look like methods in the programming model.
>>>>     * Although you didn't list these, here are a couple of other 
>>>> items.
>>>>           o I am actually very concerned with "newslot" methods,
>>>>             non-virtual instance method calls, and explicit interface
>>>>             method definition for near term future work.  This will
>>>>             undoubtedly be a pain to implement; there is a lot of
>>>>             opportunity to make really inefficient implementations.
>>>>           o Tail calls will be another really tough thing to implement
>>>>             since the JVM programming model does not have native
>>>>             support for tail recursive calls.  This is probably not a
>>>>             highly used CLI feature anyhow (Unless you are a Scheme
>>>>             compiler), so it is not really on my radar at the moment
>>>>             because there are much larger fish to fry before I wrestle
>>>>             with that.  A lot of literature on the subject--some kind
>>>>             of trampolining implementation may be a way to support 
>>>> this.
>>>> Here is a link to my proposal--it more clearly defines the scope for 
>>>> the first phase of this project.
>>>> http://www.cs.rit.edu/~atg2335/project/proposal.pdf 
>>>> <http://www.cs.rit.edu/%7Eatg2335/project/proposal.pdf>
>>>> I hate labeling a lot of these items as "future work", but we have to 
>>>> start somewhere manageable.  Note that future work is not the same 
>>>> thing as "never planning on implementing", so any insight on these 
>>>> issues are always appreciated.
>>>> Regards,
>>>> Almann
>>>> -- 
>>>> Almann T. Goo
>>>> almann.goo at gmail.com <mailto:almann.goo at gmail.com>
>>>> ------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list at lists.ximian.com
>>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list

More information about the Mono-devel-list mailing list