Где сейчас используются BCD-числа? Разве это не пережитки прошлого? Для чего их вообще "придумали"? Из всех примеров, чем приходилось заниматься, вспоминается только "удобство", которое совсем не является (как по мне) неким преимуществом по сравнению с обычной двоичной системой счисления, к тому же обладает избыточностью. Если проект сложный, обычно переходят на С или что-то подобное, который автоматически работает с двоичными числами, если простой - не вижу смысла нагружать код допольнительными командами преобразования BCD -> binary и наоборот. Может я чего-то непонял? А вы их используете? Спасибо
Инструкци для работы с BCD в настоящее время практически не используются и поэтому в 64-битном режиме AMD64\EM64T они вообще не поддерживаются Но упакованные BCD могут использоваться как промежуточное звено при преобразовании вещественных чисел в строку командой fbstp
В длинной арифметике часто используются BCD числа - чтобы не выполнять преобразование, когда их нужно будет выводить пользователю. А длинная арифметика, например, может использоваться для денежных расчетов.
halyavin Теоретически - да. Но реально длинная BCD-арифметика была целесообразна на малоразрядных и медленных компах, а на современных 32\64 битных тачках толку от BCD имхо мало, т.к. скорости обработки\преобразования сильно возросли, а сам вывод числа пользователю как был медленным, так и остался. И уж тем более для денежных расчетов исползовать BCD на современных компах смысла нет, т.к. для них 64-битной точности с лихвой хватает
S_Alex О чем это ты ? "80-битная" это фпу-шные extended c той же 64-битной мантиссой и с проблемами округления "копеек" ?
BCD-числа -- действительно в определённом смысле пережиток прошлого. Более того, в IA-32 он ещё и плохо реализован, из-за чего крайне неудобен в работе. Сама причина команд двоично-десятичной арифметики в двоичных машинах весьма проста. Как, думаю, многие догадываются, около полувека назад процессоры были немного медленнее нынешних (и занимали немного больше места), и поэтому преобразование из двоичной системы в десятичную или наоборот выполнялось весьма значительное время. Сами же решаемые задачи можно было и тогда, и сейчас грубо разделить на две категории: занимающиеся научно-техническими расчётами и предназначенные для обработки экономической информации. Первый род задач характеризуется огромным количеством вычислений при незначительном объёме ввода-вывода (грубо говоря, программа при запуске считывает из входного потока пять чисел, потом сутки их обсчитывает, после чего выдаёт на печать три числа результата ). Экономические задачи, напротив, отличаются интенсивным вводом-выводом, но сравнительно небольшими и, главное, простыми собственно вычислительными потребностями (например, для расчёта зарплаты требуется прочитать кучу входной и справочной информации -- табели учёта рабочего времени, базовые ставки по должностям, всяческие там добавки-поправки и т.п., ну а все вычисления сводятся к нескольким операциям сложения, вычитания, реже умножения и совсем редко -- деления, причем экспоненциальная форма представления чисел не используется; после завершения расчётов печатаются огромные "простыни" ведомостей на зарплату, всяческих отчётов и т.п.). В результате оказалось выгодным в случае экономических задач вводить информацию в виде обычных текстовых строк, содержащих в том числе и числа, затем быстро переводить их из распакованного формата (иначе называемого "зонном" -- каждый байт содержит код десятичной цифры в младшем полубайте и код "зоны" в старшем, предназначенной для превращения этой цифры в символьный код; для кода ASCII код зоны равен 3, а цифры имеют коды 30-39, для кода EBCDIC, применяемого в IBMовских мэйнфреймах код зоны равен F, а цифры имеют коды F0-F9) в упакованный (когда в каждом байте упакованы две десятичные цифры; операция эта элементарна), после чего проводить необходимые расчёты в упакованном десятичном виде, а перед печатью вновь преобразовывать в распакованный. По скорости это получалось значительно быстрее, чем переводить из десятичного в двоичный, потом выполнять те же самые расчёты и вновь переводить в десятичный. Что же касается самих команд, то, например, у мэйнфреймов IBM имелись команды сложения, вычитания, умножения и деления упакованных двоично-десятичных чисел переменной длины (от 1 до 16 байт, т.е. от 1 до 31 десятичной цифры, ещё один полубайт занимал знак числа). Были также некоторые вспомогательные команды, упрощающие работу с двоично-десятичными числами. В результате программировать обработку таких чисел было очень просто. В IA-32, как известно, это не так: система команд процессора содержит лишь команды десятичной коррекции вроде AAM, с помощью которых через известное место можно в цикле организовать обработку двоично-десятичных данных, причём всё это будет работать медленно: там, где мэйнфрейм обходится одной командой, например, десятичного умножения, на ПК приходится выполнять цикл из нескольких команд. Арифметический сопроцессор вроде бы поддерживает несколько более вменяемый набор команд, но сами числа имеют фиксированную длину в 10 байт и содержат 18 десятичных цифр. Таким образом, в IA-32 обработка двоично-десятичных чисел тормознутая и попросту неудобная, поэтому практического применения не нашла. Если б Интел реализовала её в стиле тех же ИБМовских мэйнфреймов, ею пользовались бы достаточно широко.
