Assembly statements

[mollekake]

Hallo folks!
Is there an assembly statement or way to do a OR?
I want a "goto" if one or another of two conditions are met.
What i want is it to get out of the loop if the subwf goes to 0 or below 0, OR a certain pin receives an input.

 

[Ehsan]

The assembly language of what machine ?

 

[mollekake]

Oh, forgot that, a PIC microcontroller

 

[KrisBlueNZ]

You just place a label at the end of the loop, and have two or more conditional statements that jump to that label.

loop:
    blah    blah blah
    subwf   filevar,w
    bz      breakloop ; (bz is a macro)
    bnc     breakloop ; (bnc is a macro too)
    btfsc   portx,bitn ; skip next instruction if port bit is 0
    goto    breakloop
    goto    loop

breakloop:

That's the general way you can do it. You can branch to a label from any number of places.

(In this particular case you can reverse the btfsc to a btfss and delete the goto breakloop, so the btfss skips the goto loop instruction if the port bit is set; this saves one instruction.)[/code]

 

[mollekake]

Thanks! Did not know about macros, that makes things a lot easier

But one of the examples i saw, the macro did the same a call function could do. are there any advantages/disadvantages to them? (except that macros can have parameters,if i've understood it correct)

 

[shumifan50]

The main difference is that a macro, when used, causes the code to be inserted(all of it) at the point where the macro is encountered. So if you use the macro multiple times, the code is duplicated multiple times. A call the same bit of code,so the code is not duplicated, however, it is marginally less efficient as it effectively inserts a branch and pushes the return address onto the stack. When the function completes, the return address is popped and execution continues immediately after the call. If the called code contain very few statements, the cost is proportionally much higher, so callsshould typically be used for bigger blocks of code. Macros on the other hand is efficient execution wise, but each time the macro is used, it inserts the code and therefore consumes program space,so if you are using a PIC with a small flash or the program is approaching running out of flash space, you could save space by converting the macro to a call.
Another feature that macros have that calls cannot do is giving code or data definitions meaningful names.

A simplistic rule of thumb is: if you have very few statements in a block of code that you use many times use a macro otherwise use a function call.

 

[KrisBlueNZ]

Right, the difference is as shumifan50 described. Also the fact that macros accept parameters makes them more flexible than function calls; functions can accept parameters, but they need to be accessed and tested by code within the function, which branches according to the parameters. With macros, the actual code generated for each invocation can be different depending on the parameters.

Macros are used when you need to "inline" a section of code with a tidy statement. For example I have a macro called movlwf that stores a literal into a file register by loading it into W with a movlw instruction, then storing W to a file register using a movwf instruction. Every time you invoke that macro, it generates those two instructions at that point in the code, and the literal value, and the file register, could be different each time. That's what macros are best for.

Functions are best for modular functional blocks that accept and return no or few parameters, that are non-trivial in size, and that you need to invoke from several places in the program.

BTW the bz and bnc "instructions" in my code are actually pseudoinstructions that the assembler recognises and automatically converts into a conditional skip instruction followed by a goto instruction. These aren't macros, although they work like macros, look like macros, and could be implemented with macros.

 

[gorgon]

One thing to be aware of, working with the smaller PIC microcontrollers, are the sometimes very limited stack capacity. If you use nested calls, you will eventually most certainly cut off the limb you are sitting on, and not return to where you want.
In these cases macros with code repeats has to be used.

 

[KrisBlueNZ]

In these cases macros with code repeats has to be used.

There are other ways...

 

[gorgon]

Of course, but I was refering to the macro vs call discussion above. You can of course write all instructions every time, copy and paste, or whatever..

 

[KrisBlueNZ]

I was thinking of methods of "calling" a single bit of code without using the stack, so you don't have to duplicate the code at all.

 

[gorgon]

Ok, that is a new angle. Just out of curiosity, how do you do that with a PIC? The only way I can see is using a sort of index variable resulting in a conditional goto after processing in the 'called routine'. I then suppose you use a normal goto to get there.

 

[KrisBlueNZ]

Yeah, I wasn't trying to be picky!

Edit: pun not intended! I should have said "argumentative".

Yes, that's what I mean. The caller can put a return address, or a reference to the return address, in a static variable and jump to the function. The function can "return" using, for example, an indexed goto. This adds overhead, and is messy, but messy workarounds are par for the course with PICs!

 

[gorgon]

PICs has never been a favorite for me, but I've made several projects using the smaller variants in my job. I've also used the Atmel AVR variants in some projects, and I prefer them to PICs.

I suppose I may do more hobby related programming in the future, beeing made redundant, and having problems getting a new job at my age.

 

[KrisBlueNZ]

PICs has never been a favorite for me, but I've made several projects using the smaller variants in my job. I've also used the Atmel AVR variants in some projects, and I prefer them to PICs.

Likewise. In my previous job, we used several small micros, including AVRs. Back when PICs started getting popular, we looked into them, but we unanimously rejected them because of their poorly designed architecture. Just too many workarounds and kludges.

I suppose I may do more hobby related programming in the future, beeing made redundant, and having problems getting a new job at my age.

Yeah, tell me about it. I've been unemployed for five years now. There's not much work over here for someone with my skillset.