Объявление форума |
Если пользуетесь личными сообщениями и получили по электронной почте оповещение о новом письме, не отвечайте, пожалуйста, почтой. Зайдите на форум и ответьте отправителю через ЛС. |
Полигон-2 » IBM PC-совместимое. До 2000 года включительно » Сопроцессоры 8087 и утилита mcpdiag |
<<Назад Вперед>> | Страницы: 1 2 3 4 5 6 * 7 | Печать |
Fe-Restorator |
Сообщение отправлено: 17 апреля 2015 9:31
i8088 написал: Вот на этом этапе и происходит дополнение нулями до нужного формата чисел. Токма в разогнанном сопре обнуление не всегда надёжно - появление самопроизвольных бит весьма вероятно, оно и вносит ошибки в вычисления. FPU просто преобразует любое число в формвт расширенной точности, |
Сейчас на форуме |
i8088
Advanced Member
Откуда: г. Баку, Азербайджан Всего сообщений: 2132 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 30 янв. 2015 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 17 апреля 2015 10:57 Сообщение отредактировано: 17 апреля 2015 11:02
Для большей ясности уточню: нулями может дополняться только мантисса, порядок числа хранится смещенным(на 127 для чисел одинарной точности, если память не изменяет) и соответственно дополнение нулем или единицей зависит от от знака порядка(крайние порядки зарезервированы для специальных значений). Конечно в разогнанном FPU возможны какие угодно сбои, как Вы совершенно справедливо отметили. |
sanders
Advanced Member
Профессионал Откуда: Санкт-Петербург Всего сообщений: 6434 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 26 мар. 2008 |
Господа, вы уже спориите на абстрактные темы. Вы ушли от фактов и выхватываете верхушки, не анализируя связи. Я отлаживал программу и столкнулся с погрешностью НА НЕРАЗОГНАННОМ 387SX ULSI. А во-вторых, ваши теории неверны, поскольку при делении погрешность не возникает. В-третьих, абсурдно предполагать, что какие-то биты не обнуляются. 299 раз обнулились, а на 300й нет? Вот вернется у меня программисткое настроение, тогда проверю на разных процессорах, сопроцессорах и с разными форматами данных. Может, просто в компиляторе ошибка, как много их было в макросах Экселя 6.0 |
Fe-Restorator |
NEW! Сообщение отправлено: 18 апреля 2015 10:03 Сообщение отредактировано: 18 апреля 2015 10:07
sanders написал: Лучше-бы отладка проводилась на DX40, 486-го поколения. Там хотя-бы нет разбежки частот проца с сопром, возможных издержек на этой почве. Я отлаживал программу и столкнулся с погрешностью НА НЕРАЗОГНАННОМ 387SX ULSI А поскольку целевой сопр именно 8087, то и на нём стоило отлаживать, ибо также нет разбежки частот, несмотря на отдельность чипа. |
Сейчас на форуме |
i8088
Advanced Member
Откуда: г. Баку, Азербайджан Всего сообщений: 2132 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 30 янв. 2015 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 18 апреля 2015 12:00 Сообщение отредактировано: 18 апреля 2015 12:12
sanders написал: Согласен, я люблю теорию! Господа, вы уже спориите на абстрактные темы. Вполне возможно и ошибка в компиляторе, однозначно можно проверить написав все на ассемблере. Кстати что за компилятор у Вас? Можно попробовать откомпилировать другим компилятором или по крайней мере другой версией компилятора. С разными версиями компилятора(или компиляторы разных фирм) часто требуется некоторая коррекция программы, но это решаемо. Сейчас обратил внимание на Ваш алгоритм Те Вы пользуетесь функцией rnd для генерации случайное чисел? Может быть погрешность - цикл от 1 до 255. возникает просто при некоторых сочетаниях операндов, поэтому и не сразу проявляется? Проверьте на более современных FPU, там такое наблюдается? Надо поискать errata документы для старых FPU, какие ошибки были найдены. |
sanders
Advanced Member
Профессионал Откуда: Санкт-Петербург Всего сообщений: 6434 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 26 мар. 2008 |
Профиль | Сообщить модератору
NEW! Сообщение отправлено: 18 апреля 2015 15:03 Сообщение отредактировано: 18 апреля 2015 15:10
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 |
А ещё какие-то закономерности есть? Ошибка вываливается только на конкретных парах операндов/шагах цикла или всегда на разных? X и Y постоянные случайные числа! Не разные. |
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 |
1 посетитель просмотрел эту тему за последние 15 минут |
В том числе: 1 гость, 0 скрытых пользователей |
Последние | |
[Москва] LIQUID-Акция. Сливаются разъемы CF МС7004 и 7004А на AT и XT Пайка термотрубок Проммать s478 PEAK 715VL2-HT ( Full-Size SBC) Подскажите по 386 материке по джамперам. |
Самые активные 5 тем | |