Скорость в попугаях

[Sly_tom_cat]

Ну когда-то давно такие вещи казались актуальным и нужным (помню еще время первых PC).

Просто мир меняется… и порой кажется что мы за ним уже не поспеваем, не то что программы 10+ летней давности…

[Fedorkov]

Поэтому разработчик системных библиотек должен каждый день задавать себе глупые с виду вопросы:
А что, если компьютер будет работать в миллион раз быстрее?
А что, если программа запущена после 2038 года?
А что, если железо реализует вещественные числа не по IEEE 754?

[nerudo]

А что если каждые два года начнут клепать новую версию одного и того же языка программирования?

[Fedorkov]

Тогда разработчик получит ошибку компиляции или deprecation warning.

[vladimirad]

Два года?
У меня сайтик на Вордпрессе ругается на устаревший РНР 7.3

[Sly_tom_cat]

Вы просто плохо представляете те времена.
Тогда довольно трудно было представить, что через десять+ лет:
1. вашу программу/библиотеку все еще будут использовать
2. что железо лежащее в кармане будет работать быстрее и обладать гораздо большими ресурсами чем здоровенный ящик с громоздким ЭЛТ монитором.

Ведь вроде ж не дурак был Билли, но про 640Мб, которых хватит всем и навсегда от таки умудрился сказануть…

[Dukarav]

Эх, если бы про 640Мб, Билли говорил про 640 Кб ((

[Sly_tom_cat]

Да, давно это было… уже даже трудно представить что про 640Кб была речь а не про 640Мб…

[Fedorkov]

Билл Гейтс этого не говорил. Про закон Мура слышали все, и всем было очевидно, что мы в течение одной человеческой жизни застанем рост производительности на много порядков.

[DistortNeo]

Но я заметил, что большинство программистов никогда не задумывалось, почему оно так вышло.

В своё время все про эту проблему знали. Сейчас об этой проблеме забыли, т.к. в реальности с ней столкнуться уже невозможно: много ли пользователей запускают DOS-программы на современных компьютерах в нативном режиме, а не каком-нибудь DosBox, который по умолчанию ограничивает скорость выполнения инструкций?

[HardWrMan]

Т.е. для обычных, доступных всем компьютеров, такое ускорение было достигнуто примерно с 1981 по 2002 год.

По моему личному опыту, максимально быстрый процессор, который не вызывает эту ошибку был первопень на 200 мегагерц, можно ММХ. А вот 233МГц уже вызывали ошибку. Но уже во время достижения 200 мегагерц мы пользовались пропатченой либой CRT для компиляции своих программ. А для тех программ что нельзя пересобрать был доступен специальный патч.

[rutenis]

Делением на ноль это прерывание обозвали авторы runtime library, по-видимому, для краткости. А в документации от Intel оно называется более корректно — «divide error». Вот, к примеру, цитата из Intel 8086 Family User's Manual:

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 вводят в заблуждение, а кто-то, кто не удосужился прочитать документацию до конца.

[Mishootk]

Никто не упомянул, зачем все это нужно было.
Всего лишь для реализации функции паузы.

[force]

Чуть дополню, нужно для модной точной паузы в миллисекундах. Прерывания времени в DOS щёлкали каждые 55мс, но разработчики Турбо Паскаля решили помочь программистам и реализовали возможность паузы с точностью до 1мс. Достигалось это как раз тем, что при инициализации запускался цикл и выяснялось, сколько итераций происходило за 55мс. Соответственно, во время паузы крутился цикл с нужным количеством итераций.

Патчили CRT обычно убиванием этой проверки, т.е. побочный эффект от этого — спячка становилась опять дискретной.