Немного оффтоп. Самое смешное, что MySQL еще лет 10 тому хранил и обрабатывал NUMERIC не как BCD, а как Float. С потерей точности на операциях. И приходилось людям объяснять, почему биллинг нельзя просто так перенести на MySQL. Может он и сейчас такой ущербный, лень проверять.
При научных вычислениях, когда нужно быстрее, так как вычислений МНОГОСообщение от Vslav
Ну а чё, вместо того, что бы написать соответствующие процедуры, берём float - и всё типа тип-топ. Ключевое слово - типа
- - - Добавлено - - -
Я тут прикинул так на пальцах, если делать для (современного) проца что то типа CIS от DEC, то надо максимальную длину BDC числа делать не 31 (десятичная) цифра, а 124
Последний раз редактировалось Hunta; 14.10.2020 в 19:52.
Угу, и моделированием плазмы в фронте волны ядерного взрыва я тоже занимался. Но это было еще до кассовых аппаратовПри научных вычислениях, когда нужно быстрее, так как вычислений МНОГО
На СМ4 с FIS, потом СМ1420 с FPP. Сначала ты две недели считаешь, потом проводишь проверку законов сохранения заряда, имульса и энергии и ничего не сходится, начинаешь искать где же оно точность потеряло. Блин, фортрановский REAL, оказывается фигня, DOUBLE? Ну здравствуйте, виртуальные массивы
Но мой пост был о том что кассовый аппарат - это навороченная бухгалтерская программа - скидки, налоги, конвертация валют, проценты за услуги, накопительные итоги, весовые товары - дофига всего бухгалтерского, и вполне нормально живет без этих ваших флоат и бцд.
Последний раз редактировалось Vslav; 14.10.2020 в 21:31.
А расскажи про 4-bit ALU в серии AM2900: зачем там отдельный флаг для переноса, если число == 10?
В Am2900 такого флажка не припомню. А вот в 8080 оно есть, да. Ну не все умеют в кассовый аппарат без float. Вот для людей попроще такой флажок и сделали
Ты бы видел структуру дневного Z-отчета. Там все упаковано-переупаковано, какой там BCD, размер фискальной памяти очень жесткий, изволь 2100 отчетов (7 лет срок службы, 2100 минимум для сертификации надо) в 64К засунуть, бо 128К уже денег больше стоит.
Насчет точности BCD для десятичной плавучке - оно возможно, но для бухгалтерии точность банально решается увеличением разрядности (см. кассу), для научки тоже нужна разрядность, но точность там менее критична (более того - точность десятичных дробей там бессмысленна), скорость важнее - BCD в пролете. Единственное реальное преимущество BСD - это быстро делить/умножать на 10, в остальном оно сомнительно. Ну и да, историческая совместимость, для фана. 8080 инструкцию для BCD имеет, а вот SSE/AVX инструкций для BCD не видать
Последний раз редактировалось Vslav; 14.10.2020 в 22:02.
yu.zxpk(14.10.2020)
Ещё раз напомню, когда это всё первоначально создавалось. Какие, блин, микропроцессоры, какие, блин 64 кб памяти?? Вот и запихали формат, который удобен хранения и вычислений на уровень команд. Да, сейчас всё это уже не сильно применимо в силу разрядности процов, доступной памяти и скорострельности.
Да? И как это сделать на 16-ти разрядной машине, у который крайне ограниченные возможности по большей разрядности? Очень просто - уходить от двоичной на большую разрядность. Идеальные варианты будут кратны степеням двойки, ещё более идеальные - размеру байта. Как тебе арифметика с основанием 256? Но вот проблема - эту нужно рисовать соответствующие команды и опять таки - проблемы с вводом/выводом (нужны преобразования). Поэтому и придумал кто-то промежуточный вариант - хранение чисел в формате с основанием 10. Очень удобно для людей, ввода/вывода, больше разрядов, большая относительная скорострельность по сравнению с основание 2 (меньше циклов), а уж если это запихать на уровень команд процессора...
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Ну кассовые аппараты лет 10 жили на AVR, оно как бы 8-битное. Мы еще с mega103 начинали, в 1997 году, как только оно появилось на рынке - сразу в оборот пошло. Я еще avreal помню
Да нормально, тем более целочисленная обеспечивает полную точность, а там где округления - ТУ на кассы все очень точно описывает (и в обычной бухгалтерии - тоже).
С вводом-выводом проблем нет - индикатор, принтер, порт выводят числа сильно медленнее чем даже AVR успевал это преобразовать.
Там проблема со счетом, приходит тебе SQL-запрос и нужно посканировать флешку и миллион записей сложить, от тут BCD лишние секунды и сожрал бы.
Вот я не понял где тут в BCD большая скорострельность. Возьмем два числа - 1222333444 1000111222, в дополнительном коде это 4 байта, в BCD - 5. Уже на 25 процентов больше объема. Перенос в BCD между байтами кривой, на ALU не ложиться. Даже между разрядами в байте кривой - на 8080 нужно сначала сложить, потом делать коррекцию.
Не, ну исторически применение BCD понятно, но сейчас-то оно никак не живет. Ну нету SSE/AVX инструкций BCD, не надо оно сейчас никому.
Если интересно, почему "VAX загнулся" и при чем тут сложные для реализации инструкции - есть Long Read:
https://yarchive.net/comp/vax.html
Вот цитата, которая объясняет невозможность реализации Out-Of-Order (OOO) execution в VAX:
ILP, NORMAL INSTRUCTIONS, and IA-32 VERSUS VAX
Consider the normal unprivileged instructions that need to be executed
quickly, meaning with high degrees of ILP, and with minimal stalls from
memory system.
RISC instructions make 0-1 memory reference per operation. Despite the
messy encodings, *most* IA-32 instructions (dynamic count) can be
directly decoded into a fixed, small number of RISC-like micro-ops,
with register references renamed onto the (larger) set of physical
registers. Both IA-32 and VAX allow unaligned operations, so I'll
ignore that extra source of complexity in the load/store unit.
In an OOO design, the front-end provides memory references to a
complex, highly-asynchronous load/store/cache control unit, and then
goes on. In one case, [string instructions with REP prefix], IA-32
needs the equivalent of a microcode loop to issue a stream of micro-ops
whose number is dependent on an input register, or dynamically, on
repeated tests of operands. Such operations tend to lessen the
parallelism available, because the effect is of a microcode loop that
needs to tie together front-end, rename registers, and load/store unit
into something like a lock-step. Although this doesn't require that
all earlier instructions be retired before the first string micro-ops
are issued, it is likely a partial serializer, because it's difficult
do much useful work beyond an instruction that can generate arbitrary
numbers of memory references (especially stores!) during its execution.
However, the VAX has more cases, and some frequent ones, where the
instruction bits alone (or even with register values) are insufficient
to know even the number of memory references that will be made, and
this is disruptive of normal OOO flow, and is likely to force difficult
[read: complex, high-gate-count or long-wire] connections among
functional blocks on a chip. Hence, while the VAX decoding complexity
can be partially ameliorated by a speculative OOO design with decoded
cache [I alluded to this in the RISC CISC 1991 posting], it doesn't
fix the other problems, which either create microcode lock-steps
between decode, load/store, and other execution units, or require other
difficult solutions. In some VAX instructions, it can take a dependent
chain of 2 memory references to find a length!
VAX EXAMPLES [1], [2], especially compared to IA-32 [10] and sometimes
S/360.
Specific areas are:
- Decimal string ops
- Character string ops
- Indirect addressing interactions with above
- VAX Condition Codes (maybe)
- Function calls, especially CALL*/RET, PUSHR/POPR.
DECIMAL STRING OPERATIONS: MOVP, CMPP, ADDP, SUBP, MULP, DIVP, CVT*,
ASHP, and especially EDITPC: are really, really difficult without
looping microcode. [S/360 has same problem, which is why (efficient)
non-microcoded implementations generally omitted them. The VAX
versions, especially the 3-address forms, are even more complex than
the 2-address ones on S/360, and there are weird cases. DIVP may
allocate 16-bytes on the stack, and then restore the SP later.
Vslav(15.10.2020)
Ну так вот это и есть, по сути, идея CIS - уйти от арифметики с основанием 2 к большему основанию.
Не 4 байта, а 32 бита, то есть, грубо - цикл, повторенный 32 раза (ещё раз - мы берём классическую арифметику по основания 2), 1222333444 - 10 цифр - цикл, повторенный 10 раз. Если развивать идею с битностью, предположим, что у нас на аппаратном уровне есть 8-ми битный умножитель, тогда да, для 4-ёх байтного числа - цикл, повторенный 4 раза.
А причём здесь 8080 - мы ведём разговор о PDP-11, CIS и почему оно будет в общем случае быстрее (на больших числах), чем программная реализация. И CIS у нас вполне полноценный в этом плане - без всяких этих костылей в 8080
- - - Добавлено - - -
С моей точки зрения, VAX загнулся, потому что идеи его архитектуры базировались на устаревших принципах
Но RISC мне тоже не нравится
Где то в какой то момент развитие процессоров свернуло не туда.. Но вот как лучше и более правильно - пока не могу придумать
Каких 32 раза? АЛУ у всех сделано на обычную арифметику, тот же 8080 или AVR складывает 4 байта, всего 4 цикла. И они же умеют 16-битные сложения - всего две операции, вместо минимум 3-х для BCD. А вот для BCD надо и флаг специальный чтобы ловить перенос между тетрадами, и перенос между байтами не особо. Умерло оно все, невыгодно ни по скорости, ни по плотности данных.
Именно что костыли там, по-крайней мере, глядя на LSI-11 понятно как они могли BCD арифметику в микрокоде сделать. АЛУ LSI-11 тупо не умеет в десятичную арифметику, но там есть флажок межтетрадного переноса C4, вот на нем и играют. Если бы сделали обычную длинную арифметику - она была бы быстрее BCD.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
