Стек и bootloader

[kuraga]

Pavia в сообщении #395577 писал(а):

Circiter
Al это младшая часть регистра eax поэтому ничего перемещать не надо.

Угу. Я не понял, что это не известно...

Pavia в сообщении #395577 писал(а):

Цитата:

А то сейчас все указывает на то, что push уменьшает esp всего на 2...

Всё правильно. Как я и писал здесь и ошибка. Вам надо будет препроцессор написать
Которая заменяет push на push DWord ptr или как там в as выглядит приведение типов.

Я только не понял - то, что это так, опытом подтверждено? Сорри, я просто сейчас проверить не могу...

[Circiter]

2kuraga

Цитата:

Я только не понял - то, что это так, опытом подтверждено?

Если вы про проблемы с разрядностью push'а, то да, а если про решенность исходной задачи, то нет. :) Я действительно попробовал заменить тот нехороший push на что-нибудь безопасное, но ни один вариант не сработал, т.е. сообщение на экран так и не выводится... Есть ещё парочка идей, позже поковыряюсь....

[Circiter]

Отчаявшись, я перечитал эту тему с целью ещё разок перепробовать все идеи. В частности, я попробовал последовать совету Pavia об отказе от intel-синтаксиса промежуточного ассемблерного листинга... И, о чудо, все заработало. Аж страшно. У gcc явно какие-то проблемы, это конечно не баг, но и явно не фича. :)

В общем, достаточно убрать опцию -masm=intel. Для настройки стека подойдет такая заглушка в начале исходника ядра:

__asm__
    (
        ".code16gcc\n"
        ".align 4\n"
        "mov $(stack + 0x1000), %esp\n"
        "jmp _start\n"
        "stack: .space 0x1000"
    );

У меня ещё вопрос теперь возник насчет выравнивания. Я вот на всякий случай написал .align 4, насколько это критично?

2kuraga
Можете сообщить в открытой вами на другом ресурсе ветке об успешном "решении" проблемы (хорошо было бы post factum разобраться, откуда такие пироги с gcc).

[Circiter]

Опцию -Ttext 0 тоже нужно убрать, чтобы она не перекрывала скрипт компоновщика.

[kuraga]

Прикольно... Я тоже думал об этом, но тут же решил, что это будет слишком странно - просто в другом синтаксисе...

[Circiter]

Но вам ничто не мешает писать ассемблерную часть кода на любимом диалекте (например, для nasm) и линковать результат трансляции вместе с объектными файлами, сгенерированными gcc'ом.

Ну что-ж, поиграться-то поигрались, но также абсолютно понятно, что дальше так писать не шибко-то правильно. Все-таки gcc будет себя лучше чувствовать в 32pm (ну или 64 :) ). Другое дело, что может захотеться написать на gcc, ну например, что-то вроде монитора, висящего в rm и "перенаправляющего" запросы pm-части системы к bios'у (чтобы сэкономить на драйверах :) ). Это обсуждение показывает, что такое все-таки возможно, но код получается очень плохим и в нормальом релизе использоваться не должен (хотя, может быть все-таки стоит поискать 16b-кодогенераторы для gcc).

Вообще, интересно было бы запустить теперь уже работающую "ОС" на реальном железе (просто залив образ, к примеру, на флешку). Мне вот что-то лень сейчас перезагружать систему, но попозже обязательно попробую (особенно интересно, если вообще хоть что-то заработает, то как поведет себя прямой доступ к видеопамяти в том виде, в каком я его использовал при экспериментах в qemu :) ). Эмуляторы -- опасная штука, можно такого наворотить, а потом это просто не будет работать на настоящем процессоре. :)