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

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

Тема:

> > > > А чтобы создать 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. Эта идея немного сумбурная -- не могу пока ясно представить, как бы это можно было реализовать...
> 
> Ну почему же "ещё один"? Именно эти варианты и назывались с самого начала.

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