Post by thread:Code error

Philip Martin <.....PICLISTKILLspam@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 - fastfwdKILLspamix.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

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

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

I wrote: > Microchip [could] permanently solve the problem by adding the > "standard" '$' and '%' radix specifiers to MPASM's vocabulary. and Andy Kunz <EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.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 - fastfwdspam_OUTix.netcom.com === Fast Forward Engineering - Vista, California === === Custodian of the PICLIST Fund -- For more info, see: === www.geocities.com/SiliconValley/2499/fund.html

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}>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 @spam@philipKILLspamphilmart.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 > ------------------------------------------------------------------ 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! ------------------------------------------------------------------

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

Thus spake Andy Kunz (KILLspammontanaKILLspamFAST.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 RemoveMEclydeTakeThisOuThtsoft.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/

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

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

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

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 : spamBeGonealtorspamBeGonecook.kharkov.ua via InterNet or 2:461/28 via FidoNet --- GoldED 2.50.A0531+