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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Юрий Пронякин
To : Igor Vaskov
Subj : Тут надо определиться :)
> Я про 64 бита пока не говорил.

Я, кстати, тоже :-)

> Кстати, как такая идея? Сделать эмулятор для выполнения 16-и битного кода. Т.е. такую хитрую пробирку, но только не для системы в целом, а только для кода? Да, будет не сильно быстро, но проблему решит. В принципе же можно написать 32-х битный интерпретатор бинарного 16-и ричного кода. Кстати, а коротенько для чайников, вроде меня, расшифруйте в чем проблема 16/32/64? Именно в командах ассемблера или только в адресации? В 64 битном режиме можно выполнить mov ax, bx или нет?

У процессоров x86 своеобразная система команд. Одни и те же коды команд могут обозначать разные команды в зависимости от контекста. Одним из элементов контекста является разрядность того сегмента кода, в котором находится данная команда.
Когда процессор работает в 32-разрядном режиме, у него могут быть только 16- и 32-разрядные сегменты кода. А когда он работает в 64-разрядном режиме, сегменты кода могут быть только 32- и 64-разрядные (разрядность сегмента определяется одним битиком в его дескрипторе). Поэтому как бы мы ни извращались, но _правильно_ проинтерпретировать последовательность кодов, предназначенную для помещения в 16-разрядный сегмент, процессор не сможет.
Но это не означает, что выхода нет. Возможных решений даже несколько. Например:
1. Уже названный интерпретатор (эмулятор).
2. Загрузчик LX-файлов может иметь встроенный декомпилятор и в процессе загрузки переводить 16-разрядные объекты в соответствующий 32-разрядный код.
3. Упомянутые объекты никто ведь руками не писал, это thunk-и, вставленные компилятором для вызова 16-разрядных функций OS/2 из 32-разрядного кода. У каждого компилятора thunk-и свои, типовые, и компиляторов у нас совсем не много, поэтому загрузчик может иметь встроенную систему опознавания, которая будет подменять в программе call, направленный на thunk, call-ом на заранее заготовленный 32-разрядный аналог (или вообще сразу на соответствующую 32-разрядную функцию нового ядра).
4. Можно написать конвертор LX-файлов в полностью 32-разрядные (по аналогии с Одиновским конвертором).

> Одно несоменно - новое ядро обязано поддерживать весь старый софт включая 16-и битный. Иначе это будет не ядро OS/2, а ядро какой-то другой системы.

Написанное выше - о том, как можно исполнять 32-разрядные программы OS/2 в 64-разрядном режиме. Что же до совместимости с OS/2... Безусловным является одно: должны работать 32-разрядные программы, PM и WPS. Остальное зависит от поставленной цели и выбранного направления развития. Если окажется, что это направление несовместимо с 16-разрядным кодом или включение такой поддержки требует чрезмерно больших усилий, то от старого лучше отказаться. Мне, например, сейчас очень не нравится, что у программ память разорвана на куски: отдельно нижняя область памяти, отдельно - верхняя.
А если в такой ситуации кому-то очень нужно будет запускать 16-разрядные программы - виртуальные машины американские правоблюстители пока не запретили.

Thu 07 Jun 2007 13:57 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.