[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