Рубрика «Компиляторы» - 51

Disclaimer: это перевод статьи Армина Ронашера «The Python I Would Like To See».

Вступление

Ни для кого не секрет, что я не являюсь фанатом Python 3 и того, куда язык сейчас движется. За последние несколько месяцев мне прилетела целая гора писем с вопросами о том, что именно мне не нравится и что я хотел бы видеть. Поэтому я решил, что должен поделиться своими мыслями на эту тему, чтобы, возможно, также дать почву для размышлений будущим авторам языков программирования.

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

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

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

Чем статический анализ отличается от предупреждений компилятора?

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

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

Читать полностью »

Checking PVS-Studio with Clang
Да, да. Вы не ослышались. В этот раз статья «наоборот». Не мы проверяем какой-то проект, а проверили наш анализатор с помощью другого инструмента. На самом деле, подобное делали мы и раньше. Например, проверяли PVS-Studio с помощью Cppcheck, с помощью анализатора, встроенного в Visual Studio, смотрели на предупреждения Intel C++. Но раньше не было повода написать статью. Ничего интересного не находилось. А вот Clang смог заинтересовать своими диагностическими сообщениями.
Читать полностью »

Компиляторы последних поколений стали настолько умными, что практически самостоятельно генерируют код, оптимизируя всё подряд. Иногда это приводит к неприятным последствиям.

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

Линус Торвальдс внимательно разобрался в вопросе и ёмко ответил одному из сообщивших о баге: «Ok, я посмотрел на генерацию кода и твой компилятор — чистое и полное дерьмо».
Читать полностью »

В соответствии со стандартами C и C++, если выполнение программы приводит к переполнению знаковой целой переменной, или к любому из сотен других «неопределённых действий» (undefined behaviour, UB), то результат выполнения программы может быть любым: она может запостить на Твиттер непристойности, может отформатировать вам диск…
Увы, в действительности «пасхальные яйца», которые бы заставляли программу в случае UB делать что-то из ряда вон выходящее, не встречались со времён GCC 1.17 — та запускала nethack, когда встречала в коде программы неизвестные #pragma. Обычно же результат UB намного скучнее: компилятор просто оптимизирует код для тех случаев, когда UB не происходит, не придавая ни малейшего значения тому, что этот код будет делать в случае UB — ведь стандарт разрешает сделать в этом случае что угодно!
В качестве иллюстрации того, как изобилие UB в стандарте позволяет компилятору выполнять неочевидные оптимизации, Реймонд Чен приводит такой пример кода:

int table[4];
bool exists_in_table(int v)
{
    for (int i = 0; i <= 4; i++) {
        if (table[i] == v) return true;
    }
    return false;
}

В условии цикла мы ошиблись на единицу, поставив <= вместо <. В итоге exists_in_table() либо должна вернуть true на одной из первых четырёх итераций, либо она прочтёт table[4], что является UB, и в этом случае exists_in_table() может сделать всё что угодно — в том числе, вернуть true! В полном соответствии со стандартом, компилятор может соптимизировать код exists_in_table() до

int table[4];
bool exists_in_table(int v)
{
    return true;
}

Такие оптимизации иногда застают программистов врасплох. Читать полностью »

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

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

JBrainfuck — оптимизирующий интерпретатор и компилятор Brainfuck под Java VM. Благодаря JIT обладает высокой производительностью.

Читать полностью »

В данной статье я хочу поделиться опытом, полученным в ходе переписывания одного проекта с Perl на Go. В ней будет больше о минусах, чем о плюсах, ибо о достоинствах Go и так поведано немало, а вот о подводных камнях, ожидающих новых разработчиков, узнать зачастую, кроме как от собственных шишек — неоткуда. Пост никоим образом не преследует цели охаять язык Go, хотя, признаться, некоторые вещи я был бы рад не писать. Также в нем охвачено сравнительно небольшой срез всей платформы, в частности, не будет ничего о шаблонах, регекспах, распаковке/запаковке данных и подобного, часто используемого в веб-программировании, функционала.
Читать полностью »

Статья демонстрирует технику создания парсеров с использованием наследования грамматик. Наследование позволяет описывать новые грамматики на основе уже существующих путем добавления новых правил или переопределения унаследованных, что существенно упрощает реализацию новых парсеров. Изменения в базовой грамматике автоматически становятся доступными во всех порожденных грамматиках. Основная область применения такой техники — поддержка нескольких диалектов или версий языков.
Читать полностью »

«Инициация в программирование» (1997 году, на 286-х), вторые деньги, заработанные в школе за написание программ на информатике для двоечников (первые деньги были за решение задач по физике), призовое место на краевой олимпиаде по программированию (хотя принимали программы только на Паскале и Сях, я раздобыл BASIC-компилятор и вооружившись речью про дискриминацию, загружал exe-шники, сделанные на Бэйсике. Прокатило). Первые программы по шифрованию, поворот картинки на 90 градусов… Все это было на Бэйсике (а друзья даже писали музыку и 3д-тетрис).

Недавно на Хабре промелькнул перевод «50 лет Бейсику!»и я решил поисследовать историю создания Бэйсиков.

1964

imageВ 1964 два профессора Дартмутского колледжа создали BASIC как инструмент, с помощью которого студенты-непрограммисты могли самостоятельно создавать компьютерные программы для решения собственных задач.

Джон Кемени, учился у Ричарда Феймана и Алонзо Чёрча (разработчик λ-исчисления), водил знакомство с фон Нейманом и консультировал Эйнштейна по математическим вопросам.

Томас Курц, учился у Джон Тью́ки (автора слов «software» и «bit»).

Оба награждены медалями «Пионер компьютерной техники».

Первоначально Бейсик был реализован на мейнфрейме GE-265 с поддержкой множества терминалов.
Вопреки распространённому убеждению, в момент своего появления это был компилируемый язык.

При проектировании языка использовались следующие восемь принципов. Новый язык должен был:
— быть простым в использовании для начинающих;
— быть языком программирования общего назначения;
— предоставлять возможность расширения функциональности, доступную опытным программистам;
— быть интерактивным;
— предоставлять ясные сообщения об ошибках;
— быстро работать на небольших программах;
— не требовать понимания работы аппаратного обеспечения;
защищать пользователя от операционной системы.
Читать полностью »

Доступна превью новой версии Visual Studio, с Roslyn и C# 6
Сегодня Microsoft выпустила превью новой версии Visual Studio «14» Community Technology Preview. Скорее всего, эта версия выйдет в 2015-м году и будет называться Visual Studio 2015. (Не стоит путать этот релиз с недавним релизом Visual Studio 2013 Update 3 Preview.)

Основным нововведением «14» стало повсеместное использование платформы Roslyn — высококачественного расширяемого компилятора C# и Visual Basic с открытым исходным кодом. В обновлениях для VS 2013 уже использовались компоненты из Roslyn, но теперь он проник повсюду.

Помимо Roslyn, улучшения затронули возможности рефакторинга, ASP.NET vNext, поддержку C++11/14, а также другие приятные мелочи.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js