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

Перед вами третья и заключительная часть саги про борьбу двух великих американских кремниевых компаний — Intel и AMD (первую и вторую часть читайте в нашем блоге). Каждая из них внесла свой неоценимый вклад в развитие процессорной индустрии и высоких технологий в целом. Если бы не они — кто знает, в каком мире мы жили бы сейчас. 

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

В 1970 году молодой швейцарский учёный и программист Никлаус Вирт (Niklaus Wirth) выпустил первую версию Pascal. Прошло более полувека, автор умер в 89 лет, а вот Паскаль остаётся актуальным и популярным языком программирования.

Существует довольно много распространённых «мудростей» о разработке игр на C++, различных обрядах и видах магии. И как это часто бывает с подобными сакральными знаниями, при внимательном осмотре - у части действительно есть право на жизнь, часть можно отправить в Каирский музей отбирать славу у мумий, а часть вообще оказывается родом из чужой реальности, и работать как предполагалось отказывается. Но это не мешает некоторым компаниям относиться к таким советам как к скрижалям, бережно принесённым с великой горы совещаний. Новым сотрудникам их передают почти с торжественностью обряда посвящения: «Так делали наши предки, так делаем и мы».

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

Когда-то давным-давно (то есть до C++20) мы форматировали вывод либо по-старинке через printf, либо используя громоздкие стримы ввода-вывода из <iostream>. Оба подхода, мягко говоря, не очень. printf работал шустро и лаконично, но требовал строгого соответствия типов, забудешь правильный %d или %s в формате, и получишь неопределённое поведение вплоть до падения программы. Компиляторы иногда предупреждают о несоответствиях, но полностью проблему не решают (особенно если форматируемая строка не литерал). Кроме того, printf не умеет выводить пользовательские классы, только примитивы.

Сейчас ситуация изменилась. В C++20 завезли библиотеку <format>, современный подход к форматированию строк, сочетающий лаконичность printf с безопасностью iostream. Инструмент называется std::format и объявлен в заголовке <format>. По сути, это адаптация популярной библиотеки fmt.

Привет, постоянные и не очень читатели!

Пора вернуться к моим любимым архитектурам, процессорам, техпроцессам и всему причастному. Это седьмой и САМЫЙ масштабный материал из цикла (и, вероятно, во всём Рунете) про китайские ISA, микроархитектуры и микроэлектронику.

Что было раньше:

Part I: Скандальное разоблачение x86: ARM врывается с двух ног (58K, +61, 160 комментариев)

Part II: Этой индустрии нужен новый герой: ARM врывается с двух ног 

Part III: Китайский киднэппинг: похищение дочки 

Part IV: RISC‑V — звезда родилась: x86 не у дел, ARM сломала две ноги (67K, +64, 207 комментариев)

Part V: Смерть GPU/CPU на транзисторах — архитектура квантовых компьютеров

Part VI: У VLIW длиннее x86: Itanium в шаге от величества, Эльбрус — подержите моё пиво, тайны PS2 

Part VII: Как китайцы убили x86, ARM и создали своё — детектив в Восточном экспрессе ← ВЫ ЗДЕСЬ

Part VIII — ██████████████.

В этом лонгриде я расскажу вам всё о серверных процессорах из Поднебесной на всех ключевых архитектурах: ARM (Huawei), x86 (Zhaoxin), RISC-V (T-Head) и LoongArch (Loongson). Будет и про строящиеся мегафабрики Huawei, и про создание независимой ISA (как наш Эльбрус, но с конкурентными продуктами и производством), и про китайские лицензированные x86-процессоры, и про многое другое.

Бонусом в каждом разделе распишу интересные факты про иероглифы в названиях компаний и их продуктах (символизм в китайской культуре). Например, вы узнаете, как компания Медоед куёт свои процессоры из легендарной стали (образно), чтобы бесстрашно сражаться с западными техногигантами (буквально). И это не шутка, а оммаж на мемы про медоедов.

Дамы и господа — Восточный экспресс готов к посадке. Пожалуйста, позвольте стюарду проводить вас к личному купе.

Недавно мы в Beeline Cloud поднимали тему забытых RFC из 90-х, а сегодня решили обсудить феномен текстовых игр. Кроме того, собрали руководства и веб-ресурсы, которые помогут запустить подобный проект или протестировать кастомные игры.

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

Немного разобрались, как добраться до PEB руками в IDA Pro и написали простейшее приложение для манипуляции аргументами в PEB.

Из новостей: Crystal Dynamics провела очередную волну сокращений, Valve представила новые железяки, движок Cocos купили за 72 млн долларов, Unreal Engine 5.7.

Из интересностей: у трупных забегов могут возникнуть проблемы, как устроены зеркала в Sims 4, в Donkey Kong Bananza лучший компаньон.

Начав знакомство с серией Fallout с ее первых частей, выход третьей вызвал во мне смешанные чувства. С одной стороны, это было захватывающее приключение от первого лица в мире любимой игры, с другой же проект ощущался для меня больше как шутер с элементами RPG, где от глубокой ролевой системы классики осталось не так много. И только с выходом New Vegas я наконец получил ту игру, которая по духу оказалась ближе всех к классическому Fallout — даже несмотря на то, что работала она всё на том же движке, что и «тройка».

Для подготовки этой статьи я перелопатил весь интернет в поисках редких фактов и комментариев людей, которые работали над New Vegas. Нашлись даже интервью на японском языке 🤯 — не говоря уже о множестве англоязычных материалов. Я постарался собрать из всего этого цельный, увлекательный текст, который не просто расскажет о создании игры, но и, надеюсь, пробудит у вас желание снова вернуться на Мохавскую пустошь. New Vegas — по-настоящему глубокая и многослойная игра, и мне искренне хочется, если не отправить вас туда лично, то хотя бы подарить повод поностальгировать и узнать что-то новое, читая мой свежий обзор. А в конце вас ждёт бонус: полностью готовая сборка игры с фанатской модификацией, чтобы вы могли сразу после прочтения отправиться навстречу приключениям!

Ошибки при составлении программ для ЭВМ появились даже раньше, чем были придуманы самые первые языки программирования. Собственно, языки программирования и были придуманы как раз для того, чтобы программы писались проще, а количество ошибок в них было как можно меньше.

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

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

В данной серии статей пойдёт речь о проекте собственного Personal-Document-Assistant (в дальнейшем буду округлять до КПК). Проект подразумевает открытые исходники, разборы, обсуждение и иное N-ное количество контента, поэтому рад приветствовать вас в этой истории.

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

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

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

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

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

Многие embedded-разработчики привыкли работать без автоматизированных тестов, полагаясь на ручное тестирование и отладку через программатор. Это кажется простым и быстрым решением для небольших проектов. Однако при росте кодовой базы и команды такой подход приводит к критическим проблемам: баги возвращаются в новых релизах, знание о системе хранится только в головах разработчиков, а каждое изменение требует длительного ручного тестирования на стенде.

Автоматизация CI/CD для embedded-систем решает эти проблемы, хотя требует начальных усилий на настройку инфраструктуры.

Данная статья является альтернативой hello-world в DirectX от Microsoft в связи с излишней перегрузкой терминами и не нужной информацией. Объяснение для новичков, просто и понятно.

Статья посвящена очереди сообщений окна в Windows. Рассматриваются все действия с нею. Статья предназначена в основном для новичков в DirectX & Direct2D.

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

— «О какой именно памяти мы говорим?»

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

Но есть и другая память. Та, что скрывается за сухой статистикой «количества одновременно играющих». За каждым мощным ПК, за каждым гигагерцем и терафлопсом сидит не просто железо. Там сидит человек. И эта статья — именно о нем. О человеке, чья память, в отличие от компьютерной, работает чуть менее предсказуемо. Она капризна, избирательна, подвержена эмоциям и легко может «зависнуть» от перегрузки. Но, не поверите... она все ещё достаточно предсказуема!

У нас была рабочая видеокарта, драйвер для нее, Linux, полный набор кода, который заставлял работать нашу видеокарту, возможно, была даже прошивка. Не то чтобы это был необходимый запас для запуска AMD GPU на ПЛИС с RISC-V. Но если начал запускать видеокарту на ПЛИСе с RISC-V Linux, становится трудно остановиться…

Вэтом тексте изложены базовые теоретические основы по CAN шине безотносительно к конкретному микроконтроллеру.

CAN — это двухпроводный, дифференциальный, последовательный, полудуплексный интерфейс для передачи бинарных данных между электронными платами (PCB). В качестве кабеля чаще всего применяют одну экранированную витую пару проводов с именами: CAN_L и CAN_H.

Зачастую, в проектах ограничивается использование препроцессора по следующим причинам:

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

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

Со всеми его недостатками, инструмент есть в языке и достоин изучения.