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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : Юрий Пронякин
Subj : Вернемся с небес на землю (злосчастный кусок)
> > Что-то я не понял. -- То есть как? У нас 32-битное микроядро. 16-битные функции находятся в 16-битных сегментах.
>
> Небольшое уточнение: нам в этом случае не нужны 16-битные функции. Нужны 16-битные точки входа в 32-разрядные функции.
>

в принципе, верно...

> > А чтобы создать 16-битный сегмент, надо создать его дескриптор в GDT или LDT. "Allocate GDT selector" реализуется в ядре OS/2 как device helper, то есть, это интерфейс ядра. Полностью же 32-битное микроядро таких интерфейсов не предоставляет (по крайней мере, L4).
>
> Ну и что? Интерфейс можно же и добавить. При этом само микроядро останется полностью 32-битным.
>

Как бы это не было из серии "а бантик-то гвоздиком прибили...". То есть, такой интерфейс должен хорошо вписываться в остальные механизмы микроядра... Кроме того, сегментная модель не имеет аналогов на других процессорах, кроме x86, а хотелось бы, чтобы решение работало и для ARM и прочих процессоров...

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

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


> "Враппер" - это тонкая прослойка между вызываемой извне точкой входа и другой функцией, в которой собственно рабочий код и находится; причём прослойка эта выполняется непосредственно процессором.

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

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


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