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


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

Но хотелось бы запускать существующие LX-файлы если не на ARM, то например, на AMD64 и IA64 процессорах...

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

Не совсем так. Насколько я знаю про QEMU, он работает через специальный translation buffer, в котором инструкции заменяются на inline-функции, их реализующие. Он находится в сегменте данных, но потом содержимое буфера вызывается как функция (на реальном процесосре). В нашем случае еще фрагменты вида

push arg1
push arg2
...
push argN
call func
add sp,...

, вызывающие 16-бит функции, могут заменяться на аналогичные фрагменты, вызывающие 32-бит API. То есть, как я себе представляю, идет выполнение инструкций в буфере, и иногда происходят переходы на внешние функции. Получается усовершенствованный принцип работы QEMU, где часть инструкций выполняется вне эмулятора.
...
>
> Исполнять 16-разрядные коды непосредственно процессором, естественно, можно. При условии, что мы не загнали процессор в 64-разрядный режим. Но мы ведь не собираемся его всенепременно его туда загонять?

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

Но сегментные регистры "спрятаны" микроядром. То есть, опять придется вмешиваться в механизмы микроядра? Не хотелось бы вводить что-то несовместимое с общепринятыми механизмами микроядра и завязываться на это..

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

"Еще один" потому что тут предлагается сделать интерпретатор 16-битного кода, встроенный в LX- или NE-загрузчик, а не заменять типовые thunk'и 32-битными кусочками (см. мое следующее сообшение)

Thu 14 Jun 2007 14:56 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.10) 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.