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

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > Но хотелось бы запускать существующие 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-разрядным аналогом в файле (конвертор) или памяти. Последнее и есть то, что ты пишешь сейчас.

__, _, __, _,_ _, _ \|_ / \ \|_) \| \| \|\/\| \| \ / \| \ \| \| \| \| ~ ~ ~ ~ `~' ~ ~