Рубрика «системное программирование» - 64

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

На этот раз я хочу подойти к вопросу планирования с другой стороны. А именно, теперь я постараюсь рассказать про планирование не потоков, а их “младших братьев”. Так как статья получилась довольно объемной, в последний момент я решила разбить ее на несколько частей:

  1. Многозадачность в ядре Linux: прерывания и tasklet’ы
  2. Многозадачность в ядре Linux: workqueue
  3. Protothread и кооперативная многозадачность

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

Рассказывать я постараюсь подробно, описывая основное API и иногда углубляясь в особенности реализации, особо заостряя внимание на задаче планирования.
Читать полностью »

В последнее время все более активно развивается тематика встроенных (embedded) систем и многие крупные компании такие как Google, Microsoft, Intel вкладывают огромные ресурсы в исследования и разработки в данной области. Взять, например, проект Майкрософт по созданию специализированной ОС для умных домов homeos или процессоры от Intel для встроенных решений Intel Quark, а о различных исследовательских проектах от Google по робототехнике и говорить не стоит, они и так на слуху.

Подобные системы всегда имели свои особенности: ограниченность вычислительных ресурсов, различные процессорные архитектуры, порядок байт и многое другое. Всё это накладывает отпечаток на процесс разработки встроенного ПО. Несмотря на то, что в последнее время для создания встроенных систем все чаще применяются принципы и технологии из области “обычных” десктопных систем, сам процесс остается специфичным. Поэтому считается, что порог вхождения при разработке системного и встроенного ПО очень высокий. Для подготовки хороших специалистов в этой области на Мат-Мехе СПбГУ организовали исследовательский проект по созданию ОС реального времени для встроенных применений Embox, в котором активную роль играют студенты.

[Питер] Встреча с техлидом OpenSource ОС Embox: Современное встроенное ПО и классика Таненбаума - 1

В четверг, 27 ноября, в 20:00 в бизнес-инкубаторе «Ингрия» состоится встреча CodeFreeze с Антоном Бондаревым, техническим руководителем проекта Embox. В докладе будет раскрыты аспекты разработки встроенного ПО на примере этой ОС.
Читать полностью »

Вторая часть перевода D Programming Language Tutorial от Ali Çehreli. Содержание главы расчитано для начинающих и, как мне кажется, даже не раскрывает темы. Но это перевод одной из глав.

Предыдущие части:

  1. Часть 1
  2. Часть 2

Читать полностью »

Всё началось полтора месяца назад, когда я от нахлынувшего по результатам собеседований чувства свободы и вседозволенности решил написать новую 64-битную операционную систему. 10 лет назад у меня уже был подобный опыт, но тогда система была 32-х разрядной и обладала другими недостатками, которые сейчас-то я и решил исправить. Например, в той системе (DuS) не было memory management, т.е. страничной организации, поэтому память приходилось распределять до запуска программ, что доставляло неудобства.

Но главное, там не было доступа к сети, а как же можно работать в системе, если там нет Интернета?
Читать полностью »

Rust LogoСегодня Аарон Тюрон — разработчик, недавно присоединившийся к разработке Rust в Mozilla — объявил об отсрочке реализации какого-либо механизма исключений, кроме уже существующего макроса try! и типа Result, до неопределённого момента после первого релиза языка программирования Rust.

Это означает, что в Rust 1.0 будут отсутствовать исключения первого класса — то есть, полностью интегрированные с другими фичами языка.

Для обработки ошибок в данной момент в Rust существует тип Result { Ok(value), Err(why) } и макрос try!. Тип Result представляет из себя перечисление (enum), похожее на Option { Some(value), None } и связанное с ним по смыслу. Вариант None типа Option говорит об отстутствии значения, а вариант Err(why) типа Result уточняет, почему значение отсутствует.

Rust предлагает возвращать тип Result из функций, чтобы передавать значение возврата или причину, по которой значение вернуть не удалось. Макрос try! в свою очередь позволяет автоматически возвращать Err(why) из текущей функции, если вызов другой функции не удался (применяется к объекту типа Result).
Читать полностью »

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

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

Мне периодически приходится объяснять разным людям некоторые аспекты архитектуры Intel® IA-32, в том числе замысловатость системы адресации данных в памяти, которая, похоже, реализовала почти все когда-то придуманные идеи. Я решил оформить развёрнутый ответ в этой статье. Надеюсь, что он будет полезен ещё кому-нибудь.
При исполнении машинных инструкций считываются и записываются данные, которые могут находиться в нескольких местах: в регистрах самого процессора, в виде констант, закодированных в инструкции, а также в оперативной памяти. Если данные находятся в памяти, то их положение определяется некоторым числом — адресом. По ряду причин, которые, я надеюсь, станут понятными в процессе чтения этой статьи, исходный адрес, закодированный в инструкции, проходит через несколько преобразований.

Адреса памяти: физические, виртуальные, логические, линейные, эффективные, гостевые

На рисунке — сегментация и страничное преобразование адреса, как они выглядели 27 лет назад. Иллюстрация из Intel 80386 Programmers's Reference Manual 1986 года. Забавно, что в описании рисунка есть аж две опечатки: «80306 Addressing Machanism». В наше время адрес подвергается более сложным преобразованиям, а иллюстрации больше не делают в псевдографике.
Читать полностью »

Базовым адресом по умолчанию для DLL является 0x10000000, но для исполняемых файлов это 0x00400000. Почему именно такое особое значение для EXE? Что такого особенного в 4 мегабайтах?

Это имеет отношение к размеру адресного пространства, отображаемого одной таблицей страниц в архитектуре x86, и такую конструкцию выбрали в 1987 году.

Единственным техническим требованием для базового адреса EXE является кратность 64 КБ. Но некоторые варианты базового адреса лучше, чем другие.

Цель выбора базового адреса состоит в минимизации вероятности, что модули будут перемещены. Это означает, что следует предотвратить столкновение 1) с другими объектами, которые уже в адресном пространстве (что и вызовет перемещение); 2) а также с объектами, которые могут появиться в адресном пространстве позже (форсируя их перемещение). Для исполняемых файлов избегать конфликта с объектами, которые могут появиться позже, означает уход из района адресного пространства, который может быть заполнен библиотеками DLL. Поскольку сама операционная система помещает файлы DLL в старшие адреса и базовым адресом по умолчанию для несистемных DLL является is 0x10000000, то базовый адрес для EXE должен быть где-то младше 0x10000000, и чем младше, тем больше места останется до того, как вы начнёте конфликтовать с библиотеками. Но насколько низко нужно заходить?
Читать полностью »

Полное оригинальное название статьи: «Why your first FizzBuzz implementation may not work: an exploration into some initially surprising but great parts of Rust (though you still might not like them)»

tl;dr;-версия: На первый взгляд некоторые аспекты Rust могут показаться странными и даже неудобными, однако, они оказываются весьма удачными для языка, который позиционируется как системный. Концепции владения (ownership) и времени жизни (lifetime) позволяют привнести в язык сильные статические гарантии и сделать программы на нём эффективными и безопасными, как по памяти, так и по времени.

Лицензия: CC-BY, автор Chris Morgan.

Почему ваша первая реализация FizzBuzz может не работать: исследование некоторых особенностей Rust, которые изначально шокируют, но в действительности являются его лучшими сторонами (хотя они всё равно могут вам не понравиться)

http://chrismorgan.info/media/images/rust-fizzbuzz.svgFizzBuzz предлагается как простое задание для новичка, но в Rust присутствуют несколько подводных камней, о которых лучше знать. Эти подводные камни не являются проблемами Rust, а, скорее, отличиями от того, с чем знакомо большиство программистов, ограничениями, которые на первый взгляд могут показаться очень жёсткими, но в действительности дают громадные преимущества за малой ценой.

Rust это движущаяся цель, тем не менее, язык становится стабильней. Код из статьи работает с версией 0.12. Если что-то сломается, пожалуйста, свяжитесь со мной. Касательно кода на Python, он будет работать как в двойке, так и в тройке.
Читать полностью »

Классической тестовой программой для большинства программистов на системах, имеющих хоть какой-то дисплей, является Hello World. Такая традиция была введена Керниганом и Ритчи в 1978 году.

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

image

UPD: В комментариях привели ссылку на рекордное решение в 12 байт. Браво!

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js