Меня всегда интересовало, как же реализуются видеоадаптеры и искал примеры как их можно реализовать. Я много занимаюсь разной разработкой, в основном программированием, но периодически вспоминаю радиотехнику/схемотехнику. И, исходя из опыта программирования и не только я вспомнил об одной достаточно важной вещи: если хочешь что‑то реализовать, начни с самого простого и потом дорабатывай полученный результат. Таким образом можно будет понять, что же мы всё‑таки хотим сделать и правильным ли путём идём?

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

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

Предлагаем вашему вниманию интересную историю о поиске бага внутри анализатора PVS-Studio. Да, мы тоже допускаем ошибки, но мы готовы засучить рукава и залезть в самую глубину "кроличьей норы".

Небольшое предисловие

Наш коллега уже рассказывал про нашу техническую поддержку. Но всегда интересно послушать какие-то истории, и они у нас есть.

Если хочется программистской жести, то можете сразу переходить к следующему разделу. Если же хочется в целом познакомиться, как мы работаем, то продолжайте читать :). Также вы можете посмотреть юмористический доклад о поддержке С++ программистов.

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

ISO26262 это международный текст, который объясняет как создавать безопасный и высоконадежный встраиваемый софт для мотоциклов, автомобилей, грузовиков и автобусов.

В этом тексте я попробовал разобраться с тем как понять автомобильный стандарт функциональной безопасности ISO26262 в той части, которая относится к требованиям к программному обеспечению (часть 6).

-----

Ядро Linux часто упоминают как ужасно масштабное опенсорсное ПО. На момент написания этой статьи последняя версия 6.5-rc5 состоит из 36 миллионов строк кода. Не нужно говорить, что Linux — это плод упорного многолетнего труда множества участников проекта.

Однако первая версия Linux, v0.01, была довольно маленькой. Она состояла всего из 10239 строк кода. Если исключить комментарии и пустые строки, то остаётся всего 8670 строк. Это достаточно малый объём для анализа и хорошее начало для изучения внутренностей ядер UNIX-подобных операционных систем.

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

Я - автор двух пакетов, входящих более-менее во все дистрибутивы Linux: sane-airscan и ipp-usb.

Кроме того, sane-airscan входит во все основные дистрибутивы BSD (FreeBSD, NetBSD и OpenBSD) и в ChromeOS. ipp-usb в ChromeOS не взяли потому, что он написан на Go, а у них там очень жестко с размером исполняемых файлов, вместо этого они написали свое на Rust, но предпочли бы взять моё изделие, если бы могли. Совсем недавно появился порт ipp-usb на FreeBSD, вероятно, другие BSD тоже скоро подтянутся.

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

Кроме того, ipp-usb делает возможным "бездрайверную" печать на USB-устройствах.

Здесь я хочу рассказать, каково оно, быть автором популярных OpenSource пакетов. Хоть эта работа и не принесла мне особых денег (на что я, впрочем, особо и не рассчитывал), она принесла мне бесценный опыт.

В целом, я полагаю, продвижение OpenSource пакетов структурно близко к продвижению на рынок программных продуктов. Занимаясь этой деятельностью, очень хорошо начинаешь понимать разницу между (1) написать программу, которая работает для меня (2) написать программу, которую можно назвать продуктом (3) вывести продукт на рынок.

Первое занимает гораздо меньше времени, чем второе. Второе - гораздо меньше времени, чем третье.

Нам подвернулась возможность провести небольшое, но крайне интересное тактическое учение

Я работаю проектировщиком аппаратного блока графического процессора в телефонах Samsung, в рамках совместного проекта с AMD. Сейчас наш менеджмент расширяет команду и поощряет инженеров распостранять информацию о новых позициях среди своих знакомых. Я решил написать это пост для более широкой аудитории, так как множество людей, способных пройти интервью на RTL или DV позицию - больше, чем множество моих знакомых. Если вы сможете прислать мне ответ на задачку в моем посте вместе с вашим резюме, я перешлю его нанимающему менеджеру и рекрутеру нашей группы (в комментах прошу ответ не писать). Если резюме им понравится, вам нужно будет пройти стандартное собеседование на несколько часов, с несколькими инженерами, у каждого из которых свой набор задачек.

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

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

Ключевые идеи

• Прогресс программного обеспечения может стимулировать архитектурные инновации
  
• Повышение уровня программно-аппаратных интерфейсов создаёт возможности для инноваций архитектуры
  
• Рынок в конечном итоге определяет победителя в споре архитектур

Введение от автора поста

Какой Вы используете инструмент тестирования?

Вы не сможете оценить инструмент тестирования, прочитав его спецификацию

"No matter how hard you try, you can't make a racehorse out of a pig. You can, however, make a faster pig" (комментарий в исходном коде Емакса)

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

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

Виртуальные машины языков программирования в последние десятилетия получили весьма широкое распространение. С презентации Java Virtual Machine во второй половине 90-х прошло уже достаточно много времени, и можно с уверенностью сказать, что интерпретаторы байт-кодов — не будущее, а настоящее.

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

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