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