2009-08-17 19 views
3

Das .NET Framework 4.0 führt verschiedene Elemente in die Reflection-API ein, die für meine Arbeit äußerst nützlich sind. Unter diesen sind geschützte Konstruktoren für Assembly, Module, MethodBody und LocalVariableInfo und die neue CustomAttributeData Klasse. Es gibt ein paar Dinge, die ich noch brauche, die ziemlich mühsam sind, um zu arbeiten. Ich glaube, sie können leicht auf die gleiche [kleine] Gruppe von Menschen angewendet werden, müssten die Typen, die ich gerade aufgelistet habe, erweitern.Können wir eine Instanz von `OpCode` konstruieren?

Diesmal: Ich bin für einen Weg suchen, um eine Instanz der System.Reflection.Emit.OpCode Struktur mit eigenen Parametern zu konstruieren. Ich rufe derzeit den internen Konstruktor auf, um die Instanzen zu erstellen. Es ist nicht schädlich für die Leistung, weil ich die konstruierten Elemente als public static readonly Mitglieder einer Klasse für die Wiederverwendung verfügbar machen, aber wie Sie sich vorstellen können, ist dies ein extrem suboptimales Szenario.

Gibt es einen Grund, warum es nicht möglich ist, den aktuellen internen OpCode Konstruktor public mit der Dokumentation zu machen, die OpCode s benutzer konstruiert heißt es kann nicht mit ILGenerator verwendet werden.

Edit: Hier ist ein Beispiel. Indem ich den folgenden benutzerdefinierten Opcode erstelle, kann ich ihn in Byte-Code-Transformationen zwischen einigen Zwischenanweisungen verwenden, ohne auf temporäre lokale Variablen zurückgreifen zu müssen. Wenn ich IL austrage, würde ich die verbleibenden swap Anweisungen in eine gültige IL-Darstellung konvertieren, aber in meinem Fall ist der nächste Schritt ein JIT, der die benutzerdefinierte swap-Anweisung versteht. Ich verwende das Prefix2 Präfix 0xFD, das reserviert und von keinem gültigen IL-Opcodes verwendet wird.

/// <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; 

Ich werde dies auch für JIT-Spezifika verwenden, die eine einfache plattformabhängige Darstellung in den verschiedenen nativen Code-Generatoren keine einfache/common Managed-Code-Darstellung, sondern haben. Eine davon ist ldthread (lädt einen Verweis auf die RuntimeThread Darstellung des aktuellen verwalteten Threads).

+2

Meinst du http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcode.aspx, die seit 1.0 vorhanden ist? –

+0

Ja, das ist der eine. –

Antwort

0

Ich glaube nicht, dass es möglich ist, benutzerdefinierte OpCode-Instanzen zu erstellen, da OpCode-Instanzen streng von Common Language Infrastructure (CLI) documentation abgeleitet sind. Auch wenn Ihr Fall sinnvoll ist, scheint OpCode nicht der richtige Weg zu sein.

+1

Die vordefinierten OpCode-Instanzen basieren auf der Dokumentation, aber die Struktur selbst ist nicht Teil von TR/84. Ein Teil des Grundes, warum mein Code in dieser Anwendung * so * sauber ist, ist eine Reflektion, um den OpCode-Konstruktor aufzurufen, um die neuen Instanzen zu erstellen. Für jeden, der IL transformiert, bevor er das Ergebnis an ILGenerator sendet, kann die Fähigkeit, "spezielle" Opcodes in die Zwischenergebnisse einzubetten, extrem hilfreich sein, und angesichts der engen, technischen Benutzerbasis, die tatsächlich OpCode verwendet, scheint es nicht schädlich zu sein dieser Fall. Lass ILGenerator nur werfen, wenn ungültige Codes es so weit bringen. –

+1

Ich verstehe die Notwendigkeit. Vielleicht können Sie (mit Hilfe eines MVP) Microsoft Lobbyarbeit leisten, um den Konstruktor öffentlich zu machen. –

0

Warum verwenden Sie nicht unsere eigenen IL-Opcodes für die Zwischenergebnisse und konvertieren diese dann im letzten Schritt in echte Opcodes.

Verwandte Themen