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

Цель статьи — рассказать о методе построения проекта на C и/или C++, при котором, в случае изменения участка кода, отладка которого производится чаще всего, большая часть проекта не нуждалась в повторной перезаписи. А так же показать, почему данный метод не всегда является эффективным решением.

Команда TestMace снова с вами. На этот раз мы публикуем перевод статьи о преобразовании кода TypeScript, используя возможности компилятора. Приятного чтения!

Введение

Это мой первый пост, и в нём мне бы хотелось показать решение одной задачи с помощью API компилятора TypeScript. Чтобы найти это самое решение, я долгое время копался в многочисленных блогах и переваривал ответы на StackOverflow, поэтому, чтобы уберечь вас от такой же участи, я поделюсь всем тем, что я узнал о таком мощном, но слабо документированном наборе инструментов.

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

Эти компоненты, начиная с графа Tensorflow, могут быть представлены в виде такой диаграммы:



На самом деле всё сложнее

В последнем семестре университета я выбрал курс компиляторов CS444. Там каждая группа из 1-3 человек должна была написать компилятор из существенного подмножества Java в x86. Язык на выбор группы. Это была редкая возможность сравнить реализации больших программ одинаковой функциональности, написанных очень компетентными программистами на разных языках, и сравнить разницу в дизайне и выборе языка. Такое сравнение породило массу интересных мыслей. Редко можно встретить такое контролируемое сравнение языков. Оно не идеально, но намного лучше, чем большинство субъективных историй, на которых основано мнение людей о языках программирования.

Мы сделали наш компилятор на Rust, и сначала я сравнил его с проектом команды на Haskell. Я ожидал, что их программа будет намного короче, но она оказалась того же размера или больше. То же самое для OCaml. Затем сравнил с компилятором на C++, и там вполне ожидаемо компилятор был примерно на 30% больше, в основном, из-за заголовков, отсутствия типов sum и сопоставлений с образцом. Следующее сравнение было с моей подругой, которая сделала компилятор самостоятельно на Python и использовала менее половины кода, по сравнению с нами, из-за мощности метапрограммирования и динамических типов. У другого товарища программа на Scala тоже была меньше нашей. Больше всего меня удивило сравнение с другой командой, которая тоже использовала Rust, но у них оказалось в три раза больше кода из-за разных дизайнерских решений. В конце концов, самая большая разница в количестве кода оказалась в пределах одного языка!

Компилятор — часть Emscripten. А что, если удалить все свистелки и оставить только его?

Emscripten необходим для компиляции C/C++ в WebAssembly. Но это гораздо больше, чем просто компилятор. Цель Emscripten в том, чтобы полностью заменить ваш компилятор C/C++ и запустить в вебе код, который изначально не предназначен для Сети. Для этого Emscripten эмулирует всю операционную систему POSIX. Если программа использует fopen(), то Emscripten предоставит эмуляцию файловой системы. Если используется OpenGL, то Emscripten предоставит С-совместимый контекст GL, поддерживаемый WebGL. Это немалая работа, и немало кода, который придётся внедрить в итоговый пакет. Но можно ли просто… удалить его?

Как и многие молодые разработчики, когда появляется желание найти работу/стажировку — я смотрю в сторону крутых IT компаний.

Недавно я попробовал попасть в ряды JetBrains и под катом готов поделиться полученным опытом.

Внимание: содержит системное программирование. Да, в сущности, ничего другого и не содержит.

Давайте представим, что вам дали задание написать фэнтезийно-фантастическую игру. Ну там про эльфов. И про виртуальную реальность. Вы с детства мечтали написать что-нибудь эдакое и, не раздумывая, соглашаетесь. Вскоре вы понимаете, что о мире эльфов вы знаете по большей части из анекдотов со старого башорга и прочих разрозненных источников. Упс, неувязочка. Ну, где наша не пропадала… Наученный богатым программистским опытом, вы отправляетесь в Гугл, вводите «Elf specification» и идёте по ссылкам. О! Вот эта ведёт на какую-то PDF-ку… так, что тут у нас… какой-то Elf32_Sword — эльфийские мечи — похоже, то что нужно. 32 — это, по-видимому, уровень персонажа, а две четвёрки в следующих столбцах — это урон, наверное. Точно то, что нужно, да к тому же как систематизировано!..

Эта статья — окончание цикла статей про eForth на программируемом калькуляторе. Начало здесь.

Команды входного языка «Электроники МК-161» занимают только половину файла eForth0.mkl. Вторую половину занимают таблицы, разработать которые был не меньший труд, чем написать алгоритмическую часть транслятора. Попробуем разобраться, как эти таблицы используются.

Это первая статья цикла про 161eForth v0.5b, окончание здесь: habr.com/ru/post/452572

Транслятор EFORTH теперь есть и на отечественном калькуляторе «Электроника МК-161»! 17 мая версия v0.5b успешно прошла мои тесты, а также пять авторских тестов TEST-TEST4. Я добился того, что можно сделать в одиночку, но считаю это лишь половиной дела. Настало время представить сообществу новый инструмент, открыв код 161eForth для публичного тестирования. У меня есть список, что улучшить и где «поработать над стабильностью». Ваши предложения и замечания будут учтены при завершении работ и выпуске версии 1.0

При переносе последней версии eForth на отечественную платформу успешно преодолены два препятствия — относительно низкое быстродействие 8-битной машинки, которая программируется на собственном входном языке, и скромный объём доступной двоичной памяти (см. 2.4.1), всего 4096 байт.

Большинство компиляторов имеют следующую архитектуру:



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

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

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

Разработка компилятора — очень тяжёлая задача. Но, к счастью, с развитием проектов наподобие LLVM решение этой задачи значительно упрощается, что позволяет даже программисту-одиночке создать новый язык, близкий по производительности к C. Работа с LLVM осложняется тем, что эта система представлена огромным объёмом кода, снабжённого небольшой документацией. Для того чтобы попытаться этот недостаток исправить, автор материала, перевод которого мы сегодня публикуем, собирается продемонстрировать примеры кода, написанного на Go, и показать, как они транслируются сначала в Go SSA, а потом — в LLVM IR с использованием компилятора TinyGO. Код Go SSA и LLVM IR был немного отредактирован, из него было удалено то, что не относится к приводимым тут пояснениям, ради того, чтобы эти пояснения оказались бы более понятными.

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

Где же именно пытаются применить методы машинного обучения при создании компиляторов? И почему до сих пор «умные» компиляторы не стали частью повседневной жизни разработчика?

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

Буквально несколько дней назад компания Microsoft представила публике новый язык программирования. Языку дали название Bosque. Главная миссия дизайна языка — лучше быть богатым и здоровым, чем бедным и больным чтобы он был прост и понятен как для человека, так и для компьютера.

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

Давайте попробуем рассмотреть некоторые особенности языка.

Привет, Хабр! Представляю вашему вниманию перевод статьи "The Rust Release Team "Announcing Rust 1.34.0".

Команда разработчиков Rust рада сообщить о выпуске новой версии Rust, 1.34.0. Rust — это язык программирования, который даёт возможность каждому создавать надёжное и эффективное программное обеспечение.

Если у вас установлена предыдущая версия Rust с помощью rustup, то для обновления Rust до версии 1.34.0 вам достаточно выполнить:

$ rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта.

Что вошло в стабильную версию 1.34.0

Основное улучшение этого выпуска это поддержка альтернативных cargo-реестров. Релиз также включает поддержку ? в документационных тестах, некоторые улучшения в #[attribute(...)] и стабилизацию TryFrom. Читайте далее о ключевых вещах или можете посмотреть подробные примечания к выпуску для дополнительной информации.

Как навсегда вписать своё имя в историю? Первыми слетать на Луну? Первым встретиться с инопланетным разумом? У нас есть способ проще — можно вписать себя в стандарт языка C++.

Хороший пример показывает Эрик Ниблер — автор C++ Ranges. «Запомните это. 19 февраля 2019 года — день, когда термин «ниблоид» впервые произнесли на встрече WG21» — написал он в Twitter.

И действительно, если зайти на CppReference, в раздел cpp/algorithm/rangescpp/algorithm/ranges, можно найти там множество упоминаний (niebloid). Для этого даже сделан отдельный вики-шаблон dsc_niebloid.

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

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

Интерпретатор языка MSH

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

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

Очень рад объявить о завершении моего первого компилятора для языка программирования! Malcc — это инкрементальный AOT-компилятор Lisp, написанный на C.

Вкратце расскажу о его многолетней разработке и что я узнал в процессе. Альтернативное название статьи: «Как написать компилятор за десять лет или меньше».

(В конце есть TL;DR, если вас не волнует предыстория).

Время от времени мы возвращаемся к проектам, которые уже проверяли ранее с помощью PVS-Studio и писали про это статьи. Делать это интересно по двум причинам. Во-первых, чтобы понять, насколько лучше стал наш анализатор. Во-вторых, чтобы отследить, обратили ли авторы проекта внимание на нашу статью, а также на отчет об ошибках, который мы им обычно предоставляем. Конечно, ошибки могут быть исправлены и без нашего участия. Но всегда приятно, когда именно наши усилия помогают сделать какой-то проект лучше. Не стал исключением и Roslyn. Предыдущая статья о проверке этого проекта датируется 23 декабря 2015 года. Это довольно давно, учитывая путь, который за это время проделал в своём развитии наш анализатор. Дополнительный интерес лично для нас Roslyn представляет ещё и тем, что на нём базируется ядро C# анализатора PVS-Studio. Таким образом, мы очень заинтересованы в качестве кода этого проекта. Устроим ему повторную проверку и выясним, что же нового и интересного (но будем надеяться, что ничего существенного) там сможет найти PVS-Studio.

Прошло полгода, а значит — время устанавливать новую Java! Это был долгий путь, и до конца добрались немногие. Из интересных JEP-ов отвалились сырые строки, а вот об оставшемся мы поговорим под катом.