Хотя я обещал вам где-то в Главе 14, что мы никогда снова не будем переписывать каждую одиночную функцию заново, я начал делать это с Главы 15. Единственная причина: эта длинная пауз между двумя главами делала обзор кажущимся чрезвычайно оправданным... даже необходимым и для вас и для меня. Более важно, решение собрать процедуры в модули заставило нас взглянуть на каждую из них снова, хотели мы этого или нет. И, наконец, откровенно говоря, за последние четыре года у меня появились некоторые новые идеи, которые гарантировали свежий взгляд на некоторые старые вещи. Когда я сперва начал эту серию я был искренне поражен и обрадован, узнав насколько простыми могут быть сделаны подпрограммы анализа. Но в этот последний раз я удивил сам себя снова и был способен делать их точно также, но даже немного проще.
      Однако, из-за тотального переписывания модулей синтаксического анализа я не был только способен включить многого в последнюю главу. Из-за этого наш герой, синтаксический анализатор, когда мы последний раз его видели, был только тенью себя прежнего, содержащий только код, достаточный для анализа и обработки показателя состоящего или из переменной или константы. Основным достижением этой текущей главы должно стать восстановление синтаксического анализатора в его прежней славе. В этом процессе, я надеюсь, вы будете терпеливы, если мы иногда будем рассматривать основы, с которые мы имели дело и давно уже прошли.
      Сначала, давайте позаботимся о проблеме, к которой мы обращались прежде: наша текущая версия процедуры Factor, как мы оставили ее в Главе 15, не может обрабатывать отрицательные параметры. Чтобы исправить это мы представим процедуру SignedFactor:

      {–}
      { Parse and Translate a Factor with Optional Sign }
      procedure SignedFactor;
      var Sign: char;
      begin
      Sign := Look;
      if IsAddop(Look) then
      GetChar;
      Factor;
      if Sign = '-' then Negate;
      end;
      {–}

      Заметьте, что эта процедура вызывает новую подпрограмму генерации кода Negate:

      {–}
      { Negate Primary }
      procedure Negate;
      begin
      EmitLn('NEG D0');
      end;
      {–}

      (Здесь и в других местах в этой серии я собираюсь только показывать вам новые подпрограммы. Я рассчитываю, что вы поместите их в соответствующий модуль, который вы должны без проблем определить. Не забывайте добавлять заголовок процедуры в раздел interface модуля.)
      В основной программе просто измените вызов процедуры Factor на SignedFactor и протестируйте код. Разве не хорошо компоновщик Turbo и средство make поддерживают все детали?
      Да, я знаю, код не очень эффективен. Если мы введем число -3 будет сгенерирован такой код:
      MOVE #3,D0
      NEG D0
      что действительно, действительно грубо. Мы можем сделать лучше, конечно, просто предварительно добавив знак минус к строке, передаваемой в LoadConstant, но это добавляет несколько строк кода в SignedFactor и здесь я применяю философию KISS очень агрессивно. Более того, сказать правду, я думаю что подсознательно наслаждаюсь генерацией «действительно грубого» кода, так как я могу иметь удовольствие наблюдать как он будет становиться драматически лучше, когда мы примемся за методы оптимизации.
      Большинство из вас никогда не слышало о Джоне Спрее, поэтому позвольте мне представить его вам здесь. Джон из Новой Зеландии и преподает информатику в одном из ее университетов. Джон написал компилятор для Motorola 6809, основанный на восхитительном, Паскаль-подобном языке собственной разработки, названном «Whimsical». Позднее он перенес компилятор на 68000 и некоторое время это был единственный компилятор, который я имел для своей доморощенной системы на 68000.
      К слову сказать, один из моих стандартных тестов для любого компилятора – изучение того, как компилятор работает с пустой программой типа:
      program main;
      begin
      end.
      Мой тест измеряет время, требуемое на компиляцию и связывание и размер сгенерированного объектного файла. Бесспорный проигравший в этом тесте – компилятор DEC C для VAX, который тратит 60 секунд на компиляцию на VAX 11/780 и генерирует объектный файл 50k. Компилятор Джона бесспорно сейчас, в будущем и навсегда король по части размера кода. Для данной пустой программе Whimsical генерирует точно два байта, реализуя одну инструкцию:
      RET
      Устанавливая опцию компилятора генерировать include файл а не автономную программу, Джон может даже урезать этот размер с двух байт до нуля! Несколько трудно добиться нулевого обьектного файла, вы не согласны?
      Само собой разумеется, что я рассматриваю Джона как эксперта в оптимизации кода и мне нравится что он однажды сказал: «Лучший способ оптимизации – не оптимизировать вообще, а изначально производить хороший код». Слова, по которым стоит жить. Когда мы начнем оптимизацию мы будем следовать уведомлению Джона и нашим первым шагом будет не добавление щелевого оптимизатора или другого постфактного устройства, но улучшение качества выдаваемого кода перед оптимизацией. Поэтому пометьте SignedFactor как первого хорошего кандидата на внимание и пока оставим его.

      Я уверен вы знаете, что будет дальше. Мы должны еще раз создать остальные процедуры, которые реализуют синтаксический анализ выражений по методу рекурсивного спуска. Все мы знаем, что иерархия процедур для арифметических выражений такая:
      выражение
      терм
      показатель
      Однако сейчас давайте продолжим разработку по шагам и рассмотрим выражения только с аддитивными термами. Код для реализации выражений, включающих возможно первый терм со знаком, показан ниже:

      {–}
      { Parse and Translate an Expression }
      procedure Expression;
      begin
      SignedFactor;
      while IsAddop(Look) do
      case Look of
      '+': Add;
      '-': Subtract;
      end;
      end;
      {–}

      Эта процедура вызывает две другие процедуры для обработки операций:

      {–}
      { Parse and Translate an Addition Operation }
      procedure Add;
      begin
      Match('+');
      Push;
      Factor;
      PopAdd;
      end;
      {–}
      { Parse and Translate a Subtraction Operation }
      procedure Subtract;
      begin
      Match('-');
      Push;
      Factor;
      PopSub;
      end;
      {–}

      Эти три процедуры Push, PopAdd и PopSub – новые подпрограммы генерации кода. Как подразумевает имя, процедура Push генерирует код для помещения основного регистра (D0 в нашей реализации для 68000) в стек. PopAdd и PopSub выталкивают вершину стека и прибавляют или вычитают ее из основного регистра. Код показан ниже:

      {–}
      { Push Primary to Stack }
      procedure Push;
      begin
      EmitLn('MOVE D0,-(SP)');
      end;
      {–}
      { Add TOS to Primary }
      procedure PopAdd;
      begin
      EmitLn('ADD (SP)+,D0');
      end;
      {–}
      { Subtract TOS from Primary }
      procedure PopSub;
      begin
      EmitLn('SUB (SP)+,D0');
      Negate;
      end;
      {–}

      Добавьте эти подпрограммы в Parser и CodeGen и измените основную программу для вызова Expression. Вуаля!
      Следующий шаг, конечно, это добавление возможности работы с мульпликативными термами. С этой целью мы добавим процедуру Term и процедуры генерации кода PopMul и PopDiv. Эти процедуры генерации кода показаны ниже:

      {–}
      { Multiply TOS by Primary }
      procedure PopMul;
      begin
      EmitLn('MULS (SP)+,D0');
      end;
      {–}
      { Divide Primary by TOS }
      procedure PopDiv;
      begin
      EmitLn('MOVE (SP)+,D7');
      EmitLn('EXT.L D7');
      EmitLn('DIVS D0,D7');
      EmitLn('MOVE D7,D0');
      end;
      {–}

      Я должен признать, что подпрограмма деления немного перегружена, но с этим ничего нельзя поделать. К сожалению, хотя процессор 68000 позволяет выполнять деление используя вершину стека (TOS), он требует аргументы в неправильном порядке, подобно тому как для вычитания. Поэтому наше единственное спасение в том чтобы вытолкнуть стек в рабочий регистр (D7), выполнить там деление, и затем поместить результат обратно в наш основной регистр D0. Обратите внимание на использование знаковых операций умножения и деления. Этим неявно подразумевается что все наши переменные будут 16-разрядными целыми числами со знаком. Это решение затронет нас позднее, когда мы начнем рассматривать множественные типы данных, преобразования типов и т.п.
      Наша процедура Term это практически аналог Expression и выглядит так:

      {–}
      { Parse and Translate a Term }
      procedure Term;
      begin
      Factor;
      while IsMulop(Look) do
      case Look of
      '*': Multiply;
      '/': Divide;
      end;
      end;
      {–}

      Наш следующий шаг – изменение некоторых имен. SignedFactor теперь становится SignedTerm а вызовы Factor в Expression, Add, Subtract и SignedTerm заменяются на вызов Term:

      {–}
      { Parse and Translate a Term with Optional Leading Sign }
      procedure SignedTerm;
      var Sign: char;
      begin
      Sign := Look;
      if IsAddop(Look) then
      GetChar;
      Term;
      if Sign = '-' then Negate;
      end;
      {–}
      ...
      {–}
      { Parse and Translate an Expression }
      procedure Expression;
      begin
      SignedTerm;
      while IsAddop(Look) do
      case Look of
      '+': Add;
      '-': Subtract;
      end;
      end;
      {–}

      Если память мне не изменяет мы однажды уже имели и процедуру SignedFactor и SignedTerm. У меня были причины сделать так в то время... они имели отношение к обработке булевой алгебры и, в частности, булевой функции «not». Но, конечно, для арифметических операций дублирование не нужно. В выражении типа:
      –x*y
      очевидно, что знак идет со всем термом x*y а не просто с показателем x и таким способом Expression и закодирован.
      Протестируйте этот новый код, выполнив Main. Она все еще вызывает Expression, так что теперь вы должны быть способны работать с выражениями, содержащими любую из четырех арифметических операций.
      Наше последнее дело, относительно выражений, это модификация процедуры Factor для разрешения выражений в скобках. Используя рекурсивный вызов Expression мы можем уменьшить необходимый код практически до нуля. Пять строк, добавленные в Factor, выполнят эту работу:

      {–}
      { Parse and Translate a Factor }
      procedure Factor;
      begin
      if Look ='(' then begin
      Match('(');
      Expression;
      Match(')');
      end
      else if IsDigit(Look) then
      LoadConstant(GetNumber)
      else if IsAlpha(Look)then
      LoadVariable(GetName)
      else
      Error('Unrecognized character ' + Look);
      end;
      {–}

      К этому моменту ваш «компилятор» должен уметь обрабатывать любые допустимые выражения, которые вы ему подбросите. Еще лучше, что он должен отклонить все недопустимые!

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

      {–}
      { Parse and Translate an Assignment Statement }
      procedure Assignment;
      var Name: string;
      begin
      Name := GetName;
      Match('=');
      Expression;
      StoreVariable(Name);
      end;
      {–}

      Присваивание вызывает еще одну подпрограмму генерации кода:

      {–}
      { Store the Primary Register to a Variable }
      procedure StoreVariable(Name: string);
      begin
      EmitLn('LEA ' + Name + '(PC),A0');
      EmitLn('MOVE D0,(A0)');
      end;
      {–}

      Теперь измените вызов в Main на вызов Assignment и вы должны увидеть полную операцию присваивания, обрабатываемую правильно. Довольно хорошо, не правда ли? И безболезненно также.
      В прошлом мы всегда старались показывать БНФ уравнения для определения синтаксиса, который мы разрабатываем. Я не сделал этого здесь и давно пора это сделать. Вот эти БНФ:
      <factor> ::= <variable> | <constant> | '(' <expression> ')'
      <signed_term> ::= [<addop>] <term>
      <term> ::= <factor> (<mulop> <factor>)*
      <expression> ::= <signed_term> (<addop> <term>)*
      <assignment> ::= <variable> '=' <expression>

      Следующий шаг, как мы изучили несколько раз до этого, это добавление булевой алгебры. В прошлом этот шаг по крайней мере удваивал количество кода, который мы должны были написать. Когда я прошел эти шаги в своем уме, я обнаружил, что отклоняюсь все больше и больше от того, что мы делали в предыдущих главах. Чтобы освежить вашу память, я отметил, что Паскаль обрабатывает булевы операторы в значительной степени идентично способу, которым он обрабатывает арифметические операторы. Булево «and» имеет тот же самый уровень приоритета, что и умножение, а «or» то же что сложение. Си, с другой стороны, устанавливает их на различных уровнях приоритета, которые занимают 17 уровней. В нашей более ранней работе я выбрал что-то среднее, с семью уровнями. В результате, мы закончили на чем-то называющемся булевыми выражениями, соответствующим в большинстве деталей арифметическим выражениям, но на другом уровне приоритета. Все это, как оказалось, возникло потому, что мне не хотелось помещать скобки вокруг булевых выражений в утверждениях типа:
      IF (c >= 'A') and (c <= 'Z') then ...
      При взгляде назад, это кажется довольно мелкой причиной для добавления многих уровней сложности в синтаксический анализатор. Возможно более существенно то, что я не уверен что был даже способен избежать скобок.
      Чтобы оттолкнуться, давайте начнем заново, применяя более Паскаль-подобный подход и просто обрабатывая булевы операторы на том же самом уровне приоритетов что и арифметические. Мы увидим, куда это нас приведет. Если это окажется тупиком, мы всегда сможем возвратиться к предыдущему подходу.
      Сперва, мы добавим в Expression операторы «уровня сложения». Это легко сделать; во первых, измените функцию IsAddop в модуле Scanner чтобы включить два дополнительных оператора: '|' для «или» и "~" для «исключающее или»:

      {–}
      function IsAddop(c: char): boolean;
      begin
      IsAddop := c in ['+','-', '|', '~'];
      end;
      {–}

      Затем, мы должны включить анализ операторов в процедуру Expression:
      {–}

      procedure Expression;
      begin
      SignedTerm;
      while IsAddop(Look) do
      case Look of
      '+': Add;
      '-': Subtract;
      '|': _Or;
      '~': _Xor;
      end;
      end;
      {–}

      (Символы подчеркивания необходимы, конечно, потому что «or» and «xor» являются зарезервированными словами Turbo Pascal).
      Затем процедуры _Or and _Xor:

      {–}
      { Parse and Translate a Subtraction Operation }
      procedure _Or;
      begin
      Match('|');
      Push;
      Term;
      PopOr;
      end;
      {–}
      { Parse and Translate a Subtraction Operation }
      procedure _Xor;
      begin
      Match('~');
      Push;
      Term;
      PopXor;
      end;
      {–}

      И, наконец, новые процедуры генерации кода:

      {–}
      { Or TOS with Primary }
      procedure PopOr;
      begin
      EmitLn('OR (SP)+,D0');
      end;
      {–}
      { Exclusive-Or TOS with Primary }
      procedure PopXor;
      begin
      EmitLn('EOR (SP)+,D0');
      end;
      {–}

      Теперь давайте протестируем транслятор (вы возможно захотите изменить вызов в Main обратно на вызов Expression просто чтобы избежать необходимости набирать каждый раз «x=» для присваивания).
      Пока все хорошо. Синтаксический анализатор четко обрабатывает выражения вида:
      x|y~z
      К сожалению, он также не делает ничего для того, чтобы защитить нас от смешивания булевой и арифметической алгебры. Он радостно сгенерирует код для:
      (a+b)*(c~d)
      Мы говорили об этом немного в прошлом. Вообще, правила какие операции допустимы а какие нет не могут быть применены самим синтаксическим анализатором, потому что они не являются частью синтаксиса языка, а скорее его семантики. Компилятор, который не разрешает смешанные выражения такого вида должен распознать, что c и d являются булевыми переменными а не числовыми и передумать об их умножении на следующем шаге. Но такая «охрана» не может быть выполнена синтаксическим анализатором; она должна быть обработана где-то между синтаксическим анализатором и генератором кода. Мы пока не в таком положении, чтобы устанавливать такие правила, потом что у нас нет способа ни объявления типов ни таблицы идентификаторов для сохранения в ней типов. Так что, для того что у нас на данный момент работает, синтаксический анализатор делает точно то, что он предназначен делать.
      В любом случае, уверены ли мы, что не хотим разрешить операции над смешанными типами? Некоторое время назад мы приняли решение (или по крайней мере я принял) чтобы принимать значение 0000 как логическую «ложь» и -1 или FFFFh как логическую «истину». Хорошо в этом выборе то, что побитовые операции работают точно таким же способом, что и логические. Другими словами, когда мы выполняем операцию с одним битом логической переменной, мы делаем это над всеми из них. Это означает, что мы не должны делать различия между логическими и поразрядными операциями, как это сделано в C операторами & и &&, и | и ||. Уменьшение числа операторов наполовину конечно не выглядит совсем плохим.
      С точки зрения данных в памяти, конечно, компьютер и компилятор не слишком интересуются представляет ли число FFFFh логическую истину или число -1. Должны ли мы? Я думаю что нет. Я могу придумать множество примеров (хотя они могут быть рассмотрены как «мудреный» код) где возможность смешивать типы могла бы пригодиться. Пример, функция дельты Дирака, которая могла бы быть закодирована в одной простой строке:
      –(x=0)
      или функция абсолютного значения (определенно сложный код!):
      x*(1+2*(x<0))
      Пожалуйста, заметьте, что я не защищаю программирование подобным образом как стиль жизни. Я почти обязательно написал бы эти функции в более читаемой форме, используя IF, только для того, чтобы защитить от запутывания того, кто будет сопровождать программу в будущем. Все же возникает моральный вопрос: Имеем ли мы право осуществлять наши идеи о хорошей практике кодирования на программисте, написав язык так, чтобы он не смог сделать что-нибудь не так? Это то, что сделал Никлаус Вирт во многих местах Паскаля и Паскаль критиковался за это – как не такой «прощающий» как Си.
      Интересная параллель представлена в примере дизайна Motorola 68000. Хотя Motorola громко хвастается об ортогональности их набора инструкций, факт то, что он является далеко не ортогональным. К примеру, вы можете считать переменную по ее адресу:
      MOVE X,D0 (где X это имя переменной)
      но вы не можете записать ее таким же образом. Для записи вы должны загрузить в регистр адреса адрес X. То же самое остается истиной и для PC-относительной адресации.
      MOVE X(PC),DO (допустимо)
      MOVE D0,X(PC) (недопустимо)
      Когда вы начинаете спрашивать, как возникло такое неортогональное поведение, вы находите, что кто-то в Motorola имел некоторые теории о том, как должно писаться программное обеспечение. В частности, в этом случае они решили, что самомодифицирующийся код, который вы можете реализовать, используя PC-относительные записи – Плохая Вещъ. Следовательно, они разработали процессор, запрещающий это. К сожалению, по ходу дела они также запретили все записи в форме, показанной выше, даже полезные. Заметьте, что это было не что-то, сделанное по умолчанию. Должна была быть сделана дополнительная дизайнерская работа, добавлены дополнительные ограничения для уничтожения естественной ортогональности набора инструкций.
      Один из уроков, которым я научился в жизни: Если у вас есть два выбора и вы не можете решить которому их них последовать, иногда самое лучшее – не делать ничего. Зачем добавлять дополнительные ограничители в процессор, чтобы осуществить чужие представления о хорошей практике программирования? Оставьте эти инструкции и позвольте программистам поспорить что такое хорошая практика программирования. Точно так же, почему мы должны добавлять дополнительный код в наш синтаксический анализатор для проверки и предупреждения условий, которые пользователь мог бы предпочесть использовать? Я предпочел бы оставить компилятор простым и позволить программным экспертам спорить, должна ли такая практика использоваться или нет.
      Все это служит как объяснение моего решения как избежать смешанной арифметики: я не буду ее избегать. Для языка, предназначенного для системного программирования, чем меньше правил, тем лучше. Если вы не согласны, и хотите выполнять проверку на такие условия, мы сможем сделать это, когда у нас будет таблица идентификаторов.

      С это небольшой философией, мы можем приступить к оператору «and», который пойдет в процедуру Term. К настоящему времени вы возможно сможете сделать это без меня, но в любом случае вот код:
      В Scanner:
      {–}
      function IsMulop(c: char): boolean;
      begin
      IsMulop := c in ['*','/', '&'];
      end;
      {–}
      в Parser:
      {–}
      procedure Term;
      begin
      Factor;
      while IsMulop(Look) do
      case Look of
      '*': Multiply;
      '/': Divide;
      '&': _And;
      end;
      end;
      {–}
      { Parse and Translate a Boolean And Operation }
      procedure _And;
      begin
      Match('&');
      Push;
      Factor;
      PopAnd;
      end;
      {–}
      и в CodeGen:
      {–}
      { And Primary with TOS }
      procedure PopAnd;
      begin
      EmitLn('AND (SP)+,D0');
      end;
      {–}
      Ваш синтаксический анализатор теперь должен быть способен обрабатывать почти любые виды логических выражений а также (если вы хотите) и смешанные выражения.
      Почему не «все виды логических выражений»? Потому что пока мы не имели дела с логическим оператором «not» и с ним все становится сложнее. Логический оператор «not» кажется на первый взгляд идентичным в своем поведении унарному минусу, поэтому моей первой мыслью было позволить оператору исключающего или, '~', дублировать унарный «not». Это не работало. При моей первой попытке процедура SignedTerm просто съедала мой '~' потому что символ проходил проверку на addop но SignedTerm игнорировал все addop за исключением "-". Было бы достаточно просто добавить другую строку в SignedTerm, но это все равно не решит проблему, потому что, заметьте, Expression принимает терм со знаком только для первого аргумента.
      Математически, выражение типа: