On 08/16/05 David Srbecky wrote: > schoolwork, I will do some research, produce a battle plan and I will > come back :-)
Ok:-) > Do you mean that Cecil can not access the runtime similarly as > Reflection.Emit? Ok, got it. It can access it, but only through a very coarse mechanism: assembly loading. > > Hope this helps to understand where Cecil and re.emit fits in. > > Thank you very much, it help me to see the differences between Cecil and > S.R.Emit, however I still do not understand why you do not use Cecil in > S.R.Emit. > > Am I correct that Cecil will be powerful assembly reading and writing > library? Yes, hopefully;-) > And S.R.Emit needs, among other things, read and write libraries. Right? Yes, mostly. > S.R.Emit does that using unmanaged code now. Right? Some managed and some unmanaged. > Isn't it better to use managed Cecil in S.R.Emit do the reading and > writing of assemblies? No. The runtime needs to be able to read assemblies before executing them, so this code must be unmanaged. Having a second copy of the code in managed form would be just a huge and useless resource waste. (Yes, I know about jikes-rvm and I also know about the orrible maintainance issues they have: they can afford it because it's a research program). As for writing, re.emit is not obly concerned with writing assemblies, but also with creating and executing code in memory: this is only possible with a tight integration with the unmanaged runtime. Some parts of Re.Emit are already managed code and I guess some small parts of unamanged code will be moved to managed sometimes in the future. But this won't involve Cecil in any way: the unmanaged code amounts to about 40 KB of x86 binary and the Cecil assembly is 300+ KB of IL. We can't afford to use that much code to implement one of the fundamental runtime features. lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better _______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
