Where do the counting numbers start when using hexadecimal in assembly code?

Hi,

As far as I am aware, when you use a hexadecimal number in assembly code it does not always represent a number.

For example,

BCLR n,M will clear bit n, in byte M:

BCLR $0007,$0001 will clear bit 7 in byte 1

However this syntax is not consistent, sometimes the hexadecimal numbers do not represent numbers, but instead represent commands.

for example

bset 7,$0004 will tell the microcontroller that bit 7 in data direction registry A is an output.

This is because the address of data direction registry A is $0004, so it put a 1 in bit 7 of DDR A. When a bit in a data direction registry is a 1 it means that the corresponding pin for port A will be an output. (and when it is a 0 it will be an input)

bset 7,$0004 will put a 1 in bit 7 of DDR A, which means that pin 7 of port A will be an output.




So my question is:

At what point do the hexadecimal numbers stop being addresses for registers and other things, and instead start to represent actual numbers.

Thanks.

It's how the op code interprets the number or how the number in a particular special purpose register is interpreted. I'm not familiar with these op codes, so I'll take your word for how they function. In your second example using 'bset', the $0004 is just a number that is interpreted as an address. According to you, the register addressed by $0004 is the register that controls the direction of data for Port A? If so, then the number (and it's still just a number) stored in that register (the DDR register at $0004) is _used_ to determine the direction of data flow in that port, and bit 7 will function as an output port because that bit is set (in a PIC, a '1' indicates an input port -- it was done that way because a '1' looks like an 'I' and a 0 looks like an O -- makes it easier to remember ;)

It's all about context. A different register might interpret the number it stores in some other way. For instance, in certain PICs (the uController I'm most familiar with), there is a WPUA register. It turns on or off the "weak pullup 'resistors'" on the bits of Port A. There is another register that determines whether the port bits are Analog or Digital. It's all determined by the context of the register assignment. In each case, they are just numbers, but they are interpreted in different ways.

Now, you said that sometimes these numbers represent "commands". They aren't really commands. The only part of the statement that is a command is the OP code, the rest of the statement are arguments that are interpreted by the command processor in terms of the OP code. You need to make a distinction between an opcode and a register. OP codes often modify or interact with registers. They set register content, reset it, move it from one register to another (or to the accumulator -- which is just another register). But the contents of the special purpose registers aren't commands (generally, there might be exceptions in arcane cases -- but it's been a while since I have written assembly -- I mostly code in C, now, so I can't call up an instance).

Special Purpose Registers direct things, which might be why you are confused, but they aren't commands. Commands are executed in a sequence determined by the program counter. Special function registers are tied to the various modules of the uController and act asynchronous with the program counter. A uController can be asleep and the ports on a uController will continue to be output. input, digital, analog, with weak pullups or not, even the ADC(s) can be converting as determined by the registers that control their behavior while the uController is asleep (at least with most PICs), etc. Even when the program counter is not being incremented and the opcode interpreter is not reading anything, the fundtions controled by the Special Purpose Registers will continue to act as the content of those registers dictate. They could be said to _command_ the functions they control, but that doesn't make them _commands_, as least in terms of how a number field in a Special Purpose Register is interpreted.

Let me know if that wasn't clear or if you still have questions.

A simpler answer would be to look at the set of each command you are going to use, and the information will tell you each command function of addresses, location properties, functions, and number, in hex most probably. Unfortunately I'm going to tell you go RTFM.... Paul

Haha yeah I've found the manual, I didn't expect it to be so easy to follow (and its 400 pages long) so I didn't try that first. These answers have helped though.
Thank you!

To put the answer in a small nutshell, the first hex number in an instruction is the opcode, and this number tells the processor what to do with the numbers in the rest of the instruction.