IL-to-IL "front-end-compiler" ... ?


G

Guest

There are many source to source compilers for C, C++, and other languages.
CodeDom is .NET's closest attempt for C# and VB.NET. I am trying to explore
the idea of an IL-to-IL "front-end-compiler" that would take a managed
assembly created by Visual Studio and convert it into a "set of structures"
proserving the layout of the assembly. Modules would use this "set of
structures" to further manipulate the assembly's original definition in order
to replace, inject, and rearrange instructions. Finally, the "set of
structures" are written back into a managed IL assembly using Reflection.Emit.

The advantages I see with this approach would be to avoid the short-comings
of CodeDom (snipplets, etc.) and to gain independance from
language-dependancy semantics like in C# and VB.NET. Reflection.Emit cannot
be used by itself because, it is more sequencial nature...IL OpCodes must be
emitted sequencially where as with the proposed method, IL can be inserted,
removed, etc. at any time.

There are several obvious disadvantages. Working with IL OpCodes is
typically more error-prone than working with higher-level languages. The
modules that would manipulate the "set of structures" used to modify a set of
assemblies would be extremely difficult to develop properly. Furthermore,
optimizations made by one IL compiler could be ruined by one of these modules.

I can see a clear way of reading in the IL into a set of structures. I can
understand basically how the modifications can take place. However, I am
concerned about writting the final managed IL assembly using Reflection.Emit.
Past experience with Reflection.Emit has proven Reflection.Emit is a very
unforegiving API. NOP and other instructions are emitted when I thought they
should not be. I have since realized I did not properly cast the values of
several the OpCodes. If I remember correctly, some OpCodes yield multiple IL
instructions in the final assembly. It is almost like there should have been
more validation and/or strongly-typed instructions to avoid a
misunderstanding of the IL to be in the output assembly. I am concerned
Reflection.Emit might not emit the exact IL that am expecting. On that note,
should I expect to write my own routines to output a managed IL assembly?

I am still evaluating this approach and have not commited to implement it
yet. I welcome your suggests.
 
Ad

Advertisements

B

Barry Kelly

Michael said:
Past experience with Reflection.Emit has proven Reflection.Emit is a very
unforegiving API.
I am concerned
Reflection.Emit might not emit the exact IL that am expecting. On that note,
should I expect to write my own routines to output a managed IL assembly?

On the other hand, you've got a very easy way to validate your library -
roundtripping (unsigned) assemblies should be an idempotent operation.

-- Barry
 
Ad

Advertisements

P

Patrice

Don't remember the name right now but I have seen something similar on the
http://research.microsoft.com site that is AFAIK an object oriented view of
the assembly that you can update to generate updated IL code.

Made a quick search on AOP IL there. This is called the Runtime Assembly
Instrumentation Library (RAIL) :
http://rail.dei.uc.pt/
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top