Переменные, предположим, можно все разместить до подпрограмм и к этапу кодогенерации уже иметь готовые адреса. А как быть с подпрограммами? Если текущая подпрограмма должна вызвать следующую, то откуда может быть известно, по какому адресу её вызывать? Упорядочивать на основе того, какая подпрограмма какую вызывает, не получится из-за конструкций вида ,  и тому подобных перекрёстных вызовов. Как это обычно решается?

Есть же декларация функции. Более того, в современных C/C++ она обязательна. 


Но даже в C в стиле K&R компилятор отнюдь не запутывался. Применяются специальные техники увязывания реального адреса функции и места её вызова.

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

Добавлено через 5 минут и 54 секунды

Вот такой код в отдельном модуле:
Полагаете, что компилятор уже знает адрес переменной g_Count? 

Но вот линковщик уже должен знать этот адрес. При чём здесь "до подпрограмм"? Вы, случаем, не ассемблерщик?

Она и обязательна Но как это связано с размером текущей функции и стартовым адресом следующей? Или предварительная генерация асма обязательна для счёта размера?

Добавлено @ 12:12
Речь шла о внутримодульных адресах и прямой адресации. С межмодульных потом разберусь. Скорей всего с помощью неявного превращения в ссылку, реализованную на указателе. Но для внутримодульных адресов это не подходит.

Это сообщение отредактировал(а) ТарасАтавин - 7.9.2013, 12:15

Никак. А как связан порядок следования функций в исходниках с их адресами? Компилятор не обязан располагать коды функций в порядке их следования в исходниках. Он может руководствоваться какими-то своими резонами.


Не обязательна.

Вот именно. Поэтому нефиг придумывать, что речь об исходнике, а не о порядке кодогенерации.

Добавлено через 1 минуту и 33 секунды
Тогда как?

как насчет отложить часть символов на потом?
а вообще конечно нужно читать. например это

То есть? Вот отложил я часть тела функции, перешёл к следующей, сколько места займёт предыдущая не знаю. По какому адресу начинать следующую?

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

Я ничего не придумывал   Это Ваши фантазии.


Вот именно. 

Внешние вызовы как раз достаточно косвенны, чтоб не вызывать проблемы. А это забота системы. Пусть как хочет, так и перебазирует, хоть анализирует код в поисках адресов внутримодульных переходов и исправляет. Или виртуализирует адреса каждого модуля. Меня это не касается.

Добавлено через 2 минуты и 32 секунды
Это как раз понятно. А где его искать потом, чтоб вставить? Кстати, к go to вперёд это тоже относится.

касается, потому что ты должен дать системе таблицу релоков

что то новенькое. Вроде в формате были предусмотрены таблицы импорта и экспорта, а теперь ещё и реаллоков добавляется.

Это сообщение отредактировал(а) ТарасАтавин - 7.9.2013, 16:53

секция .reloc

Добавлено через 9 минут и 19 секунд
добавлять в рабочие данные компилера список таких мест для каждого символа, адрес которого не известен, а потом при выяснении адреса проходить по этому списку?

Что это?

Это сообщение отредактировал(а) ТарасАтавин - 7.9.2013, 17:12

что именно? "секция .reloc"? ну так часто называется секция РЕ-файла, содержащая таблицу релоков. "Часто" потому что насколько я помню загрузчик не использует имена секций для поиска нужной инфы, а пользуется массивом DataDirectory опционального заголовка. Релоки это это элемент массива за индексом IMAGE_DIRECTORY_ENTRY_BASERELOC