Тестовые примеры компилятора или как протестировать компилятор

Составители, такие как все программное обеспечение, также будут подвержены ошибкам, логическим ошибкам.

Как проверять результат, сгенерированный компилятором. Как правило, мой вопрос (есть)

  • Как проверить правильность написания машинного кода?

  • Как обеспечить, чтобы сгенерированный машинный код соответствовал спецификации языка.

  • Имеет смысл просто выбрать проект с открытым исходным кодом (в C, если вы также пишете компилятор на C), чтобы просто скомпилировать его через "компилятор". В этом случае также, как судить о том, что компилятор ведет себя так, как ожидалось.

  • Существуют ли какие-либо формальные тестовые примеры (литература), предоставленные комитетом по языковым стандартам, который должен удовлетворять компилятор, соответствующий языку?

  • Какова уверенность в том, что проблема в программе, скомпилированной компилятором, является ошибкой компилятора, а не ошибкой программы.

    - Любые примеры, когда компиляторы основного потока запутываются и компилируют код неправильно?

Ссылки на любую литературу будут оценены.

Ответы

Ответ 1

Существует несколько комплектов тестов компилятора. Нам посчастливилось использовать тестовый набор Plum Hall для компилятора C. Он состоит из большого набора C-кода, специально написанного для тестирования по языковому стандарту. Он проверяет, что компилятор может обрабатывать синтаксис и семантику языка.

Ответ 2

Хорошие комплекты тестов для реальных языков дороги для создания и обслуживания. Там причина, по которой набор тестов Plum Hall, который является отраслевым стандартом для ANSI C, настолько дорого стоит.

Джордж Некула проверка перевода - это блестящая идея, но также довольно дорогостоящая реализация.

Единственное, что дешево и просто: поддерживать набор регрессионных тестов и каждый раз, когда вы исправляете ошибку в своем компиляторе, поместите подходящий тест в свои регрессионные пакеты. С компиляторами невероятно, насколько легко продолжать повторять одну и ту же ошибку снова и снова. Дисциплинированные дополнения к вашему набору регрессии предотвратят это, и они не будут стоить дорого.

Ответ 3

Общая практика заключается в создании большого набора небольших программ, каждый из которых демонстрирует одни аспекты компилятора. Они будут включать как компиляцию программы, так и те, которые не должны. Генерал ASM, выходящий из задней части, не проверяется, а, скорее, программа запускается и проверяется выход. Что касается того, как убедиться, что в тестовых случаях нет ошибок: сделайте их маленькими, как и по 5-10 строк.

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

Ответ 4

Идея скомпилировать большой проект с открытым исходным кодом:

Вы можете взять проект, в котором есть набор тестов. Затем вы скомпилируете проект и его тестовый набор и посмотрите, проходят ли тесты. Чтобы проверить эти результаты, вы компилируете проект и набор тестов с другим компилятором и снова запускаете тесты.

Ответ 5

Ранее был вопрос связанный с этим для C, но он сводится к тщательно написанному тестовому набору компиляторов.

Что касается того, когда компиляторы неправильно кодируют код, я попал так часто в свою профессиональную карьеру, спасибо. Это происходило все меньше и меньше, но На этой неделе я обнаружил ошибку в компиляторах MS С++, нацеленных на CLI.

Ответ 6

Компилятор Eiffel является открытым исходным кодом и имеет обширную библиотеку тестовых примеров и внутренних контрактов на проектирование.

http://dev.eiffel.com