Построение пользовательских деревьев выражений при использовании операторов в C#

C# поддерживает назначение лямбда-выражения Expression<TDelegate>, что заставит компилятор выдавать код для создания дерева выражений, представляющего лямбда-выражение, которым затем можно управлять. Например:

Expression<Func<int, int, int>> times = (a, b) => a * b;

затем вы можете потенциально взять сгенерированное дерево выражений и преобразовать его в синтаксическое дерево вашего ассемблера, но это не совсем то, что вы ищете, и я не думаю, что вы сможете использовать компилятор C# для этого произвольный ввод.

вам, вероятно, придется создать свой собственный парсер для вашего ассемблера, так как я не думаю, что компилятор C# будет делать то, что вы хотите в этом случае.

опять же, не совсем уверен, что это именно то, что вы ищете, но с начальной точки желания создать какое-то дерево выражений с использованием синтаксиса c#, я придумал...

public abstract class BaseExpression
{
    // Maybe a Compile() method here?
}

public class NumericExpression : BaseExpression
{
    public static NumericExpression operator +(NumericExpression lhs, NumericExpression rhs)
    {
        return new NumericAddExpression(lhs, rhs);
    }

    public static NumericExpression operator -(NumericExpression lhs, NumericExpression rhs)
    {
        return new NumericSubtractExpression(lhs, rhs);
    }

    public static NumericExpression operator *(NumericExpression lhs, NumericExpression rhs)
    {
        return new NumericMultiplyExpression(lhs, rhs);
    }

    public static NumericExpression operator /(NumericExpression lhs, NumericExpression rhs)
    {
        return new NumericDivideExpression(lhs, rhs);
    }

    public static implicit operator NumericExpression(int value)
    {
        return new NumericConstantExpression(value);
    }

    public abstract int Evaluate(Dictionary<string,int> symbolTable);
    public abstract override string ToString();
}

public abstract class NumericBinaryExpression : NumericExpression
{
    protected NumericExpression LHS { get; private set; }
    protected NumericExpression RHS { get; private set; }

    protected NumericBinaryExpression(NumericExpression lhs, NumericExpression rhs)
    {
        LHS = lhs;
        RHS = rhs;
    }

    public override string ToString()
    {
        return string.Format("{0} {1} {2}", LHS, Operator, RHS);
    }
}

public class NumericAddExpression : NumericBinaryExpression
{
    protected override string Operator { get { return "+"; } }

    public NumericAddExpression(NumericExpression lhs, NumericExpression rhs)
        : base(lhs, rhs)
    {
    }

    public override int Evaluate(Dictionary<string,int> symbolTable)
    {
        return LHS.Evaluate(symbolTable) + RHS.Evaluate(symbolTable);
    }
}

public class NumericSubtractExpression : NumericBinaryExpression
{
    protected override string Operator { get { return "-"; } }

    public NumericSubtractExpression(NumericExpression lhs, NumericExpression rhs)
        : base(lhs, rhs)
    {
    }

    public override int Evaluate(Dictionary<string, int> symbolTable)
    {
        return LHS.Evaluate(symbolTable) - RHS.Evaluate(symbolTable);
    }
}

public class NumericMultiplyExpression : NumericBinaryExpression
{
    protected override string Operator { get { return "*"; } }

    public NumericMultiplyExpression(NumericExpression lhs, NumericExpression rhs)
        : base(lhs, rhs)
    {
    }

    public override int Evaluate(Dictionary<string, int> symbolTable)
    {
        return LHS.Evaluate(symbolTable) * RHS.Evaluate(symbolTable);
    }
}

public class NumericDivideExpression : NumericBinaryExpression
{
    protected override string Operator { get { return "/"; } }

    public NumericDivideExpression(NumericExpression lhs, NumericExpression rhs)
        : base(lhs, rhs)
    {
    }

    public override int Evaluate(Dictionary<string, int> symbolTable)
    {
        return LHS.Evaluate(symbolTable) / RHS.Evaluate(symbolTable);
    }
}

public class NumericReferenceExpression : NumericExpression
{
    public string Symbol { get; private set; }

    public NumericReferenceExpression(string symbol)
    {
        Symbol = symbol;
    }

    public override int Evaluate(Dictionary<string, int> symbolTable)
    {
        return symbolTable[Symbol];
    }

    public override string ToString()
    {
        return string.Format("Ref({0})", Symbol);
    }
}

public class StringConstantExpression : BaseExpression
{
    public string Value { get; private set; }

    public StringConstantExpression(string value)
    {
        Value = value;
    }

    public static implicit operator StringConstantExpression(string value)
    {
        return new StringConstantExpression(value);
    }
}

public class NumericConstantExpression : NumericExpression
{
    public int Value { get; private set; }

    public NumericConstantExpression(int value)
    {
        Value = value;
    }

    public override int Evaluate(Dictionary<string, int> symbolTable)
    {
        return Value;
    }

    public override string ToString()
    {
        return Value.ToString();
    }
}

теперь, очевидно, ни один из этих классов на самом деле ничего не делает (вы, вероятно, захотите Compile() метод там среди других), и не все операторы реализованы, и вы можете, очевидно, сократить имена классов, чтобы сделать его более кратким и т. д... но это позволяет вам делать вещи например:

var result = 100 * new NumericReferenceExpression("Test") + 50;

после чего, result будет:

NumericAddExpression
- LHS = NumericMultiplyExpression
        - LHS = NumericConstantExpression(100)
        - RHS = NumericReferenceExpression(Test)
- RHS = NumericConstantExpression(50)

это не совсем идеально - если вы используете неявные преобразования числовых значений NumericConstantExpression (вместо явного приведения/построения их), то в зависимости от порядка ваших терминов некоторые вычисления могут выполняться встроенными операторами, и вы получите только результирующее число (вы можете просто назвать это "оптимизацией времени компиляции"!)

чтобы показать, что я имею в виду, если вы было выполнить это:

var result = 25 * 4 * new NumericReferenceExpression("Test") + 50;

в этом случае 25 * 4 оценивается с помощью встроенных целочисленных операторов, поэтому результат фактически идентичен приведенному выше, а не создает дополнительный NumericMultiplyExpression С NumericConstantExpressions (25 и 4) на LHS и RHS.

эти выражения могут быть напечатаны с помощью ToString() и оценивается, если вы предоставляете таблицу символов (здесь просто простой Dictionary<string, int>):

var result = 100 * new NumericReferenceExpression("Test") + 50;
var symbolTable = new Dictionary<string, int>
{
    { "Test", 30 }
};
Console.WriteLine("Pretty printed: {0}", result);
Console.WriteLine("Evaluated: {0}", result.Evaluate(symbolTable));

результаты:

Pretty printed: 100 * Ref(Test) + 50
Evaluated: 3050

надеюсь несмотря на упомянутый недостаток(ы), это что-то приближается к тому, что вы искали (или я просто потратил последние полчаса!)

вы реализуете двухфазный (pass? ассемблер? Назначение двухпроходного сборщика это обрабатывать прямых ссылок (например, символ, который не определен при первой встрече).

тогда вам в значительной степени не нужно создавать дерево выражений.

в фазе (Проход 1) вы анализируете исходный текст (любыми способами: специальным парсером, рекурсивным спуском, генератором парсера) и собираете значения символов (в частности, относительные значения меток в отношении кода или раздела данных, в котором они содержатся. Если вы сталкиваетесь с выражением, вы пытаетесь оценить его, используя оценку выражения "на лету", обычно включающую стек push down для подвыражений и получение конечного результата. Если вы сталкиваетесь с символом, значение которого не определено, вы распространяете неопределенность как результат выражения. Если оператор сборки / команда должен значение выражения для определения символа (например., X EQU A+2) или определить смещения в раздел код/данные (e.g, DS X+23), то значение должно быть определено или ассемблер выдает ошибку. Это позволяет организации A+B-C работать. Другие операторы сборки, которым не нужно значение во время передачи, просто игнорируют неопределенный результат (например, LOAD ABC не заботится о том, что такое ABC, но может определить длину инструкции LOAD).

в фазе (pass II) вы повторно анализируете код таким же образом. На этот раз все символы имеют значения, поэтому все выражения должны оценивать. Те, которые должны были иметь значение в фазе I, проверяются по значениям, полученным в фазе II, чтобы убедиться, что они идентичны (иначе вы получите ошибку фазы). Другие операторы сборки / инструкции теперь имеют достаточно информации для создания фактических инструкций машины или инициализации данных.

дело в том, что вам никогда не нужно создавать дерево выражений. Вы просто оцениваете выражение, когда сталкиваетесь с ним.

Если вы построили один пройти ассемблер, вам может потребоваться смоделировать выражение, чтобы разрешить повторную оценку позже. Я обнаружил, что легче производить обратный польский как последовательность " PUSH стоимостью" и arithop и сохраните последовательность (эквивалентную дереву выражений), потому что она плотная (деревья не являются) и тривиальная для оценки путем выполнения линейного сканирования с использованием (как указано выше) небольшого стека pushdown.

на самом деле я сделал это, чтобы произвести обратный польский, который на самом деле действовал как стек выражений сам; во время линейного сканирования, если операнды могут быть оценены они были заменены на "толчок стоимостью " команда, и оставшаяся обратная полировка сжимается, чтобы удалить пузырь. Это не дорого, потому что большинство выражений на самом деле маленькие. И это означало, что любое выражение, которое нужно было сохранить для последующей оценки, было как можно меньше. Если вы резьбовой PUSH идентификатор команды через таблицу символов, затем, когда символ будет определен, вы можете заполнить все частично оцененные выражения и переоценить их; те, которые производят одно значение затем обрабатываются и их пространство рециркулируется. Это позволило мне собрать гигантские программы в 4K word, 16-битной машине, еще в 1974 году, потому что большинство прямых ссылок не очень далеко.