C (или любой) компиляторы детерминированная производительность

Я думаю, что возможно уменьшить эту проблему до Проблема остановки так или иначе.

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

, Если Вы используете другого, "безопасный" компилятор, хотя, я не уверен. То, что я уверен, пишет, что компилятор с нуля, вероятно, был бы более легким заданием.

Даже квалифицированный или сертифицированный компилятор может привести к нежелательным результатам. Сохраните свой код простым и тест, тест, тест. Это или обход через машинный код вручную, не позволяя человеческой ошибки. Плюс операционная система или безотносительно среды Вы работаете (предпочтительно никакая операционная система, просто Ваша программа).

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

, Если Вы не находитесь в одних из тех отраслей промышленности, затем Вы получаете то, что Вы получаете. Коммерческая программа в операционной системе COTS на аппаратных средствах COTS. Это перестанет работать, который является гарантией.

Если Вы обеспокоены неожиданным машинным кодом, который не приводит к видимым результатам, единственный путь состоит в том, чтобы, вероятно, связаться с поставщиком компилятора для какой-то сертификации, которая удовлетворит Вашего клиента.

Иначе Вы будете знать это то же, которое Вы знаете об ошибках в Вашем коде - тестирование.

Машинный код из современных компиляторов может весьма отличаться и может быть полностью непостижимым для маленьких людей.

Вы получаете тот, который записал Dijkstra.

1. Изменение уровня оптимизации компилятора изменит вывод.
2. Небольшие изменения в функции могут сделать компилятор встроенным или больше не встраивать функцию.
3. Изменения в компиляторе (gcc версии, например) могут изменить вывод
4. , библиотечные функции Certain могут быть instrinic (т.е. испустить оптимизированный блок), в то время как другие больше всего не.

хорошие новости - то, что для большинства вещей это действительно не имеет значения так очень. Где это делает, можно хотеть рассмотреть блок, если это действительно имеет значение (например, в ISR).

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

И оптимизация и числа с плавающей точкой? Забудьте это!

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

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

1. Использование квалифицированный компилятор, где "квалифицировано" средства, что это было проверено согласно стандартам, изложенным регулирующим органом.
2. Выполняют анализ объектного кода. По существу Вы компилируете часть кода ссылки и затем вручную анализируете вывод, чтобы продемонстрировать, что компилятор не вставил инструкций, которые не могут быть прослежены до Вашего исходного кода.

Попробуйте поблочное тестирование.

, Если это недостаточно, используйте различные компиляторы и сравните результаты Ваших модульных тестов. Сравните strace выводы, запустите свои тесты в VM, сохраните журнал диска и сети I/O, затем сравните их.

Или предлагают записать Ваш собственный компилятор и сказать им, чего он собирается стоить.

Большинство, которое можно легко сертифицировать, - то, что Вы используете не вмешавшийся компилятор от поставщика X. Если они не доверяют поставщику X, это - их проблема (если X довольно защищено). Если они не доверяют никакому поставщику компилятора, то они полностью неблагоразумны.

Ответ на их вопрос: Я удостоверяюсь, что использую не вмешавшийся компилятор с X на эти средства. X хорошо сочтен, плюс у меня есть хороший набор тестов, которые показывают, что наше приложение ведет себя как ожидалось.

Все остальное начинает открывать кучу проблем. Необходимо остановиться где-нибудь, как говорит Rob.

... Вы доверяете своему компилятору неявно

, Вы прекратите делать это в первый раз, когда Вы сталкиваетесь с ошибкой компилятора. ;-)

, Но в конечном счете это - то, для чего тестирование. Для Вашего тестового режима не имеет значения, как ошибка вошла к Вашему продукту во-первых, все, что имеет значение, то, что это не передало Ваш обширный режим тестирования.

Некоторые интеллектуальные боеприпасы могли бы быть найдены в Перекрестных помехах, журнале для разработчиков программного обеспечения защиты. Этим вопросом является вид вещи, на которую они проводят много часов бодрствования. http://www.stsc.hill.af.mil/crosstalk/2006/08/index.html (Если я могу найти свои старые примечания из старого проекта, я вернусь здесь...)

то, Как Вы знаете, что компилятор используете, генерирует машинный код, который соответствует функциональности c кода точно и что компилятор полностью детерминирован?

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

единственное программное обеспечение, которое я сертифицировал, является авиационной радиоэлектроникой. Сертификация ФАА не достаточно строга, чтобы доказать, что программное обеспечение работает правильно, в то время как одновременно это действительно вынуждает Вас перейти через определенное количество обручей. Прием должен структурировать Ваш 'процесс', таким образом, он улучшает качество как можно больше с таким небольшим посторонним переходом обруча, как можно сойти с рук. Таким образом, что-либо, что Вы знаете, бесполезно и на самом деле не найдет ошибки, Вы можете, вероятно, ласка из. И что-либо, Вы знаете Вас, должно сделать, потому что это будет находить ошибки, относительно которого явно не просит ФАА, Ваш лучший выбор состоит в том, чтобы скрутить слова, пока это не кажется, что Вы даете людям QA ФАА/Вашей, что они попросили.

Это на самом деле не столь нечестно, как я заставил его звучать, в целом ФАА заботится больше о Вас являющийся добросовестным и уверенным, что Вы попытка , чтобы сделать хорошее задание, чем о том, что точно Вы делаете.

Вы никогда не не можете полностью доверительный компилятор, даже настоятельно рекомендованные. Они могли выпустить обновление, которое имеет ошибку, и Ваш код компилирует то же. Эта проблема усугублена при обновлении старого кода с ошибочным компилятором, выполнении тестирования и посылания товары только, чтобы сделать, чтобы клиент звонил Вам 3 месяца спустя проблемой.

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

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

Существуют доступные костюмы для проверки компилятора.
тот, который я помню, "Постоянный" .

, Когда я работал над компилятором C для встроенного процессора SOC, мы должны были проверить компилятор против этого и двух других костюмов для проверки (что я забываю название). Проверка компилятора к определенному уровню соответствия к этим, которым удовлетворяет тест, была частью контракта.

Все это сводится к доверию. Ваш клиент доверяет какому-либо компилятору? Используйте это или по крайней мере сравните выходной код между Вашим и их.

, Если они не доверяют никому, там ссылочная реализация для языка? Вы могли убедить их доверять ему? Затем сравните Ваш со ссылкой или используйте ссылку.

Это все принятие Вы на самом деле проверяете фактический код, который Вы получаете от поставщика/поставщика и что Вы проверяете, что в компилятор не вмешались, который должен быть первым шагом.

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

Вы знаете путем тестирования. Когда Вы тестируете, Вы тестируете Ваш и код и компилятор.

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

Можно применить тот аргумент на любом уровне: Вы доверяете сторонним библиотекам? Вы доверяете ОС? Вы доверяете процессору?

А хороший пример того, почему это может быть обоснованной озабоченностью, конечно, то, как Ken Thompson поместил бэкдор в исходную программу 'входа в систему'... и изменил компилятор C так, чтобы, даже если Вы перекомпилировали вход в систему, Вы все еще получили бэкдор. Посмотрите, что этот отправляет для получения дополнительной информации.

Подобные вопросы были подняты об алгоритмах шифрования - как мы знаем, что нет бэкдора в DES для NSA для отслеживания через?

В конце Вас должны решить, доверяете ли Вы инфраструктуре, Вы основываетесь на достаточно для не волнения об этом, иначе необходимо начать разрабатывать собственные кремниевые чипы!

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

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

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

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

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

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

Если вас беспокоят вредоносные ошибки в компиляторе, то одной из рекомендаций (IIRC, требование АНБ для некоторых проектов) является то, что бинарный компилятор должен предшествовать написанию кода. По крайней мере, тогда вы знаете, что ни у кого нет добавленных ошибок , нацеленных на вашу программу.

Выберите формально верифицированный компилятор, например, компилятор Compcert C.

Ну... нельзя просто сказать, что доверяешь выводам своего компилятора - особенно если работаешь со встроенным кодом. Нетрудно найти несоответствия между кодом, сгенерированным при компиляции одного и того же кода разными компиляторами. Это происходит потому, что сам стандарт Си слишком свободен. Многие детали могут быть реализованы по-разному разными компиляторами без нарушения стандарта. Как мы с этим справляемся? Мы избегаем по возможности зависимых от компилятора конструкций. С этим можно справиться, выбрав более безопасное подмножество Си типа Misra-C, как уже упоминалось ранее пользователем cschol. Мне редко приходится проверять сгенерированный компилятором код, но со мной такое иногда случалось. Но, в конце концов, вы полагаетесь на свои тесты, чтобы убедиться, что код ведет себя так, как задумывалось.

Есть ли лучший вариант? Некоторые утверждают, что есть. Другой вариант - написать свой код на SPARK/Ada. Я никогда не писал код на SPARK, но, насколько я понимаю, вам все равно придется связывать его с рутиной, написанной на C, которая будет иметь дело с "голыми металлическими" штучками. Прелесть SPARK/Ada в том, что вы абсолютно уверены, что код, сгенерированный любым компилятором, всегда будет одним и тем же. Никакой двусмысленности. Кроме того, язык позволяет аннотировать код с пояснениями, как он должен себя вести. Инструментарий SPARK будет использовать эти аннотации, чтобы формально доказать, что написанный код действительно делает то, что описано в аннотациях. Итак, мне сказали, что для критических систем SPARK/Ada является довольно хорошей ставкой. Однако я никогда не пробовал использовать его сам.