Ассемблер: почему существует BCD?
Я знаю, что BCD похож на более интуитивный тип данных, если вы не знаете двоичный. Но я не знаю, почему использовать эту кодировку, ее как не имеет смысла, так как ее отходы представление в 4 битах (когда представление больше 9).
также я думаю, что x86 поддерживает только добавления и субтитры напрямую (вы можете конвертировать их через FPU).
возможно, что это происходит от старых машин или других архитектур?
спасибо!
10 ответов
Я думаю, что BCD полезен для многих вещей, причины приведены выше. Одна вещь, которая вроде бы очевидна, что, похоже, была упущена, - это предоставление инструкции перейти от двоичного кода к BCD и наоборот. Это может быть очень полезно при преобразовании числа ASCII в двоичный для арифметики.
один из плакатов ошибся в том, что числа часто хранятся в ASCII, на самом деле много двоичного хранения чисел сделано, потому что его более эффективно. И преобразование ASCII в двоичный немного сложно. BCD-это своего рода переход между ASCII и binary, если бы были инструкции bsdtoint и inttobcd, это сделало бы преобразования как таковые очень легкими. Все значения ASCII должны быть преобразованы в двоичные для арифметики. Таким образом, BCD действительно полезен в этом ASCII для двоичного преобразования.
арифметика BCD полезна для точных десятичных вычислений, что часто является требованием для финансовых приложений, бухгалтерского учета и т. д. Это также упрощает такие вещи, как умножение/деление на степени 10. В наши дни есть лучшие альтернативы.
хороший статья в Википедии который обсуждает за и против.
BCD полезно на очень нижнем конце спектра электроники, когда значение в регистре показано некоторым прибором вывода. Например, скажем, у вас есть калькулятор с несколькими семисегментными дисплеями, которые показывают число. Удобно, если каждый дисплей управляется отдельными битами.
может показаться невероятным, что современный процессор x86 будет использоваться в устройстве с такими дисплеями, но x86 возвращается долго путь, и ISA поддерживает большая часть обратной совместимости.
BCD является космическим расточительным, это правда, но у него есть преимущество быть формат "фиксированный шаг", что позволяет легко найти n-ю цифру в определенном числе.
еще одно преимущество заключается в том, что позволяет точные арифметические вычисления на произвольных числах размера. Кроме того, используя упомянутые характеристики "фиксированного шага", такие арифметические операции можно легко разбить на несколько потоков (параллельная обработка).
BCD существует в современных процессорах x86, так как он был в оригинальном процессоре 8086, и все процессоры x86 совместимы с 8086. Операции BCD в x86 использовались для поддержки бизнес-приложений в то время. Поддержка BCD в самом процессоре больше не используется.
обратите внимание, что BCD-это точное представление десятичных чисел, которых нет с плавающей запятой, и что реализация BCD в аппаратном обеспечении намного проще, чем реализация с плавающей запятой. Эти рода вещи важнее когда в процессорах было меньше миллиона транзисторов, работающих на нескольких мегагерцах.
В настоящее время принято хранить числа в двоичном формате и преобразовывать их в десятичный формат для отображения, но преобразование занимает некоторое время. Если основная цель числа должна отображаться или добавляться к числу, которое будет отображаться, может быть более практичным выполнять вычисления в десятичном формате, чем выполнять вычисления в двоичном формате и конвертировать в десятичный. Много приборов с численными отсчетами, и много видеоигр, хранят номера в упакованном BCD формат, в котором хранятся две цифры на байт. Вот почему многие счетчики очков переполняются на 1,000,000 точек, а не какое-то значение мощности двух. Если бы аппаратное обеспечение не облегчало арифметику упакованного BCD, альтернативой было бы не использовать двоичный код, а использовать распакованный десятичный. Преобразование упакованного BCD в распакованный decimal в момент его отображения может быть легко выполнено цифрой за раз. Преобразование двоичного кода в десятичный, напротив, намного медленнее и требует работы на всем количество.
кстати, набор инструкций 8086-единственный, который я видел с инструкциями для "ASCII Adjust for Division" и "ASCII Adjust for Multiplication", один из которых умножает байт на десять, а другой делит на десять. Любопытно, что значение "0A" является частью инструкций машины, и замена другого числа приведет к умножению или делению этих инструкций на другие величины, но инструкции не задокументированы как универсальные инструкции multiply/divide-by-constant. Интересно, почему эта функция не была задокументирована, учитывая, что она могла быть полезной?
также интересно отметить разнообразие подходов процессоров, используемых для добавления или вычитания упакованных BCD. Многие выполняют двоичное добавление, но используют флаг, чтобы отслеживать, произошел ли перенос из бита 3 в бит 4 во время добавления; затем они могут ожидать, что код очистит результат (например, PIC), предоставит код операции для добавления очистки, но не вычитание, поставьте один код операции для очистки сложения и другой для вычитания (например, x86), или используйте флаг для отслеживания, была ли последняя операция сложения или вычитания и использовать тот же код операции для очистки обоих (например, Z80). Некоторые используют отдельные опкоды для арифметики BCD (например, 68000), а некоторые используют флаг, чтобы указать, должны ли операции добавления/вычитания использовать двоичные или BCD (например, 6502 производные). Интересно, что оригинальный 6502 выполняет математику BCD с той же скоростью, что и двоичная математика, но CMOS производные ИТ требуют дополнительного цикла для операций BCD.
Я уверен, что статья Wiki, связанная с ранее, более подробно, но я использовал BCD для программирования мэйнфреймов IBM (в PL/I). BCD не только гарантировал, что вы можете посмотреть на определенные области байта, чтобы найти отдельную цифру, что иногда полезно, но также позволил аппаратным средствам применять простые правила для вычисления требуемой точности и масштаба, например, для добавления или умножения двух чисел вместе.
насколько я помню, мне сказали, что на мейнфреймах поддержка BCD была реализован в аппаратном обеспечении и в то время был нашим единственным вариантом для представления чисел с плавающей запятой. (Мы говорим 18 лет иди сюда!)
когда я был в колледже более 30 лет назад, мне сказали, почему BCD (COMP-3 в COBOL) был хорошим форматом.
ни одна из этих причин по-прежнему не актуальна для современного оборудования. У нас быстрая двоичная арифметика с фиксированной точкой. Нам больше не нужно иметь возможность конвертировать BCD в формат отображения, добавляя смещение к каждой цифре BCD. Мы редко храним числа как восемь бит на цифру, поэтому тот факт, что BCD принимает только четыре бита на цифру, не очень интересен.
BCD это реликвия, и ее следует оставить в прошлом, где ей и место.
очень немногие люди могут определять количество, выраженное в Гекса, поэтому полезно показать или, по крайней мере, позволить просмотреть промежуточный результат в десятичном формате. Особенно в финансовом или бухгалтерском мире.
современные вычисления подчеркнули кодирование, которое захватывает логику проектирования, а не оптимизирует несколько циклов процессора здесь или там. Значение времени и / или сохраненной памяти часто не стоит писать специальные процедуры битового уровня.
Это, как говорится, BCD по-прежнему иногда полезно.
один пример, который я могу придумать, - это когда у вас есть огромные плоские файлы базы данных или другие такие большие данные в формате ASCII, как CSV. BCD является удивительным, если все, что вы делаете, это смотреть для значения между некоторыми пределами. Чтобы преобразовать все значения при сканировании всех этих данных, значительно увеличится время обработки.