Первое знакомство с языком ассемблера

Мы, авторы канала, уверены, что сегодня в IT можно сделать карьеру, ни разу не столкнувшись с языком ассемблера. Разрабатывать на столь низком уровне приходится достаточно редко: даже разработчики операционных систем не каждый день сталкиваются с необходимостью писать ассемблерный код, хотя и должны хорошо понимать его — например, для работы в отладчике.

Как поступить, если хочется разобраться, что же такое ассемблер, но на полноценное погружение в низкоуровневое программирование для современных платформ нет времени? Здесь могут выручить ретро-платформы.

Хорошо подойдет процессор MOS6502, архитектура которого настолько примитивна, что освоить низкоуровневое программирование для него не будет сложным, даже если вы с этим никогда не сталкивались. Но, как говорится: «But you gotta focus!»

Поняв основные принципы — инструкции, регистры, косвенную адресацию, флаги, условные и безусловные переходы — вы сможете легче осваивать языки ассемблера и для современных архитектур вроде x86_64, ARMv8 или RISC-V.

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

6502 — очень важный процессор, сильно повлиявший на индустрию. Его «близкие родственники» работали в игровых приставках (Nintendo Entertainment System), домашних компьютерах (Commodore 64, Apple-II) и бытовой технике. Система команд этой серии настолько популярна, что до сих пор выпускаются совместимые с ней микроконтроллеры и процессоры.

#digest

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

Решили иногда делиться этими обсуждениями с вами. Что скажете?

#fun

Качественное программирование (robustness)

Наткнулись на старенькую статью старенького дяденьки Бишопа. Того самого профессора в UC Davis, который написал самую важную книгу по теоретической безопасности (толщиной всего-то в 1383 страницы). Статья небольшая и сугубо практическая, нацеленная на прокачку скилла robusntess.

На примере реализации очереди показано, что может поломаться, и как писать код, устойчивый против этих поломок. В несколько утрированно-параноидальном примере Бишопа куча проверок, но, как нам кажется, часть из этих проверок должна переехать с уровня кода на уровень архитектуры. Иначе каждый класс, каждая подсистема будут обречены строить свои системы контроля целостности. И эти системы будут либо неполны по числу проверок, либо раздуты по объему кода (либо раздуты и неполны). Ведь любые хранимые и передаваемые данные могут быть повреждены. Даже биты в памяти выпадают периодически, что уж говорить о файлах или о передаче по сети (не надейтесь на встроенные checksum-ы TCP 🙂).

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

#digest

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

Мы прошли бы мимо проекта ChrysaLisp, если бы судили только по названию. Сколько уже написано интерпретаторов различных диалектов Lisp — трудно подсчитать. Lisp-системами тоже никого не удивить, это давно пройденная страница истории. Но было в проекте что-то притягательное и мы решили разобраться. Не зря.

Автор проекта, Крис Хинсли (Chris Hinsley), планирует разработать распределенную операционную систему с современным графическим интерфейсом. Он начал с разработки 64-битной виртуальной машины для выдуманной архитектуры процессора VP64. Архитектура команд для этой машины построена так, чтобы легко транслироваться в код x86_64 и ARMv8. Далее был разработан язык похожий на ассемблер, но со скобочным синтаксисом, как в Lisp: на этом языке написаны примитивы низкого уровня. Поверх может запускаться код, созданный на более высокоуровневом языке, семантически близком к C, но тоже с lisp-подобным синтаксисом.

Пользуясь этими инструментами, Крис создал ОС, способную работать на нескольких распределенных в сети вычислительных узлах. Для системы написано множество приложений с довольно современным GUI, который работает благодаря гибкой объектной системе.

Есть в системе и интерпретатор более-менее традиционного Lisp, который может исполнять компиляторы более низкоуровневых языков, описанных двумя абзацами ранее. Таким образом, в окружении ChrysaLisp можно разрабатывать ChrysaLisp, оно полностью замкнуто (self-hosted).

Крис также планирует научиться запускать свою систему на голом железе и оценивает эту задачу как не очень трудную.

#digest

Хардкорные инструменты для WEB-разработки

Мы привыкли, что бэкенд для WEB пишут на высокоуровневых языках программирования со сборкой мусора: Python, Go, JavaScript, PHP, Java и других. Появляются новые фреймворки, упрощающие типовые задачи разработки и улучшающие безопасность решений, тулинг. Таким образом, WEB-бэкенд — отдельная область знания со своей экосистемой, стандартами, типовыми языками и инструментами.

Но возможно ли разработать относительно безопасное WEB-приложение с использованием таких хардкорных инструментов, как язык C? Ответ на этот вопрос в полушутливой форме дает Кристапс Джонсонс (Kristaps Dzonsons).

Кристапс предлагает использовать стек технологий под названием BCHS: BSD, C, httpd, SQLite. Наверняка в названии вы уловили шутливую аналогию с LAMP: Linux, Apache, MySQL, PHP. Но подождите, разве C подходит для таких задач? WEB-приложения оперируют множеством строк (например, JSON объектами), а в этом язык C не слишком хорош — сказывается ручное управление памятью. Более того, чтобы разработать действительно безопасное приложение на C, требуется серьезная инженерная дисциплина, большой опыт системной разработки и глубокое знание стандарта языка — статический и динамический анализ способны отловить далеко не все ошибки и уязвимости.

Для достижения такой, казалось бы, странной цели, Кристапс предлагает использовать метод разработки, похожий на Secure by design. Его подход подразумевает разбиение приложения на независимые процессы, общающиеся через примитивы межпроцессного взаимодействия. При этом, привилегии этих процессов сбрасываются ровно до того уровня, который необходим им для функционирования. OpenBSD позволяет строить такие решения благодаря системным вызовам pledge и unveil. FreeBSD же предоставляет гибкий механизм Capsicum.

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

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

#digest

🧭 Как пользоваться каналом Just Code IT?

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

#digest — разбор механизмов, методов, проектов, фичей, форматов, стандартов и конечно кода.

#literature — заметки, статьи и книги, а также гайды; короче говоря, чтиво, которое научит полезным приёмам или сподвигнет на большие свершения.

#fun — забавные моменты, скрашивающие нашу рабочую жизнь: ролики, игры, технические флэшбеки из детства и скрины из наших рабочих чатов =)

Высокоуровневое программирование на C

Мы, авторы канала, любим системное программирование, и хорошо знакомы с языком C. Этот язык — один из наших основных инструментов. А инструменты должны соответствовать задачам: мало кто забивает гвозди микроскопом или использует гвоздодер в качестве прецизионного экстрактора SMD-элементов. Тем не менее, иногда хочется использовать знакомый инструмент даже в тех областях, для которых он мало подходит.

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

Таким образом, на C становится удобно писать небольшие «скрипты» для автоматизации повседневных задач.

Использовать ли эту необычную библиотеку в продакшне? Решать вам.

#digest

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

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

Баллада об неинициализированных переменных

Использование неинициализированных переменных — очевидно грустная тема. С одной стороны, это угроза безопасности (можно подстроить стек или кучу таким образом, чтобы без инициализации использовались вредоносные значения). С другой стороны, это угроза надежности/стабильности работы — в неинициализированных данных может оказаться все что угодно и это «что угодно» будет меняться от запуска к запуску, от платформы к платформе. Про запрет на использование неинициативных переменных говорят стандарты (ISO26262-6-6.1c, SEI CERT), компиляторы помогают нам найти подобные опасные места (gcc -Wuninitialized -Wgnu-empty-initializer). Статические анализаторы тоже поддерживают эстафету (раз и два).

Но почему ж такое до сих пор встречается в коде? Да потому что вопрос «а как надо?» до сих пор не решен. Ясно, что разнесение декларации от инициализации создает пространство для внесения ошибки. Можно оставить переменную в начале блока, но там не всегда известны правильные значения инициализации (а забивание переменной «мусором» скроет от компилятора потенциальное нарушение бизнес логики).

Можно объявить по месту, но тут мы встаем на скользкую тропку in-place initialisation and against holy war, а это уже война Сишников против Плюсовиков, для которых RAII является естественным. Можно дробить на микро-блоки/микро-функции, так чтобы объявление шло рука об руку с инициализацией и было осмысленным, но тут уже вкусовщина и снижение читаемости через излишне высокую гранулярность функций.

Так что же в итоге? А нет однозначного ответа! Не используйте неинициализированные переменные и пишите красивый код, как бы эта красота не была хрупка…

#digest

Еще немного из нашего внутреннего чатика. В канун пятницы дошли до обсуждений об архитектуре пива в Haskell :)

#fun

Базовые концепции информатики

Обнаружили прелюбопытнейший сайт, охватывающий массу тем, на которые необходимо обратить внимание современному программисту.

Автор начинает с архитектуры компьютера: представления чисел, понятий процессора и инструкций, описания типичных пайплайнов, иерархии памяти, кэшей и шин, а затем на примере Unix объясняет такие понятия, как многозадачность, системные вызовы, привилегированный режим ядра, процессы, динамическая компоновка, виртуальная память…

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

Кстати, вот здесь выложена офлайн-версия в формате PDF.

#literature

Есть у нас тут менеджеры? Хотите назад на ветку? :)

#fun

Обучение детей программированию

Обучать ли детей программированию, и если да, то когда начинать? А главное как это делать?

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

Совсем необязательно сажать чадо за компьютер — возможно начать обучение вообще без контакта с машиной. Например, существуют карточные настольные игры, способные познакомить ребенка с работой Unix-шелла, или с низкоуровневым программированием. Существуют выдуманные процессорные архитектуры, специально спроектированные для изучения системного программирования на бумаге, например WDR Paper Computer. Любители низкого уровня наверняка оценят детские раскраски, позволяющие моделировать логику на основе NOR вентилей, а приверженцы функционального стиля обрадуются, что смогут обучить чадо основам лямбда-исчисления на основе «Alligator Eggs Puzzle Game».

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

Есть специальные среды для детского программирования. Наиболее популярная такая среда — Scratch. Здесь можно создавать игры и симуляции на императивном языке программирования.

Много хороших сред с низким порогом входа существует для Lua: одна из наиболее популярных — среда для iPad под названием Codea. Она позволит начинающим программистам достаточно быстро начать создавать простые игры и симуляции. Вдохновившись Codea, автор Redis Сальватор Санфилиппо разработал простую открытую среду load81 именно с целью обучения детей программированию.

Кстати, благодаря простоте освоения Lua появилось множество фентезийных консолей — симуляторов игровых платформ, которых никогда не существовало. Для этих игровых платформ можно разрабатывать игры в довольно простых и понятных для юных разработчиков средах. Самая популярная фэнтези-консоль — PICO-8. Для нее уже создано множество игр, но каждый пользователь может создать что-то свое благодаря встроенным средствам разработки. PICO-8 стоит денег, но есть множество открытых аналогов, например суперпопулярная TIC-80. В качестве более серьезной платформы для программирования на Lua можно рассмотреть LÖVE 2D и ZeroBrane Studio.

Ну и всегда в топе остаются реализации нестареющей классики, языка LOGO.

Мы уверены, что в этом обзоре перечислены далеко не все способы, что могут заинтересовать чадо программированием :)

Пишите ваши варианты/лайфхаки в комментариях.

#digest

Логические схемы на… пайпах

Наверняка многие из читателей используют какой-либо вариант Unix: MacOS, GNU/Linux или, например, OpenBSD. Даже MS Windows предоставляет возможность пользоваться благами Unix-мира через WSL.

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

Сама идея пайпов и комбинирования небольших программ принадлежит Дугласу Макилрою (Douglas McIlroy) — одному из авторов Unix.

Все мы используем этот простой механизм, но осознаем ли до конца его возможности? Лайнус Акессон (Linus Åkesson) нашел пайпам очень необычное применение.

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

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

#digest