[Mono-dev] JaCIL Project
zac at zacbowling.com
Sun May 21 21:03:03 EDT 2006
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 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list