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

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

Тема:

> > Я про 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-разрядные программы - виртуальные машины американские правоблюстители пока не запретили.

_, _, _, _, _ _, _,_ (_ \| / \ \|\ \| / \ \|_/ , ) \| , \ / \| \\| \ / \| \ ~ ~~~ ~ ~ ~ ~ ~ ~