Comments 14
Ну когда-то давно такие вещи казались актуальным и нужным (помню еще время первых PC).
Просто мир меняется… и порой кажется что мы за ним уже не поспеваем, не то что программы 10+ летней давности…
Просто мир меняется… и порой кажется что мы за ним уже не поспеваем, не то что программы 10+ летней давности…
Поэтому разработчик системных библиотек должен каждый день задавать себе глупые с виду вопросы:
А что, если компьютер будет работать в миллион раз быстрее?
А что, если программа запущена после 2038 года?
А что, если железо реализует вещественные числа не по IEEE 754?
А что, если компьютер будет работать в миллион раз быстрее?
А что, если программа запущена после 2038 года?
А что, если железо реализует вещественные числа не по IEEE 754?
А что если каждые два года начнут клепать новую версию одного и того же языка программирования?
Вы просто плохо представляете те времена.
Тогда довольно трудно было представить, что через десять+ лет:
1. вашу программу/библиотеку все еще будут использовать
2. что железо лежащее в кармане будет работать быстрее и обладать гораздо большими ресурсами чем здоровенный ящик с громоздким ЭЛТ монитором.
Ведь вроде ж не дурак был Билли, но про 640Мб, которых хватит всем и навсегда от таки умудрился сказануть…
Тогда довольно трудно было представить, что через десять+ лет:
1. вашу программу/библиотеку все еще будут использовать
2. что железо лежащее в кармане будет работать быстрее и обладать гораздо большими ресурсами чем здоровенный ящик с громоздким ЭЛТ монитором.
Ведь вроде ж не дурак был Билли, но про 640Мб, которых хватит всем и навсегда от таки умудрился сказануть…
Но я заметил, что большинство программистов никогда не задумывалось, почему оно так вышло.
В своё время все про эту проблему знали. Сейчас об этой проблеме забыли, т.к. в реальности с ней столкнуться уже невозможно: много ли пользователей запускают DOS-программы на современных компьютерах в нативном режиме, а не каком-нибудь DosBox, который по умолчанию ограничивает скорость выполнения инструкций?
Т.е. для обычных, доступных всем компьютеров, такое ускорение было достигнуто примерно с 1981 по 2002 год.
По моему личному опыту, максимально быстрый процессор, который не вызывает эту ошибку был первопень на 200 мегагерц, можно ММХ. А вот 233МГц уже вызывали ошибку. Но уже во время достижения 200 мегагерц мы пользовались пропатченой либой CRT для компиляции своих программ. А для тех программ что нельзя пересобрать был доступен специальный патч.
Делением на ноль это прерывание обозвали авторы runtime library, по-видимому, для краткости. А в документации от Intel оно называется более корректно — «divide error». Вот, к примеру, цитата из Intel 8086 Family User's Manual:
Так что это не разработчики x86 вводят в заблуждение, а кто-то, кто не удосужился прочитать документацию до конца.
The CPU itself generates a type 0 interrupt immediately following execution of a DIV or IDIV (divide, integer divide) instruction if the calculated quotient is larger than the specified destintion.
Так что это не разработчики x86 вводят в заблуждение, а кто-то, кто не удосужился прочитать документацию до конца.
Никто не упомянул, зачем все это нужно было.
Всего лишь для реализации функции паузы.
Чуть дополню, нужно для модной точной паузы в миллисекундах. Прерывания времени в DOS щёлкали каждые 55мс, но разработчики Турбо Паскаля решили помочь программистам и реализовали возможность паузы с точностью до 1мс. Достигалось это как раз тем, что при инициализации запускался цикл и выяснялось, сколько итераций происходило за 55мс. Соответственно, во время паузы крутился цикл с нужным количеством итераций.
Патчили CRT обычно убиванием этой проверки, т.е. побочный эффект от этого — спячка становилась опять дискретной.
Патчили CRT обычно убиванием этой проверки, т.е. побочный эффект от этого — спячка становилась опять дискретной.
Sign up to leave a comment.
Скорость в попугаях