2009-08-17 2 views
3

.NET Framework 4.0 представляет несколько элементов API Reflection, которые варьируются от чрезвычайно полезного до жизненно важного для моей работы. Среди них охраняемые конструкторы для Assembly, Module, MethodBody и LocalVariableInfo и новый класс CustomAttributeData. Есть еще пара вещей, которые мне по-прежнему нужны, что довольно хлопотно для работы. Я считаю, что они легко применимы к той же [небольшой] группе людей, которые должны были расширить типы, которые я только что перечислил.Можем ли мы построить экземпляр `OpCode`?

На этот раз: Я ищу способ построить экземпляр структуры System.Reflection.Emit.OpCode с моими собственными параметрами. В настоящее время я вызываю внутренний конструктор для создания экземпляров. Это не наносит вреда производительности, потому что я выставляю построенные элементы как public static readonly членов класса для повторного использования, но, как вы можете себе представить, это крайне субоптимальный сценарий.

Есть ли какая-либо причина не представляется возможным сделать текущую внутреннюю OpCode конструктор общественность с документацией, которая гласит, пользовательский возведенные OpCode S не может быть использован с ILGenerator.

Редактировать: Вот пример. Создав следующий пользовательский код операции, я могу использовать его в преобразованиях байтового кода между некоторыми промежуточными списками инструкций, не прибегая к созданию временных локальных переменных. Если бы я излучал IL, я бы преобразовал оставшиеся инструкции swap в действительное представление IL, но в моем случае следующим шагом является JIT, который понимает пользовательскую инструкцию swap. Я использую префикс Prefix20xFD, который зарезервирован и не используется никакими действительными кодами операций IL.

/// <summary> 
/// Swaps adjacent elements on the evaluation stack. The supplied inline int32 argument gives the 
/// index of the topmost item in the pair. 
/// </summary> 
public static readonly OpCode Swap; 

Я также буду использовать это для JIT встроенных функций, которые не имеют простой/общее управляемое представление кода, но имеют простое зависимую от платформы представления, доступного в различных нативных генераторах коды. Один из них - ldthread (загружает ссылку на представление текущего управляемого управляемого потока RuntimeThread).

+2

Вы имеете в виду http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcode.aspx, который существует с 1.0? –

+0

Да, это тот. –

ответ

0

Я не думаю, что можно создать собственный экземпляр OpCode, поскольку экземпляры OpCode строго производны от Common Language Infrastructure (CLI) documentation. Поэтому, даже если ваш случай имеет смысл, OpCode, похоже, не подходит.

+1

Предустановленные экземпляры OpCode основаны на документации, но сама структура не является частью TR/84. Одна из причин, по которой мой код в этом приложении * так * clean, я использовал отражение, чтобы вызвать конструктор OpCode для создания новых экземпляров. Для тех, кто делает IL, преобразовывает себя перед отправкой результата в ILGenerator, возможность встраивания «специальных» кодов операций в промежуточные результаты может быть чрезвычайно полезна и с учетом узкой технической базы данных, которая фактически использует OpCode, не кажется вредным для открытия Это дело. Просто сделайте ILGenerator, если недействительные коды сделают это так далеко. –

+1

Я понимаю необходимость. Возможно, вы можете лоббировать (с помощью MVP) Microsoft, чтобы сделать конструктор общедоступным. –

0

Почему бы вам не использовать наши собственные IL-Opcodes для промежуточных результатов, а затем преобразовать их в реальные коды операций на последнем шаге.

Смежные вопросы