RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Вернемся с небес на землю (злосчастный кусок)


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Юрий Пронякин
To : valerius
Subj : Вернемся с небес на землю (злосчастный кусок)
> > > А чтобы создать 16-битный сегмент, надо создать его дескриптор в GDT или LDT. "Allocate GDT selector" реализуется в ядре OS/2 как device helper, то есть, это интерфейс ядра. Полностью же 32-битное микроядро таких интерфейсов не предоставляет (по крайней мере, L4).
> >
> > Ну и что? Интерфейс можно же и добавить. При этом само микроядро останется полностью 32-битным.
> >
>
> Как бы это не было из серии "а бантик-то гвоздиком прибили...". То есть, такой интерфейс должен хорошо вписываться в остальные механизмы микроядра... Кроме того, сегментная модель не имеет аналогов на других процессорах, кроме x86, а хотелось бы, чтобы решение работало и для ARM и прочих процессоров...

Зачем? Нам это нужно только для того, чтобы запускать существующие LX-файлы. Разве для ARM-ов такие файлы имеются? А все будущие программы должны использовать только 32-разрядные функции, быть чисто 32-разрядными (и, скорее всего, быть не в LX).

> > "Не прав" (если можно так выразиться) в терминологии. В описанном тобой случае мы имеет просто эмулятор.
>
> Не совсем "просто" эмулятор... Может быть, имеет смысл не просто эмулятор, который заменяет инструкцию эмулируемого процессора на набор инструкций реального процессора (как QEMU), а такой аналог QEMU, который 1) транслирует 16-битные инструкции в 32-битные 2) вызовы 16-разрядных функций перенаправляет в реальные 32-битные функции (32-разрядные аналоги 16-разрядных API).

Как там внутри себя работает эмулятор - в данном случае дело десятое. Важно другое: то, что раньше загрузчиком помещалось в 16-разрядный сегмент _кода_, теперь должно помещаться в сегмент _данных_, а эмулятор эти данные будет интерпретировать и, в зависимости от этих _данных_, что-то там делать.

> То есть, может быть, имеет смысл такой эмулятор, который часть кода (довольно небольшую) исполняет через чистую трансляцию кода (как QEMU), а другую (основную) часть кода -- вызовы 16-разрядных API -- реализует не через интерпретацию, а через вызов реальных 32-бит API. Это я, возможно не совсем корректно, обозвал "врапперами".

Ну вот и я сказал, что дело в терминологии.

> > Вспомни, нам ведь нужно не просто 16-битные точки входа предоставить, нужно организовать выполнение кода в 16-битных объектах. Три способа (полная эмуляция, преобразование в 32 бита и замена типовых мест 32-разрядными заготовками) мы уже рассмотрели. Можно обдумать и четвёртый вариант: ограниченная поддержка 16-разрядного кода. В объёме, минимально достаточном для исполнения кода 16-битных объектов.
>
> Так эти 16-бит участки состоят из 16-битных инструкций. Можно ли их исполнять непосредственно на "голом процессоре"? По идее, можно (например, "mov ax, bx" можно делать в 32-бит программе наравне с "mov eax, ebx"), хотя, возможно, загрузчику LX-файлов придется заменять некоторые из этих инструкций на 32-битные аналоги?

Исполнять 16-разрядные коды непосредственно процессором, естественно, можно. При условии, что мы не загнали процессор в 64-разрядный режим. Но мы ведь не собираемся его всенепременно его туда загонять?
Нам только нужно позаботится, чтобы сегментные регистры содержали корректные значения. Осталось лишь оценить, насколько трудоёмкой окажется реализация поддержки этих корректных значений и какие ограничения мы при этом получим.

> То есть, возможно, тут еще один подход: 1) загрузчик LX-файлов на этапе загрузки заменяет 16-битные фрагменты на их 32-бит аналоги и второй подход: 2) эмулятор, который часть кода интерпретирует, а вызовы функций перенаправляет во внешние 32-разрядные API. Эта идея немного сумбурная -- не могу пока ясно представить, как бы это можно было реализовать...

Ну почему же "ещё один"? Именно эти варианты и назывались с самого начала.

Thu 14 Jun 2007 14:31 Mozilla/5.0 (OS/2; U; Warp 4.5; ru-RU; rv:1.7.12) Gecko/2005



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.