AVR Freaks

That is an interesting your use for this Cbit copied from bit 15, even missing the exact and real math function of the carry bit.

I wrote about N bit, because any other instruction, ADD, SUB, SHIFTs (except LSR) , OR, AND, etc, Nbit is a pure copy of bit7, no matter if thinking about signed value of not.

When accumulating the result of multiplication even if the high byte (R1) is 0x01, it could create an overflow at the accumulator, it would be a dangerous piece of code to rely on bit 15 to be aware of overflow, any multiply-and-accumulate should always test carry bit after adding.

Interesting to observe that SER (set on all reg bits) change no flags, while CLR (set off all reg bits) sets SVN=0, Z=1, there should be a strong reason for such decision, breaking reciprocity rules.

I was unable to find ANY information anywhere in the instruction set documentation about the differences in operation logic for MUL, MULS and MULSU, except for the range of regs used, I mean, what they really does.

Examples:

LDI R25, 0x82  ; 130
LDI R26, 0x83  ; 131
MUL R25, R26

Results in 0x4286 (17030), R1=0x42, R0=0x86 

But if R25+R26 should be considered Signed, -126 * -125 must result in a positive 15750 (0x3D86), to do that, it is needed to NEGate the Signed negative bytes, so

LDI R25, 0x82 ; (-126)
LDI R26, 0x83 ; (-125)
MULS R25, R26

when both are negative, should do the same as

LDI R25, 0x82 ; (-126)
LDI R26, 0x83 ; (-125)
NEG R25       ; R25 = 0x7E
NEG R26       ; R26 = 0x7D
MUL R25, R26

Another single example, a multiplication of two signed numbers, one negative, another positive.

LDI R27, 0xFD      ; -3
LDI R28, 3         ; +3
MUL R27, R28       ; regular unsigned mul
                   ; Results in 0x02F7 (759)
                   ; while 
MULS R27, R28      ; Should result in -9 (0xFFF7)

So, how MULS do it?

As far as I know about signed ALU processing in other chips, it checks bit 7 of both R27 and R28, then NEGates whichever has bit7 on.

The MULS decoding, based on reg's bit7, NEGates R27 value while entering ALU (InputDataBusNegate), from 0xFD to 0x03, this also latches OutputDataBusNegate at the ALU ouput, since result will be negative.  Then the MUL takes place, resulting 3 x 3 = 9 (0x0009), and because the OutputDataBusNegate the logic automatically NEGates the ALU output, changing 0x00 to 0xFF and 0x09 to 0xFD resulting in 0xFFFD, what is a signed -9.

So, I guess, MULS always NEGate any register with bit7=1, but only NEGates to the result if an XOR of both bit7 is 1, I mean, if both bits 7 where the same is doesn't NEGate the result.

In case of both positive (bit 7 down), no NEGates takes place, neither at ALU input or output, while a regular MUL instruction takes place. 

Then, a simple (human) way for the MULS to decide is, adding both bits7:

0 = Both values are positive.  Just do a regular MUL and nothing else, result is positive.

1 = NEGate the only register with bit7 on, do a regular MUL, NEGate the result since the result is negative.

2 = Both values are negative. Negate both registers, do a regular MUL, nothing else, result is positive.

I guess for the "MULSU Rd,Rs", the decision is based only on the signed register, Rd.

If Rd7 is on, result will be negative, latches InputDataBusNegate and OutputDataBusNegate, NEGate Rd, regular MUL, NEGate the result, otherwise, regular MUL. 

The point of my complains for years, why this is not explained in the documentation?  Perhaps "we don't need to know". Well, I use to work with assembly language, bare chip code, not because I want to suffer, but to super-optimize and make the best possible, I am entitled to have such information, mostly when datasheet for MUL/MULS/MULSU doesn't show any difference among them.

By the same way, I still wonder why MUL/MULS/MULSU copy bit 15 to Cbit... and don't use SREG Nbit based on OutputDataBusNegate, we don't need to know, just need to guess.

When I say "it is not the chip", referring to the text on the datasheet that say about "For AVR microcontroller with program memory not exceeding 4k words (8kBytes)", meaning it is not the chip that has some magic and allows to jump within 8kBytes with only 12 bits of address displacement, it is the assembler or compiler that recognize the chip selected has only 13 bits of addressing, so overlap could be done.  Of course, the chip will do its natural address overlap within 13 bits of addressing, but it is the compiler/assembler that prepare the other way jump if the displacement is larger than 2k words.

Mike, that exactly why I question this Cbit = bit15, Cbit is for overflow, period.

It is impossible to have overflow in a Mul 8 x8 bits when the result is 16 bits.

The engineers may though about some other use of Cbit copying Bit15 for some subsequent instructions.

If they thought about that, I want to know, it may be very useful.

This kind of knowledge shall not be lost just by some documentation shortage of explanation. 

Theusch, no, I am not here trying to fix anything that could be wrong, not the idea.  My curiosity sticks to the possibility that the original designer thought about to use Cbit as a copy of Bit15 in MUL for some productive way in subsequent instructions.  I can not see it, and I would love to know.   And you are correct, all the Fractional Multiplication uses the Cbit correctly as Bit16 after the left shift (fractional multiplication required), as a real overflow (2's complement overflow) result.   I am really curious about MChip eng's answer for that.

Got the ticket result from Microchip about this issue, and it is not clear for them the original intention, just guessing.

Item #1, the example Aarthi said:

mac16x16_32_method_B:			; uses two temporary registers
					; (r4,r5), but reduces cycles/words
					; by 1
	clr	r2

	muls	r23, r21		; (signed)ah * (signed)bh
	movw	r5:r4,r1:r0

	mul	r22, r20		; al * bl

	add	r16, r0
	adc	r17, r1
	adc	r18, r4
	adc	r19, r5

	mulsu	r23, r20		; (signed)ah * bl
	sbc	r19, r2
	add	r17, r0
	adc	r18, r1
	adc	r19, r2

	mulsu	r21, r22		; (signed)bh * al
	sbc	r19, r2
	add	r17, r0
	adc	r18, r1
	adc	r19, r2

	ret

Item #2, multiplying by 1/2, Aarthi is trying to say that when you divide by 2 (rotate right) a negative number resulting from a MUL, bit 15 (sign) is also carry and will still 15 after being shifted right to 14.  But that is also done by instruction ASR.  So...  not really convincing.  

Westfw, exactly, and it is only possible if the chip has no more than 8192Bytes (4096Words) Flash memory, as the datasheet states.  The displacement of a RJMP or RCALL is limited to only +2048/-2047 words, what only allows to reach any 4kWords because the rollover of the overflow.  0001 + 2048 does not reach word address 3000, but 0001 - 1096 does, only if the memory is 4096 words long.  The compiler or assembler takes care of that, IF it knows the chip has 8192bytes of code memory or lower.  I will need to make few tests with different def chips and see how the assembler complains.   

It would be very interesting to use a 16k chip, lying to assembler it has only 8k, then duplicating the code from lower 8kbytes to upper 8k.  The program would be jumping between the upper and lower 8kbytes without even noticing, but saving one byte on every RJMP/RCALL instruction.   This would happens, because the hardware rollover of the 16k chip would be different, 0001 - 1096 will not point to 3000, but 7095, that is exactly the counterpart address of the high block, 7095 is 4095+3000.

In the past I did some crazy stuff like that with 8051, addressing several banks of 64k of code.  A transition jump section on the bottom part of every 64k block was exactly the same, so when the code changes the port bits selecting another 64k Eprom the code never gets interrupted, lost or broken. 

This webtext is very old, explains it in my silly wording at the time.