Flash i RAM: wykonanie kodu

Niedawno zacząłem uczyć się asemblera i poznałem skrypty linkera oraz inne szczegóły niskiego poziomu programowania sprzętowego. Uczę się również architektury komputerowej i gdzieś po linii zacząłem się obawiać, że moje zdjęcie modelu pamięci może być przez cały czas błędne.

Zgodnie z tym, co rozumiem obecnie, cały kod i dane znajdują się w nieulotnej pamięci tuż po „wypaleniu” pliku binarnego na procesorze - pamięć RAM, która jest niestabilna, nie zawiera niczego po zresetowaniu. Kiedy program zaczyna „wykonywać”, robi to z adresu 0x0000, który prawie zawsze (AFAIK) jest najniższym adresem we Flashu. Instrukcje są więc zaczepiane na szynie łączącej Flash z rdzeniem procesora i tam właśnie odbywa się faktyczne wykonanie. Jednak, gdy mówimy o odzyskiwaniu lub przechowywaniu danych z pamięci przez procesor, zwykle mówimy o pamięci RAM - mam świadomość, że możemy również odczytywać / zapisywać dane z pamięci programu (widziałem to na AVR) ale czy to nie jest tak powszechne? Czy dlatego, że RAM jest szybszy niż ROM, wolimy tam przechowywać dane?

Akceptowana odpowiedź na to pytanie mówi, że większość fragmentów kodu jest wykonywana poza pamięcią RAM.

Czy to oznacza, że ​​kod uruchomieniowy uruchamiania (który sam wykonuje się z Flasha) musi skopiować wszystkie kody programu z Flasha do RAM i w jakiś sposób mapuje adresy we Flashu, aby wskazywały na RAM, aby CPU pobierał stamtąd stamtąd? Czy jest podobny do procesu, w którym przenosimy sekcje .data z ROM do RAM podczas uruchamiania?

Mogę sobie wyobrazić, że jest to prostsze w architekturach von Neumanna, w których pamięć programu i danych współużytkuje magistralę, ale w architekturach Harvarda czy to nie znaczy, że cały kod i dane muszą najpierw przejść przez rejestry procesora?

Jak zapewne można się domyślić, jestem trochę zbyt zdezorientowany całą tą sprawą. Zawsze programując na wyższym poziomie abstrakcji, łatwo mnie niepokoją takie szczegóły. Każda pomoc jest mile widziana.

To zależy od urządzenia.

Pamięć RAM można budować szybciej niż Flash; zaczyna to być ważne w zakresie około 100 MHz.

Proste mikrokontrolery

Małe wolne mikrokontrolery działają bezpośrednio z Flasha. Systemy te zwykle mają też więcej pamięci Flash niż SRAM.

Systemy średniotonowe

Gdy Twoje urządzenie przyspieszy, sytuacja będzie nieco inna. Mogą to zrobić również systemy ARM ze średniej półki lub mogą mieć maskowy moduł ładujący ROM, który robi coś mądrzejszego: być może pobiera kod z USB lub zewnętrznych pamięci EEPROM do wewnętrznej pamięci SRAM.

Duże systemy

Większe, szybsze systemy będą miały zewnętrzną pamięć DRAM i zewnętrzną pamięć flash. Jest to typowe dla architektury telefonu komórkowego. W tym momencie dostępna jest duża ilość pamięci RAM i jest szybsza niż Flash, więc bootloader ją skopiuje i uruchomi. Może to wymagać przeszukiwania rejestrów procesora lub transferu DMA, jeśli dostępna jest jednostka DMA.

Architektury Harvarda są zazwyczaj małe, więc nie zawracaj sobie głowy fazą kopiowania. Widziałem ARM z „hybrydowym harwardem”, który jest pojedynczą przestrzenią adresową zawierającą różne pamięci, ale dwie różne jednostki pobierania. Kod i dane mogą być pobierane równolegle, o ile nie pochodzą z tej samej pamięci. Możesz więc pobrać kod z Flasha i dane z SRAM lub kod z SRAM i dane z DRAM itp.

Pamięć RAM jest generalnie szybsza niż flash, ale tak naprawdę nie ma to znaczenia, dopóki nie osiągniesz częstotliwości taktowania przekraczającej około 80-100 MHz - tak długo, jak długo czas dostępu do pamięci flash jest krótszy niż czas potrzebny na uruchomienie instrukcji, nie powinno mieć znaczenia.

Fizyczna konstrukcja pamięci RAM pozwala nam budować bardzo szybkie urządzenia; znacznie szybciej niż flash. W tym momencie sensowne jest skopiowanie bloków kodu do pamięci RAM przed wykonaniem. Daje to także dodatkowe korzyści dla programisty, takie jak możliwość modyfikowania kodu w czasie wykonywania.

w architekturach von Neumanna, gdzie pamięć programu i danych współużytkuje magistralę, ale w architekturach Harvarda nie oznacza to, że cały kod i dane muszą najpierw przejść przez rejestry procesora?

Niekoniecznie. W tym miejscu pojawia się adresowanie wirtualne . Zamiast kodu programu odnoszącego się do nieprzetworzonych sprzętowych adresów RAM, faktycznie odnosi się do wirtualnej przestrzeni adresowej. Bloki wirtualnej przestrzeni adresowej są mapowane na fizyczne urządzenia pamięciowe, którymi mogą być RAM, ROM, flash, a nawet bufory urządzeń.

Na przykład, gdy odwołujesz się do adresu 0x000f0004 na karcie micro, możesz odczytywać adres 0x0004 z pamięci flash. Adres wirtualny jest 0x000f0004, ale adres fizyczny jest tylko 0x0004 - cała przestrzeń adresowa 0x000fxxxx są odwzorowywane na urządzeniu 4KB pamięci fizycznej. Jest to oczywiście tylko przykład, a metoda zarządzania wirtualną przestrzenią adresową i organizowania jej znacznie różni się w zależności od architektury.

W związku z tym, gdy mówisz, że „program rozpoczyna wykonywanie [...] od adresu 0x0000, który jest prawie zawsze najniższym adresem w pamięci flash”, nie masz gwarancji, że jest poprawny. W rzeczywistości wiele mikrokontrolerów zaczyna się od 0x1000.

To, co mówisz, nie jest do końca prawdą ani fałszem. Istnieją różne scenariusze.

To zależy od tego, czy programujesz na surowym sprzęcie, czy na sprzęcie zainstalowanym z systemem operacyjnym.

Twój system operacyjny działający na komputerze ogólnego przeznaczenia pobiera kod z dysku twardego i zapisuje go w pamięci RAM, aby uzyskać szybszy dostęp. Jeśli twój procesor próbuje pobierać bezpośrednio z dysku twardego na bieżąco, operacje byłyby znacznie wolniejsze z powodu niedopasowania prędkości między dwoma. Tak więc twoja pamięć RAM wchodzi w grę, gdzie fragment powtarzalnego kodu jest przechowywany dla szybszego dostępu. Co więcej, pamięć podręczna procesorów udostępnia ją jeszcze bardziej, aby była jeszcze szybsza.

Teraz, gdy pracujesz nad mikrokontrolerem, zależy to całkowicie od ciebie, gdzie umieścisz swoje dane na chipie. Jeśli dane są statyczne, możesz chcieć zlokalizować je w pamięci kodu, co pozwoli zaoszczędzić pamięć RAM, która jest znacznie mniejsza niż pamięć Code. W języku C podczas inicjowania typu danych przy użyciu statycznego lub w pewnym kompilatorze stałej prefiksu dane będą przechowywane w pamięci kodu lub w pamięci RAM. A w zespole bezpośrednio używasz DB (Define Byte w przypadku Basic 8051) do inicjalizacji danych w konkretnej lokalizacji. Teraz nawet w niektórych kontrolerach, takich jak PIC ARM, możesz pisać ROM w czasie wykonywania, ale pobieranie danych zajmie dużo czasu.

Dodatkowo istnieją programy sprzętowe boot loader na średnim poziomie i zaawansowane kontrolery, które mówią kontrolerom lub procesorowi, gdzie wykonać kod startowy lub sam kod startowy, który jest właściwie podzielony na pamięć, więc istnieje wiele możliwości dzięki zaawansowaniu , Wolałbym powiedzieć, że hybrydowe doradztwo w branży jest niezgodne z koncepcją konwencjonalnej pamięci RAM i pamięci RAM. Więc w zasadzie twoje zamieszanie jest uzasadnione.