Являются ли синтаксические анализаторы LL(1) более эффективными для префиксного кодирования, а LR(1) более эффективными для постфиксного?

Это педаль с ручным кодированием для вопроса о металле, а не ANTLR против BISON.
Кроме того, это для разбора двоичного формата. Лексического анализа нет.


person Olsonist    schedule 23.07.2016    source источник
comment
Добро пожаловать в Stack Overflow! Я отредактировал ваш вопрос, насколько я мог догадаться о вашей проблеме. Однако добавьте больше описания, чтобы его увидело больше людей со знанием предмета. П Удачи!   -  person Enamul Hassan    schedule 23.07.2016
comment
Даже если у вас есть двоичный формат, вам все равно придется идентифицировать токены (например, извлечь четырехбайтовое целое число — в порядке байтов с прямым порядком байтов или с обратным порядком байтов, в зависимости от вашего протокола — из входного потока), который моральный эквивалент лексического анализа. И в большинстве случаев это все равно займет больше циклов, чем относительно тривиальные затраты на связывание токенов в синтаксические формы (анализ).   -  person rici    schedule 25.07.2016


Ответы (3)


Стоимость синтаксического анализа строгого выражения до (или после) порядка тривиальна при использовании методов «сверху вниз» или «снизу вверх». Он затмит любые другие задачи, даже лексический анализ. Крошечные различия в скорости будут результатом деталей реализации, а не алгоритмической стратегии.

Нет смысла использовать синтаксический анализатор LR(1), поскольку вам не нужен токен упреждающего представления ни для предварительного, ни для последующего порядка, предполагая, что представление является чисто предварительным/послезаказным. LR(0) было бы просто отлично. Вы вряд ли найдете полезный генератор синтаксического анализатора LR(0), но если вы хотите написать синтаксический анализатор от руки, этот факт упростит вашу задачу.

person rici    schedule 23.07.2016

Игнорируя LL(1) и LR(1) на данный момент, вы обычно анализируете такие виды выражений, запуская свой собственный код синтаксического анализа. Вы будете поддерживать стек ранее проанализированных и оцененных подвыражений, а затем неоднократно либо извлекать два верхних элемента из стека и объединять их (если вы читаете другой оператор), либо помещать что-то в стек (если вы читаете число).

Есть несколько способов реализовать этот стек. Вы можете сделать стек явной структурой данных стека, где вы сканируете ввод слева направо и вставляете и извлекаете элементы по мере необходимости. По стилю это ближе всего к тому, как работает парсер LR(1), поскольку вы будете думать в терминах сдвига (вталкивания) и сокращения (выталкивания). В качестве альтернативы вы можете использовать рекурсивный алгоритм и использовать стек вызовов вместо явного стека, что по духу ближе к тому, как работает синтаксический анализ LL(1).

Парсинг LL(1) и LR(1) в этом случае, если вы заботитесь только о чистой производительности, кажется полным излишеством. Они предназначены для обработки больших классов общих грамматик, и накладные расходы на таблицы, вероятно, будут снижать вашу производительность. Я бы просто написал код двумя разными способами (явный стек/снизу вверх и неявный стек/сверху вниз) и посмотрел, какой из двух на самом деле окажется быстрее.

person templatetypedef    schedule 08.08.2016
comment
Спасибо. Это педаль в пол, где задержка синтаксического анализа имеет решающее значение. Моя интуиция подсказывает, что LL лучше для префикса, а LR лучше для постфикса. Но, как вы предлагаете, я напишу оба и протестирую. На самом деле, я, вероятно, протестирую все четыре случая: LL/pre, LL/post, LR/pre, LR/post и тест. - person Olsonist; 09.08.2016
comment
На самом деле, стеки вызовов имеют явную аппаратную поддержку на современных платформах x86. Это дает преимущество рекурсивно-приличному управлению таблицей, о котором я не думал. - person Olsonist; 09.08.2016

В этой статье Разоблачение тайны синтаксического анализа LL и LR, подтверждает мою интуицию:

Польская и обратная польская нотации, на мой взгляд, напрямую соответствуют разбору LL и LR соответственно.

person Olsonist    schedule 22.09.2016