LINUX.ORG.RU
ФорумTalks

BCD числа живы?

 ,


0

1

Конкурс по Си и показанные там более или менее низкоуровневые подходы заставил вспомнить как года 3 назад читал учебник Юрова по Ассемблеру и там было такое машинное представление числа как двоично-десятичные числа. А для архитектуры amd64 их еще используют или R.I.P.? И вообще в чем была практическая выгода от их использования на x86?

★★★★★

Последнее исправление: Twissel (всего исправлений: 1)

Профит от BCD - когда нужно работать числами в 10-30 знаков длинной, BCD куда проще переводить в человеко-читаемое представление. (Представьте как вы будете делить обычный 128-битный integer в цикле на 10, что-бы отобразить его на экране на каком-нибудь 80286, на это же вечность уйдет, там операция деления и так не подарок тактов 50 на деление двух 16-битных чисел, а когда приходится вручную реализовывать столбик для такой высокой разрядности - будет вообще ахтунг полный).

qrck ★★
()
Ответ на: комментарий от qrck

Хорошо. А мне где-то не очень давно попадалось, что на amd64 они не используются, это так, Вы не в курсе?

Twissel ★★★★★
() автор топика
Ответ на: комментарий от gadfly

У них - сами себе выпустили, сами подписали. Издатель: wasm.ru Субъект: wasm.ru

VinilNavigator
()
Ответ на: комментарий от gadfly

Не чудить так и есть. Все меняется, ресурс который лет 6 назад был форумом кулхацеров, сейчас, мне показалось, тихо помирает...

Twissel ★★★★★
() автор топика
Ответ на: комментарий от qrck

что-бы отобразить его на экране (...) ахтунг полный

этот ахтунг- сотые доли процента от ресурсов необходимых чтобы отобразить число на экране (сотни/тысячи пикселов с хитингами, векторными шрифтами и прочим),
а кроме как на экране оно нигде не нужно, а при передаче по сети/записи/в памяти/кэше больший объём имеет значение - 40 лет назад, когда при печати на стандартный вывод было видно, как зелёный курсор бегает по экрану, это имело смысл, а сейчас вангую заглушку из микрокода вместо реальной аппаратной поддержки у большинства процессоров.

Anonymous ★★★★★
()
Ответ на: комментарий от qrck

там операция деления и так не подарок тактов 50 на деление двух 16-битных чисел

22 такта. Вообще, BCD всегда жрёт ресурсов больше, чем при реализации через честные двоичные операторы. Потому этот метод и не прижился. Зато позволял хранить точные числа высокой разрядности. Потому и заводили.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

О, рад видеть в топике :) Спасибо за ответ.

Twissel ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Я про то, что при отображении на экран - делить таки не нужно было, так что это было заметно быстрее, и что немаловажно - гораздо проще в коде.

qrck ★★
()
Ответ на: комментарий от KRoN73

ЗЫ не помню откуда у меня в голове страшные цифры про 50 тактов, да,286ой так за 22 такта регистры и за 25 память делит, но можно крутануть рычаг машины времени чуть сильнее, 8086ой - 170-190 тактов на div с одним из операндов расположенным в памяти. Я не знаю сколько точно делений и умножений потребуется на деление 128 бит не BCD числа в столбик на 16 битное число (10), но явно дофига, мои мозги говорят что штук 8 минимум 16ти битных делений, раза в 2 больше 16 битных умножений, итого - порядка 2000 тактов что-бы поделить 128-ти битный integer на 10 один раз, эту операцию надо проделать раз 20, что-бы отобразить все цифры числа, итого - 40k тактов. Если чисел на экране штук 20(вполне нормальная ситуация для финансового приложения), выходит под 800k тактов только на перевод чисел в человеческое представление. Тактовая частота первых 8086 была что-то на уровне 4 MHz, т.е. на обсчет чисел, без их отображения, уже уходило бы по 0.2 секунды.

qrck ★★
()
Последнее исправление: qrck (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.