Полигон-2

pahan написал:

[q]

Отличаются от чего? От тех же самых операций над теми же самыми числами на том же или другом сопроцессоре? И кстати, в какой разрядности (32, 64, 80 бит) проводятся вычисления и в какой выводится конечный результат?

[/q]

Отличаются по ходу выполнения программы, спустя микросекунду или сколько там времени нужно на следующее вычисление.
Алгоритм такой:
- цикл от 1 до 255.
а(i):=X_случайное число умножить на Y_случайное число
b(i):=X_случайное число делить на Y_cлучайное число
конец цикла
- цикл от 2 до 255
если a(1)>>a(i) то аварийный останов с выдачей несовпадения a(1) и a(i)
если b(1)>>b(i) то аварийный останов с выдачей несовпадения b(1) и b(i)
конец цикла
И такие итреации крутятся в главном цикле от 1 до 65535.
Так вот, останов по ошибке умножения выпадает спустя 100...300 итреаций.
Останов по ошибке деления - никогда!
Разрядность массивов результатов умножения и деления = real - кажется это 32 байт. На 9 знаке выпадает ошибка.
Пришлось уменьшить разрядность до single = 8 байт - сейчас нет под рукой хэлпа по Турбо Паскалю, а память стала подводить, но вроде разрядность такая.
Причем отлаживал я прогу на 386/387SX с сопроцессором ULSI (не на 8087, уж очень все медленно на ХТ).
Я не исследовал детально этот феномен. Можно попробовать компильнуть без сопроцессора, а задав его эмуляцию и сравнить результат. Можно попробовать не чередовать умножение и деление (может что-то где-то засоряется в регистрах), а выполнить подряд только умножение и сравнить... Но это если меня снова пробьет на программирование. Пока что стояла задача понять, можно ли использовать 8087 на повышенных частотах, и если да, то каков критерий рабочести, а если нет, то почему.

Что-то у меня этот редактор нашего форума индекс i в квадратных скобках воспринимает, как тэг курсива. Пришлось ставить круглые скобки. А как отключать тэги в сообщении?

Все числа внутри FPU всегда числа с расширенной точностью.

При загрузке числа одинарной, двойной точности целого - FPU просто
преобразует любое число в формвт расширенной точности, при выгрузке
числа в память - наоборот(в зависимости от того с какой точностью
работаем).

Ни о каком отбрасывании или обнулении неиспользуемых бит разговор
не идет. Да и форматы чисел с плавающей точкой не такие чтобы можно
было что-то отбрасывать.

Для большей ясности уточню: нулями может дополняться только мантисса, порядок числа хранится
смещенным(на 127 для чисел одинарной точности, если память не изменяет) и соответственно
дополнение нулем или единицей зависит от от знака порядка(крайние порядки зарезервированы для
специальных значений).
Конечно в разогнанном FPU возможны какие угодно сбои, как Вы совершенно справедливо отметили.

sanders написал:

[q]

Я отлаживал программу и столкнулся с погрешностью НА НЕРАЗОГНАННОМ 387SX ULSI

[/q]

Лучше-бы отладка проводилась на DX40, 486-го поколения. Там хотя-бы нет разбежки частот проца с сопром, возможных издержек на этой почве.
А поскольку целевой сопр именно 8087, то и на нём стоило отлаживать, ибо также нет разбежки частот, несмотря на отдельность чипа.

X и Y постоянные случайные числа! Не разные.
Грубо говоря я 255 раз умножаю 2 на 2 и запоминаю результат. Потом проверяю. Если все 255 раз ответ был 4, то меняю операнд и снова 255 раз... И вдруг на каком-то этапе ответ не сходится единственный раз из 255. Почему ответ не 4? Причем 254 раза ответ 4, а 255й не 4. Вот я о чем.
Я бы понял, если бы сопроцессор неправильно умножал 2 на 2. Но он бы одинаково неправильный ответ давал все 255 раза. А он дает единственный неверный результат из 255. Операнд 2 на 2 выбран для демонстрации идеи.
Пользовался Turbo Pascal 6.0 со встроенным компилятором.