33

The intermediate carry flag, or "adjust flag", or half-carry flag is used to facilitate binary-coded decimal (BCD) arithmetic, where each decimal digit of a number is represented as a nibble (a group of 4 bits). The range of valid values for each nibble is 0 to 9 (0000 to 1001). If, after an arithmetic operation, the result contains a "non-...


14

(Only partly my answer, as the important list is a collection of what has been found and noted by others in comments to the question - I thought putting it in an answer would be helpful to others looking) I know the Atari's FP package used BCD for rather dubious reasons, I wouldn't call it dubious, but rather obvious. Using BCD based FP will always ...


13

Yes; it's called Chen-Ho encoding Theodore M. Hertz of Rockwell filed for a patent on a similar encoding in 1969. The patent was granted in 1971. Independently in 1971, IBM researchers Tien Chi Chen and Irving Tze Ho worked on encoding two decimal digits in 7 bits. The company filed for a patent in 1973, citing Hertz' patent as prior art, which was ...


13

The Ricoh 2A03 (NTSC) and 2A07 (PAL) are best thought of as ASIC devices. They include a 6502-compatible CPU core, but these chips also include the NES's 5-voice Programmable Sound Generator. The inclusion of the PSG, plus other I/O interfaces for the NES, together resulted in 22 internal memory-mapped I/O ports that are on-chip. As you mentioned, the binary-...


9

Why does the Z80 have a half-carry bit? Because the ALU is only 4 bits wide. The Z80 needs to preserve the carry between bits 3 and 4. Why did the designers of this chip choose to preserve that value in the flags register? Good question. You can't access the H bit directly except by saving the status register and then examining its contents, so there is ...


8

Other than changed immediate operand lengths (to support 64-bit addresses) and register encodings (to support the new registers), which obviously make practically all code incompatible at the binary level, there are a few other major changes in long mode: Instruction prefix handling is changed; older processors allowed arbitrary sequences of prefixes (...


8

The “ASCII” instructions are really about unpacked BCD, not ASCII. There is some justification for calling them “ASCII”, because unpacked BCD can easily be converted to and from ASCII, and in fact if only the lower nibble is considered, ASCII numerals are encoded using the exact same values as their unpacked BCD counterparts. The 8086 Primer explains the ...


6

But beyond that, is there any fundamental difference in performance? On a fundamental base: No. In code looping and adjusting needs to take into account that digits are shifted by 4 instead of 1 and carry ripples at 10 instead of 2. Speed will be about the same. Ofc, it helps to have a BCD mode to do so. But not as much as one may assume. When doing FP ...


5

It is well-known that binary floating point is unsuitable for financial applications, because 0.1 is not exactly representable in binary. It's less the binary part, than floating point in general. Financial application want fixed precision. And they want to have exceptions handled according to established rules - rules not set by scientists, but accountants,...


4

To adjust a value, one needs to know how many carries there were out of each decimal digit. When adding two 8-bit numbers, there can be at most one carry out of each 4-bit chunk, which will fit in two flags which are devoted to that purpose. Multiplication of two decimal digits, however, may yield up to eight carries--far too many to fit into two one-bit ...


4

The KIM Math package used packed BCD for storage and unpacked decimal for computation. I used to have a vintage bound copy of the source code, but sold it to a collector. I have no idea whether any loadable-program computers included the KIM Math routines in ROM for use by loaded programs, but the package was published by MOS Technologies--makers of the ...


4

Let's write some actual code for fixed point arithmetic and see how it goes. 1) Addition and Subtraction is obviously fundamentally the same. 2) Multiplication. There are quite a few ways to do multiplication. A reasonably performant and still straightforward algorithm uses shifts and adds. Pseudo code to calculate z = x * y: z := 0 while x != 0: x := x ...


4

The Intel 4004 and 4040 were 4-bit CPUs. In some ways, the 8008 and its successor, the 8080 behaved as if it were two 4004s glued together, although the 8008 architecture was not just two 4004s glued together. For instance, the 8008 had an extensive carry prediction chunk attached to the ALU. Adding either BCD or 4-bit values in the 4004 could result in ...


3

The reason there needs to be a visible "half carry" bit is a combination of two factors. BCD support Interrupt handling. As other answers have pointed out the Z80 provided BCD support through an adjustment instruction run after the addition or subtraction operation (this constrasts with the 6502 that implemented it as a mode flag). This instruction needs ...


2

AAM is needed because the result of multiplying two unpacked BCD is a 'strange' value that needs to be 'normalized' again. The whole mechanic of using the binary multiply with BCD only woks with 'unpacked' values. Using two packed BCD values will return a result that can't be decoded as easy. To allow multiplication with packed BCD would have required the ...


2

On the 8086, an 8-bit quantity can represent a number in four ways. Of these four, unpacked BCD is the closest to direct representation by ASCII. The AAx instructions are needed to use this representation. Unsigned binary number Bit format: 8 binary digits dddddddd Represents values from 0 to 255. Addition: ADD (or ADC). Subtraction: SUB (or SBB). ...


2

The IBM floating point representation had a hexadecimal exponent — in other words, it used 4-bit units in the mantissa field. It was widely criticized for its "wobbling precision". What you're proposing — 10 bit wide mantissa units — would be 2.5 times (or, from another point of view, 62.5 times) worse than that.


1

Yes, there are differences in the algorithms used for BCD compared with binary arithmetic. The code for BCD is more complex, so larger and probably slower, if implemented with roughly equivalent skill and tradeoff between size and speed. That's even assuming there is not also a basic difference in execution speed, which there also is on the 65C02 (and on ...


1

Visicalc for the Apple II used "a variation of decimal arithmetic" which I assume means BCD. The reason they give is the same reason decimal arithmetic was used on mainframes: [...] so all money values could be represented exactly, with no funny behavior common at the time from binary floating point. And this would probably also be the reason for the ...


1

Preface: Before writing anything that I got it wrong, it might be helpful to take a look at the original documentations instead of refering some web page, as there are TONS out there who got that part wrong. I'm just curious if there was ever other instructions that were more ASCII-centric than the CISC associated ones we're left with now? Sure, while the ...


Only top voted, non community-wiki answers of a minimum length are eligible