Компиляторы *

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

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

rustup update stable

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

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

В 2017 году, Per Vognsen - программист с более чем 15-летним стажем, работавший в таких компаниях как NVIDIA и Oculus берет паузу и в марте 2018 стартует амбициозный обучающий проект Bitwise, в котором он собирается разработать и написать весь программно-аппаратный стек для простого компьютера с нуля и запустить его на FPGA. 

Проект должен был включать в себя операционную систему, компилятор, системные библиотеки, а также HDL код для центрального процессора и периферийных контроллеров. Пререквизиты к нему минимальны - свободное владение языком Cи (и немного Python), а также знание некоторых алгоритмов и структур данных из стандартных CS курсов. Все остальное объясняется по ходу написания кода.

Проекты подобные Bitwise можно пересчитать по пальцам (думаю многие еще вспомнят о знаменитом Handmade Hero от Casey Muratori). Автором данного проекта выступает отличный программист, который в формате скринкастов показывает и объясняет каждое решение по ходу написания кода. Этой короткой статьей я бы хотел заполнить пробел и познакомить большее число людей с проектом Bitwise, так как сам извлек из него много нового.

продолжение TypeScript Native (AOT) Compiler

Задача коммерческих статических анализаторов выполнять более глубокий и полный анализ кода, чем компиляторы. Давайте посмотрим, что смог обнаружить PVS-Studio в исходном коде проекта LLVM 13.0.0.

На работе я пишу почти исключительно на Python, с университетской скамьи остались некоторые знания C/C++, в одном pet-project использовал Haskell. С таким багажом знаний я взялся за написание компилятора на основе LLVM - зачем и что получилось я уже рассказывал в предыдущей статье.

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

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

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

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

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

И, наконец, хочется,  чтобы конечное приложение работало быстрее, чем в среде разработки.

И вот тут настало время скомпилировать Python-код.

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

TypeScript Native (AOT) Compiler

Имплементация нативного Ahead-of-Time компилятора для языка TypeScript

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

У constexpr с каждым годом становится больше возможностей. Сейчас использовать в compile-time вычислениях можно почти всю стандартную библиотеку. Пример вычисления числа до 1000 с наибольшим количеством делителей: ссылка на код.

История constexpr насчитывает долгую историю эволюции с ранних версий C++. Исследуя предложения в стандарт и исходники компиляторов, можно понять, как слой за слоем создавалась эта часть языка, почему именно так она выглядит, как на практике вычисляются constexpr-выражения, какие возможности ждут нас в будущем, а какие - могли бы быть, но не были приняты в Стандарт.

Эта статья подходит как тем, кто еще не знает, что такое constexpr, так и тем, кто уже долгое время его использует.

Как происходит проверка решения

source.cpp:
#include <bits/stdc++.h>

using namespace std;

int main() {
    int a, b;
    cin >> a >> b;
    cout << a + b << endl;
}

Уже несколько лет я веду разработку собственного языка программирования — Ü. Около двух лет назад я публиковал вводную статью о нём на Хабре. Компилятор этого языка написан на C++ и долгое время он таковым и оставался. Но после той публикации я пришёл к выводу, что язык Ü уже достаточно продвинут, чтобы написать на нём компилятор языка Ü. О написании этого компилятора и будет повествовать данная статья.

То, что написано ниже, для многих квалифицированных C++ разработчиков будет прекрасно известной и очевидной вещью, но тем не менее, я периодически встречаю using namespace std; в коде различных проектов, а недавно в нашумевшей статье про впечатления от высшего образования было упомянуто, что студентов так учат писать код в вузах, поэтому давайте повторим очевидное еще раз.

Итак... многие слышали, что using namespace std; в C++ считается плохой практикой. Касательно недопустимости использования using namespace в header-файлах вопросов обычно не возникает, если мы хоть немного понимаем, как работает препроцессор компилятора: .hpp-файлы при использовании директивы #include вставляются в код "как есть", и соответственно using автоматически распространится на все затронутые .hpp- и .cpp-файлы, если файл с ним был заинклюден хоть в одном звене цепочки (на одном из сайтов это метко обозвали как "заболевание, передающеемя половым путем"). Но вот про .cpp-файлы все не так очевидно, так что давайте еще раз разберем, что же именно здесь не так.

Добрый день друзья. Как-то мне захотелось установить Qbittorrent на мой роутер который оснащен OpenWRT. Конечно создатели OpenWRT уже предусмотрели возможность сборки кастомных покетов об этом можно почитать вот тут: https://habr.com/ru/company/ruvds/blog/530984/ . Но данный способ очень долгий, приходится скачивать исходники OpenWRT, компилировать тулчайн и прочее. И я подумал а почему-бы просто не скачать тулчайн и собрать проек обычным образом под катом мой опыт.

Недавно я проходил собеседование и одним из вопросов, стал такой загадочный экземпляр:
"А какое главное преимущество системы типов Kotlin перед Java"?

Честно говоря, выделить какое преимущество считалось главным, оказалось неразрешимой для меня задачей: Nothing, отсутсвие Wildcard и First-Class Functions вместо Java-костыля с Functional Interface (имеется ввиду 8я версия Java) не заняли первых мест в личном топе интервьюера, который мне предложили угадать.

Оказалось что главное в Kotlin - возможность обьявить Nullable Type и Null Safety подход (Замечу, что по моему опыту собственные или библиотечные Optional или Maybe решают эту проблему, и пишутся за 10 минут на Java 7. А еще есть аннотации Nullable, позволяющие проверять поля в сompile-time. Короче, есть много способов заставить делать Null проверки в plain Java. Ну да ладно).

Но речь пойдет не о странных вопросах, связанных со вкусовыми предпочтениями интервьюеров относительно синтаксического сахара.
Дело в том, что Null Safety в Kotlin можно сломать, притом не выходя из под его безопасного купола в суровый дикий мир Java и Null-Referrences.

Как?

Long story short: ClassLoader ведет себя интересным образом при попытке загрузить статические поля классов рекурсивно ссылающиеся на классы друг-друга.

Под катом примеры кода и подробное объяснение того, как он обманывает проверки на Nullable. Я искренне надеюсь что специфические знания Java/Kotlin для статьи не нужны - я объясню все детали на ходу, и уложу расследование в 10 минут.

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

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

rustup update stable

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

10 ноября 2020 года произошло во многом эпохальное событие в индустрии микропроцессоров - компания Apple презентовала новый Mac Mini, главной фишкой которого являлся чип собственной разработки Apple M1. Данный процессор, без преувеличения, является знаковым достижением для экосистемы ARM - наконец-то был сделан чип, обошедший конкурентов из Intel в той нише, где архитектура x86 доминировала десятилетия.

Но для нас главным интересом является не сам процессор M1, а технология двоичной трансляции Rosetta 2, разработанная с целью запуска legacy x86 кода, не успевшего переехать на архитектуру ARM. Компания Apple имеет большой опыт в разработке решений по двоичной трансляции и является признанным лидером в данной области. Первая версия двоичного транслятора Rosetta появилась в 2006-ом году, когда помогла компании Apple совершить переход с архитектуры PowerPC на x86. И хотя в этот раз гостевая и целевая платформы отличались от тех, которые были в 2006-ом, очевидно, что весь опыт, накопленный инженерами Apple за эти годы, был учтён и вложен в следующую версию Rosetta 2. Тем интреснее было сравнить решение от Apple с аналогичным продуктом Huawei ExaGear (ведущего свою родословную от Eltechs ExaGear), разрабатываемого нашей командой. Заодно, мы оценили производительность двоичной трансляции из x86 в ARM от компании Microsoft (входящей в состав MS Windows 10 для Arm устройств) на лэптопе Huawei MateBook E. На текущий момент, это все известные нам решения по двоичной трансляции из X86 в ARM, доступные на широком рынке.

Данная статья содержит небольшое введение в JIT-компиляцию и .NET Core (отныне .NET 5, .NET 6 и так далее), а также несколько практических примеров ускорения запуска приложений на .NET. Данные советы могут быть полезны как для приложений, запускаемых на больших многоядерных x64 серверах, так и для приложений, запускаемых на ARM чипах с малым числом ядер. Например, подобные оптимизации используются в операционной системе Tizen, об этом далее.