Системное программирование *

В прошлой статье мы выяснили, что кэш — это безусловно полезная штука, но применительно к контроллерной логике он иногда создаёт трудности. В частности, он вносит непредсказуемость длительности импульсов либо иных задержек при программном формировании временных диаграмм. Ну, и в «общепрограммистском» плане, неудачное расположение функции может свести выигрыш от кэша на нет, постоянно провоцируя его перезагрузку из медленной памяти. Я упоминал, что 15 лет назад мы вынуждены были делать специальный препроцессор, который устранял возникающие проблемы для процессора SPARC-8, и обещал, что расскажу, как легко устранить подобные трудности при разработке для синтезированного процессора Nios II, рекомендуемого для использования в комплексе Redd. Пришла пора выполнить обещание.

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

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

Что-то я буду описывать своим языком.

Пришло время написать первую отдельную программу для нашего ядра — оболочку. Она будет храниться отдельным .elf файлом и запускаться init процессом при старте ядра.

Это последняя статья из цикла по разработке своей операционной системы.

В предыдущей статье мы ввели многозадачность. Сегодня пришло время рассмотреть тему драйверов символьных устройств.

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

Начнем с создания структуры устройства, затем введем базовую поддержку файлового ввода-вывода, рассмотрим структуру io_buf и функции для работы с файлами из stdio.h.

Завкафедрой системного программирования Матмеха СПбГУ, профессор, доктор физмат наук, президент компании «Ланит-Терком» Андрей Николаевич Терехов — о том, как делал первый в СССР транслятор языков Алгол 68 и Ада, о силе обкома КПСС и рождении «Самсона», который никогда не ломался.

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

В предыдущей статье мы рассмотрели основы работы в защищенном режиме IA-32. Сегодня пришла пора научиться работать с виртуальным адресным пространством.

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



Про оптимизацию изданы толстые книжки. Часть этих книжек полезна, часть уже устарела, так как описанные в них принципы давно перекочевали на этап автоматической оптимизации при сборке кода… Но существуют некоторые вещи, которые не имеют никакой ценности при разработке обычных программ под обычные процессоры, поэтому в типовых книжках обычно не описывается. Их мы сейчас и начнём рассматривать.

О чем эта статья

Продолжаем цикл статей о ShIoTiny — визуально программируемом контроллере на базе чипа ESP8266.

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

Сайт проекта ShIoTiny

Предыдущие статьи серии.

ShIoTiny: малая автоматизация, интернет вещей или «за полгода до отпуска»

ShIoTiny: узлы, связи и события или особенности рисования программ

ShIoTiny: вентиляция влажного помещения (проект-пример)

ShIoTiny и окружающий мир: подключение датчиков к бинарным входам, дребезг контактов и другие вопросы

ShIoTiny и окружающий мир: аналоговые датчики или АЦП для самых маленьких

Бинарные прошивки, схема контроллера и документация

В предыдущей статье мы с вами реализовали менеджер динамической памяти.
Сегодня мы рассмотрим основы работы в защищенном режиме процессора Intel i386.
А именно: глобальную таблицу дескрипторов и таблицу векторов прерываний.

Каждый уважающий себя программист хотя бы раз в жизни хотел придумать свой язык программирования – и сделать для него компилятор.

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

А если хочется конструировать компиляторы в своей профессиональной деятельности? Надо сказать, это действительно редкая профессия, можно даже сказать, элита программистского сообщества. Чтобы «с нуля» разработать компилятор хотя бы для весьма компактного и простого языка программирования, требуется знакомство с внушительным пластом математических оснований – теорией формальных грамматик, алгоритмами над деревьями и графами, механизмами оптимизационных преобразований – а также освоение богатого практического опыта реализации компиляторов, накопленного за несколько десятков лет.

Кому требуются специалисты этой редкой профессии? Основные работодатели – это крупные международные компании, производители вычислительной техники. И современные теоретические и практические знания по созданию компиляторов сосредоточены именно там.
Исследовательский Центр Samsung в Москве одно из таких редких мест, и мы предлагаем осуществить мечту о собственном работающем компиляторе, поступив на программу Samsung Compiler Bootcamp.



Подробности читайте под катом.

Не смогли пройти мимо и перевели ко Дню программиста комикс Джулии Эванс об утилите Strace. Полезный инструмент, который помогает отслеживать системные вызовы и доставку сигналов между процессами и ядром Linux. Читайте и вдохновляйтесь. С наступающим, друзья!

С 21 по 25 августа в Германии проходил крупнейший хакерский фестиваль Chaos Communication Camp.

Он организуется каждые четыре года, и, как в предыдущий раз, площадкой для проведения стал индустриальный парк Ziegeleipark Mildenberg. Это крупная старинная фабрика по производству кирпичей с узкоколейной железной дорогой и речным портом, которая превращена в музей под открытым небом. И в этом удивительном месте на пять дней собрались более 5000 хакеров со всего света, которые неузнаваемо преобразили Ziegeleipark.

Предлагаю вам обзор докладов CCCamp 2019, которые мне особенно понравились.

Пьяный программист сидит с открытым Norton Commander на экране. На обоих панелях открыт диск С. «Ну и зачем мне два диска С с одними и теми же файлами?» — подумал он и стер все его содержимое, нажав F8 и Enter.

— анекдот конца 80-х годов

Нортон (Norton Commander) for DOS – это файловый менеджер для DOS, который существовал в 5 основных версиях – 1.0, 2.0, 3.0, 4.0, 5.0, причем только последняя версия имеет подверсию 5.5. Многие версии до сих пор используются различными энтузиастами и лежат на различных сайтах по сети Интернет.

Это был, возможно, один из самых популярных файловых менеджеров в эпоху операционной системы DOS, который наряду с XTree порвал со своими корнями DOS и в виде других программ, унаследовавших его функциональность, которые существуют на других операционных системах.

В предыдущей статье мы с вами реализовали системный журнал ядра. Теперь пришло время реализовать менеджер динамической памяти.

В предыдущей второй по счету статье мы с вами разработали необходимые функции для работы со строками из библиотеки С. В этом уроке мы реализуем полноценный отладочный вывод на экран — системный журнал ядра.

В предыдущей статье мы научились запускать Hello World ядро и написали пару функций для работы со строками. Теперь пришло время расширить библиотеку С чтобы можно было реализовать kprintf и другие необходимые функции. Поехали!

В связи с отрицательными отзывами пробной статьи «Разработка микроядерной Unix подобной OC — планировщик» я решил перезапустить серию статей с учетом некоторых замечаний. Теперь, осознав свою целевую аудиторию, я смог сместить фокус с подобных себе на тех кому это действительно нужно.

.NET – управляемая среда выполнения. Это означает, что в ней представлены высокоуровневые функции, которые управляют вашей программой за вас (из Introduction to the Common Language Runtime (CLR), 2007 г.):

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

1. Основные функции, которые влияют на устройство других. К ним относятся:
   1. сборка мусора;
   2. обеспечение безопасности доступа к памяти и безопасности системы типов;
   3. высокоуровневая поддержка языков программирования.
2. Дополнительные функции– работают на базе основных. Многие полезные программы обходятся без них. К таким функциям относятся:
   1. изолирование приложений с помощью AppDomains;
   2. защита приложений и изолирование в песочнице.
3. Другие функции – нужны всем средам выполнения, но при этом они не используют основные функции CLR. Такие функции отражают стремление создать полноценную среду программирования. К ним относятся:
   
   1. управление версиями;
   2. отладка/профилирование;
   3. обеспечение взаимодействия.

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

Основным требованием при разработке Nucleus SE была высокая степень совместимости с главным ОСРВ-продуктом Mentor – Nucleus RTOS. Nucleus SE поддерживает определенную часть функционала Nucleus RTOS, о чем много раз говорилось в предыдущих статьях, однако в этой статье я постараюсь собрать все ключевые отличия в одном месте. Данная статья задумывалась как краткий справочник для всех, кто собирается переходить с одного ядра на другое, либо находится в процессе выбора ядра для определенного проекта.



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

В Nucleus RTOS система может быть создана с неопределенным количеством объектов ядра, единственным ограничением здесь выступает количество доступных ресурсов (то есть памяти). Nucleus SE имеет ограничение в шестнадцать объектов каждого типа; система может иметь от одной до шестнадцати задач и от нуля до шестнадцати объектов каждого типа (почтовые ящики, очереди и т.д.). Несмотря на то, что этот лимит может быть увеличен, потребуются значительные усилия, так как в Nucleus SE широко используется возможность хранения индекса объекта в полубайте (четыре бита). Кроме того, при более чем шестнадцати задачах планировщик приоритетов (Priority), скорее всего, станет очень неэффективным. Приложение, функционал которого серьезно страдает от данных ограничений, не подходит для Nucleus SE, в данном случае Nucleus RTOS является гораздо более подходящим выбором.