середа, 11 жовтня 2017 р.

Література до принципів організації комп'ютера -- Інтернет

Взято тут.
Продовжуючи список літератури, тепер -- значно більш ефемерні джерела, посилання в Інтернеті. Зате їх більше. :-)

Цей список складається із двох частин -- літератури для безпосереднього вивчення теми та окремий історичний підрозділ. Прочитайте хоча б вступ до нього! :-)

Почнемо із вікіпедії. Звичайно, тут легко втонути, список може стати величезним, тому, в основному, посилання "першого рівня" -- вглиб треба рухатися самостійно.

Загальні посилання:
Елементна база:
  • 7400 series -- найбільш популярна серія мікросхем, включає реалізації всіх тих компонент, про які пише Токхейм та інші. 
  • List of 7400 series integrated circuits -- список членів цього сімейства мікросхем.
  • 4000 series -- ще одна така серія. Зараз, на загал, менш популярна, ніж 74хх, але трапляється. 
  • List of 4000 series integrated circuits.
  • NE555 -- таймер, генератор імпульсів і взагалі дуже корисна штука.
  • Не на вікі, ще один список мікросхем серії 74xx, привабливий тим, що містить схеми розташування виводів більшості мікросхем серії -- сильно спрощує практичну роботу із ними. 

Мікропроцесорний "напрямок":

вівторок, 10 жовтня 2017 р.

Література до принципів організації комп'ютера -- книги

Взято тут.
Один із курсів, що викладаю в УКУ -- "Принципи організації комп'ютера". Він складається із двох частин. Перша присвячена елементарним блокам комп'ютера, від способів представлення даних -- чисел та тексту, до простих логічних елементів, мультиплексорів, тригерів та защібок, з яких будуються блоки пам'яті, арифметичні та арифметично-логічні (ALU) модулі тощо. Друга -- програмуванню простих обчислювальних систем без допомоги операційної системи -- так-би мовити, bare metal. 
На жаль, через обмеження часу, в цьому курсі доводиться користуватися такою собі логарифмічною шкалою -- стрибати між рівнями абстракцій, не заповнюючи проміжки щільно. Після арифметичних модулів, мінімалістичних блоків пам'яті та оглядом функціонування ALU зразу слідує bare-metal програмуванням сучасних систем.

В ролі bare metal системи обрано демоплату на базі мікроконтролера STM32 -- з одного боку, це цілком серйозний 32-бітний процесор, із 4Гб адресним простором, перериваннями із підтримкою пріоритету, DMA, MPU (але, на жаль, без MMU) і все таке (на противагу крихітним і простеньким AVR8), мікропроцесори. З іншого боку, у них немає великої і плутаної стандартної периферії машин на базі x86 та складнощів із кешем, суперскалярністю, перевпорядкуванням команд і т.д. "великих процесорів". (Про них говоримо в наступному курсі, але це -- окрема історія. :-). Взагалі, про STM32 в цьому блозі написано багато.

четвер, 5 жовтня 2017 р.

Зовсім просто про semihosting

Структура SemiHosting. Взято тут.
Що таке Semihosting, як його підключити і використовувати із "старим та добрим" printf(), детально описано тут: "Стандартна бібліотека C та SemiHosting (на прикладі STM32 і CoIDE)", хоча, як видно з назви, для іншого середовища розробки.

А зараз опишу як ним можна скористатися із мінімальними зусиллями, так би мовити, для лінивих. :-)

Ідея наступна: існує апаратний інтерфейс для передачі даних із мікроконтролера дебаггеру. Є бажання зробити так, щоб по ньому можна було передавати текст, за допомогою звичних функцій вводу-виводу С: printf(), puts(), тощо. Як описується у згаданому вище пості, для цього слід мати реалізацію стандартної бібліотеки та надати для неї відповідні системні виклики, котрі вмітимуть передавати дані семіхостингом.
Часто із компілятором для мікроконтролера йдуть newlib чи newlib-nano, мінімалістичні реалізації стандартної бібліотеки С. Зокрема, є вона і в збірках компіляторів для MCU ARM Cortex M, тому про неї окремо можна не турбуватися. Хоча знати слід -- коли стандартні налаштування перестануть влаштовувати або просто не працюватимуть як належить.
І тут є два варіанти:
  • Із більшим контролем але і більшою морокою -- надати системні виклики самостійно, як описано за посиланням вище.
  • Скористатися готовою реалізацією, що йде разом із компілятором для наших мікроконтролерів -- ARM Cortex M.
Розглянемо їх.

середа, 4 жовтня 2017 р.

Марсіанські справи -- 1

Увага, це старий текст, написаний на початку 2015-го! З того часу не мав можливості до нього повертатися, але викидати шкода, тому трішки відредагував і викладаю. 

Не маючи можливості охопити неосяжне, пишу (upd кінця 2016: на жаль, ймовірно -- писав) лише про нові місії, зокрема із марсіанських -- MSL Curiosity, MAVEN та MOM. Однак, над тим же Марсом працює багато інших (на загал -- потужніших, якщо говорити про орбітальні) станцій та, що важливіше, наукових колективів. Раніше всілякі цікавинки про них я поміщав під заголовком "Додаток до огляду Curiosity", але на додаток воно мало схоже :-) То завів окрему серію, "Марсіанські справи".

Користуючись наземними телескопами, група дослідників розрахувала ймовірну кількість води на Марсі в епоху Ноя, яка закінчилася 3.7 млрд років тому, коли Марс ще був вологим.  За їх оцінками, об'єм води складав мінімум 20 мільйонів кубічних кілометрів --- достатній, щоб  вкрити всю його поверхню шаром товщиною 140 м. Ймовірно, вона, в основному, містилася в океані, що займав помітну частину теперішньої північної півкулі (орієнтація Марсу в просторі помітно змінюється з часом!), де зараз низини. Його площа могла складати 19% поверхні планети, а глибина досягати 1.6 км.
Так міг виглядати Марс 4 млрд років тому.
(c) ESO/M. Kornmesser/N. Risinger

субота, 12 серпня 2017 р.

Огляд (CPU) performance counters API

Схема процесора M68000. Взято тут.
Сучасні процесори надають доступ до різноманітної інформації, пов'язаної із їх роботою -- кількість кеш-промахів та кеш-попадань, кількість виконаних переходів та кількість не вгаданих branch-предиктором переходів, кількість виконаних команд різних видів і т.д. і т.п.

Звичайно, до цієї інформації можна доступатися безпосередньо -- якщо ОС надає відповідні права працювати із моделе-специфічними регістрами процесора (MSR) або є можливість завантажити відповідний драйвер. Однак, це складно -- набір регістрів прив'язаний не тільки до архітектури процесора (x86 чи ARM), але й виробника (Intel vs AMD) і конкретної моделі процесора. Код виходить дуже непортабельним, або дуже громіздким. Зате все під контролем. Детальніше про такий підхід -- див., наприклад, сайт славнозвісного Агнера Фога: "Test programs for measuring clock cycles and performance monitoring". 

Однак, розвинені ОС надають і звичайним програмам доступ до цих інструментів. Про відповідні API MS Windows трішки говорилося в попередньому пості. Для повноти коротко (дуже коротко!) розглянемо спеціалізоване API для POSIX систем -- PAPI та кросплатформову бібліотеку від Intel Processor Counter Monitor (PCM).
Як бачимо, повної кросплатформовості немає -- або тільки POSIX (з обмовками), або тільки процесори Intel, при тому -- достатньо сучасні (конкретніше -- див. далі).

неділя, 30 липня 2017 р.

Огляд інструментів трасування та профілювання багатопоточних програм

Взято тут.
Для вирішення описаних раніше задач (та багато яких інших!) існує ряд хороших готових інструментів. З тих чи інших причин вони для задачі, згаданої в попередньому пості, не підходять, зокрема -- через складність автоматизації і не завжди присутню можливість фіксувати фрагменти коду, що досліджуються. Але знати про них слід -- вони дозволяють детально, іноді -- майже інтерактивно, подивитися, як паралельна програма функціонує. Та й автоматизація, в принципі, можлива.

MS Windows - Concurrency Visualizer


Інструмент, власне, візуалізації роботи багатопоточної програми. Може використовуватися як додаток до Visual Studio або самостійно.


понеділок, 24 липня 2017 р.

Вимірювання часу роботи коду

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

Задача ця виявилася далеко не тривіальною. Сучасний процесор -- дуже складний пристрій. Який працює із складно організованою пам'яттю -- кеші, NUMA, інші жахіття. А на ньому виконується жахливо складна операційна система.

Однак, задачу таки треба вирішувати. Що важливо -- профайлери, на жаль, не дуже підходять, через необхідність дослідити час виконання певного шматка коду -- достатньо великого, але не цілої програми. Точніше -- десятків програм на різних мовах. Добування потрібної інформації із профілів -- чи не складніша задача, за самостійне вимірювання.

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

Отож, задача: є багатопоточна програма, слід виміряти час виконання її фрагменту, тривалість роботи якого складатиме між секундами і хвилинами.