Searching \ for 'Code error' 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/index.htm?key=code+error
Search entire site for: 'Code error'.

Truncated match.
PICList Thread
'Code error'
1997\02\20@033613 by Philip Martin

flavicon
picon face
Hi all,

Wonder if someone can help me. Im in the middle of trying to write a
small program, but I cant figure out why I keep getting a error from
MPASM on the following line.

newlin  MOVLW   c0h

This keeps on giving the following on compiling:

Error   LCD_PHIL.ASM 289 : Undefined argument (c0h)

Yet, the following line seems to compile OK:

     MOVLW   02h

To me, it would seem that it is not accepting c0h as a Hex number to
load into W. If that is the case then why. Else, what am I doing wrong ?

TIA.
--
Philip Martin   email spam_OUTphilipTakeThisOuTspamphilmart.demon.co.uk
Royal Quays, North Shields

1997\02\20@042654 by Andrew Warren

face
flavicon
face
Philip Martin <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU> wrote:

> newlin  MOVLW   c0h
>
> This keeps on giving the following on compiling:
>
> Error   LCD_PHIL.ASM 289 : Undefined argument (c0h)
>
> Yet, the following line seems to compile OK:
>
>       MOVLW   02h
>
> To me, it would seem that it is not accepting c0h as a Hex number to
> load into W. If that is the case then why.

Philip:

You're right; MPASM sees "C0H" as a symbol, not a number.  To solve
the problem, replace it with "0C0H" or use one of the other radix
specifiers ("0xC0" or "h'C0') that are accepted by MPASM.

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

=== Andrew Warren - fastfwdspamKILLspamix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Did the information in this post help you?  Consider
=== contributing to the PICLIST Fund.  Details are at:
=== www.geocities.com/SiliconValley/2499/fund.html

1997\02\20@051833 by Andy Kunz

flavicon
face
>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@063022 by ermott

flavicon
face
Philip-

I think MPASM requires that hex numbers start with 0.  Where 02h is
accepted c0h would need to be written as 0c0h.

1997\02\20@072731 by D. R. Chicotel

flavicon
face
At 05:19 AM 2/20/97 -0500, you wrote:
>$ 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.
>

Isn't an infinite loop done with:   goto   $

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

Sorry, I'm picking nits.

1997\02\20@141614 by David W. Duley

picon face
In a message dated 97-02-20 03:36:29 EST, you write:

<< Hi all,

Wonder if someone can help me. Im in the middle of trying to write a
small program, but I cant figure out why I keep getting a error from
MPASM on the following line.

newlin  MOVLW   c0h

This keeps on giving the following on compiling:

Error   LCD_PHIL.ASM 289 : Undefined argument (c0h)

Yet, the following line seems to compile OK:

      MOVLW   02h

To me, it would seem that it is not accepting c0h as a Hex number to
load into W. If that is the case then why. Else, what am I doing wrong ?

TIA.
--
Philip Martin   email .....philipKILLspamspam.....philmart.demon.co.uk
Royal Quays, North Shields

 >>
Philip,
Try 0C0H
Some hex numbers need a leading zero for the assembler to properly identify
it as a hex number.  Personally I like Motorolla's "$" indicator your number
would be $C0.  Easier to parse.

Dave Duley

1997\02\20@143037 by Andrew Warren

face
flavicon
face
I wrote:

> Microchip [could] permanently solve the problem by adding the
> "standard" '$' and '%' radix specifiers to MPASM's vocabulary.

and Andy Kunz <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU> replied:

> 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.

   Andy:

   Many assemblers (not all, though; note that I put "standard" in
   quotes) use the "$" prefix for hexadecimal numbers and "%" for
   binary.  In those assemblers, the following are all equivalent:

       LDA $AA
       LDA %10101010
       LDA 170

   The advantage here is that numbers so prefixed are COMPLETELY
   unambiguous.  With what you call the "real" standard ("0C0H"),
   ambiguity is easy to achieve.

   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"!

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

   Yeah, but only if you chose to use the "$" symbol for that
   purpose.  The "$" choice isn't necessarily "the standard"... The
   older assemblers from Microchip used "!", and many other
   assemblers use "*" (and they seem to handle the
   "context-sensitive" nature of that use pretty easily).

   MPASM doesn't leave MANY characters unused, but there are a few
   (like "?", for example) that could easily have been used instead
   of "$" to denote "current PC".

   -Andy

=== Andrew Warren - fastfwdspamspam_OUTix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html

1997\02\20@145457 by Tim Kerby

picon face
Hi
I have had the same problem.  Most assemblers like 0c0h as an ascii
character looks like a label or something.

Tim

At 14:15 20/02/97 -0500, you wrote:
{Quote hidden}

------------------------------------------------------------------
If you can read this, it is the end of the message!
My web pages are at http://web.ukonline.co.uk/members/tim.kerby/
My PIC site is at web.ukonline.co.uk/members/tim.kerby/pic/
It needs your projects!
------------------------------------------------------------------

1997\02\20@161553 by Andy Kunz

flavicon
face
>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@164606 by Clyde Smith-Stubbs

flavicon
face
Thus spake Andy Kunz (KILLspammontanaKILLspamspamFAST.NET):

> >Isn't an infinite loop done with:   goto   $
>
> No, because PC has been incremented to point to the next instruction.
>
> Funny, but that's the way it is.

Well, that's the way it is sometimes - some assemblers evaluate $ (or the
equivalent) as the start of the current instruction, some as the
start of the next instruction. Making it the address of the current
instruction is preferable, IMHO.

Here's a tricky one; the 68000 has two forms of relative branch; one
takes a single word (two bytes) one a double word. The range of the
first type is +126/-128 bytes, the second form is +32766/-32768
bytes. Now here's the trick; the second form is implemented as the
same opcode as the first form, but with a zero offset, and then
the next word is the actual offset. This makes it impossible
to code

       jmp     $+2             ($ here means this instruction's address)

If you write

       jmp     next
next:

then you get a four byte instruction!

Oh, I should point out that, like most processors, the relative jump
offset is added to the PC after it has been incremented to point to
the next instruction.

Now back to your regularly scheduled program....


--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
RemoveMEclydeTakeThisOuTspamhtsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/

1997\02\20@165217 by myke predko

flavicon
face
Andy Warren 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"!

This is one of the reasons why in all my List Statements I have the
instruction (R=DEC) and then use the 0x0 header on all Hex - that's *my*
standard.  I wish there was a 0b0 header for binary.

Of course, the fact that I only *think* in Decimal has nothing to do with
this method of doing things :)

>> $ would then be context sensitive, because it's the standard to
>> denote "current PC" as in "goto $-1"
>
>    Yeah, but only if you chose to use the "$" symbol for that
>    purpose.  The "$" choice isn't necessarily "the standard"... The
>    older assemblers from Microchip used "!", and many other
>    assemblers use "*" (and they seem to handle the
>    "context-sensitive" nature of that use pretty easily).

When I first saw that you said "$" was the standard for hex - I was confused
as well by the "standard" statement, I don't think I've seen it used since
my 6800/6502 days (early '80s).

What is that saying about "standards aren't"?

myke

"I don't do anything that anybody else in good physical condition and
unlimited funds couldn't do" - Bruce Wayne

1997\02\20@165829 by Clyde Smith-Stubbs

flavicon
face
I told a lie;

> Here's a tricky one; the 68000 has two forms of relative branch; one
> If you write
>
>         jmp     next
> next:
>
> then you get a four byte instruction!

Depending on the assembler, you may well get a 2 byte instruction -
it has the same bit pattern as NOP.

1997\02\20@204110 by John Payson

picon face
> I told a lie;
>
> > Here's a tricky one; the 68000 has two forms of relative branch; one
> > If you write
> >
> >         jmp     next
> > next:
> >
> > then you get a four byte instruction!
>
> Depending on the assembler, you may well get a 2 byte instruction -
> it has the same bit pattern as NOP.

The opcode for NOP on the 68000 is decidedly NOT the same as the opcode for
a jump-short to the next instruction.  On the 68000, a jump instruction has
an eight bit relative address.  If this field is non-zero, it will be added
to the address of the following instruction and loaded into the PC.  If this
field is zero, then the 68000 will fetch the next 16 bits and use those as a
relative address.  I am not sure why the designers at Motorola did not shift
the 8-bit displacement left a bit (since all addresses have to be even) but
nonetheless the crucial point remains that on the 68000 it is not possible to
have a short jump to the next instruction and any compiler or assembler which
outputs such a thing is broken.

This does open up the interesting question of what an assembler should actually
do upon encountering a "branch to next instruction" within the code.  There are
three options that I can see:

[1] Output some useless one-word instruction [e.g. NOP].  This will be compact
   but it will produce slightly skewed timings.

[2] Output a short jump ahead 2, followed by a NOP.  The NOP will put the tar-
   get of the jump in an acceptable place, while giving execution timings
   comparable to just using a short jump (if such a thing were possible).  The
   extra NOP may mess up cache timings, however.

[3] Output a long jump to next instruction.  This may be slower to execute than
   method #2, and probably doesn't have any particular advantage, but it is
   the only output which is "literally" correct.

1997\02\20@212030 by John Payson

picon face
> I have had the same problem.  Most assemblers like 0c0h as an ascii
> character looks like a label or something.

The problem lies in the use of an alphabetic suffix character to distinguish
numeric radix.  I think this was first done by Intel in their assembler and
it really is a poor way of doing things.

Generally, most assemblers that use this notation require any numbers to start
with a decimal digit (0-9).  For binary numbers, this is not a problem (since
they all start with zero or one anyway) but for hexadecimal this can be a real
pain.  It is especially unfortunate since in many applications hex numbers are
deliberately printed so as to indicate the size.  For example, on the 8088,
instructions to load a 8- or 16- bit registers with the quantity one would be
written as

       mov     al,01h
       mov     si,0001h

A cursory examination of the code makes it quite obvious that the former is
an eight-bit quantity and the latter is a sixteen-bit quantity.  Unfortunate-
ly, if the number in question was 255 decimal ("FF" hex), the code would have
to read

       mov     al,0FFh
       mov     si,00FFh

The distinction between operand size is no longer so visually obvious; nor is
it visually obvious that the most significant bits of AL are being set.

There was, by the way, one Z80 assembler that would assume any alphanumeric
token which could be interpreted as a valid hex number (including the trailing
h) should in fact be interpreted in that way.  Nice feature.  Unfortuantely,
the assembler didn't like a program I wrote which played a two part (musical)
invention by a rather famous compose.  Something about the composer's name...

Another caveat with alpha-suffix notation: no matter what the default radix
is, assemblers which use "d" as the flag for decimal will generally interpret,
e.g., 129D as one hundred twenty-nine.  To ensure that the number is evaluated
correctly, it should be written as 129Dh.  Of course, this rather defeats the
purpose of using a default radix of 16, though the problem may be mitigated in
part by using "t" [think "ten"] as the flag rather than "d".

Because the trailing alpha suffix character is really a feeble way of deter-
mining number radix, some other conventions have emerged.  One common variant
which is still in many ways my favorite, is to use the following prefix char-
acters:

 $ - Hexadecimal
 % - Binary
 ! - Octal

Unfortunately, assemblers which support C-style expressions can't use the
last one without syntactic ambiguity, and even supporting the "%" may be a
bit tricky (it requires the token scanner to be aware of what the parser is
doing).  Nonetheless, the leading-dollar-sign method of denoting hex numbers
is highly readable, compact, and unambiguous.

Other techniques I've seen would write, e.g., the hex number $C9 as follows:

h'C9'
h'C9  [without the second ']
16#C9 [Adobe(R) PostScript(R)]
&hC9  [Microsoft Basic]
0xC9  [the C programming language]

Of all the forms of writing hex, I think the $ prefix is by far the best (it
among other things is the only one which only adds one extra character of
baggage).  Were I to create the standard, I would probably keep a leading
dollar sign as the hex indicator and use a combination of an "it's a number"
flag character and an alpha base specifier (similar to Microsoft Basic or the
C programming language's "0x" convention, to which I'd add "0q1234" for octal
format [__NOT__ just 01234!] and 0b1011 for binary).

1997\02\21@231400 by Alex I. Torres

flavicon
face
  Hi All PICers !

> newlin  MOVLW   c0h
>
> This keeps on giving the following on compiling:
>
> Error   LCD_PHIL.ASM 289 : Undefined argument (c0h)
>
> Yet, the following line seems to compile OK:
>
>       MOVLW   02h
>
> To me, it would seem that it is not accepting c0h as a Hex
> number to load into W. If that is the case then why. Else,
> what am I doing wrong ?

If the first digit in hex number is letter (A-F) You MUST
begin the number with zero, if not - assembler use it as
string.

 0Ch - number
0AAh - number
 AAh - string

Another way is :    h'C0' or 0xC0


  Best Wishes, Alex Torres.
  Kharkov, Ukraine, exUSSR.
  E-Mail To : spamBeGonealtorspamBeGonespamcook.kharkov.ua   via InterNet
              or 2:461/28             via FidoNet

--- GoldED 2.50.A0531+

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