Структура исходного кода программы

Содержание

Как мы уже отмечали во вводных лекциях, в ранних ОС, в особенности – для персональных компьютеров, для пользовательского процесса были вынужденно введены очень жесткие ограничения по памяти, — например, в MS DOS – не более 640 килобайт. При таком дефиците основной памяти, если программа оказывается настолько велика, что полностью не помещается в память максимально разрешенного объема, необходимо предпринимать специальные меры при разработке программы, чтобы разбить ее на непересекающиеся группы модулей, такие.что в каждой группе модули логически взаимосвязаны и должны присутствовать в памяти одновременно, модули же разных групп не обязательно должны вместе загружаться в память. Во время исполнения такой программы должен использоваться специальный системный механизм, называемый оверлейная структура (overlay,дословно – наложение), обеспечивающий поочередную загрузку в одну и ту же область памяти то одной, то другой исполняемой группы модулей. Простая программа, которая выполняет эти действия, называется драйвер оверлея (overlay driver). Интегрированная среда разработки Турбо Паскаль обеспечивала специальные опции компилятора, которые позволяли явно указывать модули, входящие в каждый оверлей.

Обзор кода программиста из Microsoft — 6 вещей которые стоит перенять!

Типичный для ранних компьютеров и ОС пример программы с оверлейной структурой – двухпросмотровый ассемблер. На первом просмотре он преобразует исходный ассемблерный код в промежуточное представление, которое программа второго просмотра ассемблера получает на входе. Полностью весь ассемблер (оба просмотра) в память не помещался, и пришлось применить оверлейную структуру.

Рис. 15.3. Оверлейная структура двухпросмотрового ассемблера.

Ключевые термины

ld (linker and loader) – редактор связей и загрузчик в системе UNIX.

Бинарный образ программы в памяти – файл, содержащий образ программы для ее считывания в память и запуска, формируемый загрузчиком.

Время (фаза) загрузки, или линковка (linking) — фаза вызова редактора связей и загрузчика для получения бинарного образа программы в памяти.

Время (фаза) компиляции – этап обработки программы, на котором исходный код программы компилируется в объектный модуль.

Входная очередь – совокупность процессов на диске, ожидающих размещения в памяти для выполнения своих программ.

Динамическая загрузка — загрузка подпрограммы в память при первом обращении к ней из пользовательской программы.

Динамическая линковка — линковка во время исполнения программы.

Динамически линкуемые библиотеки (dymanically linked libraries) – библиотеки подпрограмм, загружаемые в память во время исполнения, при первом обращении к ним из пользовательской программы.

Драйвер оверлея (overlay driver) – системная программа, выполняющая поочередную загрузку в одну и ту же область памяти то одной,то другой группы модулей из пользовательской программы.

Заглушка для исполнения (execution stub) – фрагмент кода в бинарном коде программы, выполняющий системный вызов модуля ОС, размещающего в памяти код динамически линкуемой библиотечной подпрограммы.

Makefile. Компиляция нескольких файлов с исходным кодом

Загрузчик (loader) – системная программа, которая получает на вход загрузочный модуль и файлы с бинарными кодами системных библиотек, используемых программой и, объединяя код программы с кодами системных библиотек, создает бинарный образ программы в памяти.

Исходный код (source code) – код программы (в виде текстового файла) на языке высокого уровня или на языке ассемблера.

Линковка (linking) – то же, что и редактирование связей и загрузка.

Читайте также:

Ментальная арифметика это программа

Логический адрес — адрес, генерируемый процессором при выполнении машинной команды.

Объектный модуль – файл бинарного кода программы, генерируемый компилятором, содержащий выполняемые машинные команды и таблицу символов.

Оверлейная структура (overlay) – организация программы при недостаточном объеме основной памяти, при которой система выполняет поочередную загрузку в одну и ту же область памяти то одной, то другой исполняемой группы модулей программы.

Перемещаемый код (relocatable code) – код, в котором адресация происходит относительно значения регистра перемещения,и адрес в памяти равен сумме значения регистра перемещения и адреса, вычисляемого в команде.

Регистр перемещения (relocation register) – регистр, содержащий начальный адрес области памяти, отведенной операционной системой для загруженной в память программы.

Редактирование связей (linking) – этап обработки программы, на котором редактор связей формирует из объектных модулей загрузочный модуль,разрешая все межмодульные ссылки.

Редактор связей (linkage editor) – систeмная программа, формирующая из объектных модулей загрузочный модуль,разрешая все межмодульные ссылки.

Редактор связей и загрузчик (linker and loader) — системная программа, в которой объединены функции редактора связей и загрузчика.

Связывание адресов во время загрузки (load-time) – схема адресации, при которой генерируемый код адресует данные и программу относительно регистра перемещения, значение которого определяется при загрузке программы.

Связывание адресов во время исполнения (runtime),или динамическое (позднее) связывание – гибкая схема адресации, при которой абсолютный адрес программы или данных определяется только во время выполнения программы; для реализации используется аппаратная поддержка отображения адресов – например, регистры базы и границы.

Связывание адресов во время компиляции (compile-time) — если адреса программы и данных в памяти априорно известны, генерация компилятором кода с абсолютными адресами.

Cтатически линкуемая библиотека – библиотека подпрограмм, код которой объединяется с кодом использующих ее объектных модулей в загрузочный модуль на этапе редактирования связей и загрузки.

Таблица символов – таблица в объектном модуле или загрузочном модуле, содержащая символы (переменных, процедур и др.), определенные или используемые в данном модуле кода.

Устройство управления памятью (Memory Management Unit – MMU) – модуль аппаратуры, выполняющий адресацию памяти и связанный с процессором и другими устройствами системной шиной; преобразует логические адреса в физические адреса.

Физический адрес – реальный адрес в памяти, который «видит» и «понимает» устройство управления памятью.

Вопросы

1. В чем заключается задача управления памятью?

2. Что такое входная очередь заданий?

3. Что такое связывание адресов и на каких этапах обработки программы оно может выполняться?

4. Какие этапы обработки проходит программа на пути от исходного кода к двоичному образу в памяти?

5. Что такое компиляция?

6. Что такое редактирование связей?

7. Что такое загрузка?

8. Что такое линковка?

9. Что такое объектный модуль?

10. Что такое таблица символов?

11. Что такое загрузочный модуль?

12. Что такое библиотека?

13. Что такое бинарный образ программы в памяти?

14. Что такое редактор связей?

15. Что такое загрузчик?

16. Что такое ассемблер?

17. Что такое логический адрес и какой компонентой системы он генерируется?

18. Что такое физический адрес и какой компонентой системы он генерируется?

19. Что такое устройство управления памятью?

20. Что такое регистр перемещения?

21. Что такое перемещаемый код?

22. Что такое динамическая загрузка?

23. Что такое динамическая линковка?

24. Что такое статически линкуемая библиотека?

25. Что такое динамически линкуемая библиотека?

26. Что такое оверлейная структура программы?

27. Что такое драйвер оверлея?

Упражнения

1. Проанализируйте структуру бинарного кода для используемого Вами компьютера и классифицируйте используемую схему адресации (связывание во время компиляции, во время загрузки или во время выполнения).

2. Разработайте и выполните в системах UNIX (Linux) и Windows последовательность команд, реализующую на командном языке последовательность фаз обработки программы от исходного кода до двоичного образа исполняемого кода в памяти.

3. Используйте статически и динамически линкуемые библиотеки в коде Вашей программы и проанализируйте ассемблерный (бинарный) код обращения к ним в коде Вашей программы.

Как правильно организовать структуру файлов исходного кода для проекта на C++

Хочу написать небольшой проект на C++, но ознакомившись с некоторыми проектами уже написанными на этом языке, заметил, что доминирует подход размещения файлов исходного кода, когда все файлы складываются в одну папку. Мне кажется это не очень удобно, т.к. всегда пытался разбивать проект на модули. Вопрос заключается в следующем, считается ли размещение всех файлов исходного кода в одной директории хорошей практикой? И есть ли альтернативные способы размещения файлов исходного кода, чтобы в них как можно меньше путаться ?

Отслеживать
задан 30 мая 2018 в 7:04
RapperOfCodings RapperOfCodings
321 1 1 золотой знак 4 4 серебряных знака 4 4 бронзовых знака
Какую планируете использовать систему сборки? Например у QMake и Cmake есть подпроекты

30 мая 2018 в 7:10

Скажу честно, я новичок на столько, на сколько это возможно, системы сборки никогда не использовал, по крайней мере явно. До этого писал немного на Си, использовал gcc все компилировал и линковал вручную)

30 мая 2018 в 7:17

Никакого доминирующего подхода к размещению файлов нет. Причем безотносительно создания подпроектов. Запихивают кто во что горазд. В С++ мне представляется рациональным подход а-ля boost, когда все исходники раскладываются по папкам в соответствии с именам пространств имен.

30 мая 2018 в 7:22

Посмотрите в сторону популярных проектов на githab. Все используют примерно +- один и тот же принцип размещения файлов: *h, *.cpp, тесты и примеры разнесены по разным каталогам.

30 мая 2018 в 10:01

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Вопрос спорный, поэтому изложу свои домыслы.

1) Во-первых файловая структура должна отражать архитектурные решения примененные в проекте.

2) Интерфейсные файлы (в основном заголовочные) лучше отделять от файлов реализации, размещать их в разных папках. Струтура папок с интерфейсными файлами должна соотвествовать стуктуре пространств имен. Пример:

// SpaceA/Foo.h namespace SpaceA < struct Foo ; void Foo(); > // SpaceA/SpaceB/Bar.h namespace SpaceA < namespace SpaceB < void Bar(); >> // client_SpaceA.cpp #include #include SpaceA::Foo foo = . ; SpaceA::Foo(); SpaceA::SpaceB::Bar();

3) Если интерфейсные файлы включают другие интерфейсные файлы то дериктивы включения должны быть в форме как в примере выше.

4) Интерфейсные файлы и файлы реализации всегда парные. Например Foo.h содержит интерфейс, а Foo.cpp реализацию. Все сущности из Foo.h должны быть реализованы в Foo.cpp , их нельзя размещать в других файлах, или в Foo.cpp добавлять то чего нет в Foo.h .

5) Заголовочные файлы могут включать ( #include ) другие заголовочные файлы, но только те которые необходимы для объявления сущностей в данном заголовчном файле. Иными словами заголовочный файл это спецификация интерфейсв, а не реализации, он не должен включать все что нужно для реализации.

Источник: ru.stackoverflow.com