Assembler Directives and Operators Confusion

[jpanhalt]

With reference to this post , I am still struggling to understand proper use of arithmetic operators in my code.

Take for example this code from Gooligum's tutorial (Baseline, Lesson 6, page 6) related to setting up the Option register:

movlw    b'11110110'       ;configure timer0:...
        ;--1-----
        ;----0---
        ;-----110
option

movlw     1<<TOCS|0<<PSA|b'110'
option

Now, the first example is quite clear to me and is what I am used to doing. The second example is a bit more difficult to decipher to my inexperienced eye, but they both do the same thing in the same number of steps.

Putting aside the actual symbols used in the second example, my question is why can those arithmetic operators be used in what looks like regular code? How does one distinguish what looks like an ordinary program instruction from an Assembler directive? Or simply put, why can't one use the same code as in the second example to set bits in any other register?

In any case, I am confused. Is there a particularly good teaching resource that presents multiple examples? As an example of what I mean, compare the instruction set descriptions included in individual PIC datasheets with what is included in Section 29 of the whole manual (DS31029A). The former includes one example at best for each instruction. The latter has two or three examples for each, and I found it far easier to understand.

John

 

[Mr RB]

This does not really answer your question, but to my eye the first example looks very good and professional, and the second looks totally nuts. I try to avoid working with code that was written by someone who codes so badly, it's usually easier to write fresh code from scratch.

 

[ericgibbs]

hi John,
I would always use example shown in the first method, IMO the second is just to convoluted and has no advantages over the first method.

The datasheet description is the one I would use.

E.

 

[Mike - K8LH]

Hi John,

You can only use those arithmetic operators in an operand that is a "constant" or "literal" expression (the operand for instructions like movlw, iorlw, xorlw, etc.). The expressions are evaluated at assembly time.

Hope that helps...

 

[jpanhalt]

Mike,

That explains it. I had been reading about constant declarations and symbols and had even highlighted this sentence in the MPASM User's Guide, "Constants may not be reset after having once been initialized, and the expression must be fully resolvable at the time of the assignment."

So to check my understanding, in the the delay program you posted, the formula for msecs is defined as a constant. 'msecs' can then be used with the Assembly operator for mulltiply (*) in later instructions like, 'delay (100*msecs)', but you cannot use that operator in an instruction like, 'delay (register_a* msecs)', because the contents of register_a cannot be evaluated at assembly. I hope that is correct.

Thanks.

John

 

[Lourens]

The assembler (directive) arithmetic operator << is very handy when for instance you want to set a particular bit in say a special function register, but the bit position is defined by Microchip in their include file for the specific chip you use. Another chip might have that bit in another position but by using the << operator you need not consern about the bit's position.

 

[Mike - K8LH]

So to check my understanding, in the the delay program you posted, the formula for msecs is defined as a constant. 'msecs' can then be used with the Assembly operator for mulltiply (*) in later instructions like, 'delay (100*msecs)', but you cannot use that operator in an instruction like, 'delay (register_a* msecs)', because the contents of register_a cannot be evaluated at assembly. I hope that is correct.

Yes, that's correct...

 

[Pommie]

The second example is more portable and is self commenting. However, to be fully portable it should read,

    movlw     1<<TOCS|0<<PSA|b'110'<<PS0
    option

Also, by including all the bits,

    movlw	(0<<NOT_RBPU|0<<INTEDG|0<<T0CS|0<<T0SE|0<<PSA|B'000'<<PS0)

You simply change 0s to 1s to set/clear bits. You don't need to know where the bits are.

It's also a good way to make code easily changeable,

#define	LED_Port	PORTB
#define Key1		7
#define Key2		6


	movlw	1<<Key1 | 1<<Key2
	iorwf	LED_Port		;Set key1 & 2 high

or,

	bsf	LED_Port,Key1

In the above code you can change the define to move port pins. I added the comment but really this isn't needed as the code is self commenting.

Mike.

 

[Mr RB]

The second example is more portable and is self commenting.
...

    movlw	(0<<NOT_RBPU|0<<INTEDG|0<<T0CS|0<<T0SE|0<<PSA|B'000'<<PS0)

You simply change 0s to 1s to set/clear bits. You don't need to know where the bits are.

Wow Pommie you stunned me! Do you really think that is a better way to write assemble for hardware register setupsr?

To me assembler is always a very vertical language, and the very best coding style keeps it vertical and well commented. Portability has it's value but when porting a PIC assembler project you always have to spend some time checking PIC hardware differences anyway, and then only a small % of projects get ported and checking the hardware registers only takes a few minutes (and has to be done anyway as I said).

To me the best code would look like this;

movlw    b'11110110'       ;configure timer0:...
          ;1-------        ; PORTB pullups OFF
          ;--1-----        ; TMR0 on external clock
          ;----0---        ; prescaler assigned to TMR0
          ;-----110        ; prescaler set to 128:1
option

 

[atferrari]

Wow Pommie you stunned me! Do you really think that is a better way to write assemble for hardware register setupsr?

To me assembler is always a very vertical language, and the very best coding style keeps it vertical and well commented. Portability has it's value but when porting a PIC assembler project you always have to spend some time checking PIC hardware differences anyway, and then only a small % of projects get ported and checking the hardware registers only takes a few minutes (and has to be done anyway as I said).

To me the best code would look like this;

movlw    b'11110110'       ;configure timer0:...
          ;1-------        ; PORTB pullups OFF
          ;--1-----        ; TMR0 on external clock
          ;----0---        ; prescaler assigned to TMR0
          ;-----110        ; prescaler set to 128:1
option

All my code is written like yours.

 

[Pommie]

Wow Pommie you stunned me! Do you really think that is a better way to write assemble for hardware register setupsr?
[/code]

Yes I do, why use 7 lines of code (you missed bits 6 & 4) to write something when one line works as well if not better.

As for commenting, I hate seeing things like,

		movlw	8		;load w with 8
		movwf	v		;put in v
l2		bsf	PORTB,2		;set clock pin
		nop
		bcf	PORTB,2		;clear clock pin
		decfsz	v,f		;decrement v
		goto	l2		;loop
		return			;return from subroutine

I'd much rather see,

#define ClockPin PORTB,2

		movlw	8
		movwf	PulseCount
SendPulse	bsf	ClockPin
		nop
		bcf	ClockPin
		decfsz	PulseCount,f
		goto	SendPulse
		return

Although both pieces of code are identical, I prefer the second as I can instantly tell what it's doing (or what the programmer intended it to do). The first bit may have more comments but they are superfluous. The second is self commenting due to selecting good names for variables and labels.

If you get a chance, read Code Complete by Steve Maconnell, it may change your mind on these matters.

BTW, code that I post on here gets lots of commenting in an effort to help beginners. I would not comment code anywhere near as much for a professional programmer. In fact, only commenting things that aren't obvious makes the comments far more valuable.

Mike.

 

[be80be]

f you get a chance, read Code Complete by Steve Maconnell,

That's a Great book looks like I read chapter 5 and the contents at his website got to order me one

Thanks Mike

I like to try to use names that are readable and why write 7 lines and still miss something
I like to open notes up and the data sheet and put it on one line
This can't get any better

 movlw	(0<<NOT_RBPU|0<<INTEDG|0<<T0CS|0<<T0SE|0<<PSA|B'000'<<PS0)

It beats my

movlw b'00000000'

I like it going to save it for next time I write some asm.

 

[Pommie]

That's a Great book looks like I read chapter 5 and the contents at his website got to order me one

I didn't know he had rewritten it, mine is the original version from 1993 (Wow, 19 years ago and still as valid as ever). It looks like the new version is written from an object orientated language perspective.

Mike.

 

[Mr RB]

Yes I do, why use 7 lines of code (you missed bits 6 & 4) to write something when one line works as well if not better.
...

Why not use 7 lines of code? Is that bad? Assembler is always very vertical by its nature. Did you come from a C background or an assembler background? I've seen some bad C code (often written by young guys) where they try to put everything on one line.

In PIC C code especially it's my preference to write very vertically, this has benefits in converting to other languages or assembler and in being able to cross-check the C code to the assembler output (to improve performance). I don't see anything as "bad" by using more lines, and there are definite payoffs to using more lines.

I haven't read "Code Complete by Steve Maconnell" but if he has a generalisation that using less lines in source is better than more lines I think he has it backwards. When I started coding many years back I tried to (and did) use less lines. Now I'm a heck of a lot better and use a lot more lines.

As for commenting, I hate seeing things like,

		movlw	8		;load w with 8
		movwf	v		;put in v
l2		bsf	PORTB,2		;set clock pin

I agree no problem, it's much better to use good variable and label/function names etc, and is really an art.

However I still don't see the problem with additional comments. Much of the code I release has been simplified and over-commented for beginner use, but there is no cost to an expert who reads that code he can just ignore the extra commenting. It's like buying a prduct that has a really complete instruction manual compared to a one-page chinese translation. Nobody complains that the instruction manual was too big and too good.

Like you I use less commenting in private code but I suspect I still use a lot more commenting than you. Often I write the program out in comments (liek a flowchart etc) until it is debugged procedurally in my head, then I just type in the code part later (and it works, usually with no bugs). I take longer to write code, but do very little debugging. There's no cost to me (or to others) that it may have superfluous looking comments or be a bit vertical in nature after it is finished.

I've worked with a young Uni-trained programmer that loved writing very horizontal code, where one C line might do 20 things (and with little to no commenting). Getting his code to work was horrendous. If that C line was written as 10 vertical lines with some comments not only is it easier to understand what is happening and in what order, but any line can be commented out in a second for testing and debugging and even adapting (cut and paste) to be used elsewhere. By the time we had been working together for a year his code was a LOT more vertical and better commented, and he was a much better coder than he was from only the Uni training.

 

[Pommie]

Hi Roman,

I come from an assembly background and worked exclusively in asm from 1981 to 1995 ish and only learnt C when the Nintendo 64 was released (I was a games programmer - partial list of games I worked on). I like code to be vertical and you will not find any code of mine (C or asm) with more than one instruction/function on a line. The reason I don't like abundant comments is that the really important comments get lost.

I think you would like Code Complete as the authors philosophy makes perfect sense. For example, he believes that if code is so complex it needs a lot of commenting then, if possible, you should rewrite the code to be more understandable.

Mike.

 

[jpanhalt]

Mike,

What's that thing about 6 degrees of separation? Do you happen to know my nephew: https://www.mobygames.com/developer/sheet/view/developerId,20733/

I assume there were a lot of folks doing games at that time. He built his reputation while an undergrad at UCLA and graduated with a profit. My brother was particularly happy about that part. He dba'd as under the name Redline.

John

 

[Mr RB]

...
I like code to be vertical and you will not find any code of mine (C or asm) with more than one instruction/function on a line. The reason I don't like abundant comments is that the really important comments get lost.
...

Excellent. Then we can both complain about these young guys that use function call/return as part of a complex compound if() statement which is included in a for() statment... All on the one line!

...
I think you would like Code Complete as the authors philosophy makes perfect sense. For example, he believes that if code is so complex it needs a lot of commenting then, if possible, you should rewrite the code to be more understandable.
...

Ok, you sold me. Anyone that is into clarity and minimalisation in design sounds like they know what they are talking about. I'll see if my library can order in the book, they have access to a nationwide comprehensive list of software books (surprisingly). I think someone in the Aussie library system thought it was a good idea to stock up on lots of software titles (and it beats buying a book if it's a read-once deal).

 

[Pommie]

I just checked Brisbane library and they have a copy on the shelf. Unfortunately it's the second edition which I haven't read (maybe I should). From looking at the contents, the second edition seems to be aimed more at OO languages. The first was asm, C & Pascal - more to my taste.

Edit, you can read some of it here.

Mike.

 

[Mr RB]

Thanks Pommie! The Google link showed me the front cover and all of two pages!

No drama I'll check at the library, they can order from anywhere and someone may have a first edition.

 

[jpanhalt]

That's odd. When I tried it, many pages showed up. There were interspersed notices that some pages had been omitted from the review, but there were more than enough pages presented to get a good feel for the entire book. I had to use the scroll bar on the right and they loaded very slowly. Browser dependent? I use Chrome.

John