Programowanie niskopoziomowe / Moduł 2: Proces tworzenia programu
|
... |
|
... |
|
Generowanie postaci wykonywalnej programu zapisanego w języku wysokiego poziomu w większości środowisk programowania składa się z trzech etapów. Kompilator języka wysokiego poziomu zamienia każdy plik źródłowy programu na postać asemblerową (niektóre kompilatory, w tym Microsoft C dla x86, mogą bezpośrednio generować postać pośrednią. Asembler transluje symboliczny zapis asemblerowy na postać pośrednią (binarną). Konsolidator łączy moduły programu w postaci pośredniej tworząc postać wykonywalną. |
|
Przykład dotyczy systemu MS-DOS, używanego dawniej w komputerach osobistych klasy PC i działającego w tym systemie kompilatora Microsoft C. Przyjmijmy, że translujemy program w języku C, składający się z jednego modułu Wywoływany przez programistę program CL jest powłoką kompilatora. Program ten uruchamia właściwy kompilator, który generuje postać pośrednią modułu. Po utworzeniu postaci pośredniej następuje uruchomienie konsolidatora. Konsolidator ma za zadanie połączyć moduł startowy (dostarczany wraz z kompilatorem), moduł wygenerowany przez kompilator oraz bibliotekę zawierającą funkcje dostępne dla programów w języku. Konsolidator tworzy postać wynikową. Wykonanie programu wynikowego rozpoczyna się od stałego punktu wejściowego modułu startowego. Moduł startowy wywołuje funkcję main, a ta z kolei – funkcje biblioteki standardowej. |
|
W systemach rodziny Unix (w tym Linux) często używa się oprogramowania GNU, w tym kompilatorów z kolekcji GCC. Sam program GCC jest powłoką kompilatora. W pakiecie GCC kompilatory generują postać asemblerową, która jest przekazywana poprzez strumień do asemblera. Po wygenerowaniu postaci wynikowej program GCC wywołuje konsolidator, który łącza moduł startowy, moduły kompilowanego programu i moduły wybrane z biblioteki standardowej. |
|
Podobnie przebiega proces tworzenia programu w systemie Windows. Główna różnica w stosunku do wcześniejszych przykładów polega na tym, że Windows intensywnie korzysta z tzw. bibliotek dynamicznych, czyli modułów używanych przez wiele programów, ładowanych w jednej kopii do pamięci komputera (z bibliotek dynamicznych można korzystać również w systemie Linux). Moduły biblioteczne dołączane do programu nie zawierają pełnych procedur, a jedynie kod umożliwiający wywoływanie procedur z bibliotek dynamicznych. Postać binarna programu nie jest kompletna – zawiera ona niezrealizowane odwołania, które są łączone podczas ładowania programu do pamięci. |
|
... |
|
... |
|
... |
|
Każdy moduł źródłowy jest translowany na postać pośrednią. Moduły źródłowe mogą korzystać z symboli zdefiniowanych w innych modułach (np. wywołania funkcji bibliotecznych lub funkcji zdefiniowanych w innych modułach). Mogą one również udostępniać innym modułom własne symbole – funkcje i dane. Każdy moduł musi znać nazwy obcych symboli, z których korzysta. |
|
... |
|
... |
|
... |
|
Pierwszy moduł odwołuje się do symbolu (procedury) say_hello. Przed pierwszym użyciem tego symbolu w module użyto dyrektywy asemblera extern, która informuje asembler, że jest to symbol zewnętrzny. W wygenerowanym przez asembler module w postaci pośredniej będzie zawarta informacja, o konieczności realizacji odwołań do tego symbolu podczas konsolidacji programu. Drugi moduł udostępnia symbol say_hello jako publiczny. przed definicją symbolu (etykiety punktu wejścia do procedury) występuje dyrektywa global, informująca asembler, że symbol będzie udostępniony jako publiczny. Asembler udostępni ten symbol konsolidatorowi w pliku pośrednim. |
|
W przypadku programów jednomodułowych praca konsolidatora sprowadza się do konwersji formatu z postaci pośredniej do postaci wykonywalnej. Wszystkie odwołania są zrealizowane w obrębie jednego modułu. |
|
... |
|
... |
|
... |
