[Mono-dev] JaCIL Project

[Zac Bowling]

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
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060521/94ad5844/attachment.html