[Mono-dev] JaCIL Project

Jb Evain mono at evain.net
Mon May 22 04:08:22 EDT 2006 

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