Decimal Adjust Accumulator on the 4004

[Brent Hilpert]

On 2016-Jan-28, at 6:44 PM, Kyle Owen wrote:

> On Thu, Jan 28, 2016 at 8:33 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
>> 
>> The original looks correct to me.
>> 
>> I think you or the documentation are confusing the hardware carry flag
>> with the carry out of the 4th bit (nibble carry).
>> A binary addition of two BCD digits will require correction either if the
>> result is in the range 0xA to 0xF or if there was a carry out of the 4th
>> bit.
>> The hardware carry flag is the carry out of the 8th bit and is irrelevant
>> immediately after the addition.
> 
> 
> But this is a 4-bit architecture...? A carry out of the 4th bit does affect
> the carry flag.
> 
> The JS simulator uses an 8-bit value to hold the 4-bit accumulator, which
> is why they check if there's anything in the upper nibble, then clear the
> upper nibble of the accumulator.
> 
> Or did I miss something?
> 
> Thanks,

Sorry, yes, I was forgetting it was a 4004 and failing to distinguish between the real hardware and the emulated version of the registers, and should not have been referring to the '8th bit'.
(I was assuming the emulator was using a larger-than-4-bit container for acc.)

So then it would seem to depend on what the emu does at the end of an addition instruction (or any instruction that affects the accumulator) - that is, does it mask out the higher nibble at the end of the add instruction?
If it does, then you should be correct that the DAA implementation is faulty, as it would not detect addition results in the range 0x10 to 0x12 as needing correction.
If it does not, then the original code (might) be OK, and your additional test for C_flag would be superfluous but not incorrect.

I could see someone writing their emulator either way: always keeping an oversized container for the acc 'value-correct', or not caring what happens in the higher, oversized bits.
However the rest of the original code you presented suggests they do care, and are keeping the acc value-correct.
So I can't give a sure answer without looking at the rest of the emu code, but it looks like you may be right, the DAA impl. may be faulty.

Either that, or I need to have dinner before exercising brain cells any further.