[Mono-dev] JaCIL Project
mono at evain.net
Mon May 22 04:08:22 EDT 2006
Are you guys still using Cecil to read the CIL code?
Eyal Alaluf wrote:
> Hi, all.
> Just regarding feasibility and practicality - there is already a product
> 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
> 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
> 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>
>> 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
>>> 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
>>> * 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.
>>> 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.
>>> 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
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list