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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Юрий Пронякин
To : valerius
Subj : Вернемся с небес на землю (злосчастный кусок)
> Но хотелось бы запускать существующие LX-файлы если не на ARM, то например, на AMD64 и IA64 процессорах...

Пожалуйста. Если не в 64-битном режиме, то аж 4 (если не ошибаюсь) способа уже предложили. Осталось выбрать тот, реализация которого наименее затратная - для начала. Потом, при необходимости, можно и другие методы реализоывать.
В 64-битном режиме остаются 3 способа, но его актуальность пока невелика. Да к тому же наимее трудоёмким вполне может оказаться эмулятор, а он в любом режиме процессора одинаково работать будет.

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

Так я и говорю: не важно, как работает эмулятор. Принципиальным является то, что байты 16-разрядного кода из LX-файлов для него являются входными _данными_.

> Он находится в сегменте данных, но потом содержимое буфера вызывается как функция (на реальном процесосре). В нашем случае еще фрагменты вида
>
> push arg1
> push arg2
> ...
> push argN
> call func
> add sp,...
>
> , вызывающие 16-бит функции, могут заменяться на аналогичные фрагменты, вызывающие 32-бит API. То есть, как я себе представляю, идет выполнение инструкций в буфере, и иногда происходят переходы на внешние функции. Получается усовершенствованный принцип работы QEMU, где часть инструкций выполняется вне эмулятора.

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

> Но сегментные регистры "спрятаны" микроядром. То есть, опять придется вмешиваться в механизмы микроядра?

Почему "опять"?

> Не хотелось бы вводить что-то несовместимое с общепринятыми механизмами микроядра и завязываться на это..

Не хотелось бы. Но мы же ищем самый легкореализуемый (и практичный) способ. Поэтому просто обязаны оценить трудозатратность и этого варианта тоже.

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

И тем не менее, этот вариант уже предлагался. Вспомни:
1. Замена thunk-ов прямыми вызовами
2. Интерпретация кода до точек вызова функций ядра.
3. Замена кода 32-разрядным аналогом в файле (конвертор) или памяти. Последнее и есть то, что ты пишешь сейчас.

Thu 14 Jun 2007 17:38 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.