[Mono-dev] Re: Edit and Continue

Paolo Molaro lupus at ximian.com
Tue Aug 16 12:04:27 EDT 2005

On 08/16/05 David Srbecky wrote:
> schoolwork, I will do some research, produce a battle plan and I will
> come back :-)


> 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

> > 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?

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 at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better

More information about the Mono-devel-list mailing list