Searching \ for '[PIC]: Number crunching, enclosed is 24x24 equ 48,' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Number crunching, enclosed is 24x24 equ 48,'.

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

flavicon
face
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 so-far ) 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..pic-code on the pic-list what will come next ;)

/Tony


Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: spam_OUTtony.kubekTakeThisOuTspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"

2000\10\19@075219 by Scott Dattalo

face
flavicon
face
On Thu, 19 Oct 2000, [Iso-8859-1] 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 so-far ) 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}

  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..pic-code on the pic-list 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

picon face
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 N-byte multiple precision add. If
this trick is well-known, it has somehow escaped me. [James: how about a
section on N-byte 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 'no-endian' (ie: 8-bit memory accesses only) processor.


Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
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

picon face
----- Original Message -----
From: Scott Dattalo <.....scottKILLspamspam@spam@DATTALO.COM>

The following section may be shortened slightly in one of two ways:

{Quote hidden}

  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, low-level
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

face
flavicon
face
On Thu, 19 Oct 2000, Bob Ammerman wrote:

> ----- Original Message -----
> From: Scott Dattalo <scottspamKILLspamDATTALO.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 o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
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 e-mail
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 N-byte multiple precision
add. If
>this trick is well-known, it has somehow escaped me. [James: how about
a
>section on N-byte 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            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: .....tony.kubekKILLspamspam.....flintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"

2000\10\19@125005 by staff

flavicon
face
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

picon face
  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

flavicon
face
> movf    <somebyte>,W
> skpnc
> incfsz    <somebyte>,W
> addwf    <resultbyte>,F
>
> As a slick way to do handle carries in an N-byte multiple precision add.
If
> this trick is well-known, it has somehow escaped me. [James: how about a
> section on N-byte arithmetic in the code snippets archive?]

Note that this only works if RESULTBYTE is the last (highest) byte of the
multi-byte 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) 772-3129, EraseMEolinspam_OUTspamTakeThisOuTcognivis.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

picon face
----- Original Message -----
From: Olin Lathrop <olin_piclistspamspam_OUTCOGNIVIS.COM>
To: <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Thursday, October 19, 2000 1:29 PM
Subject: Re: [PIC]: Number crunching, enclosed is 24x24 equ 48, have fun


{Quote hidden}

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, low-level
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

flavicon
face
> > > movf    <somebyte>,W
> > > skpnc
> > > incfsz    <somebyte>,W
> > > addwf    <resultbyte>,F
> > >
> > > As a slick way to do handle carries in an N-byte multiple precision
add.
> > If
> > > this trick is well-known, it has somehow escaped me. [James: how about
a
> > > section on N-byte arithmetic in the code snippets archive?]
> >
> > Note that this only works if RESULTBYTE is the last (highest) byte of
the
> > multi-byte 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) 772-3129, KILLspamolinKILLspamspamcognivis.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

face
flavicon
face
On Thu, 19 Oct 2000, Olin Lathrop wrote:

{Quote hidden}

Yep.

Challenge:

If you don't care about the carry out, it's possible to perform a 16-bit 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

picon face
----- Original Message -----
From: Olin Lathrop <RemoveMEolin_piclistTakeThisOuTspamCOGNIVIS.COM>
To: <spamBeGonePICLISTspamBeGonespamMITVMA.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, low-level
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

picon face
> Challenge:
>
> If you don't care about the carry out, it's possible to perform a 16-bit
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, low-level
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

face
flavicon
face
On Thu, 19 Oct 2000, Bob Ammerman wrote:

> > Challenge:
> >
> > If you don't care about the carry out, it's possible to perform a 16-bit
> 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

picon face
----- Original Message -----
From: "Scott Dattalo" <TakeThisOuTscottEraseMEspamspam_OUTDATTALO.COM>
To: <RemoveMEPICLISTspamTakeThisOuTMITVMA.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 N-byte multiple
precision
> > add.
> > > > If
> > > > > this trick is well-known, it has somehow escaped me. [James: how
about
> > a
> > > > > section on N-byte arithmetic in the code snippets archive?]
> > > >
> > > > Note that this only works if RESULTBYTE is the last (highest) byte
of
> > the
> > > > multi-byte 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 16-bit
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 low-order 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 high-byte 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

picon face
From: "Bob Ammerman" <RAMMERMANEraseMEspam.....PRODIGY.NET>
To: <EraseMEPICLISTspamMITVMA.MIT.EDU>
Sent: Thursday, October 19, 2000 9:12 PM
Subject: Re: [PIC]: Number crunching, enclosed is 24x24 equ 48, have fun


{Quote hidden}

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 built-in
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

picon face
----- Original Message -----
From: Andy Howard <RemoveMEmusicaEraseMEspamEraseMEUKONLINE.CO.UK>
To: <RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.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" <RemoveMERAMMERMANTakeThisOuTspamspamPRODIGY.NET>
> To: <EraseMEPICLISTspamspamspamBeGoneMITVMA.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
16-bit
> > add in
> > > 5 cycles. Since Nikolai is away from his computer, Dmitry is quiet,
John
{Quote hidden}

an
> extra cycle to define the zero variable.  Or is known_zero some built-in
> 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, low-level
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

flavicon
face
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}

=======================================================================
Electronical devices for chemical laboratory, custom electronics design
-----------------------------------------------------------------------
Snail Instruments                      Josef Hanzal, M. S.
Vojanova 615                           phone/fax: +420-311-624433
266 01 Beroun                          e-mail: RemoveMEsnailKILLspamspamiol.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 o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
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            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: tony.kubekSTOPspamspamspam_OUTflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestSTOPspamspamEraseMEmitvma.mit.edu




2000\10\23@071102 by Scott Dattalo

face
flavicon
face
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 re-initialized each time it's
used. In those cases, it can be cleared before a long arithmetic computation
(like Tony's 24-bit 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
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu




2000\10\23@125216 by Dmitry A. Kiryashov

flavicon
face
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 16-bit 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, low-level
> software)

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamEraseMEmitvma.mit.edu




2000\10\24@042142 by Nikolai Golovchenko

flavicon
face
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@spamspam_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
????????????????????????????????????????????????????????????
E-mail: spamBeGonetony.kubekspamKILLspamflintab.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 o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
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            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: .....tony.kubekspam_OUTspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"

2000\10\24@062748 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
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            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: TakeThisOuTtony.kubek.....spamTakeThisOuTflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"

2000\10\24@062754 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi, again sorry about the last posting will not work.
I know why.

No need to correct me.

/Tony



Tony Kübek, Flintab AB            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: TakeThisOuTtony.kubekKILLspamspamspamflintab.com
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"

2000\10\24@102150 by Morgan Olsson

picon face
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}

------------------------

Part of mail on PICLIST from Rich Leggitt <RemoveMErleggittspamspamBeGoneconcentric.net> 2000-03-11 :

Consider subtraction of 16-bit 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

face
flavicon
face
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
6-cycle 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

picon face
Ah, yes... very clear now, thanks Scott!  :)
/Morgan

Scott Dattalo wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"

2000\10\24@132527 by jamesnewton

face picon face
I've posted this to the FAQ, but I'm not sure who to credit... so far I have
Tony K|bek, Nikolai Golovchenko, Scott Dattalo, and Bob Ammerman
Did I miss any?

Has this version been tested?

---
James Newton (PICList Admin #3)
spamBeGonejamesnewton@spam@spamspam_OUTpiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2000\10\24@160121 by Bob Ammerman

picon face
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, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:"

2000\10\25@043007 by o-8859-1?Q?K=FCbek_Tony?=

flavicon
face
Hi,

James newton wrote:

>I've posted this to the FAQ, but I'm not sure who to credit... so far I
have
>Tony K|bek, 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 in-efficient
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            
²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²
E-mail: TakeThisOuTtony.kubekspamspamflintab.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...