Flash та оперативна пам’ять: виконання коду

Нещодавно я почав вивчати складання і дізнався про сценарії лінкерів та інші деталі низького рівня апаратного програмування. Я також викладаю комп'ютерну архітектуру, і я десь узгоджувався з тим, що моя картина моделі пам'яті, можливо, помилялася весь час.

Згідно з тим, що я розумію в даний час, весь код і дані знаходяться в енергонезалежній пам'яті відразу після того, як ми 'спалимо' бінарний файл на процесор - оперативна пам'ять, що є летючою, не містить нічого після скидання. Коли програма починає «виконувати», вона робить це з адреси 0x0000, яка майже завжди (AFAIK) є найнижчою адресою Flash. Отже, інструкції прив’язані до шини, що з'єднує Flash з ядром процесора, і саме там відбувається власне виконання. Однак, коли ми говоримо про отримання процесора або зберігання даних з пам'яті, ми зазвичай говоримо про оперативну пам’ять - я знаю, що ми можемо також читати / записувати дані з пам'яті програми (я бачив, як це робилося на AVR) але хіба це не так часто? Це тому, що оперативна пам'ять швидше, ніж ROM, ми вважаємо за краще зберігати там дані?

Прийнята відповідь на це питання говорить про те, що більшість фрагментів коду виконується з оперативної пам'яті.

Чи означає це, що код запуску (який сам виконується з Flash) повинен копіювати всі програмні коди з Flash в оперативну пам'ять і якось відображає адреси у Flash, щоб вказувати на оперативну пам'ять, щоб CPU вибирав звідти коди? Це схоже на процес, коли ми при запуску переміщуємо розділи .data з ROM в ОЗУ?

Я можу уявити, що це простіше в архітектурах фон Неймана, де пам'ять програми та даних діляться шиною, але чи не в Гарвардській архітектурі це означає, що весь код і дані повинні пройти спочатку через регістри процесора?

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

Це залежить від пристрою.

ОЗУ можна побудувати швидше, ніж Flash; це починає набувати значення приблизно в діапазоні 100 МГц.

Прості мікроконтролери

Невеликі повільні мікроконтролери виконуються безпосередньо з Flash. У цих системах зазвичай також більше Flash, ніж SRAM.

Системи середнього діапазону

Як тільки ваш пристрій стає швидшим, ситуація трохи інша. Системи ARM середньої діапазону можуть це зробити також, або вони можуть мати маска завантажувача ROM, яка робить щось розумніше: можливо, завантаження коду з USB або зовнішніх EEPROM у внутрішній SRAM.

Великі системи

Більші, швидші системи матимуть зовнішню DRAM та зовнішній Flash. Це характерно для архітектури мобільного телефону. На даний момент доступна велика кількість оперативної пам’яті, і вона швидша, ніж Flash, тому завантажувач буде копіювати та виконувати її. Це може включати перекочування його через регістри процесора або може включати передачу DMA, якщо доступний блок DMA.

Гарвардські архітектури, як правило, невеликі, тому не переймайтесь фазою копіювання. Я бачив ARM з "гібридним харвардом", який представляє собою єдиний адресний простір, що містить різні пам'яті, але два різні блоки отримання. Код і дані можна отримати паралельно, якщо вони не з однієї пам'яті. Таким чином, ви можете отримати код з Flash та дані з SRAM або код з SRAM та дані з DRAM тощо.

ОЗУ, як правило, швидше, ніж спалах, але це насправді не має значення, поки ви не вражаєте тактову швидкість, що перевищує 80-100 МГц або близько того - якщо час доступу до спалаху швидше, ніж час, необхідний для запуску інструкції, це не має значення.

Фізична конструкція оперативної пам’яті дозволяє нам будувати дуже швидкі пристрої; набагато швидше, ніж спалах. У цей момент є сенс копіювати блоки коду в оперативну пам’ять перед виконанням. Це також приносить додаткові переваги розробнику, наприклад, можливість змінювати код під час виконання.

у архітектурах фон Неймана, де програма пам’яті даних та пам’яті даних розділяє шину, але чи це не означає, що гарвардські архітектури повинні означати, що весь код та дані повинні спочатку пройти через регістри процесора?

Не обов'язково. Тут замінюється віртуальна адресація. Замість програмного коду, що посилається на необмежену апаратну RAM-адресу, він фактично посилається на віртуальний адресний простір. Блоки віртуального адресного простору відображаються на пристрої фізичної пам'яті, які можуть бути ОЗУ, ПЗУ, флеш-пам'яті або навіть буферами пристроїв.

Наприклад, коли ви посилаєте адресу 0x000f0004 на мікро, ви можете читати адресу 0x0004 зі спалаху. Віртуальний адреса є 0x000f0004, але фізичну адресу тільки 0x0004 - весь 0x000fxxxx адресного простору відображається на пристрій 4KB фізичної пам'яті. Звичайно, це лише приклад, і метод управління та організації віртуального адресного простору сильно відрізняється в різних архітектурах.

Якщо ви скажете, що "програма починає виконувати [...] з адреси 0x0000, яка майже завжди є найнижчою адресою у спалах", ви не гарантовано будете правильними. Насправді багато мікроконтролерів починаються з 0x1000.

Те, що ви говорите, не є абсолютно правдивим чи неправдивим. Для цього існують різні сценарії.

Це залежить від того, програмуєте ви на необроблене обладнання або на апаратне забезпечення, встановлене в ОС.

Ваша операційна система, що працює на комп'ютері загального призначення, виймає код з жорсткого диска і зберігає його в оперативній пам'яті для швидшого доступу. Якщо ваш процесор намагатиметься отримувати безпосередньо з жорсткого диска на постійній основі, то операції будуть набагато повільнішими через невідповідність швидкості між двома. Таким чином, ваша ОЗУ вступає в гру, де зберігається фрагмент вашого повторюваного коду для швидшого доступу. І це ще більше надається в кеш-пам’яті процесорів, щоб зробити це ще швидше.

Тепер, коли ви працюєте над мікроконтролером, це повністю залежить від вас, де ви знаходите свої дані на мікросхемі. Якщо дані статичні, ви можете знайти їх у пам'яті коду, що дозволить зберегти оперативну пам’ять, порівняно набагато меншу, ніж пам'ять коду. На мові C, коли ви ініціалізуєте тип даних за допомогою статичного або в якомусь компіляторі, префікс const даних буде зберігатися в пам'яті коду, або ж буде зберігатися в оперативній пам'яті. І в збірці ви безпосередньо використовуєте DB (Визначте байт у випадку Basic 8051) для ініціалізації даних про конкретне місце. Зараз навіть у деяких контролерах, таких як PIC ARM, ви можете писати ROM в час виконання, але отримання даних займе багато часу.

Плюс є програмне забезпечення завантажувача середнього рівня та складні контролери, яке повідомляє контролерам або процесору, звідки слід виконувати стартовий код, або він сам є кодом запуску, який насправді сегментований в пам'яті. Отже, є багато можливостей завдяки належному просуванню , Я б сказала швидше, гібридна підтримка в галузі, яка змінює всю концепцію звичайної оперативної пам'яті та пам'яті. Отже, в основному ваша плутанина справедлива.