LLVM JIT Парсер, пишущий с Бизоном / Antlr / Packrat / Elkhound /
в Учебные пособия по LLVM Там есть инструкция, как написать простой JIT-компилятор. К сожалению, лексер и парсер в этом уроке написаны вручную. Я думал, что такое решение хорошо для учебных целей, но оно не подходит для написания сложных, готовых к работе компиляторов. Кажется, что GCC и несколько других «больших компиляторов» написаны от руки. Но я думаю, что все эти генераторы парсеров дают большой импульс при написании собственного компилятора (особенно, когда вы делаете это один, без команды людей).
Можно ли использовать какой-либо существующий генератор синтаксического анализатора, такой как Bison / Antlr / Packrat / Elkhound и т. Д. Вместе с LLVM для создания JIT-компилятора? Я хочу иметь возможность постоянно «кормить» анализатор (не один раз в начале) выражениями и компилировать их во время выполнения.
Кроме того, я нашел много вопросов о «лучшем, современном» генераторе парсера (например: https://stackoverflow.com/questions/428892/what-parser-generator-do-you-recommend). Если бы можно было использовать эти инструменты для создания JIT-компилятора LLVM, я был бы благодарен за любые дополнительные советы и рекомендации, какой инструмент был бы наилучшим с точки зрения производительности и гибкости в данном конкретном случае.
Решение
Использование генератора синтаксических анализаторов, таких как bison или antlr, дает много преимуществ, особенно при разработке языка. Вы, несомненно, в конечном итоге будете вносить изменения в грамматику, и вам захочется получить документацию по окончательной грамматике. Инструменты, которые производят грамматику автоматически из документации, действительно полезны. Они также могут дать вам уверенность в том, что грамматика языка — это (а) то, что вы думаете, и (б) не двусмысленность.
Если ваш язык (в отличие от C ++) на самом деле LALR (1) или даже лучше LL (1), и вы используете инструменты LLVM для построения AST и IR, то вряд ли вам нужно будет делать гораздо больше, чем писать вниз грамматику и предоставить несколько простых действий для построения AST. Это будет держать вас на некоторое время.
Обычная причина, по которой люди в конечном итоге выбирают создание своих собственных синтаксических анализаторов, за исключением предубеждения «настоящие программисты не используют генераторы синтаксических анализаторов», заключается в том, что нелегко обеспечить хорошую диагностику синтаксических ошибок, особенно при разборе LR (1). Если это одна из ваших целей, вы должны попытаться сделать грамматику LL (k) разбираемой (все еще нелегко обеспечить хорошую диагностику с помощью LL (k), но, кажется, это немного проще) и использовать LL (k) рамки как Antlr.
Существует другая стратегия, которая заключается в том, чтобы сначала анализировать текст программы самым простым способом, используя анализатор LALR (1), который является более гибким, чем LL (1), даже не пытаясь обеспечить диагностику. Если синтаксический анализ не удался, вы можете затем проанализировать его снова, используя более медленный, возможно, даже анализатор обратного отслеживания, который не знает, как генерировать AST, но отслеживает местоположение источника и пытается восстановиться после синтаксических ошибок. Восстановление из синтаксических ошибок без аннулирования AST еще сложнее, чем просто анализ, поэтому многое можно сказать, если не пытаться. Кроме того, отслеживание местоположения источника очень медленное, и это не очень полезно, если вам не нужно производить диагностику (если вам это не нужно для добавления отладочных аннотаций), так что вы можете немного ускорить анализ, не беспокоясь о отслеживание местоположения.
Лично я склонен против разбора пакетов, потому что не ясно, какой язык фактически анализируется PEG. Другие люди не возражают против этого, и YMMV.
Другие решения
Других решений пока нет …
detector