Searching \ for 'Re[2]: Code error' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=code+error+RE%5D
Search entire site for: 'Code error'.

Truncated match.
PICList Thread
'Re[2]: Code error'
1997\02\20@094939 by Craig Knotts

flavicon
face
    Andy, I've jibed Andy W. about his idea of "standard" notation as
    well.  I think Motorola also uses the $ prefix for hex as well.  As
    far as I know, there is no real STANDARD notation for hex numbers.  I
    have seen several, including a Hitachi assembler that uses h'C0 to
    indicate a hex number - note the lack of a closing apostrophe.


______________________________ Reply Separator _________________________________
Subject: Re: Code error
Author:  Andy Kunz <spam_OUTmontanaTakeThisOuTspamFAST.NET> at Internet
Date:    2/20/97 5:19 AM


>Much has been said, here on the list and on Microchip's BBS,
>regarding this issue.  Unfortunately, none of those comments has
>been sufficient to convince Microchip to permanently solve the
>problem by adding the "standard" '$' and '%' radix specifiers to
>MPASM's vocabulary.


Andy,

What are "$" and "%" standards in?  What do they mean?  All the assemblers
I've used either have C notation 0xc0 or the "real" standard that caught
this guy, 0c0h.

Oh wait, the Rockwell assembler (Apple ][) did use "$" I think.

$ would then be context sensitive, because it's the standard to denote
"current PC" as in
       goto    $-1

for an infinite loop.  I never liked making compilers with context-sensitive
tokens myself.

Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\02\20@160720 by Craig Knotts

flavicon
face
    Which is exactly why I feel the default radix should ALWAYS be
    decimal.  When I look at a number without a qualifier, it should be a
    decimal number.


______________________________ Reply Separator _________________________________
Subject: Re: Code error
Author:  Andrew Warren <.....fastfwdKILLspamspam@spam@IX.NETCOM.COM> at Internet
Date:    2/20/97 11:35 AM


   Here's something that I think may convince you that that "real"
   standard is evil:

   Consider the instruction "MOVLW 00000001B".

   With MPASM's default radix set to decimal, the above instruction
   is, of course, equivalent to "MOVLW 1".

   HOWEVER, if the default radix is set to hexadecimal, the SAME
   line has a totally DIFERENT meaning; the assembler is forced to
   interpret it as equivalent to "MOVLW 0x1B"!

1997\02\20@161559 by Andy Kunz

flavicon
face
At 09:45 AM 2/20/97 -0500, you wrote:
>     Andy, I've jibed Andy W. about his idea of "standard" notation as
>     well.  I think Motorola also uses the $ prefix for hex as well.  As
>     far as I know, there is no real STANDARD notation for hex numbers.  I
>     have seen several, including a Hitachi assembler that uses h'C0 to
>     indicate a hex number - note the lack of a closing apostrophe.

I remember Motorola too.  I usually use the Avocet stuff, which pretty
closely follows the mfg's standards, but I've done some with a unix-based
mot assembler which uses C syntax.

Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\02\20@161806 by Byron A Jeff

face picon face
>
>      Which is exactly why I feel the default radix should ALWAYS be
>      decimal.  When I look at a number without a qualifier, it should be a
>      decimal number.

I agree. What I do to resolve the potential conflict is to always use the
proper header (. for decimal, 0x for hex, generally don't use binary or
octal) to ensure that the number is always interpreted properly.

Hasn't failed me yet.

BAJ
>
>
> ______________________________ Reply Separator
_________________________________
{Quote hidden}

1997\02\20@164612 by Craig Knotts

flavicon
face
    I've found that it can depend on the assembler.  The assembler usually
    sets $ to the PC value of the current instruction, not to the value
    that would exist after the goto is executed; therefore goto $ would be
    the proper notation for an infinite loop.  goto $-1 would go to the
    previous instruction.  The assembler will take care of the fact that
    PC has changed by the time the goto executes.

    If fact, your examples are inconsistent on this matter.
    If " goto $-1" returns you to the current instruction, then goto $+1
    would send you two words downstream instead of to the next
    instruction.


______________________________ Reply Separator _________________________________
Subject: Re: Code error
Author:  Andy Kunz <.....montanaKILLspamspam.....FAST.NET> at Internet
Date:    2/20/97 4:18 PM


>Isn't an infinite loop done with:   goto   $

No, because PC has been incremented to point to the next instruction.
Standard notation is to do it     goto $-1 for a 1-word wide instruction.
If you were using a Z-80, you could   JP $-3, since JP is a three-byte
instruction (0xC3, LSB, MSB).

Funny, but that's the way it is.

>In your example, if the statement previous was some other goto, it might not be
>infinite.  ie:    goto  $+2
>                  goto  $-1

Here's a hint.  If you have to a waste time, and you would normally write it as
       NOP
       NOP
       NOP
       NOP

try using the following instead.

       goto    $+1
       goto    $+1

Both take 4 instruction cycles, but you only need half as many instructions
to do it.

Warning - if you're using interrupts and need very close catching of the
interrupt, go with the NOPs instead.  The interrupt won't be serviced until
the current instruction is finished, which takes 2 times rather than 1 in
this case.

Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\02\20@180957 by Andrew Warren

face
flavicon
face
I wrote:

> Consider the instruction "MOVLW 00000001B".
>
> With MPASM's default radix set to decimal, the above instruction
> is, of course, equivalent to "MOVLW 1".
>
> HOWEVER, if the default radix is set to hexadecimal, the SAME line
> has a totally DIFERENT meaning; the assembler is forced to
> interpret it as equivalent to "MOVLW 0x1B"!

and Craig Knotts <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU> replied:

> Which is exactly why I feel the default radix should ALWAYS be
> decimal.  When I look at a number without a qualifier, it should be
> a decimal number.

   I feel the same way, Craig, but in this case, I was trying to
   make a slightly different point, to wit:

   No matter WHAT default radix you choose, and no mmatter WHAT
   notation is being forced on you by your assembler vendor, you
   should always AT LEAST be able to unambiguously specify a number
   by using radix specifiers.

   The brain-dead "0xxB"/"0xxH" notation fails miserably in this
   regard.

   -Andy

=== Andrew Warren - fastfwdspamspam_OUTix.netcom.com
=== Fast Forward Engineering, Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\02\20@184913 by Andy Kunz

flavicon
face
At 04:02 PM 2/20/97 -0500, you wrote:
>     Which is exactly why I feel the default radix should ALWAYS be
>     decimal.  When I look at a number without a qualifier, it should be a
>     decimal number.

Me too.  Guess we're human, eh?

Good thing the abacus isn't the basis of computers, isn't it?!

Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\02\20@205941 by John Payson

picon face
> Here's a hint.  If you have to a waste time, and you would normally write it
as
>         NOP
>         NOP
>         NOP
>         NOP
>
> try using the following instead.
>
>         goto    $+1
>         goto    $+1
>
> Both take 4 instruction cycles, but you only need half as many instructions
> to do it.

Another alternative, if you have a spare slot in the stack, is:

       call    Wait4


... somewhere later on
       return

This uses up one space on the stack, but since you only need one return to
handle any number of calls, each delay statement after the first only needs
one instruction rather than two.

> Warning - if you're using interrupts and need very close catching of the
> interrupt, go with the NOPs instead.  The interrupt won't be serviced until
> the current instruction is finished, which takes 2 times rather than 1 in
> this case.

This is inconsistent with Microchip's documentation.  According to the data
book, the PIC will always perform a "skip" cycle at the start of every
interrupt.  If the scheduled instruction would have been skipped, the PIC
will stack the program counter at the end of that cycle; if it would have
been executed the PIC will stack the PC at the beginning of that cycle.

In general, it's easiest to think of the PIC as having all single-cycle in-
structions which may either be executed or not, except for jumps which are
two cycles if executed and one if not.  It makes it very easy to count cycles
if you use this model (e.g.

       movf    SourceH,w
       btfsc   C
        incfsz SourceH,w
        addwf  DestH,w

is clearly four cycles) rather than figuring skip instructions as 1 or 2, and
skipped instructions as 0 or 1.  In fact, by the way of thinking suggested by
Microchip's cycle counts, the third instruction in the example above may take
0, 1, or 2 cycles!  This is a level of confusion which is totally unnecessary
given the real behavior of the part.

The only time that these detailed cycle counts matter is when returning from
interrupts.  In particular, a simple interrupt routine which might appear as
though it should always take 10 cycles to execute will in fact only take nine
if the interrupt is triggered immediately before an instruction that should
be skipped.  Because the address that gets stacked is that of the instruction
following the skipped instruction, the user program does not have to waste the
skip cycle when it returns from interrupt.  In practice, I doubt if this would
ever be an issue for any practical programming project.

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...