Obviously it is a syntax issue. There are several ways to identify which means something at a source line. The use of x'nn' or nnnH or other to represent a hexadecimal number is an option taken at the compiler development time, and some are more common than another. The way to discriminate what could be a number or a variable name or label, could be observing the first digit of the element, if it is a numeric digit, then it IS a numeric value, otherwise it would be a "label" or a "variable name", so all hexadecimal numbers above 99h would require a zero upfront. By this reason, lately I decided to use all numbers starting with zero, so hexa 85 would be found as 085h at all my source files. It looks better aligned at numeric tables, and will avoid to confuse visually with a possible B5h variable name. One can say, if the variable is not previously defined, then you can't use it late in the source lines, but, otherwise the program would understand that CCH is a variable and not a number, but again, if not defined, what should be CCH, a number or a variable that you forgot to define? By some reason in one program that used lots of repeated fixed numbers (that could change ) I used to define variables names as N35 EQU 35, or H35 EQU 035H, so it could be easily changed right at the first lines of the source file, instead to change them along the file. As I used only around 20 different values, it was easy, and of course, this is the main reason to use a "variable" at the source lines. :) 10 years ago I produced a Z80 cross compiler in REXX language for a mainframe IBM VM/MVS system. It was the first I think , but the point is that I defined labels should start with "@" variables "$" and numbers "#". My own rules, that if in the market would be done by other people too. Wagner. Johnny Lindholm wrote: > ... > MOVELW 0CCH > MOVWF Variable > ... > What exactly is this? With the 16F84 as target the registers are only 8 > bit wide. I interpret the last "H" to be a "hex"- indicator and i assume > the hex code is "CC" but then why the first "0"??? > The alternatives to this that I've seen is writing h'CC' and that is > perfectly clear but does it mean the same thing?? Is this depending on > witch assembler you use?