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

Я не буду говорить про остальные затрагивающие память команды (то есть, благодаря CISC, почти все остальные), команды которые пишут массивные фрагменты памяти (это о тебе, fxsave), или иные касающиеся темы вопросы (модели кода, независящий от адреса код, и бинарная релокация). Я также не буду затрагивать исторические режимы адресации или режимы, которые активны при работе процессора x86_64 не в 64-битном режиме (т.е. любые отличные от long mode с 64-битным кодом).

Некоторые ограничения

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

Начнем с хорошего:

• На достаточно высоком уровне в архитектуре х86_64 есть всего два режима адресации.
• Все регистры в обоих режимах адресации должны быть строго одинакового размера. Другими словами, мы не можем странным образом смешивать 64, 32 и 16-битные регистры и получать актуальный адрес — в кодировании х86_64 для подобного маневра попросту нет места.

Я хотел бы рассказать о том, как я писал реализацию «Hello, World!» на C. Для подогрева сразу покажу код. Кого интересует как до этого доходил я, добро пожаловать под кат.

#include <stdio.h>
const void *ptrprintf = printf;
#pragma section(".exre", execute, read)
__declspec(allocate(".exre")) int main[] =
{
    0x646C6890, 0x20680021, 0x68726F57,
    0x2C6F6C6C, 0x48000068, 0x24448D65,
    0x15FF5002, &ptrprintf, 0xC314C483
};

Случилось так, что пришлось мне писать с нуля драйвер для usb дисплея под windows. Имея возможность — расскажу о деталях столь занимательного процесса.

USB – это simple

Несмотря на то, что написание драйверов считается достаточно трудным, в сравнении с прикладным программированием – и в этом низкоуровневом мире программисты не были обделены вниманием, большим шагом в упрощении создания драйверов стала разработка шины usb.
Итак, почему же шина usb так удобна, и что скрывает за собой слово Universal в расшифровке аббревиатуры.

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

На данный момент, большинство радиолюбителей реализуют такой тип подключения используя чипы переходники USB в RS232 таким образом организуя связь со своим устройством посредством драйвера виртуального COM порта поставляемого с чипом переходником. Минусы такого подхода думаю понятны. Это как минимум лишний чип на плате и ограничения накладываемые этим чипом и его драйвером.
Мне же хочется осветить весь процесс организации такого взаимодействия так как оно и должно быть сделано, и как делается во всех серьезных устройствах.
В конце концов, сейчас 21-й век, модуль USB есть почти во всех микроконтроллерах. Именно о том, как наиболее быстро воспользоваться этим модулем и будет эта статья.

Представим типичную ситуацию на первом курсе: вы прочитали про алгоритм Диница, реализовали, а он не заработал, и вы не знаете, почему. Стандартное решение — это начать отлаживать по шагам, каждый раз рисуя текущее состояние графа на листочке, но это жутко неудобно. Я попробовала исправить положение в рамках семестрового проекта по Software Engineering, а в посте расскажу, как у меня в итоге получился плагин для Visual Studio. Скачать можно тут, исходный код и документацию можно посмотреть тут. Вот скриншот графа, который получился для алгоритма Диница.

Вместо предисловия

Допустим, сидя вечерком в теплом кресле вам вдруг пришла в голову шальная мысль: «Хм, а почему бы мне вместо случайного подбора гиперпараметров модели не узнать, а почему оно всё работает?»

В Древнем Египте математики не пользовались доказательствами. Все их утверждения были лишь эмпирически обоснованы. Но тем не менее, пирамиды стояли, а самолеты летали. И, наверное, никто бы и не требовал строгих доказательств, если бы не желание что-то опровергнуть. Вместе с греками математика обрела новую жизнь, в которой появились такие задачи, как квадратура круга, иррациональность корня из двух и задача о трисекции угла. С этого момента потребовались аксиомы, законы логики и теоремы. Современную же математику интересует еще и то, что возможно доказать, а что — нет. Продвижением стали теоремы Геделя о неполноте, формализация логики и Теория доказательств. Я предлагаю теорию и одну аксиому, которая поможет ответить на часть оставшихся вопросов и обозначить границы нашего сознания. В частности, это вопросы полноты, проблема равенства и аксиоматизация нашего воображения.

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

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

В современном цифровом мире необходимость ЦАП/АЦП (цифро-аналоговых преобразователей/аналого-цифровых преобразователей) не подвергается сомнению: они используются для обработки сигналов разнообразных датчиков, в звуковой аппаратуре, ТВ-тюнерах, платах видеовхода, видеокамерах и т.д.

Однако использование или отладка ЦАП/АЦП могут быть затруднены поставленными производителем аппаратуры ограничениями, например, на используемое ПО или на способы управления устройством. Это наводит на мысль о проектировании собственной модели взаимодействия.

В этой статье мы рассмотрим возможность организации взаимодействия между ПК и ЦАП/АЦП при помощи ПЛИС.

Немного теории

Цифровой автомат (ЦА) — это устройство, которое осуществляет прием, хранение и преобразование дискретной информации по некоторому алгоритму и может находиться в одном из нескольких устойчивых состояний [7].



Рисунок 1 — Граф цифрового автомата

Технология FPGA (ПЛИС) в настоящее время обретает большую популярность. Растёт количество сфер применения: помимо обработки цифровых сигналов, FPGA используются для ускорения машинного обучения, в blockchain технологиях, обработке видео и в IoT.

Данная технология имеет один существенный минус: для программирования используются довольно сложные и специфичные языки описания цифровой аппаратуры Verilog и VHDL. Это осложняет вхождение новичка в FPGA и для работодателя найти специалиста с этими специфичными знаниями на рынке труда сложно. С другой стороны популярный высокоуровневый язык программирования Python с фреймворком MyHDL делают программирование FPGA простым и приятным. Тем более людей знающих Python на порядок больше специалистов владеющих Verilog/VHDL. Серией статей я хочу показать как легко и просто войти в область FPGA зная Python и начать делать настоящие сложные FPGA проекты на этом языке. Отмечу, что на ПЛИС python непосредственно не исполняется, а является инструментом для генерации прошивки.

В продолжение к первой статье, хочу на примере показать вариант работы с FPGA (ПЛИС) на python. В данной статье затрону подробнее аспект тестирования. Если фреймворк MyHDL позволяет людям, работающим на python, используя знакомый синтаксис и экосистему, заглянуть в мир FPGA, то опытным разработчикам ПЛИС смысл использования python не ясен. Парадигмы описания аппаратуры для MyHDL и Verilog похожи, а выбор в пользу определенного языка вопрос привычки и вкуса. За Verilog/VHDL выступает то, что на этих языках давно пишут прошивки, и по факту они являются стандартными для описания цифровой аппаратуры. Python, как новичок в этой сфере, может конкурировать в области написания тестового окружения. Значительную часть времени у FPGA разработчика занимает тестирование своих дизайнов. Далее я хочу на примере продемонстрировать как это делается в python с MyHDL.

Допустим, есть задача описать на ПЛИС некое устройство, работающее с памятью. Для простоты возьму память, общающуюся с другими устройствами через параллельный интерфейс (а не через последовательный, например I2C). Такие микросхемы не всегда бывают практичны в виду того, что для работы с ними требуется много пинов, с другой стороны обеспечивается более быстрый и упрощенный обмен информации. Например отечественная 1645РУ1У и ее аналоги.

Собственный софт-процессор на ПЛИС с компилятором языка высокого уровня или Песнь о МышЕ — опыт адаптации компилятора языка высокого уровня к стековому процессорному ядру.

Распространенной проблемой для софт-процессоров является отсутствие средств разработки для них, особенно, если их система команд не является подмножеством команд одного их популярных процессорных ядер. Разработчики в этом случае вынуждены будут решать эту проблему. Прямым её решением является создание компилятора языка ассемблера. Однако в современных реалиях не всегда удобно работать на Ассемблере, так как в процессе развития проекта может изменяться система команд в связи, например, с изменившимися требованиями. Поэтому задача легкой реализации компилятора языка высокого уровня (ЯВУ) для софт-процессора является актуальной.

Компилятор языка Python — Uzh представляется легким и удобным инструментарием для разработки программного обеспечения для софт-процессоров. Инструментарий определения примитивов и макросов как функций целевого языка позволяет критичные места реализовывать на ассемблере процессора. В данной работе рассмотрены основные моменты адаптации компилятора для процессоров стековой архитектуры.

Введение

Знакомый многим интерфейс PCI Express или PCIe был доступен разработчикам систем на ПЛИС уже тогда, когда он только начинал распространяться в цифровой технике. В это время существовало решение, в котором программное ядро подключалось ко внешней микросхеме физического уровня [5]. Это позволяло создавать одноканальную линию PCIe со скоростью 2,5 гигатранзакций в секунду. В дальнейшем, благодаря развитию технологий, физический уровень интерфейса перекочевал в аппаратные блоки PCIe внутри самих ПЛИС; количество возможных каналов увеличилось до 8, а в ряде новых микросхем — и до 16; вслед за современными стандартами выросли возможные скорости передачи данных.

В то же время, в русскоязычных источниках по-прежнему затруднительно найти вспомогательные материалы по работе с аппаратными ядрами современных ПЛИС, не так и много информации доступно по самому интерфейсу PCIe. Руководство к аппаратным ядрам PCI Express подразумевает, что разработчик уже ознакомился со стандартом и понимает основы передачи данных между устройством и персональным компьютером (ПК). Однако обилие информации в самом стандарте PCIe не дает сразу же разобраться в том, какие шаги необходимо предпринять, чтобы успешно передать данные от устройства в память ПК или обратно. Чтобы получить более полную картину, немалую часть сведений приходится собирать по крупицам из разных источников. Для разработчиков систем на ПЛИС фирмы Intel сложность также заключается в том, что большинство доступных материалов и статей описывают работу с аппаратными ядрами ПЛИС фирмы Xilinx.

В данной статье автор постарается рассказать о том, что необходимо знать разработчику систем на ПЛИС для работы с интерфейсом PCI Express; рассмотрит особенности работы с аппаратными ядрами PCI Express ПЛИС V-й серии фирмы Intel в варианте Avalon-ST.

Меня всегда интересовала цифровая схемотехника, а в частности языки описания аппаратуры — HDL. У меня давно лежала в списке будущего чтения книга Дэвида М. Хэррис и Сары Л. Хэррис «Цифровая схемотехника и архитектура компьютера», воспользовавшись свободным временем на самоизоляции, я добрался до этой замечательной книги. В процессе чтения я столкнулся с некоторыми трудностями, а в частности, как именно писать и отлаживать код в Quartus Prime. В процессе поисков мне очень помог сайт marsohod.org, но вот процесс симуляции схемы на этом сайте описан с использованием встроенных средств Quartus и в современных версиях программы, этих встроенных средств нет и необходимо использовать ModelSim. Чтобы как-то систематизировать те знания, которые я получил, используя Quartus и ModelSim, я решил написать эту статью. В процессе этой статьи я в качестве примера разберу задачу из книги Дэвида М. Хэррис и Сары Л. Хэррис «Цифровая схемотехника и архитектура компьютера», а конкретно задачу 3.26 про автомат газированной воды. На протяжении статьи я покажу, как установить Quartus, создать проект, написать код и произвести его симуляцию. Всем кому это будет интересно, добро пожаловать под кат.

Здравствуйте. Эта статья написана для самых-самых новичков в мире ПЛИС, которые пока что совсем не знают что такое STA (static timing analysis). В ней я попытаюсь максимально просто и наглядно рассказать что такое временны́е ограничения (timing constraints), накладываемые на проекты под ПЛИС.

Статья создана на основе собственного опыта попыток объяснить самому себе, студентам-практикантам и любопытным коллегам эту тему так, чтобы не погружаться в заумные академические дебри, а максимально просто и прозрачно, бытовым языком. Я учился работать с ПЛИС без учебы и подготовки по этой теме и знаю по своему опыту насколько трудно что-то понять не имея теоретического базиса в этой теме и в схемотехнике. Для опытного плисовода описанное — элементарно. Но для какого-нибудь студента четвертого курса статья будет полезной и поможет разобраться во всех этих слэках, сетапах и холдах.

Всем привет!

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

В этой статье показана невозможность реализации «классической» схемы очень длинного БПФ даже на самых современных кристаллах ПЛИС и предложен алгоритм, позволяющий это сделать. Также пошагово рассмотрена основная идея алгоритма: от математической составляющей до создания законченного решения на базе ПЛИС с использованием внешней DDR-памяти. Статья затронет тонкости проектирования многоканальных систем обработки для подобного класса задач и, в частности, опишет мой практический опыт.

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

Символы должны быть каким-то образом закодированы в биты. Большинство строк в интернете, включая этот пост на Хабре, закодированы в UTF-8. Формат UTF-8 представляет «символы» в одном, двух, трёх или четырёх байтах. Это обобщение для стандарта ASCII, использующего только один байт на символ. То есть строка ASCII также является строкой UTF-8.

На самом деле всё немного сложнее, потому что технически UTF-8 описывает кодовые точки. Видимый символ типа эмодзи может состоять из нескольких кодовых точек… но большинству программистов эти педантичные формулировки не нужны.

Привет, Хабр.

Данный текст можно считать продолжением статьи "Разбираем звук Dial-up модема", в которой разбирался метод установки связи между модемами. Сегодня мы пойдем дальше, и посмотрим на практике как передаются данные, для чего создадим простую реализацию модема с помощью OFDM и GNU Radio.

Данные мы будем передавать по воздуху, в прямом смысле этого слова — для приема и передачи будет достаточно динамика и микрофона.

Для тех, кому интересно как это работает, продолжение под катом.