This might be off the radar but what about translating internal members
and attribute data?
----
Zac Bowling <[EMAIL PROTECTED]>
http://www.zacbowling.com/
Almann T. Goo wrote:
On 5/21/06, Andreas Nahr
<[EMAIL PROTECTED]>
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.
- 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.
- 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.
- 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).
- 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.
- 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.
- 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
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
[EMAIL PROTECTED]
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
|
