Внимание! Это временный неофициальный архив старой версии форума Полигон Призраков, созданный сочувствующим форуму участником. Этот сайт просуществует лишь до тех пор, пока администрация Полигона не сдержит своё обещание и не откроет официальный архив по адресу old.sannata.org.

Полигон-2

Форум о старых компьютерах

Объявление форума

Если пользуетесь личными сообщениями и получили по электронной почте оповещение о новом письме, не отвечайте, пожалуйста, почтой. Зайдите на форум и ответьте отправителю через ЛС.

Полигон-2 »   IBM PC-совместимое. До 2000 года включительно »   Сопроцессоры 8087 и утилита mcpdiag
RSS

Сопроцессоры 8087 и утилита mcpdiag

<<Назад  Вперед>> Страницы: 1 2 3 4 5 6 * 7
Печать
 
Fe-Restorator
Гость

Ссылка

i8088 написал:
[q]
FPU просто преобразует любое число в формвт расширенной точности,
[/q]
Вот на этом этапе и происходит дополнение нулями до нужного формата чисел. Токма в разогнанном сопре обнуление не всегда надёжно - появление самопроизвольных бит весьма вероятно, оно и вносит ошибки в вычисления.
Сейчас на форуме
i8088
Advanced Member


Откуда: г. Баку, Азербайджан
Всего сообщений: 2132
Рейтинг пользователя: 0


Ссылка


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

Откуда: Санкт-Петербург
Всего сообщений: 6434
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
26 мар. 2008
Господа, вы уже спориите на абстрактные темы. Вы ушли от фактов и выхватываете верхушки, не анализируя связи.
Я отлаживал программу и столкнулся с погрешностью НА НЕРАЗОГНАННОМ 387SX ULSI. А во-вторых, ваши теории неверны, поскольку при делении погрешность не возникает. В-третьих, абсурдно предполагать, что какие-то биты не обнуляются. 299 раз обнулились, а на 300й нет?
Вот вернется у меня программисткое настроение, тогда проверю на разных процессорах, сопроцессорах и с разными форматами данных. Может, просто в компиляторе ошибка, как много их было в макросах Экселя 6.0
Fe-Restorator
Гость

Ссылка

sanders написал:
[q]
Я отлаживал программу и столкнулся с погрешностью НА НЕРАЗОГНАННОМ 387SX ULSI
[/q]
Лучше-бы отладка проводилась на DX40, 486-го поколения. Там хотя-бы нет разбежки частот проца с сопром, возможных издержек на этой почве.
А поскольку целевой сопр именно 8087, то и на нём стоило отлаживать, ибо также нет разбежки частот, несмотря на отдельность чипа.
Сейчас на форуме
i8088
Advanced Member


Откуда: г. Баку, Азербайджан
Всего сообщений: 2132
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
30 янв. 2015
sanders написал:
[q]
Господа, вы уже спориите на абстрактные темы.
[/q]
Согласен, я люблю теорию!
Вполне возможно и ошибка в компиляторе, однозначно можно проверить
написав все на ассемблере. Кстати что за компилятор у Вас? Можно
попробовать откомпилировать другим компилятором или по крайней
мере другой версией компилятора.

С разными версиями компилятора(или компиляторы разных фирм) часто
требуется некоторая коррекция программы, но это решаемо.

Сейчас обратил внимание на Ваш алгоритм
[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)
конец цикла
[/q]
Те Вы пользуетесь функцией rnd для генерации случайное чисел? Может быть погрешность
возникает просто при некоторых сочетаниях операндов, поэтому и не сразу проявляется?

Проверьте на более современных FPU, там такое наблюдается? Надо поискать errata
документы для старых FPU, какие ошибки были найдены.
sanders
Advanced Member
Профессионал

Откуда: Санкт-Петербург
Всего сообщений: 6434
Рейтинг пользователя: 0


Ссылка


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


Откуда: г. Баку, Азербайджан
Всего сообщений: 2132
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
30 янв. 2015
Хмм, интересно.
Давайте проверим на более современных CPU со встроенным FPU: 486, Pentium.
pahan
Advanced Member


Откуда: Химки, М.О.
Всего сообщений: 1070
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
13 мар. 2015
[q]
X и Y постоянные случайные числа! Не разные.
Грубо говоря я 255 раз умножаю 2 на 2 и запоминаю результат. Потом проверяю. Если все 255 раз ответ был 4, то меняю операнд и снова 255 раз... И вдруг на каком-то этапе ответ не сходится единственный раз из 255. Почему ответ не 4? Причем 254 раза ответ 4, а 255й не 4.
[/q]
А ещё какие-то закономерности есть? Ошибка вываливается только на конкретных парах операндов/шагах цикла или всегда на разных?
sanders
Advanced Member
Профессионал

Откуда: Санкт-Петербург
Всего сообщений: 6434
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
26 мар. 2008
Всегда на разных итерациях. Минимум 90я итреация, максимум 400я.
На разных операндах. Одинаковые невозможно получить никогда, т.к. они берутся из генератора случайных чисел.
Результат при ошибке я выводил на экран для себя, и он имел вид: " x,xxxxxxxxxxxx..... Enn >> x,xxxxxxxxYYYY... Enn "
x- совпадающие цифры, y- отличающиеся, nn - 10 в степени nn.
Т.е. результаты представлены в виде десятичной степени. Начиная с 9го, максимум с 10го знака начинались расхождения.
После этого я уменьшил разрядность вычислений до SINGLE, и остались только 8 знаков после запятой, которые всегда совпадают.
Кстати, я не проверял сколько расхождений в массиве из 255 результатов. Может одно расхождение, а может что-то идет вразнос, и там все результаты отличные друг от друга (после 8й цифры). Я делал останов по первому расхождению.
Да, есть пища для размышлений, но нет пока желания снова попрограммировать.
GrumpyCat
Advanced Member


Откуда: Москва
Всего сообщений: 564
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
22 июля 2014
sanders
Похоже, это известный глюк, наблюдаемый на ULSI.

Проверьте вот это (запускать в цикле):
>1. Беpём два числа (тип double):
>a = 8.41829604081856E-1 и b = 1.58170394306106E-1
>2. Складываем: c = a + b
>3. И можем получить:
> а) Пpавильный pезультат;
> б) Hепpавильный pезультат (лажа после 9го знака);
> в) Ошибку сопpоцессоpа.

и вот это (естественно тоже в цикле):
>глюк в сопре ulsi. при операции типа 2.2345678 + 0.7654321
>он иногда выдает не 2.9999999, а ошибку.
<<Назад  Вперед>> Страницы: 1 2 3 4 5 6 * 7
Печать
Полигон-2 »   IBM PC-совместимое. До 2000 года включительно »   Сопроцессоры 8087 и утилита mcpdiag
RSS

1 посетитель просмотрел эту тему за последние 15 минут
В том числе: 1 гость, 0 скрытых пользователей

Последние RSS
[Москва] LIQUID-Акция. Сливаются разъемы CF
МС7004 и 7004А на AT и XT
Пайка термотрубок
Проммать s478 PEAK 715VL2-HT ( Full-Size SBC)
Подскажите по 386 материке по джамперам.

Самые активные 5 тем RSS