15 лет назад не было Хабрахабра, не было фейсбука, и что характерно, не было компилятора С++, с выводом диагностических сообщений на русском. С тех пор, вышло несколько новых стандартов С++, технологии разработки сделали гигантский скачок, а для написания своего языка программирования или анализатора кода может потребоваться в разы меньше времени, используя существующие фреймворки. Пост о том, как я начинал свою карьеру и путем самообразования и написания компилятора С++, пришел к экспертному уровню. Общие детали реализации, сколько времени это заняло, что получилось в итоге и смысл затеи — тоже внутри.

Я только что закончил серию изменений в коде браузера Chrome, которая уменьшила размер его бинарника под Windows примерно на 1 мегабайт, перенесла около 500 КB из read/write сегмента в read-only, а также уменьшила потребление оперативной памяти в общем примерно на 200 KB на каждый процесс Chrome. Удивительное заключается в том, что конкретно данная серия изменений состояла исключительно из удаления и добавления ключевого слова const в некоторых местах кода. Да, компиляторы — странные.

Эта задача возникла, когда я писал документацию для некоторых утилит, которые я использую для исследования регрессий кода, связанных с увеличением размера скомпилированных бинарников под Windows. Я запустил утилиту, скопировал в документацию её вывод и начал его описывать, когда заметил нечто странное: несколько больших глобальных объектов, которые согласно архитектуре должны были быть константными, почему-то находились в сегменте read/write данных. Сокращённая версия того вывода утилиты показана ниже:



Большинство исполняемых форматов имеют как минимум два сегмента данных — один для read/write объектов и ещё один для read-only. Если у вас есть константные данные, такие, например, как kBrotliDictionary, то их будет логично поместить в read-only сегмент, который является сегментом «2» в бинарнике Chrome под Windows. Однако некоторые константные данные, такие как unigram_table, device::UsbIds::vendors_ и blink::serializedCharacterData были в секции «3», то есть в read/write сегменте.

В мире .NET все прекрасно — платформа движется в правильном направлении, новые технологии обкатываются и встают на ноги. В последнее время много разговоров про .NET/ASP.NET Core, и кажется, что все забыли про Roslyn, который предоставляет широкие документированные возможности по работе с кодом как во время рантайма, так и в процессе разработки.


Чтобы исправить это, мы взяли интервью у Filip W, Microsoft MVP, контрибьютора Roslyn и просто одного из наиболее популярных в мире ASP.NET блоггеров. Почему Filip считает, что изменения в новом С# могут пройти незамеченными, зачем писать собственные анализаторы кода, а также почему скриптинг на C# лучше, чем любом скриптовом языке?

В прошлой статье мы познакомились с одной из самых интересных возможностей языка Rust — процедурными макросами.

Как и обещал, сегодня я расскажу о том, как писать такие макросы самостоятельно и в чем их принципиальное отличие от печально известных макросов препроцессора в C/C++.

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

Ребята, свершилось! После долгих шести недель ожидания наконец вышла версия Rust 1.15 с блекджеком и процедурными макросами.

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

А что же это дает простым смертным? Практически бесплатную [де]сериализацию, удобный интерфейс к БД, интуитивный веб фреймворк, выводимые конструкторы и много чего еще.

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

curl https://sh.rustup.rs -sSf | sh

Впрочем, обо всем по порядку.

Введение

PIC-контроллеры остаются популярными в тех случаях, когда требуется создать недорогую компактную систему с низким энергопотреблением, не предъявляющую высоких требований по ее управлению. Эти контроллеры позволяют заменить аппаратную логику гибкими программными средствами, которые взаимодействуют с внешними устройствами через хорошие порты.

Миниатюрные PIC контроллеры хороши для построения преобразователей интерфейсов последовательной передачи данных, для реализации функций «прием – обработка – передача данных» и несложных регуляторов систем автоматического управления.

Компания Microchip распространяет MPLAB — бесплатную интегрированную среду редактирования и отладки программ, которая записывает бинарные файлы в микроконтроллеры PIC через программаторы.

Взаимодействие MPLAB и Matlab/Simulink позволяет разрабатывать программы для PIC-контроллеров в среде Simulink — графического моделирования и анализа динамических систем. В этой работе рассматриваются средства программирования PIC контроллеров: MPLAB, Matlab/Simulink и программатор PIC-KIT3 в следующих разделах.

• Характеристики миниатюрного PIC контроллера PIC12F629
• Интегрированная среда разработки MPLAB IDE
• Подключение Matlab/Simulink к MPLAB
• Подключение программатора PIC-KIT3

В некоторых внутренних системах для быстрого поиска по большому битовому массиву мы в Badoo используем JIT. Это очень интересная и не самая известная тема. И, чтобы исправить такую досадную ситуацию, я перевел полезную статью Элая Бендерски о том, что такое JIT и как его использовать.

Еще в далеком 2005 с выходом стандарта C# 2.0 появилась возможность передачи переменной в тело анонимного делегата посредством ее захвата (или замыкания, кому как угодно) из текущего контекста. В 2008 вышел в свет новый стандарт C# 3.0, принеся нам лямбды, пользовательские анонимные классы, LINQ запросы и многое другое. Сейчас на дворе январь 2017 и большинство C# разработчиков с нетерпением ждут релиз стандарта C# 7.0, который должен привнести много новых полезных «фич». А вот фиксить старые «фичи», никто особо не торопится. Поэтому способов случайно выстрелить себе в ногу по-прежнему хватает. Сегодня мы поговорим об одном из их, и связан он с не совсем очевидным механизмом захвата переменных в тело анонимных функций в языке C#.

Однажды, сидя вечером перед компьютером и предаваясь меланхолии и мыслям о бренности всего сущего, я задумчиво набрал в поиске одного крупного сайта по поиску работы аббревиатуру «LLVM», не надеясь, впрочем, увидеть там что-то особенное, и стал просматривать небогатый, прямо скажем, улов.

Как и следовало ожидать, почти ничего особенного не нашлось, однако одно объявление меня заинтересовало. В нём были такие строки:

«Кого мы возьмем «не глядя» или уровень выполняемых задач:
Вы скачали любой open source проект, собираемый при помощи gcc (объем исходного кода более 10 мегабайт) и для самого большого файла cpp смогли построить AST дерево при помощи clang с –fsyntax-only;
Вы скачали любой open source проект, собираемый при помощи Visual C++ (объем исходного кода более 10 мегабайт) и для самого большого файла cpp смогли построить AST дерево при помощи clang с –fsyntax-only;
Вы смогли написать утилиту, которая выделит все места деклараций и использования локальных переменных, а также все функции, не определенные в данном файле».

Ну что же, подумал я, какое-никакое, а развлечение на вечер.

Когда кто-то произносит слово многоядерный, то мы бессознательно подразумеваем SMP. Это успешно срабатывало для нас до недавнего времени, пока ARM не объявила о big.LITTLE. Архитектура ARM big.LITTLE является первым массово производимым примером архитектуры AMP, и как мы увидим далее, она поднимает планку сложности многоядерного программирования еще выше.

Язык программирования с препроцессорными директивами сложен для обработки, поскольку в этом случае необходимо вычислять значения директив, вырезать некомпилируемые фрагменты кода, а затем производить парсинг очищенного кода. Обработка директив может осуществляться во время парсинга обычного кода. Данная статья подробно описывает оба подхода применительно к языку Objective-C, а также раскрывает их достоинства и недостатки. Эти подходы существуют не только в теории, но уже реализованы и используются на практике в таких веб-сервисах, как Swiftify и Codebeat.

Swiftify — веб-сервис для преобразования исходников на Objective-C в Swift. На данный момент сервис поддерживает обработку как одиночных файлов, так и целых проектов. Таким образом, он может сэкономить время разработчикам, желающим освоить новый язык от Apple.

Codebeat — автоматизированная система для подсчета метрик кода и проведения анализа различных языков программирования, в том числе и Objective-C.

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

От переводчика

Хочу сразу предупредить, что статья местами напоминает презентацию крупной компании из-за эпитетов в духе «изменит индустрию», «лучший на рынке», «прорывные технологии» и др. Если закрыть глаза на такой эмоциональный стиль повествования, то получится интересная вводная статья про новинки технологий компиляторов и виртуальных машин.

Введение

Со времён расцвета компьютерной индустрии многие были увлечены квестом в поисках идеального языка программирования. Квест очень сложный: создание нового языка — задача не из лёгких. И очень часто в процессе происходит дробление сложившейся экосистемы программирования и возникает необходимость заново строить базовые инструменты для нового языка: компилятор, отладчик, HTTP стек, IDE, библиотеки и бесконечное число базовых блоков пишутся с нуля для каждого нового языка. Совершенство в дизайне языков программирования недостижимо, и новые идеи возникают постоянно. Мы похожи на Сизифа: приговоренного богами на вечное толкание камня в гору, чтобы в итоге увидеть, как тот скатывается вниз снова и снова … целую вечность.

Как можно разорвать этот порочный цикл? Давайте помечтаем, чего бы нам хотелось.

PVS-Studio — статический анализатор исходного кода для поиска ошибок и уязвимостей в программах на языке C, C++ и C#. В этой статье я хочу дать обзор технологий, которые мы используем в анализаторе PVS-Studio для выявления ошибок в коде программ. Помимо общей теоретической информации я буду на практических примерах показывать, как та или иная технология позволяет выявлять ошибки.

Введение

Поводом для написания статьи стало моё выступление с докладом на открытой конференции ИСП РАН 2016 (ISPRAS OPEN 2016), проходившей в первых числах декабря в Главном здании Российской академии наук. Тема доклада: «Принципы работы статического анализатора кода PVS-Studio» (презентация в формате pptx).

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

Однажды мне пришлось вычислять сумму векторов целых чисел.

Звучит необычно. Кому понадобится делать это в реальной жизни? Обычно такие вычисления встречаются только в задачках из начальной школы или бенчмарках компилятора. Но сейчас это случилось на самом деле.

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

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

Привет, Хабр! Меня зовут Марко Кевац, я системный программист Badoo в команде «Платформа», и я очень люблю Go. Если сложить эти две вещи, то вы поймёте, насколько я люблю ассемблер в Go.

Совсем недавно мы рассказывали на Хабре о том, на каких конференциях побывали. Одной из них была GopherCon 2016, где практически всем запомнился доклад Роба «Командира» Пайка про Go-шный ассемблер. Представляю вам перевод его доклада, оформленный в виде статьи. Я постарался дать в тексте как можно больше ссылок на релевантные статьи в «Википедии».

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

Название отчёта было довольно простым: «При HTTP-подключении iter_content медленно работает с чанками большого размера». Подобное название немедленно включило у меня в голове сирену по двум причинам. Во-первых, довольно сложно определить, что здесь означает «медленно»? Насколько медленно? Насколько велик «большой размер»? Во-вторых, если бы описанное проявлялось действительно серьёзно, то мы бы об этом уже знали. Метод iter_content используется давно, и если бы он существенно притормаживал в распространённом пользовательском режиме, то мимо нас такая информация не прошла бы.

Введение

Здравствуй, мир! Сегодня у нас перевод спецификации языка CHIP8. Это статья содержит только теоретическую часть.

Что такое CHIP8?

CHIP8 это интерпретируемый язык программирования, который был разработан Джозефом Вейзбекером (прим. перевод Joseph Weisbecker) в семидесятых для использования в RCA COSMAC VIP. В дальнейшем был использован в COSMAC ELF, Telmac 1800, ETI 660, DREAM 6800. Тридцать одна (35?) инструкция давали возможности для вывода простого звука, монохромной графики в разрешении 64 на 32 пикселя, а также позволяло использовать 16 пользовательских кнопок. Сегодня CHIP-8 часто используется для обучения базовым навыком эмуляции (не интерпретации). Интерпретаторы CHIP-8, часто по ошибке называемые „эмуляторами“, существуют на все более расширяющемся множестве платформ. Это обилие интерпретаторов связано со сходством дизайна интерпретатора CHIP-8 и эмулятора системы. Те, кто хочет разобраться в эмуляторах, нередко начинают с написания интерпретатора CHIP-8.

Привет, Хабр!

Эта статья станет вступительной в моем небольшом цикле заметок, посвященном такой технике анализа программ, как pointer analysis. Алгоритмы pointer analysis позволяют с заданной точностью определить на какие участки памяти переменная или некоторое выражение может указывать. Без знания информации об указателях анализ программ, активно использующих указатели (то есть программ на любом современном языке программирования — C, C++, C#, Java, Python и других), практически невозможен. Поэтому в любом мало-мальски оптимизируещем компиляторе или серьезном статическом анализаторе кода применяются техники pointer analysis для достижения точных результатов.

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

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

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

Но так ли это? Давайте не будем просто воспринимать на веру слова некоторых парней в интернете, как библейское откровение, а проведём небольшой эксперимент и выясним.

Влияние Algol на ИТ-индустрию

Название языка Algol (ALGOrithmic Language), первая версия которого появилась в 1958 году, подчеркивает то обстоятельство, что он предназначен для записи алгоритмов. Благодаря четкой логической структуре Algol стал стандартным средством записи алгоритмов в научной и технической литературе. Однако он так и не смог полноценно конкурировать с языком Fortran, а с COBOL его и вовсе было трудно сравнивать в силу отсутствия некоторых важных возможностей у Algol – той же обработки текстов например или форматирования ввода/вывода.

«Роды» Algol проходили очень тяжело. Для некоторых его создателей, прямо скажем, – в муках. Ученые и эксперты отрасли никак не могли прийти к единому мнению по многим вопросам.

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