Exact match. Not showing close matches.
PICList
Thread
'[PIC]: Number crunching, enclosed is 24x24 equ 48,'
2000\10\19@062945
by
o88591?Q?K=FCbek_Tony?=

Hi,
I while ago I posted an request for 24x24 = 48 and
48/24 = 24. Lacking replies ( apart from Nikolai's
pseudo code ) I had to 'make' them myself. Not particulary
hard, just tedious :).
Anyway had some time during the latest days to start hammer on it
and here you have the 24x24 = 48 bit routine. I *think* it works
( atleast on the values tested sofar ) but dont take my word on it:
;
***********************************************************************
; MULTTIPLY_24x24  Routine to mutltiply two 24 bit numbers
; result in 48 bits !
; Format: Ram = MSB, Ram+2 = LSB ( for 24 bit variable ) ( little
endian ? )
; Ram used: Multiplier, Multipland 3 bytes each ( 24 bits )
; Product 6 bytes ( 48 bits )
; BitCount 1 byte for loop counting
;
; Multiplier is zero at exit ( destroyed )
; Multipland is preserved
; Product holds result
;
; Probably more efficient to use Ram = LSB, Ram+2 = MSB ( big endian ? )
; According to helpful hints from Nikolai, however my requirements
; dictated the used format.
;
MULTIPLY_24x24
; preload values to test
MOVLW 0xAB
MOVWF Multipland
MOVLW 0xCD
MOVWF Multipland+1
MOVLW 0xEF
MOVWF Multipland+2
MOVLW 0x98
MOVWF Multiplier
MOVLW 0x76
MOVWF Multiplier+1
MOVLW 0x54
MOVWF Multiplier+2
; these values should generate the reply = 0x6651AF33BC6C
CLRF Product ; clear destination
CLRF Product+1
CLRF Product+2
CLRF Product+3
CLRF Product+4
CLRF Product+5
MOVLW 23
MOVWF BitCount ; number of bits
CLRC ; make sure the carry is initially
cleared
ADD_LOOP_24x24
; note carry assummed to be zero !
RLF Multiplier+2,F ; up shift multiplier one bit
RLF Multiplier+1,F
RLF Multiplier,F
BTFSS STATUS,C ; if carry is set we must add multipland
to the product
GOTO SKIP_LOOP_24x24 ; nope, skip this bit
MOVF Multipland+2,W ; get LSB of multiplicand
ADDWF Product+5,F ; add it to the lsb of the product
MOVF Multipland+1,W ; middle byte
BTFSC STATUS,C ; check carry for overflow
INCFSZ Multipland+1,W ;
ADDWF Product+4,F ; handle overflow
MOVF Multipland,W ; MSB byte
BTFSC STATUS,C ; check carry
INCFSZ Multipland,W
ADDWF Product+3,F ; handle overflow
; carry propagation, if set then make sure if 'follows' through
MOVLW 0x01 ; preload with 1
BTFSC STATUS,C ; check carry for overflow
ADDWF Product+2,F ; add one to next byte
BTFSC STATUS,C ; check carry for overflow
ADDWF Product+1,F ; add one to next byte
BTFSC STATUS,C ; check carry for overflow
ADDWF Product,F ; add one to next byte
SKIP_LOOP_24x24
; shift and prepare for next bit
; note Carry is always assumed to be zero here !
; should be handled by carry propagation above.
RLF Product+5,F
RLF Product+4,F
RLF Product+3,F
RLF Product+2,F
RLF Product+1,F
RLF Product,F
; note carry should always be zero here ( else overflow ? )
; affects rotate at the beginning of ADD_LOOP_24x24
DECFSZ BitCount,F
GOTO ADD_LOOP_24x24
NOP
NOP
RETURN
Use at will/risk/leisure/etc.
Oh..piccode on the piclist what will come next ;)
/Tony
Tony Kübek, Flintab AB
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: spam_OUTtony.kubekTakeThisOuTflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"
2000\10\19@075219
by
Scott Dattalo

On Thu, 19 Oct 2000, [Iso88591] Kübek Tony wrote:
> Hi,
> I while ago I posted an request for 24x24 = 48 and
> 48/24 = 24. Lacking replies ( apart from Nikolai's
> pseudo code ) I had to 'make' them myself. Not particulary
> hard, just tedious :).
> Anyway had some time during the latest days to start hammer on it
> and here you have the 24x24 = 48 bit routine. I *think* it works
> ( atleast on the values tested sofar ) but dont take my word on it:
I just so happen to know that Nikolai is away from his computer at the moment...
<snip>
The following section may be shortened slightly in one of two ways:
{Quote hidden}>
> ; carry propagation, if set then make sure if 'follows' through
>
> MOVLW 0x01 ; preload with 1
> BTFSC STATUS,C ; check carry for overflow
> ADDWF Product+2,F ; add one to next byte
>
> BTFSC STATUS,C ; check carry for overflow
> ADDWF Product+1,F ; add one to next byte
>
> BTFSC STATUS,C ; check carry for overflow
> ADDWF Product,F ; add one to next byte
rlf known_zero,w ;a trick learned from payson
addwf Product+2,f
rlf known_zero,w
addwf Product+1,f
rlf known_zero,w
addwf Product+0,f
OR:
skpnc
incf Product+2,f
skpnc
incf Product+1,f
skpnc
incf Product+0,f
> Use at will/risk/leisure/etc.
> Oh..piccode on the piclist what will come next ;)
Don't get me started....
Thanks for posting this , Tony
Scott

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"
2000\10\19@092616
by
Bob Ammerman

Tony,
This looks real good. I especially like the four instruction snippet:
movf <somebyte>,W
skpnc
incfsz <somebyte>,W
addwf <resultbyte>,F
As a slick way to do handle carries in an Nbyte multiple precision add. If
this trick is wellknown, it has somehow escaped me. [James: how about a
section on Nbyte arithmetic in the code snippets archive?]
Also, you said:
;
; Probably more efficient to use Ram = LSB, Ram+2 = MSB ( big endian ? )
; According to helpful hints from Nikolai, however my requirements
; dictated the used format.
;
I don't understand how this can be true when all accesses to RAM are byte
wide and indeed the individual bytes of each value can be anywhere in memory
with no change in performance.
Yeah, just what we need: an 'endianness' flame war on a list that works with
a 'noendian' (ie: 8bit memory accesses only) processor.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, lowlevel
software)

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\19@092620
by
Bob Ammerman

 Original Message 
From: Scott Dattalo <.....scottKILLspam@spam@DATTALO.COM>
The following section may be shortened slightly in one of two ways:
{Quote hidden}>
> ; carry propagation, if set then make sure if 'follows' through
>
> MOVLW 0x01 ; preload with 1
> BTFSC STATUS,C ; check carry for overflow
> ADDWF Product+2,F ; add one to next byte
>
> BTFSC STATUS,C ; check carry for overflow
> ADDWF Product+1,F ; add one to next byte
>
> BTFSC STATUS,C ; check carry for overflow
> ADDWF Product,F ; add one to next byte
rlf known_zero,w ;a trick learned from payson
addwf Product+2,f
rlf known_zero,w
addwf Product+1,f
rlf known_zero,w
addwf Product+0,f
OR:
skpnc
incf Product+2,f
skpnc
incf Product+1,f
skpnc
incf Product+0,f
Uh, this last snippet will _not_ work.
If carry is clear on entry, then no bytes will be touched, this is fine.
But, if carry is set on entry, then all three bytes will be incremented.
This is an error.
This occurs because the carry bit is _not_ set by the "incf" instruction.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, lowlevel
software)

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\19@094052
by
Scott Dattalo
On Thu, 19 Oct 2000, Bob Ammerman wrote:
>  Original Message 
> From: Scott Dattalo <scottKILLspamDATTALO.COM>
> skpnc
> incf Product+2,f
> skpnc
> incf Product+1,f
> skpnc
> incf Product+0,f
>
> Uh, this last snippet will _not_ work.
> If carry is clear on entry, then no bytes will be touched, this is fine.
> But, if carry is set on entry, then all three bytes will be incremented.
> This is an error.
>
> This occurs because the carry bit is _not_ set by the "incf" instruction.
Yep, you're right. I was just seeing if people on what used to be the "pic" list
still actually read pic code.
BTW, Bob, on the 18cxxx we'd do this instead:
clrw
addwfc Product+2,f
addwfc Product+1,f
addwfc Product+0,f
Scott

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\19@111528
by
o88591?Q?K=FCbek_Tony?=

Hi,
replies from the 'masters' :)
well well..
Scott Dattalo wrote:
<snip>
>I just so happen to know that Nikolai is away from his computer at the
moment...
><snip>
>The following section may be shortened slightly in one of two ways:
>
> rlf known_zero,w ;a trick learned from payson
> addwf Product+2,f
> rlf known_zero,w
> addwf Product+1,f
> rlf known_zero,w
> addwf Product+0,f
Yes I know he is away, still his was kind enough to reply to an email
of mine prior to posting this ( asked if he had any
objections/suggestions,
which he did not have ).
And yes the 'known zero' trick, I observed that on some code snippets on
the faq site,
very clever, but it's 'harder' to understand the effect
at first sight. Therefore to make the code somewhat easier to
read I normally leave out such optimisations ( until I really need them
:) ).
But You are correct ofcource.
However this one:
> skpnc
> incf Product+2,f
> skpnc
> incf Product+1,f
> skpnc
> incf Product+0,f
Will not work. Carry not affected by INCF. ( also noted by Bob Ammerman
)
>Thanks for posting this , Tony
If it wasn't for the *active* on this list I would still
be trying to turn on the darn LED :).
Bob Ammerman wrote:
>This looks real good. I especially like the four instruction snippet:
>
>movf <somebyte>,W
>skpnc
>incfsz <somebyte>,W
>addwf <resultbyte>,F
>
>As a slick way to do handle carries in an Nbyte multiple precision
add. If
>this trick is wellknown, it has somehow escaped me. [James: how about
a
>section on Nbyte arithmetic in the code snippets archive?]
Where do you think I got that from :), i.e. I take NO credit from
that part, someone else already thought of it ( Payson ? ).
>I don't understand how this can be true when all accesses to RAM are
byte
>wide and indeed the individual bytes of each value can be anywhere in
memory
>with no change in performance.
Neither do I, but other people has suggested from time to time that
( according to their expirience ) big endian can 'save' a few cycles.
For example Nikolai's code generator will have an variance of a few
cycles
depending on big or little endian, I dont know why but I does.
( that's the one with constant multiplication )
I'll let it rest, no flames please. ( should have left that part out :)
)
/Tony
Tony Kübek, Flintab AB
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: .....tony.kubekKILLspam.....flintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"
2000\10\19@125005
by
staff
Bob Ammerman wrote:
>
> Tony,
>
> This looks real good. I especially like the four instruction snippet:
>
> movf <somebyte>,W
> skpnc
> incfsz <somebyte>,W
> addwf <resultbyte>,F
>
Please forgive me if I'm wrong, but the movf doesn't affect the carry
bit?
only Z.
Roman

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\19@130246
by
Tom Handley
Gawd Scott, heh, heh. When you, Andy, Dmitry and our other Russian friends,
John (I wish he would come back to the list), post code, many of us take it
as `gospel'. I glanced over it as I always do but missed it due to being
focused on other topics. The last thing we need is you trying to trick us ;)
BTW Bob, I'm adding you to my list of `legendary code gurus'. It won't
buy you a cup of coffee but I'll buy a beer if you ever stop by Portland, OR.
 Tom ;)
At 08:42 AM 10/19/00 0500, Scott Dattalo wrote:
>On Thu, 19 Oct 2000, Bob Ammerman wrote:
>
>> {Original Message removed}
2000\10\19@133726
by
Olin Lathrop
> movf <somebyte>,W
> skpnc
> incfsz <somebyte>,W
> addwf <resultbyte>,F
>
> As a slick way to do handle carries in an Nbyte multiple precision add.
If
> this trick is wellknown, it has somehow escaped me. [James: how about a
> section on Nbyte arithmetic in the code snippets archive?]
Note that this only works if RESULTBYTE is the last (highest) byte of the
multibyte number. The carry generated by this code snippet won't be
correct for use by the next byte. This is because a carry could occur from
the INCFSZ instruction, which is then lost when the ADDWF instruction
executes.
*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 7723129, EraseMEolinspam_OUTTakeThisOuTcognivis.com, http://www.cognivis.com

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\19@135949
by
Bob Ammerman

 Original Message 
From: Olin Lathrop <olin_piclistspam_OUTCOGNIVIS.COM>
To: <@spam@PICLISTKILLspamMITVMA.MIT.EDU>
Sent: Thursday, October 19, 2000 1:29 PM
Subject: Re: [PIC]: Number crunching, enclosed is 24x24 equ 48, have fun
{Quote hidden}> > movf <somebyte>,W
> > skpnc
> > incfsz <somebyte>,W
> > addwf <resultbyte>,F
> >
> > As a slick way to do handle carries in an Nbyte multiple precision add.
> If
> > this trick is wellknown, it has somehow escaped me. [James: how about a
> > section on Nbyte arithmetic in the code snippets archive?]
>
> Note that this only works if RESULTBYTE is the last (highest) byte of the
> multibyte number. The carry generated by this code snippet won't be
> correct for use by the next byte. This is because a carry could occur
from
> the INCFSZ instruction, which is then lost when the ADDWF instruction
> executes.
This is _not_ true.
If there is no incoming carry, we skip the incfsz and to the addwf.
If there is an incoming carry we use INCFSZ to get one more than the input
value.
In this case there are two possibilities:
1: <somebyte> was 255. The INCFSZ will skip the ADDWF with carry still _set_
to bring the carry up to the next byte.
2: <somebyte> was some other values. The INCFSZ will give us a result that
fits in 8 bits, then the ADDWF will set carry properly for the next byte.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, lowlevel
software)

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\19@155928
by
Olin Lathrop

> > > movf <somebyte>,W
> > > skpnc
> > > incfsz <somebyte>,W
> > > addwf <resultbyte>,F
> > >
> > > As a slick way to do handle carries in an Nbyte multiple precision
add.
> > If
> > > this trick is wellknown, it has somehow escaped me. [James: how about
a
> > > section on Nbyte arithmetic in the code snippets archive?]
> >
> > Note that this only works if RESULTBYTE is the last (highest) byte of
the
> > multibyte number. The carry generated by this code snippet won't be
> > correct for use by the next byte. This is because a carry could occur
> from
> > the INCFSZ instruction, which is then lost when the ADDWF instruction
> > executes.
>
> This is _not_ true.
>
> 1: <somebyte> was 255. The INCFSZ will skip the ADDWF with carry still
_set_
> to bring the carry up to the next byte.
>
> 2: <somebyte> was some other values. The INCFSZ will give us a result that
> fits in 8 bits, then the ADDWF will set carry properly for the next byte.
Sorry, you're right. Somehow my mind blocked out the fact that is was an
INCFSZ, not INCF.
However, that brings up another problem. If SOMEBYTE was 255 and there was
an incoming carry, the ADDWF will get skipped, which will prevent RESULTBYTE
from being set. I am presuming here that the point of the code snippet is
to perform an add with carry in/out of SOMEBYTE + RESULTBYTE > RESULTBYTE?
*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 7723129, KILLspamolinKILLspamcognivis.com, http://www.cognivis.com

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\19@161138
by
Scott Dattalo

On Thu, 19 Oct 2000, Olin Lathrop wrote:
{Quote hidden}> > > > movf <somebyte>,W
> > > > skpnc
> > > > incfsz <somebyte>,W
> > > > addwf <resultbyte>,F
> > > >
> > > > As a slick way to do handle carries in an Nbyte multiple precision
> add.
> > > If
> > > > this trick is wellknown, it has somehow escaped me. [James: how about
> a
> > > > section on Nbyte arithmetic in the code snippets archive?]
> > >
> > > Note that this only works if RESULTBYTE is the last (highest) byte of
> the
> > > multibyte number. The carry generated by this code snippet won't be
> > > correct for use by the next byte. This is because a carry could occur
> > from
> > > the INCFSZ instruction, which is then lost when the ADDWF instruction
> > > executes.
> >
> > This is _not_ true.
> >
> > 1: <somebyte> was 255. The INCFSZ will skip the ADDWF with carry still
> _set_
> > to bring the carry up to the next byte.
> >
> > 2: <somebyte> was some other values. The INCFSZ will give us a result that
> > fits in 8 bits, then the ADDWF will set carry properly for the next byte.
>
> Sorry, you're right. Somehow my mind blocked out the fact that is was an
> INCFSZ, not INCF.
>
> However, that brings up another problem. If SOMEBYTE was 255 and there was
> an incoming carry, the ADDWF will get skipped, which will prevent RESULTBYTE
> from being set. I am presuming here that the point of the code snippet is
> to perform an add with carry in/out of SOMEBYTE + RESULTBYTE > RESULTBYTE?
Yep.
Challenge:
If you don't care about the carry out, it's possible to perform a 16bit add in
5 cycles. Since Nikolai is away from his computer, Dmitry is quiet, John is
(where is John?) and Andy is on a plane, this oughta be an interesting
challenge.
Scott

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\19@162220
by
Bob Ammerman

 Original Message 
From: Olin Lathrop <RemoveMEolin_piclistTakeThisOuTCOGNIVIS.COM>
To: <spamBeGonePICLISTspamBeGoneMITVMA.MIT.EDU>
Sent: Thursday, October 19, 2000 3:57 PM
Subject: Re: [PIC]: Number crunching, enclosed is 24x24 equ 48, have fun
> > > > movf <somebyte>,W
> > > > skpnc
> > > > incfsz <somebyte>,W
> > > > addwf <resultbyte>,F
> > > >
>
> However, that brings up another problem. If SOMEBYTE was 255 and there
was
> an incoming carry, the ADDWF will get skipped, which will prevent
RESULTBYTE
> from being set. I am presuming here that the point of the code snippet is
> to perform an add with carry in/out of SOMEBYTE + RESULTBYTE >
RESULTBYTE?
>
Olin, today is _not_ your day.
Yes, we skip setting <resultbyte> in the case that <somebyte> was 255 and
there was an incoming carry.
This is because we would have been adding 0 (255 plus the carry == 256, 256
mod 256 == 0) to <resultbyte>, anyway!
Bob Ammerman
RAm Systems
(contract development of high performance, high function, lowlevel
software)

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\19@162903
by
Bob Ammerman
> Challenge:
>
> If you don't care about the carry out, it's possible to perform a 16bit
add in
> 5 cycles. Since Nikolai is away from his computer, Dmitry is quiet, John
is
> (where is John?) and Andy is on a plane, this oughta be an interesting
> challenge.
>
> Scott
movf lo_a,W
addwf lo_b,F
rlf known_zero,W
addwf hi_a,W
addwf hi_b,F
Bob Ammerman
RAm Systems
(contract development of high performance, high function, lowlevel
software)

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\19@163643
by
Scott Dattalo
On Thu, 19 Oct 2000, Bob Ammerman wrote:
> > Challenge:
> >
> > If you don't care about the carry out, it's possible to perform a 16bit
> add in
> > 5 cycles. Since Nikolai is away from his computer, Dmitry is quiet, John
> is
> > (where is John?) and Andy is on a plane, this oughta be an interesting
> > challenge.
> >
> > Scott
>
>
> movf lo_a,W
> addwf lo_b,F
> rlf known_zero,W
> addwf hi_a,W
> addwf hi_b,F
Oh, I forgot about Bob. Yep.

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\19@174257
by
Andy Howard

 Original Message 
From: "Scott Dattalo" <TakeThisOuTscottEraseMEspam_OUTDATTALO.COM>
To: <RemoveMEPICLISTTakeThisOuTMITVMA.MIT.EDU>
Sent: Thursday, October 19, 2000 9:13 PM
Subject: Re: [PIC]: Number crunching, enclosed is 24x24 equ 48, have fun
> On Thu, 19 Oct 2000, Olin Lathrop wrote:
>
> > > > > movf <somebyte>,W
> > > > > skpnc
> > > > > incfsz <somebyte>,W
> > > > > addwf <resultbyte>,F
> > > > >
> > > > > As a slick way to do handle carries in an Nbyte multiple
precision
> > add.
> > > > If
> > > > > this trick is wellknown, it has somehow escaped me. [James: how
about
> > a
> > > > > section on Nbyte arithmetic in the code snippets archive?]
> > > >
> > > > Note that this only works if RESULTBYTE is the last (highest) byte
of
> > the
> > > > multibyte number. The carry generated by this code snippet won't
be
> > > > correct for use by the next byte. This is because a carry could
occur
> > > from
> > > > the INCFSZ instruction, which is then lost when the ADDWF
instruction
> > > > executes.
> > >
> > > This is _not_ true.
> > >
> > > 1: <somebyte> was 255. The INCFSZ will skip the ADDWF with carry still
> > _set_
> > > to bring the carry up to the next byte.
> > >
> > > 2: <somebyte> was some other values. The INCFSZ will give us a result
that
> > > fits in 8 bits, then the ADDWF will set carry properly for the next
byte.
> >
> > Sorry, you're right. Somehow my mind blocked out the fact that is was
an
> > INCFSZ, not INCF.
> >
> > However, that brings up another problem. If SOMEBYTE was 255 and there
was
> > an incoming carry, the ADDWF will get skipped, which will prevent
RESULTBYTE
> > from being set. I am presuming here that the point of the code snippet
is
> > to perform an add with carry in/out of SOMEBYTE + RESULTBYTE >
RESULTBYTE?
>
> Yep.
>
> Challenge:
>
> If you don't care about the carry out, it's possible to perform a 16bit
add in
> 5 cycles. Since Nikolai is away from his computer, Dmitry is quiet, John
is
> (where is John?) and Andy is on a plane, this oughta be an interesting
> challenge.
Hmmm, I think can do 6, assuming carry is reset to begin with:
movf first_low_byte,w ;Add loworder bytes and
addwf second_low_byte,f ;store result in second low byte.
skpnc ;If there's a carry from this
incf first_high_byte,f ;increment one of the high bytes.
Movf first_high_byte,w ;Then add the high bytes and
addwf second_high_byte,f ;store the result in second_high_byte
I'm sure there's some trick with the carry check that I'm missing though.
How about adding the carry bit to the highbyte result instead of testing
for it?

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\20@075255
by
Andy Howard
From: "Bob Ammerman" <RAMMERMANEraseME.....PRODIGY.NET>
To: <EraseMEPICLISTMITVMA.MIT.EDU>
Sent: Thursday, October 19, 2000 9:12 PM
Subject: Re: [PIC]: Number crunching, enclosed is 24x24 equ 48, have fun
{Quote hidden}> > Challenge:
> >
> > If you don't care about the carry out, it's possible to perform a 16bit
> add in
> > 5 cycles. Since Nikolai is away from his computer, Dmitry is quiet, John
> is
> > (where is John?) and Andy is on a plane, this oughta be an interesting
> > challenge.
> >
> > Scott
>
>
> movf lo_a,W
> addwf lo_b,F
> rlf known_zero,W
> addwf hi_a,W
> addwf hi_b,F
Hmmm, I considered something like this but discarded it because you need an
extra cycle to define the zero variable. Or is known_zero some builtin
constant from the assembler?
.

http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2000\10\20@084339
by
Bob Ammerman

 Original Message 
From: Andy Howard <RemoveMEmusicaEraseMEEraseMEUKONLINE.CO.UK>
To: <RemoveMEPICLISTspam_OUTKILLspamMITVMA.MIT.EDU>
Sent: Friday, October 20, 2000 7:44 AM
Subject: Re: [PIC]: Number crunching, enclosed is 24x24 equ 48, have fun
> From: "Bob Ammerman" <RemoveMERAMMERMANTakeThisOuTspamPRODIGY.NET>
> To: <EraseMEPICLISTspamspamBeGoneMITVMA.MIT.EDU>
> Sent: Thursday, October 19, 2000 9:12 PM
> Subject: Re: [PIC]: Number crunching, enclosed is 24x24 equ 48, have fun
>
>
> > > Challenge:
> > >
> > > If you don't care about the carry out, it's possible to perform a
16bit
> > add in
> > > 5 cycles. Since Nikolai is away from his computer, Dmitry is quiet,
John
{Quote hidden}> > is
> > > (where is John?) and Andy is on a plane, this oughta be an interesting
> > > challenge.
> > >
> > > Scott
> >
> >
> > movf lo_a,W
> > addwf lo_b,F
> > rlf known_zero,W
> > addwf hi_a,W
> > addwf hi_b,F
>
>
> Hmmm, I considered something like this but discarded it because you need
an
> extra cycle to define the zero variable. Or is known_zero some builtin
> constant from the assembler?
>
No, 'known_zero' is a RAM location that is zeroed at initiali(s,z)ation and
then left alone. The cycle it takes to do that isn't counted for purposes of
the challenge because it can be done once and forgotten.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, lowlevel
software)

http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2000\10\21@111319
by
Snail Instruments

Hi Tony and all,
I'm sorry to disappoint you, but your 24x24 routine won't work. O.K., it
will work sometimes, but not always. Wasn't it suspicious at the very first
glance, that performing 24bit arithmetic one bit at a time takes only 23
cycles? Your example result is right after 23 cycles, but only due to
improper placement of left product rotation. What your routine really
calculates is:
Product = ((Multiplier>>1)*Multipland)<<1 (unsigned arithmetic)
e.g. omitting the least significant bit of Multiplier. To correct it  put
the product left rotation at the beginning of the loop and increase number
of cycles to 24. Also explicitly stating the number base (like D'24') will
help others integrate the routine into their programs.
Regards,
Josef
{Quote hidden}>***********************************************************************
>; MULTTIPLY_24x24  Routine to mutltiply two 24 bit numbers
>; result in 48 bits !
>; Format: Ram = MSB, Ram+2 = LSB ( for 24 bit variable ) ( little
>endian ? )
>; Ram used: Multiplier, Multipland 3 bytes each ( 24 bits )
>; Product 6 bytes ( 48 bits )
>; BitCount 1 byte for loop counting
>;
>; Multiplier is zero at exit ( destroyed )
>; Multipland is preserved
>; Product holds result
>;
>; Probably more efficient to use Ram = LSB, Ram+2 = MSB ( big endian ? )
>; According to helpful hints from Nikolai, however my requirements
>; dictated the used format.
>;
>MULTIPLY_24x24
> ; preload values to test
> MOVLW 0xAB
> MOVWF Multipland
> MOVLW 0xCD
> MOVWF Multipland+1
> MOVLW 0xEF
> MOVWF Multipland+2
>
> MOVLW 0x98
> MOVWF Multiplier
> MOVLW 0x76
> MOVWF Multiplier+1
> MOVLW 0x54
> MOVWF Multiplier+2
>
> ; these values should generate the reply = 0x6651AF33BC6C
>
> CLRF Product ; clear destination
> CLRF Product+1
> CLRF Product+2
> CLRF Product+3
> CLRF Product+4
> CLRF Product+5
>
>
> MOVLW 23
> MOVWF BitCount ; number of bits
> CLRC ; make sure the carry is initially
>cleared
>
>ADD_LOOP_24x24
> ; note carry assummed to be zero !
>
> RLF Multiplier+2,F ; up shift multiplier one bit
> RLF Multiplier+1,F
> RLF Multiplier,F
>
> BTFSS STATUS,C ; if carry is set we must add multipland
>to the product
> GOTO SKIP_LOOP_24x24 ; nope, skip this bit
>
> MOVF Multipland+2,W ; get LSB of multiplicand
> ADDWF Product+5,F ; add it to the lsb of the product
>
> MOVF Multipland+1,W ; middle byte
> BTFSC STATUS,C ; check carry for overflow
> INCFSZ Multipland+1,W ;
> ADDWF Product+4,F ; handle overflow
>
> MOVF Multipland,W ; MSB byte
> BTFSC STATUS,C ; check carry
> INCFSZ Multipland,W
> ADDWF Product+3,F ; handle overflow
>
> ; carry propagation, if set then make sure if 'follows' through
>
> MOVLW 0x01 ; preload with 1
> BTFSC STATUS,C ; check carry for overflow
> ADDWF Product+2,F ; add one to next byte
>
> BTFSC STATUS,C ; check carry for overflow
> ADDWF Product+1,F ; add one to next byte
>
> BTFSC STATUS,C ; check carry for overflow
> ADDWF Product,F ; add one to next byte
>
>
>SKIP_LOOP_24x24
> ; shift and prepare for next bit
>
> ; note Carry is always assumed to be zero here !
> ; should be handled by carry propagation above.
>
> RLF Product+5,F
> RLF Product+4,F
> RLF Product+3,F
> RLF Product+2,F
> RLF Product+1,F
> RLF Product,F
> ; note carry should always be zero here ( else overflow ? )
> ; affects rotate at the beginning of ADD_LOOP_24x24
> DECFSZ BitCount,F
> GOTO ADD_LOOP_24x24
> NOP
> NOP
> RETURN
>
=======================================================================
Electronical devices for chemical laboratory, custom electronics design

Snail Instruments Josef Hanzal, M. S.
Vojanova 615 phone/fax: +420311624433
266 01 Beroun email: RemoveMEsnailKILLspamiol.cz
Czech Republic URL: http://www.vitrum.cz/snail/
GPS: 49deg58'28" North, 14deg 4'35" East
=======================================================================

http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2000\10\23@044058
by
o88591?Q?K=FCbek_Tony?=

Hi,
sorry to You all but Josef found the error :)
subtle ( albeit 23 loops with 24 bit numbers.. ;) ).
Josef wrote:
>I'm sorry to disappoint you, but your 24x24 routine won't work. O.K.,
it
>will work sometimes, but not always. Wasn't it suspicious at the very
first
>glance, that performing 24bit arithmetic one bit at a time takes only
23
>cycles? Your example result is right after 23 cycles, but only due to
>improper placement of left product rotation. What your routine really
>calculates is:
>Product = ((Multiplier>>1)*Multipland)<<1 (unsigned arithmetic)
>
>e.g. omitting the least significant bit of Multiplier. To correct it 
put
>the product left rotation at the beginning of the loop and increase
number
>of cycles to 24. Also explicitly stating the number base (like D'24')
will
>help others integrate the routine into their programs.
You are correct ofcource, below is the 'fixed' version.
Took a while before I found it myself which brings up another
subject, automated tests, any suggestion for automating tests for
these kind of routines ?
Ok this was was quite easily spotted once you started to *read* the code
but still sometime one has more advanced routines what then ?
And sorry about the omitting the number base, normally I try to
always specify the base, but as this was just the first version
I inadvertely left that out.
So without further ado here is the corrected version:
**CORRECTED 24x24 bit routine **
;
***********************************************************************
; MULTTIPLY_24x24  Routine to mutltiply two 24 bit numbers
; result in 48 bits !
; Format: Ram = MSB, Ram+2 = LSB ( for 24 bit variable ) ( little
endian ? )
; Ram used: Multiplier, Multipland 3 bytes each ( 24 bits )
; Product 6 bytes ( 48 bits )
; BitCount 1 byte for loop counting
;
; Multiplier is zero at exit ( destroyed )
; Multipland is preserved
; Product holds result
;
;
MULTIPLY_24x24
; preload values to test
MOVLW 0xAB
MOVWF Multipland
MOVLW 0xCD
MOVWF Multipland+1
MOVLW 0xEF
MOVWF Multipland+2
MOVLW 0x98
MOVWF Multiplier
MOVLW 0x76
MOVWF Multiplier+1
MOVLW 0x54
MOVWF Multiplier+2
; these values should generate the reply = 0x6651AF33BC6C
CLRF Product ; clear destination
CLRF Product+1
CLRF Product+2
CLRF Product+3
CLRF Product+4
CLRF Product+5
MOVLW D'24'
MOVWF BitCount ; number of bits
CLRC ; make sure the carry is initially
cleared
ADD_LOOP_24x24
; note carry assummed to be zero !
; shift and prepare for next bit ( first time not really needed
)
RLF Product+5,F
RLF Product+4,F
RLF Product+3,F
RLF Product+2,F
RLF Product+1,F
RLF Product,F
RLF Multiplier+2,F ; up shift multiplier one bit
RLF Multiplier+1,F
RLF Multiplier,F
BTFSS STATUS,C ; if carry is set we must add multipland
to the product
GOTO SKIP_LOOP_24x24 ; nope, skip this bit
MOVF Multipland+2,W ; get LSB of multiplicand
ADDWF Product+5,F ; add it to the lsb of the product
MOVF Multipland+1,W ; middle byte
BTFSC STATUS,C ; check carry for overflow
INCFSZ Multipland+1,W ; if carry set we add one to the source
ADDWF Product+4,F ; and add it (if not zero, in
that case mulitpland = 0xff>0x00 )
MOVF Multipland,W ; MSB byte
BTFSC STATUS,C ; check carry
INCFSZ Multipland,W
ADDWF Product+3,F ; handle overflow
; carry propagation, if set then make sure if 'follows' through
MOVLW 0x01 ; preload with 1
BTFSC STATUS,C ; check carry for overflow
ADDWF Product+2,F ; add one to next byte
BTFSC STATUS,C ; check carry for overflow
ADDWF Product+1,F ; add one to next byte
BTFSC STATUS,C ; check carry for overflow
ADDWF Product,F ; add one to next byte
SKIP_LOOP_24x24
; note carry should always be zero here ( else overflow ? )
; affects rotate at the beginning of ADD_LOOP_24x24
DECFSZ BitCount,F
GOTO ADD_LOOP_24x24
NOP
NOP
RETURN
/Tony
Tony Kübek, Flintab AB
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: tony.kubekSTOPspamspam_OUTflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

http://www.piclist.com hint: To leave the PICList
spamBeGonepiclistunsubscriberequestSTOPspamEraseMEmitvma.mit.edu
2000\10\23@071102
by
Scott Dattalo
On Fri, 20 Oct 2000, Bob Ammerman wrote:
>
> No, 'known_zero' is a RAM location that is zeroed at initiali(s,z)ation and
> then left alone. The cycle it takes to do that isn't counted for purposes of
> the challenge because it can be done once and forgotten.
BTW, one way to make a know_zero without ccnsuming any extra ram is to use
FSR. In most (not all) applications, FSR is reinitialized each time it's
used. In those cases, it can be cleared before a long arithmetic computation
(like Tony's 24bit multiplication routine). The beauty of this is that the FSR
my be accessed from any bank. Furthermore, you can use INDF as known_zero too
(if fsr is cleared). I imagine if your goal was to write obfuscated code (with
the intent of discouraging reverse engineering), then this would be one clever
trick to keep in your bag.
Scott

http://www.piclist.com hint: To leave the PICList
KILLspampiclistunsubscriberequestspamBeGonemitvma.mit.edu
2000\10\23@125216
by
Dmitry A. Kiryashov
Hi Bob, Scott and other Piclisters ;)
Actually Bob answer is too prefect to improve it ;)
(I also just jumped out of plane from europe two
days ago ;)
WBR Dmitry.
Bob Ammerman wrote:
> Challenge
>
> If you don't care about the carry out, it's possible to perform a 16bit add in
> 5 cycles. Since Nikolai is away from his computer, Dmitry is quiet, John is
> (where is John?) and Andy is on a plane, this oughta be an interesting
> challenge.
>
> Scott
movf lo_a,W
addwf lo_b,F
rlf known_zero,W
addwf hi_a,W
addwf hi_b,F
Bob Ammerman
RAm Systems
> (contract development of high performance, high function, lowlevel
> software)

http://www.piclist.com hint: To leave the PICList
EraseMEpiclistunsubscriberequestEraseMEmitvma.mit.edu
2000\10\24@042142
by
Nikolai Golovchenko

Hi all!
Tony, the corrected version seems okay. I can see a way to
make it a bit smaller and less RAM requiring. The trick is
to share Product and Muliplier variables.
Something like this:
cblock
Product:6
Multipland:3
BitCount:1
endc
Multiplier EQU Product+3 ;3 bytes shared with Product's
;less significant bytes (+3..5)
MULTIPLY_24x24
; preload values to test
MOVLW 0xAB
MOVWF Multipland
MOVLW 0xCD
MOVWF Multipland+1
MOVLW 0xEF
MOVWF Multipland+2
MOVLW 0x98
MOVWF Multiplier
MOVLW 0x76
MOVWF Multiplier+1
MOVLW 0x54
MOVWF Multiplier+2
; these values should generate the reply = 0x6651AF33BC6C
;24 x 24 Multiplication
;Input:
; Multiplier  3 bytes (shared with Product)
; Multiplicand  3 bytes (not modified)
;Temporary:
; Bitcount
;Output:
; Product  6 bytes
CLRF Product ; clear destination
CLRF Product+1
CLRF Product+2
MOVLW D'24'
MOVWF BitCount ; number of bits
RRF Product+3,F ;shift out to carry
RRF Product+4,F ;next multiplier bit
RRF Product+5,F
ADD_LOOP_24x24
BTFSS STATUS,C ; if carry is set we must add multipland
; to the product
GOTO SKIP_LOOP_24x24 ; nope, skip this bit
MOVF Multipland+2,W ; get LSB of multiplicand
ADDWF Product+2,F ; add it to the lsb of the product
MOVF Multipland+1,W ; middle byte
BTFSC STATUS,C ; check carry for overflow
INCFSZ Multipland+1,W ; if carry set we add one to the source
ADDWF Product+1,F ; and add it (if not zero, in
; that case mulitpland = 0xff>0x00 )
MOVF Multipland,W ; MSB byte
BTFSC STATUS,C ; check carry
INCFSZ Multipland,W
ADDWF Product,F ; handle overflow
SKIP_LOOP_24x24
; note carry contains most significant bit of
; addition here
; shift in carry and shift out
; next multiplier bit, starting from less
; significant bit
RRF Product,F
RRF Product+1,F
RRF Product+2,F
RRF Product+3,F
RRF Product+4,F
RRF Product+5,F
DECFSZ BitCount,F
GOTO ADD_LOOP_24x24
NOP
NOP
RETURN
In that case big endian takes exactly the same amount of
code as little endian would. I think as long as you use
fixed number of bytes for variables in a program, it does
not matter which notation to use, because the code would be
the same.
But often you variable size grows or shrinks during
calculations. For example, if you multiply a 9 bit variable
by 0.5 the result would be 8 bit, and it would be more
efficient to use the result as one byte instead of using two
bytes, one of which is zero. So it depends on how you keep
track of variable sizes. If you don't, then the notation
probably doesn't matter.
I think the little endian notation is a more convinient form
for human(e) assembly programmers. In little endian byte
number means its weight, which is always the same.
For example:
Little endian:
8 bit R0
weight=1
16 bit R1 (MSB) R0(LSB)
weight=256 1
24 bit R2 (MSB) R1 R0(LSB)
65536 256 1
Big endian:
8 bit R0
weight=1
16 bit R1 (LSB) R0(MSB)
weight=1 256
24 bit R2 (LSB) R1 R0(MSB)
1 256 65536
Therefore, it's easier to shrink/extend a variable using
little endian. If you know the variable has changed its size
from 9 to 8 bits you simply don't use the R1 byte, which is
zero. But in big endian, this approach is a complete mess,
because you have to remember not to use R0 (MSB), but use
R1. Similarly, when you switch size from 8 to 9 bits in
little endian, you just start to use next byte (R1). But in
big guy, you have to copy R0 to R1 and clear R0 first, which
is a waste of resources (and brain cells).
The only advantage of big endian I can think of is when you
need to divide by 256. That operation does not require any
instructions. For example, R2:R0 / 256 = R1:R0
Any other thoughts on that?
Nikolai

Subject: Re: [PIC]: Number crunching, enclosed is 24x24 equ 48, have fun < Corrected !
From: Kubek Tony (@spam@tony.kubek@spam@spam_OUTFLINTAB.COM)
Date: Mon Oct 23 2000  00:55:33 PDT

Hi,
sorry to You all but Josef found the error :)
subtle ( albeit 23 loops with 24 bit numbers.. ;) ).
Josef wrote:
>I'm sorry to disappoint you, but your 24x24 routine won't work. O.K.,
it
>will work sometimes, but not always. Wasn't it suspicious at the very
first
>glance, that performing 24bit arithmetic one bit at a time takes only
23
>cycles? Your example result is right after 23 cycles, but only due to
>improper placement of left product rotation. What your routine really
>calculates is:
>Product = ((Multiplier>>1)*Multipland)<<1 (unsigned arithmetic)
>
>e.g. omitting the least significant bit of Multiplier. To correct it 
put
>the product left rotation at the beginning of the loop and increase
number
>of cycles to 24. Also explicitly stating the number base (like D'24')
will
>help others integrate the routine into their programs.
You are correct ofcource, below is the 'fixed' version.
Took a while before I found it myself which brings up another
subject, automated tests, any suggestion for automating tests for
these kind of routines ?
Ok this was was quite easily spotted once you started to *read* the code
but still sometime one has more advanced routines what then ?
And sorry about the omitting the number base, normally I try to
always specify the base, but as this was just the first version
I inadvertely left that out.
So without further ado here is the corrected version:
**CORRECTED 24x24 bit routine **
;
***********************************************************************
; MULTTIPLY_24x24  Routine to mutltiply two 24 bit numbers
; result in 48 bits !
; Format: Ram = MSB, Ram+2 = LSB ( for 24 bit variable ) ( little
endian ? )
; Ram used: Multiplier, Multipland 3 bytes each ( 24 bits )
; Product 6 bytes ( 48 bits )
; BitCount 1 byte for loop counting
;
; Multiplier is zero at exit ( destroyed )
; Multipland is preserved
; Product holds result
;
;
MULTIPLY_24x24
; preload values to test
MOVLW 0xAB
MOVWF Multipland
MOVLW 0xCD
MOVWF Multipland+1
MOVLW 0xEF
MOVWF Multipland+2
MOVLW 0x98
MOVWF Multiplier
MOVLW 0x76
MOVWF Multiplier+1
MOVLW 0x54
MOVWF Multiplier+2
; these values should generate the reply = 0x6651AF33BC6C
CLRF Product ; clear destination
CLRF Product+1
CLRF Product+2
CLRF Product+3
CLRF Product+4
CLRF Product+5
MOVLW D'24'
MOVWF BitCount ; number of bits
CLRC ; make sure the carry is initially
cleared
ADD_LOOP_24x24
; note carry assummed to be zero !
; shift and prepare for next bit ( first time not really needed
)
RLF Product+5,F
RLF Product+4,F
RLF Product+3,F
RLF Product+2,F
RLF Product+1,F
RLF Product,F
RLF Multiplier+2,F ; up shift multiplier one bit
RLF Multiplier+1,F
RLF Multiplier,F
BTFSS STATUS,C ; if carry is set we must add multipland
to the product
GOTO SKIP_LOOP_24x24 ; nope, skip this bit
MOVF Multipland+2,W ; get LSB of multiplicand
ADDWF Product+5,F ; add it to the lsb of the product
MOVF Multipland+1,W ; middle byte
BTFSC STATUS,C ; check carry for overflow
INCFSZ Multipland+1,W ; if carry set we add one to the source
ADDWF Product+4,F ; and add it (if not zero, in
that case mulitpland = 0xff>0x00 )
MOVF Multipland,W ; MSB byte
BTFSC STATUS,C ; check carry
INCFSZ Multipland,W
ADDWF Product+3,F ; handle overflow
; carry propagation, if set then make sure if 'follows' through
MOVLW 0x01 ; preload with 1
BTFSC STATUS,C ; check carry for overflow
ADDWF Product+2,F ; add one to next byte
BTFSC STATUS,C ; check carry for overflow
ADDWF Product+1,F ; add one to next byte
BTFSC STATUS,C ; check carry for overflow
ADDWF Product,F ; add one to next byte
SKIP_LOOP_24x24
; note carry should always be zero here ( else overflow ? )
; affects rotate at the beginning of ADD_LOOP_24x24
DECFSZ BitCount,F
GOTO ADD_LOOP_24x24
NOP
NOP
RETURN
/Tony
Tony Kubek, Flintab AB
????????????????????????????????????????????????????????????
Email: spamBeGonetony.kubekKILLspamflintab.com
????????????????????????????????????????????????????????????

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads
2000\10\24@045123
by
o88591?Q?K=FCbek_Tony?=
Hi,
(congrats! :) )
You beat me to it, thought about 'removing' one of the
variables to save ram, was positive it could be done.
As always, amazing job.
( havent tested it yet though..will be back later )
/Tony
Tony Kübek, Flintab AB
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: .....tony.kubekspam_OUTflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"
2000\10\24@062748
by
o88591?Q?K=FCbek_Tony?=

Hi, seems ok, but how about saving three cycles:
Something like this:
cblock
Product:6
Multipland:3
BitCount:1
endc
Multiplier EQU Product+3 ;3 bytes shared with Product's
;less significant bytes (+3..5)
MULTIPLY_24x24
; preload values to test
MOVLW 0xAB
MOVWF Multipland
MOVLW 0xCD
MOVWF Multipland+1
MOVLW 0xEF
MOVWF Multipland+2
MOVLW 0x98
MOVWF Multiplier
MOVLW 0x76
MOVWF Multiplier+1
MOVLW 0x54
MOVWF Multiplier+2
; these values should generate the reply = 0x6651AF33BC6C
;24 x 24 Multiplication
;Input:
; Multiplier  3 bytes (shared with Product)
; Multiplicand  3 bytes (not modified)
;Temporary:
; Bitcount
;Output:
; Product  6 bytes
CLRF Product ; clear destination
CLRF Product+1
CLRF Product+2
MOVLW D'24'
MOVWF BitCount ; number of bits
ADD_LOOP_24x24
; 1) first time carry=0 then shift out least significant bit
; 2) every other loop carry in and carry out
RRF Product+3,F ;shift out to carry
RRF Product+4,F ;next multiplier bit
RRF Product+5,F
; note this segement is also equal to:
; ( as multiplier = Product+3 )
; RRF Multiplier,F
; RRF Multiplier+1,F
; RRF Multiplier+2,F
BTFSS STATUS,C ; if carry is set we must add multipland
; to the product
GOTO SKIP_LOOP_24x24 ; nope, skip this bit
MOVF Multipland+2,W ; get LSB of multiplicand
ADDWF Product+2,F ; add it to the lsb of the product
MOVF Multipland+1,W ; middle byte
BTFSC STATUS,C ; check carry for overflow
INCFSZ Multipland+1,W ; if carry set we add one to the source
ADDWF Product+1,F ; and add it (if not zero, in
; that case mulitpland = 0xff>0x00 )
MOVF Multipland,W ; MSB byte
BTFSC STATUS,C ; check carry
INCFSZ Multipland,W
ADDWF Product,F ; handle overflow
SKIP_LOOP_24x24
; note carry contains most significant bit of
; addition here
; shift in carry and shift out
; next multiplier bit, starting from less
; significant bit
RRF Product,F
RRF Product+1,F
RRF Product+2,F
; carry out to rotate at beginning of add_loop
DECFSZ BitCount,F
GOTO ADD_LOOP_24x24
NOP
NOP
RETURN
Saves three cycles ;)
/Tony
Tony Kübek, Flintab AB
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: TakeThisOuTtony.kubek.....TakeThisOuTflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"
2000\10\24@062754
by
o88591?Q?K=FCbek_Tony?=
Hi, again sorry about the last posting will not work.
I know why.
No need to correct me.
/Tony
Tony Kübek, Flintab AB
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: TakeThisOuTtony.kubekKILLspamspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"
2000\10\24@102150
by
Morgan Olsson

Dmitry A. Kiryashov wrote:
>Actually Bob answer is too prefect to improve it ;)
It´s so nice I´m putting it in my 16bit macro file. :)
And... the carry out IS correct, right?
I found a 16bit subtract constant in my archive which I append at end.
I´m too tired to convince myself about the carry on that one for the moment though.
I tend to believe there is also a five cycle add constant solution.
Five cycle subtract register from register seem impossible... not?
Gotta go
/Morgan
{Quote hidden}>Bob Ammerman wrote:
>
>> Challenge
>>
>> If you don't care about the carry out, it's possible to perform a 16bit add in
>> 5 cycles. Since Nikolai is away from his computer, Dmitry is quiet, John is
>> (where is John?) and Andy is on a plane, this oughta be an interesting
>> challenge.
>>
>> Scott
>
> movf lo_a,W
> addwf lo_b,F
> rlf known_zero,W
> addwf hi_a,W
> addwf hi_b,F
>
>Bob Ammerman
>RAm Systems
>
>> (contract development of high performance, high function, lowlevel
>> software)
>
>
>
http://www.piclist.com hint: To leave the PICList
>
.....piclistunsubscriberequestRemoveMEmitvma.mit.edu

Part of mail on PICLIST from Rich Leggitt <RemoveMErleggittspamBeGoneconcentric.net> 20000311 :
Consider subtraction of 16bit constant from memory:
PIC = 5 cycles/70 bits (14 bit core):
movlw low(const)
subwf LO,f
rlf ZERO,w
sublw high(const)+1
subwf HI,f
Regards
/Morgan

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"
2000\10\24@105056
by
Scott Dattalo
On Tue, 24 Oct 2000, Morgan Olsson wrote:
> Dmitry A. Kiryashov wrote:
> >Actually Bob answer is too prefect to improve it ;)
>
> It´s so nice I´m putting it in my 16bit macro file. :)
> And... the carry out IS correct, right?
most of the time... Here's the routine again.
Now suppose you add: a= 0xff80
b= 0xff80
The result 0x1ff00, or 0xff00 with a carry. But consider the routine:
movf lo_a,W ;W = 0x80
addwf lo_b,F ;lo_b = 0x80 + 0x80 ==> 0, carry is set
rlf known_zero,W ;W=1 (picks up the carry)
addwf hi_a,W ;W=0xff+1 ==> 0, carry is set
addwf hi_b,F ;hi_b = 0xff+0 ==> 0xff carry is cleared.
So, the lower 16bits are correct, but the carry should be set and isn't. The
6cycle solution doesn't suffer this problem.

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"
2000\10\24@124115
by
Morgan Olsson
Ah, yes... very clear now, thanks Scott! :)
/Morgan
Scott Dattalo wrote:
{Quote hidden}>On Tue, 24 Oct 2000, Morgan Olsson wrote:
>
>> Dmitry A. Kiryashov wrote:
>> >Actually Bob answer is too prefect to improve it ;)
>>
>> It´s so nice I´m putting it in my 16bit macro file. :)
>> And... the carry out IS correct, right?
>
>most of the time... Here's the routine again.
>
>Now suppose you add:
> a= 0xff80
> b= 0xff80
>
>The result 0x1ff00, or 0xff00 with a carry. But consider the routine:
>
>
> movf lo_a,W ;W = 0x80
> addwf lo_b,F ;lo_b = 0x80 + 0x80 ==> 0, carry is set
> rlf known_zero,W ;W=1 (picks up the carry)
> addwf hi_a,W ;W=0xff+1 ==> 0, carry is set
> addwf hi_b,F ;hi_b = 0xff+0 ==> 0xff carry is cleared.
>
>So, the lower 16bits are correct, but the carry should be set and isn't. The
>6cycle solution doesn't suffer this problem.
>
>

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"
2000\10\24@132527
by
jamesnewton
I've posted this to the FAQ, but I'm not sure who to credit... so far I have
Tony Kbek, Nikolai Golovchenko, Scott Dattalo, and Bob Ammerman
Did I miss any?
Has this version been tested?

James Newton (PICList Admin #3)
spamBeGonejamesnewton@spam@spam_OUTpiclist.com 16196520593
PIC/PICList FAQ: http://www.piclist.com or .org
{Original Message removed}
2000\10\24@160121
by
Bob Ammerman
It´s so nice I´m putting it in my 16bit macro file. :)
And... the carry out IS correct, right?
> movf lo_a,W
> addwf lo_b,F
> rlf known_zero,W
> addwf hi_a,W
> addwf hi_b,F
Unfortuntately the carry out is _not_ right. Try this case:
lo_a = 128
lo_b = 128
hi_a = 255
hi_b = 0
movf lo_a,W ; w < 128
addwf lo_b,F ; lo_b < 0, carry is set
rlf known_zero,W ; w<1, carry is clear
addwf hi_a,W ; w<0, carry is set
addwf hi_b,F ; hi_b = 0, carry is clear
Carry, of course, should be set in this case.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, lowlevel
software)

http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"
2000\10\25@043007
by
o88591?Q?K=FCbek_Tony?=
Hi,
James newton wrote:
>I've posted this to the FAQ, but I'm not sure who to credit... so far I
have
>Tony Kbek, Nikolai Golovchenko, Scott Dattalo, and Bob Ammerman
>Did I miss any?
Well I think the original version was made entirely by Nicolai,
( of the enclosed one ), albeit I made an slightly more inefficient
last week. Nethertheless I think credit should go to Nicolai alone.
>Has this version been tested?
Well, the enclosed version has an error :) the original by
Nicolai however does not ( as far as I have confirmed sofar ).
Thought one could save a few cycles but apperently not.
/Tony
Tony Kübek, Flintab AB
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
Email: TakeThisOuTtony.kubekspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
More... (looser matching)
 Last day of these posts
 In 2000
, 2001 only
 Today
 New search...