Начинаем разговор о многозадачности

[whitequark]

Операционная система на ассемблере под 32-битный режим x86? Простите, я попал в 20 век?

[Igor1024]

На асме я пишу только для себя любимого.
iley и pehat скоро продолжат свои посты про осьдев, используя HLL.
Знаете, у меня в наличии только 32 — разрядный проц, так что пишу под него.

[whitequark]

Пишете «для себя любимого», и публикуете в интернете. Нелогично.
Дело в том, что практическая ценность такой статьи стремится к нулю: для того, чтобы быть полезной с точки зрения обучения, она содержит слишком много технических подробностей и дурно отформатированного кода, а практическая польза отсутствует в принципе.

Я даже не говорю о том, что в современных ОС отказались от 8259 в пользу IOAPIC (который уж точно есть в вашем проце и намного менее кривой), и так далее. Все это — и 32 бита, и 8259 (не сомневаюсь, что в других статьях есть еще примеры) — жуткое легаси, от которого надо всеми силами избавляться.

[Igor1024]

Мне просто не нужны на данный момент фичи IOAPIC.

[whitequark]

Пожалуй, поясню. Я не имею ничего против ассемблера: у него есть множество применений, как в эмбеддеде, так и на десктопах. Я ничего не имею против 32-битных систем в общем: на рынке полно, например, ARM-ов, где это отлично работает. Я согласен, что под x86 сделано огромное количество софта и железа, и все это нужно поддерживать.

Я просто хочу сказать, что сочетание ассемблера, 32-битного x86 и 2011 года нежизнеспособно, поскольку применимость отсутствует даже в теории.

[Igor1024]

Ваш вариант жизнеспособного стартапа? x86-64?

[whitequark]

Если бы у меня была задача, требующая ассемблерной ОС на современных x86, то да, я бы делал под 64 бита. Кстати, оказалось, что недавно на хабре писали о такой ОС. Посмотрим, насколько оно будет жизнеспособно.

[pxx]

Извеняюсь за свой английский

извИнитесь еще пожалуйста за русский и продолжайте писать интересные статьи

[anoshenko]

На сколько я понял у вас не вытесняющая многозадачность? Все задачи работают в общем адресном пространстве, как это было во времена Windows 3.0?

[megabrain]

Вытесняющая, если по таймеру. Но насчет адресного пространства вы правы. Пока автор не предложил решения ни на базе сегментной, ни на базе страничной модели. Хотя, судя по закомментированным кускам кода, они у него, вероятно, есть, просто он не хотел вываливать такой объем проблем аппаратуры на головы читателей за один присест.

[Igor1024]

Это же ещё вводная статья. Представляете, если в одном топике расписать весь ход работы по реализации всего-всего… много будет.

[ice2heart]

много кода, в обучающих целях хорошо

[whiteglasses]

На аппаратное переключение процессов забили даже в самом Intel.

In 64-bit mode, task structure and task state are similar to those in protected mode.
However, the task switching mechanism available in protected mode is not supported in 64-bit mode. Task management and switching must be performed by software.

Intel® 64 and IA-32 Architectures Software Developer's Manual
Volume 3A: System Programming Guide, Part 1, 7-22 Vol. 3A

[cursed]

Не осилил. Вы опустили мое ЧСВ на 10 пунктов ;(

[megabrain]

Извините, а что помешало выделять по стеку на задачу и использовать для сохранения контекста аппаратные и такие привычные pushad и pushd, процессор же сам подобным образом сохраняет часть контекста в стеке — те самые ss, esp, eflags, cs и ip, можно же взять и помочь ему, сохранив регистры общего назначения и сегмент данных в том же стеке? Даже ничего нового городить не нужно: если уже разработан диспетчер прерываний, то контекст там наверняка сохраняется во враппере обработчика, в стеке. Остается только подменять стек при переключении задач, ну и если это необходимо, каталог страниц.

Кстати, TSS вам все равно понадобится, когда окунетесь в Ring3.

Немного больше системности, меньше хаоса, и все будет хорошо.

[CleverMouse]

Почему бы не использовать структуры вместо непосредственных смещений? Код

struc TSS_struct
{
.privilege_level db ?
.esp dd ?
.cr3 dd ?
.eip dd ?
.eflags dd ?
.eax dd ?
.ecx dd ?
.edx dd ?
.ebx dd ?
.esp2 dd ?
.ebp dd ?
.esi dd ?
.edi dd ?
}
virtual at 0
TSS_struct TSS_struct
end virtual

 mov [es:100h+TSS_struct.eip],task

 mov [es:edi+TSS_struct.eflags],eax
 mov [es:edi+TSS_struct.ecx],ecx
 mov [es:edi+TSS_struct.edx],edx
 mov [es:edi+TSS_struct.ebx],ebx
 mov [es:edi+TSS_struct.ebp],ebx ; ???
 mov [es:edi+TSS_struct.esi],esi
 mov [es:edi+TSS_struct.edi],edi

смотрится более естественно — разве что за исключением особой fasm'овской магии с virtual, — чем

 mov [es:100h+9],dword task

 mov [es:edi+13],eax;EFLAGS

 mov [es:edi+21],ecx
 mov [es:edi+25],edx
 mov [es:edi+29],ebx
 mov [es:edi+37],ebx
 mov [es:edi+41],esi
 mov [es:edi+45],edi

Между прочим, нет ли в коде, помеченном "???", опечатки?

Весь код

push eax
 push ebx
 mov eax,[cur_task_num];в этой dword’овой переменной будем хранить номер тек. задачи
 mov ebx,100h
 mul ebx
 pop ebx
 mov edi,eax;EDI – начало TSS_struct 
 pop eax

можно заменить одной командой

 imul edi,[cur_task_num],100h

но ещё лучше двумя

 mov edi,[cur_task_num]
 shl edi,8 ; mul 100h

[Igor1024]

Да, поспешил. Опечатался.
Насчёт умножения — знаю, что сдвигом быстрее, но, может, не все поймут.

[Igor1024]

Спасибо, что поправили.