Снова R8830

Где-то это уже было:

Процессоры RDC имеют серьезный bug - они, будучи типа 186, определяются как 386+. Существует хорошо известный способ программного определения типа процессора. Этот способ основан на манипуляциях с регистром флагов с целью определения какие разряды этого регистра используются, а какие являются резервными. На основании этих манипуляций делается вывод о том, является ли процессор 16- или 32-разрядным. Вот эта последовательность:

mov dl,2 ;186/286

Как я уже сказал, процессоры RDC в результате выполнения этой последовательности команд заявляют себя 386+, а значит, позволяют использовать в исполняемом коде 32-разрядные команды.

Bпервые эта "странность" проявилась при загрузке операционной системы FDOS. Поскольку FDOS является продуктом Fastwel, эту проблему решили легко и быстро внесением небольшого дополнительного кода. С уверенностью могу сказать что FDOS от 26.10.2004, без проблем работает с процессорами RDC 8830 и 1610.

2. Ассемблер и Borland C++ 3.1

Программы написанные на языке ассемблера работают на процессорах RDC без всяких проблем. Разумеется если разработчик программы явно определил тип процессора директивой .186. Программы разработанные в среде Borland C++ версии 3.1 также работают на процессорах RDC без всяких проблем. Для этого лишь необходимо правильно указать в среде разработки тип процессора: Options|Compiler|Advanced Code Generations|Instructions Set -> 186. Все приложения, разработанные ранее на языке ассемблера или с помощью Borland C++ 3.1 и успешно работавшие на процессорах AMD будут без проблем работать на процессорах RDC.

Даже если явно задавать в среде разработки тип процессора - 186, программы разработанные в этих средах будут при запуске вызывать исключение 6 (unused opcode). Причина кроется в startup-коде: программа определяет тип процессора и узнает что процессор процессор - 386+. Программа далее пытается уточнить тип процессора: 386, 486 или 586. Для этого она использует 32-разрядные инструкции, которые, разумеется, вызывают исключение "unused opcode". Можно предложить 3 способа решения этой проблемы. Первый - самый простой, но не всегда применимый - перейти на использование пакета Borland C++ 3.1. Второй - предпочтительный, но более трудоемкий - отредактировать startup-код и выбросить оттуда бесполезный и опасный кусок. Третий - установить на изделии новую версию BIOS, в которой обработчик исключения состоит из одной единственной команды IRET. Это приведет к тому что при встрече с запрещенной командой однобайтный префикс 32-разрядной команды (66h, 67h и т.п.) будет проигнорирован, а основное "тело" команды будет выполнено. Разумеется, в целом, команда будет выполнена неверно, но "опасный" участок startup-кода будет успешно пройден. Недостаток данного способа очевиден - теряется эффективное средства диагностики ошибок программирования.

4. Turbo Pascal 7.0

Ситуация с этим пакетом несколько сложнее чем с BC++. В начале программы проводится определение типа процессора - до 386 или 386 и выше. Поскольку тип процессора определен неверно, программа в ряде случаев (например, при обработке данных типа LongInt) может прибегнуть к инструкции из набора команд процессора 386, что приведет к появлению исключения 6 (unused opcode). К сожалению, ни одно из средств предложенных в п.3 для данного случая не применимо. Особенно следует предостеречь пользователя от использования BIOS с "игнорирующим" обработчиком исключения "unused opcode". Единственное что я могу посоветовать пользователям TP 7.0 - совершенно отказаться от типов данных размером более 16-и разрядов.

Program Main;

begin

initialization
{$IFNDEF WIN32}
{$IFDEF UseRDC8k}
  Test8086 := 0;
{$ENDIF}
{$ENDIF}
end.

Нас это СПАСАЕТ !!!!

Главное - чтобы это было первым исполняемым кодом в программе.