Они пытались сделать с нуля -- архитектура IA-64, более известная под маркой Itanium. Но толком дело не пошло: слишком много ПО существует для уродской IA-32, и просто так от неё не откажешься, ну а эмуляция IA-32 на IA-64 (именно таким путём предполагалось идти) не всё позволяет сделать гладко. Плюс вопрос цены: пока спрос невелик, процессоры не могут быть дешёвыми, поскольку выпускаются в ограниченном количестве, а пока их мало, разработчики ПО не спешат по-настоящему переходить на новую архитектуру... Собственно, этим и воспользовалась АМД, слепив свою АМД64 как расширение ИА-32 (тоже уродское, естественно), а Интел позже была вынуждена скопировать это расширение, ведь оно, в отличие от итаниумов, оставалось полностью (ну, почти полностью -- полной совместимости у этих уродцев не существует и из-за непродуманности, и из-за ошибок в самих процессорах) программно совместимым с ИА-32. Новые регистры АМД64 нельзя использовать, например, для адресации строк: там всё равно используются прежние регистры, только увеличенные до 64 разрядов (RSI и RDI). Никуда не делись ограничения в командах ввода-вывода, умножения-деления и т.п. В общем, кривой фундамент...
Это описано в BIOS Boot Specification, пункт «6.5.1 Booting from BAIDs». При загрузке с CD могут быть варианты (El Torito насчёт этого весьма невнятен, но в "section entry" можно указать сегмент загрузки; возможно, это только для "no emulation"). Грузить смещение в сегментный регистр можно, но смысл это имеет очень редко. mov al, [cs:code16] вполне справляется с задачей. Для более компактного кода (как уже было предложено) можно загрузить в какой-нибудь базовый/индексный регистр 0x7C80 и использовать базовую/индексную адресацию, которая иногда короче абсолютной (для адресации диапазона 7C00…7CFF будет достаточно однобайтного смещения). ----8<---- Маленькая поправка: в 16-битном коде. Насчёт замороченности x86 в кодировании инструкций неплохо расписано у Майкла Абраша (Michael Abrash, “The Zen of Assembly Language”): обратная совместимость — жуткая штука. Даже AMD-шники, проектируя x86-64, не смогли полностью отказаться от этой порочной практики (отчасти их можно понять: популярность платформы в немалой степени определяется наличием программного обеспечения для неё). Страшно представить, что получилось бы у Intel, финишируй они с 64 битами первыми.
baldr Ну, собственно, так и есть. Если для адресации используются 32-разрядные регистры, то и правила вычисления адреса соответствуют 32-разрядным режимам, хотя сам адрес в итоге всё равно усекается. Они и финишировали первыми, только отказавшись от совместимости на уровне машинного кода. Рынок, увы, не принял...
KIV как cmp al, 0, test al, al, mov bh, 0 так и xor bh, bh занимают 2 байта пример не удачный выбрали cmp ax, 0 - 3 байта, test ax, ax - 2 байта mov bx, 0 - 3 байта, xor bx, bx - 2 байта
А если всё-таки располагать данные не на Floppy-носителе, а на USB-Flash...если в материнку интегрирован разъём USB, то значит ли это, что BIOS позволяет читать данные из USB-накопителя? И если позволяет, то соблюдается такое же условие (512 байт и последние два 0x55AA) как и для Floppy-носителя? Просто я сомневаюсь что за 512 байт (-2 байта на 0x55AA) будет написан драйвер для работы с USB-накопителем.
Без понятия, никогда не пробовал. Но, по идее, флэшка будет выглядеть как обычный диск, а значит, к ней и обращаться надо как к обычному диску -- т.е. ёмкость ограничена возможностями дисковых сервисов БИОС (2 Тбайта, если БИОС современный, насколько помню).
SII А вот как она будет выглядеть - это уже зависит от настроек. в большинстве современных биосов они могут выглядеть как fd, hd, stream, flash. Кстати как было выявлено экспериментально, не все биосы осуществляют полную эмуляцию. Некоторые сервисы могут быть не подвержены этим фишкам. Например при чтении с флешки в эмуляции как hd через edd она есть, а при записи темже способом эмуляции может не быть. В некоторых биосах эмуляция распространяется только на edd и обычными функциями нельзя даже считать с usb-flash. s3dworld Да но для начала их надо загрузить в знакогенератор
s3dworld Можно, если сначала переопределить знакогенератор (русские символы туда, понятное дело, не входят). То же самое касается вывода русского текста путём прямой записи в видеопамять в текстовом режиме.
SII То есть это мне придётся самому каждый символ описывать (на каждый символ по 8 байт, там как матрица что ли идёт 8 на 8 бит)? И где это хранить? Кто-нибудь знает, как для программы Bochs (именно для bochsdbg.exe), задать параметр, чтобы он при запуске загружал настройки, из указанного ему bxrc-файла?
Помогите (очень надо): А у меня ещё такой вопрос: клавиатура это очень важное устройство. К примеру когда ставишь в CD/DVD-привод диск с установщиком Microsoft Windows и перезагружаешь компьютер, то загрузчик ждёт нажатия кнопки для запуска установщика определённое время. И если время вышло и на кнопку не нажали, то...я не знаю что тогда делает программа загрузчик. Кстати, а что она делает чтобы передать управление BIOS? Так о чём это я...через BIOS я могу дождаться нажатия кнопки на клавиатуре, если сама клавиатура подключена к PS/2. А как быть если клавиатура подключена только лишь к USB? Или BIOS позволяет через свои функции работать и с USB-клавиатурой? Правда ещё надо определить есть ли вообще клавиатура. И если есть, то где.
На один вопрос ответ нашёл. Если кому интересно, то расскажу... Я работаю в Windows. Использую ассемблер FASM. Для набора исходного кода использую Programmer's Notepad. Эта программа позволяет запускать из себя программы с указанными параметрами. Таким образом я настроил её так, что при нажатии клавиши F9 у меня происходит компиляция исходного кода через FASM (бинарный файл создаётся в той же директории где лежит файл исходного кода), а при нажатии клавиши F5 - запускается эмулятор Bochs (уже с загруженным файлом конфигурации, в котором указано что грузить). Для того чтобы исполняемому файлу bochsdbg.exe указать команду для загрузки указанного файла конфигурации при запуске, нужно в качестве параметров запуска указать флаг -f и далее имя файла (если имя файла содержит пробелы или путь, то нужно заключить их в двойные кавычки).
s3dworld БИОСу управление передают не просто так, а для чего-то. Когда Вы выполняете INT 10h, чтобы вывести символ, Вы тоже передаёте тем самым управление БИОСу -- а именно его обработчику данного программного прерывания, а уж тот разбирается, что находится в регистрах, и из этого делает вывод, чего от него хотят. Так что Ваш вопрос про передачу управления без конкретизации, зачем, лишён смысла. Естественно, позволяет. А как иначе можно работать с клавиатурой через БИОС? На то сервисы БИОС и существуют, чтобы прятать от остальных программ особенности железа конкретного компьютера.
Впихнуть, пожалуй, можно. Однако если BIOS погрузила-таки бут-сектор, значит читать умеет. Т.е. есть шанс через int13 читать. Нужно, правда, учесть возможность различной CHS-трансляции. В большинстве случаев int13x уже есть, можно не заморачиваться. Опять же, BIOS Boot Specification. На int18 BIOS отреагирует как на ошибку IPL с конкретного устройства (типа не нашла 0xAA55 по смещению 510) и пойдёт дальше по тропинке, прописанной в CMOS. Многие чипсеты и BIOS поддерживают PS/2-эмуляцию USB-клавиатуры/мыши. В настройках BIOS что-нибудь про legacy KB/mouse support. А сама BIOS, естественно, умеет с USB-клавиатурой общаться. P.S. Боксу можно ещё и -q сказать, чтобы диалог не выводил.
SII и baldr Спасибо! Я вот сейчас читаю про кодирование команд для процессора x86 на русском языке (Микропроцессор i486 (Книга 1)). А если ли что-нибудь подобное для x64? Имею в виду хорошее описание кодирования машинной инструкции на русском.
Не знаю, насколько хорошее: http://ru.osdev.wikia.com/wiki/Кодирование_команд А вообще, всё есть в документации, ей и приучайтесь пользоваться.
Код загрузчика майкрасофт не один из самых удачных. Там очень много допущений, благодаря которым они выигрывают место под всякую муть типа этой. Но если интерестно, то можно сделать так Code (Text): push ds cli xor bx, bx mov ds, bx mov dx, cs mov ax, timer_irq xchg [bx+8*4+0], ax xchg [bx+8*4+2], dx mov [bp+timer_irq+0-$$], ax mov [bp+timer_irq+2-$$], dx mov [bp+timer_irq+4-$$], 18*5+2; (~5 sec, таймер выдает 18,5 сработок в секунду) sti next: mov ah, 1 int 0x16 jz wait xor ah, 0 int 0x16 cmp al, 0x0D jz done wait: cmp [bp+timer_irq+4-$$], 0 jnz next ;timeout call resetirq int 0x19 done: call resetirq pop ds ;continue boot up resetirq: mov [bp+timer_irq+0-$$], ax mov [bp+timer_irq+2-$$], dx cli mov [bx+8*4+0], ax mov [bx+8*4+2], dx sti retn но для загрузочного сектора это очень длинный код
