OSDev

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

Адрес в 64-разрядном режиме, насколько помню, есть смысл рассматривать как число со знаком в диапазоне от -2**n до 2**n-1, где n -- число аппаратно реализованных битов адреса (не помню, сколько сейчас -- 40?). Если размещать приложение в младших адресах, это означает, что оно строится с адреса 0 или около него (обычно нулевую страницу исключают для ловли нулевых указателей, но в данном случае это не важно). Соответственно, приложение сначала занимает некую область адресов от 0 до какого-то положительного адреса, а впоследствии может быть расширено вплоть до 2**n-1.

Если размещать приложение в старших адресах, то резонно в качестве базового адреса при его построении брать -2**n. В этом случае приложение изначально займёт какие-то наименьшие адреса в старшей половине памяти (численно эти адреса будут минимальными вообще, если их рассматривать как числа со знаком). Впоследствии оно без проблем может "дорасти" до нуля -- т.е. получить ровно тот же объём памяти, что при размещении его в нижних адресах (и даже больший на размер страницы, учитывая, что нулевой адрес обычно запрещён). Все алгоритмы, связанные с выделением и освобождением памяти, отображением виртуальных адресов на физические и т.д. остаются абсолютно неизменными.

Таким образом, абсолютно никакой принципиальной разницы в том, где в виртуальных адресах располагать ядро, а где -- прикладной код, нет.

Никак не могу понять, вы действительно не понимаете такой простой вещи или просто прикалываетесь. Оставим пока Intel 64, т.к. суть одна, только порядки (показатели степени) разные. Как ты расширишь к примеру размер прикладного пространства до 3 гиг, если у тебя базовый адрес приложения 0x80000000 (2 гига)? Вариант только один, не считая релокации/перекомпиляции, - распределять память ниже данной базы. А если пространство ядра больше двух гиг, то приложение вообще не запустится.

Короче пользуйтесь тем, чем пользуетесь. Я свою точку зрения высказал

Ну, выделю по запросу задачи память ниже базы загрузки. И что здесь такого? Если приложение сделано нормально (в частности, программист не использовал адресную арифметику либо использовал, но не предполагал, что указатели непременно будут положительными числами, ну и т.д.), ему абсолютно без разницы, где система выделяет ему память, куда она подгружает библиотеки и т.д. и т.п. -- т.е. база загрузки приложения вообще не играет никакой роли. Кстати говоря, кривое 32-разрядное приложение и в Вашем примере потеряет работоспособность, если ему выделить память свыше 2 Гбайт: указатели-то отрицательными станут.

Так что, извините, это не я, а Вы не понимаете столь простой вещи или прикалываетесь.

Следует учесть, что существуют две стратегии заполнения памяти - снизу вверх и сверху вниз. Для начала нужно выяснить - с какого бодуна приложение оказалось на уровне 2 Гига? Очевидно, что тут действует стратегия сверху вниз и это значит что выше нет свободной памяти, и есть только нижние 2 Гига, так что места для 3-х нет вообще.

А на нуле как обычно и делается пустая страница, так что она может выполнять двойную роль - ловить нулевые адресации программы и переполнение стека.

Просто идея.

Можно попробовать вариант с использованием так называемой канарейки. Суть в том что в последнию разрешенную ячейку стека записывается "странное" предопределенное значение. Периодически ячейка проверяется. Если значение изменилось -> то произошло переполнение стека -> Panic!.

Использую такой подход в dev версии просто, чтобы обнаружить сам факт переполнения. Для релиза в идеале максимальный объем стека используемого точками входа в ядро должен высчитываться путем трассировки всех возможных путей выполнения кода, и таким образом доказываться, что переполнение стека невозможно при использовании данного кода с данным объемом предвыделенного стека невозможно. В деве, при получении stack overflow panic, я просто накручиваю на стек больше памяти, чтобы избежать повторения этого действа в будущем при дальнейшем тестировании. Канарейку проверяю каждый раз выходя из ядра.

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>