Emulating ADDWFC on 16F PIC uCONTROLLER

I agree with you about the add + carry. My guess is they wanted to keep the instruction set down so something had to go.

You should take a look at app note 00617. Add with carry can be implemented much more simply as:

movf lsb_a, w addwf lsb_b ' ' repeat the lines below for higher precision ' movf msb_a, w btfsc _c incfsz msb_a, w addwf msb_b

I couldn't follow what your code was doing, but it looks far too complicated.

The same app note has instructions for multi-byte subtract.

--
Kyle A. York
Sr. Subordinate Grunt
DSBU

Quite possibly. I see an awful lot of unnecessary GOTOs. This should be equivalent (in PIC18 idiom). Example assembly pasted below (again, on PIC18).

_addwfc macro F btfsc STATUS,C incf F addwf F endm

movf B_L,w addwf A_L movf B_M,w _addwfc A_M movf B_H,w _addwfc A_H

--Toby

00000000 00058 B_L equ 0 00000001 00059 B_M equ 1 00000002 00060 B_H equ 2 00000003 00061 A_L equ 3 00000004 00062 A_M equ 4 00000005 00063 A_H equ 5 000040 5000 00064 movf B_L,w 000042 2603 00065 addwf A_L 000044 5001 00066 movf B_M,w 00067 _addwfc A_M 000046 B0D8 M btfsc STATUS,C 000048 2A04 M incf A_M 00004A 2604 M addwf A_M 00004C 5002 00068 movf B_H,w 00069 _addwfc A_H 00004E B0D8 M btfsc STATUS,C 000050 2A05 M incf A_H 000052 2605 M addwf A_H

I believe this is a little smaller and easier to read with local variables.

addwfc MACRO file ;ADD W to File with Carry local easy, done btfss STATUS,C goto easy incf file,F btfss STATUS,Z goto easy addwf file,F bsf STATUS,C goto done easy: addwf file,F done: endm

The only optimisation I can see is if you don't care about the carry at the end or know you are not starting with 255.

My first attempt, similar to Kyle's, overlooked that the INCF may itself generate a carry, which must be passed on. Unconditionally following the INCF with ADDF loses this information.

If the INCF does carry, we are adding to zero and can use a move instead, which handily keeps the carry:

_addwfc macro F local doadd,done bnc doadd incf F bnc doadd movwf F ; doesn't touch carry bra done doadd: addwf F ; computes carry done: endm

; In use: movf B_L,w addwf A_L movf B_M,w _addwfc A_M movf B_H,w _addwfc A_H

--Toby

Kyle's INCFSZ version is much better than mine. :)

Of course there is a reason. The PIC instruction set was designed in a RISC model with a limited number of instructions and a limited number of addressing modes. So instead of having dozens upon dozens of built in instructions, the PIC has a handful of simple instructions that you combine to get what you need.

I'll leave other folks to optimze the routine. But here's a sample that will do a multibyte add of any length operands:

BAJ

BAJ,

Thanks for the link - I shall study it.

I accept that (by definition) a "reduced instruction set" has to have a limited number of commands. The 6502 stored instructions AND data discreetly in 8 bits so there was a theoretical 256 different instructions - and, if memory serves, there were indeed in excess of

200 - taking into account the variations in addressing modes and plethora of test/branching commands etc.

However, Microchip didn't *have* to add another instruction - my disbelief was that the add without carry instruction took preference over an add with carry instruction. A straight swap leaves the exact same number of instructions - 35 I think. So the limiting the number of instructions doesn't cut it as an explanation in my eyes.

Most PICs have a modest amount of memory to hold programs. Since addition commands are required for addition, multiplication and subtraction (2's compliment etc.) then taking into account the single bit of the carry flag would cut down on the number of instructions required to implement such operations with the existing instruction set.

I suppose if (as a designer) you were between a rock and a hard place and it was the only thing you could afford to lose - and you HAD to lose something, I could understand it. After all, they (Microchip) introducted the add with carry instruction to the 18F chipset.

I guess I'd have to ask them why - lol!

Regards

Dave Giblin Lancashire England

Its not a simple decision of just eliminating the instruction. There was simplicity in not lining up the register with a carry in to the ALU data path of the chip.

The idea is that this processor is supposed to be doing tremendously simple operations, not high level math, so if you needed the carry you can implement it.

Now the 18F versions are designed to do "some Math" so they can do DSP applications. A full ALU data path complete with a carry in from the status register makes more sense for these devices.

I think the original "plan" for the pic was a design from 1980 or something like that. Some teachers kicking around a simple processor model and then microchip taking off with the 16C54 and the rest is history. I remember seeing a similar datapath mini micro in a textbook from a while back. It always reminded me of the PIC. My details are probably way off...I am loosing my mind faster than most of my age. Tony