Почему сегмент стека моего загрузчика равен 0x3FF (конец реального режима IVT)? - PullRequest
Новая
       61

Почему сегмент стека моего загрузчика равен 0x3FF (конец реального режима IVT)?

3 голосов
/ 29 апреля 2010

«адрес 0x500 - последний, используемый BIOS» - вот что Википедия -

"00000000-000003FF Реальный режим IVT (таблица векторов прерываний)" - это то, что говорится в статье osdev.org над картой памяти BIOS.

Так можете ли вы сказать мне, почему NASM устанавливает указатель стека моего файла .com на 0x3FF, а указатель моей инструкции начинается с 0x7C00? Для меня самое интуитивное место для SP было бы прямо ниже 0x7C00.

Ответы [ 4 ]

3 голосов
/ 25 августа 2010

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

Удачный ответ - 3FFh является допустимым расположением стека для некоторых BIOS. Дело в том, что в этом случае это нижняя часть IVT, потому что эти векторы прерываний не используются BIOS. Это не секрет.

Область стека BIOS
BIOS использует 30: 0000h - 30: 00FFh (поверх таблицы векторов прерываний) в качестве области стека. Эта область используется для расчетов BIOS и временного хранения. Адреса для INT от C0h до FFh, не поддерживаемые в AMIBIOS, обычно занимали бы это пространство.

Руководство программиста по AMIBIOS 1993, стр. 181

1 голос
/ 02 мая 2010

Я не верю, что BIOS будет поддерживать правильный стек для вас. Таким образом, вы должны установить стек самостоятельно в любой имеющейся у вас памяти. Моя общая последовательность запуска в загрузчиках выглядит так: 

[BITS 16]
[ORG 0x7C00]
xor ax,ax ;AX=0
mov ds,ax
mov es,ax ;can be omitted
mov ss,ax
mov sp,0x7000 ;or replace with some other nice valid piece of memory
jmp word 0:begin ;BIOSes are sometimes buggy and load you initially with CS=7C0
begin:
;....

NASM не делает ничего, кроме того, что вы говорите. Это точка использования сборки. Каждая строка кода сборки имеет соотношение кодов операций 1: 1, выполняемых компьютером. Таким образом, если BIOS не устанавливает стек для вас, и нигде в коде сборки вы не устанавливаете стек, то стек будет в недопустимом состоянии. Nasm не будет вставлять магический код для настройки стека.

0 голосов
/ 02 мая 2010

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

Согласно руководству Intel, это не тот процессор, который заставляет SP содержать такое нечетное значение. http://www.intel.com/design/pentiumii/manuals/243192.htm

Поскольку не существует ОС, в которой выполняется код, единственной оставшейся опцией, вызывающей состояние SP (и других регистров), является BIOS. К сожалению, BIOS являются «коммерческими секретами» с закрытым исходным кодом, и поэтому вопрос «почему» останется без ответа. Coreboot на http://www.coreboot.org/Welcome_to_coreboot может дать некоторые подсказки о том, почему все так, как есть, но Coreboot, кажется, делает вещи, иногда очень отличающиеся от традиционных BIOS ...

0 голосов
/ 29 апреля 2010

Я не знаком с NASM, но я почти уверен, что он устанавливает для вашего регистра сегмента стека (SS) значение, отличное от 0, поэтому SS: SP указывает куда-то совсем иначе.

Редактировать: Подождите, ваш сегмент или указатель установлен на 03FF?

...