Making PBP code more modular

[mister_e]

Many thanks Darrel for this tutorial about the Macro. I guess it could be interesting to place a post in the FAQ or Code example on that AND how to work with the internal PBP macro also work... you know those MOVE?CB etc...

I could start it myself but... oooooh... you're really better than me to explain those

Well just an idea!

[forgie]

Thanks heaps for the info, Darrel, much appreciated.

With the LCD example, I was actually thinking more along the lines of how would one get a macro that can handle a list of arguments, like LCDOUT does. It's by no means a necessity, the workarounds are very easy, it would just be nice luxury to have in the world of coding.

Is it possible to do for loops in macros? e.g. make a macro called LCDRIGHT x which moves the cursor right x spaces, and define it using a for loop? Sorry, I don't know how to display code on this forum, so I can't write down the code for what I'm thinking of.

Anyway,
Thanks heaps for the info,
Nick

[mister_e]

Forgie,

to display code you must use those VbCode... really easy to use and explain Here

[Darrel Taylor]

With the LCD example, I was actually thinking more along the lines of how would one get a macro that can handle a list of arguments, like LCDOUT does.

Well, I thought that's what it does. It takes a list of arguments, but instead of using commas, it uses the Plus sign instead.

Take a look at this thread Embedded Strings in your Code Space
It has some more examples of passing parameters with macro's.

But really, the main problem is that MPASM always has to have the exact number of parameters supplied to a macro. So a single macro can't accept 2 parameters on 1 use and 5 on another. PM has that ability, but I don't like making programs that only work with PM since you can't use it with the 18F's

Is it possible to do for loops in macros? e.g. make a macro called LCDRIGHT x which moves the cursor right x spaces, and define it using a for loop?

Yes, you can do that. But keep in mind that every time you use a macro, it duplicates the entire code at the place where it is used. So, big macro's that are used several times can eat up a lot of code space. There are ways around that too, but it's not for the scardy cats. For instance, consider this example as an alternative to the LCDRIGHT idea. It allows you to move the cursor anywhere on the screen using either constants or byte variables. Using the constant version would look like this

@ LCDCUR?C 1,5  ; Row, Col

Which would move the cursor to Row1, Colomn5.

Or, using the byte variable version would be like this

Row  VAR BYTE  system
Col  VAR BYTE  system

Row = 2
Col = 10
@ LCDCUR?B  Row, Col

Here's the macros for them. They are self optimising, so that no code is generated unless you actually use them. The main parts of the routine are actually subroutines that can be "called", and the macros you use in the main program simply place the parameters in Temp variables so that the "called" routine can access them. This way it only uses a few words each time you use one of the macro's.

This code has been removed, please see a couple posts down for the revision.
Should have tested it first. Doh!

I just threw this together last night in anticipation of your next question, so if you actually try it, and have problems, let me know.

Best regards,
   Darrel

[Darrel Taylor]

... it could be interesting to place a post in the FAQ or Code example on that AND how to work with the internal PBP macro also work... you know those MOVE?CB etc...!

Yeah, probably would..., but I don't know, something about the FAQ section scares me.

If you choose a topic, then your supposed to answer all the frequently asked questions about that topic. It's like you're supposed to know everything about it, and you don't want to miss anything because nobody's going to write an FAQ that conflict's with you're FAQ.

Coupled with the fact that, I don't know Everything about Anything. It's just not a good fit for me.

But actually, I've tried to write something for the macro's in PBP 3 times now. Then when I read it back afterwards, it never seems to get the point across. Not even close.

I do think it's worthwhile to laud the abilities of INCLUDE macro's. Especially since nobody seems to use them. So maybe it's time for a new approach.

Hmmm, what could it be .... scratch, scratch ...

DT

[Darrel Taylor]

OK, so that last example was terrible. Should have tested it first.

Here's a better one that shows more of how to use PBP statements in macro's. It's also a little easier to see how the "self optimization" works. (this time I tested it)

<b>DEFINE  </b></font><b>LCDCOLS 16  </b><font color="#0000FF"><b><i>; can be 8, 16, 20, 24 or 40
                    ; but 20 is the only one that matters in this routine
</i></b></font><b>LCD_Row   </b><font color="#008000"><b>VAR BYTE </b></font><b>system
LCD_Col   </b><font color="#008000"><b>VAR BYTE </b></font><b>system

</b><font color="#008000"><b>ASM
    </b></font><font color="#000080">ifndef LCDCOLS
        #define LCDCOLS 16    </font><font color="#0000FF"><b><i>; Default to 16 Columns
    </i></b></font><font color="#000080">endif

MoveCursorExpanded = 0


</font><font color="#0000FF"><b><i>; --- Move cursor to new location ---(inputs are LCD_Row and LCD_Col)-----------
</i></b></font><font color="#000080">Expand_MoveCursor  macro
  local  OverCode
    goto      OverCode
MoveCursorExpanded = 1
MoveCursor
    if LCDCOLS == 20          </font><font color="#0000FF"><b><i>; if using a 4x20 display
        </i></b></font><font color="#008000"><b>ENDASM
            LOOKUP </b></font><b>LCD_Row</b>,[<b>$80</b>,<b>$80</b>,<b>$C0</b>,<b>$94</b>,<b>$D4</b>],<b>LCD_Row
        </b><font color="#008000"><b>ASM
    </b></font><font color="#000080">else                      </font><font color="#0000FF"><b><i>; if NOT using a 4x20 display
        </i></b></font><font color="#008000"><b>ENDASM
            LOOKUP </b></font><b>LCD_Row</b>,[<b>$80</b>,<b>$80</b>,<b>$C0</b>,<b>$90</b>,<b>$D0</b>],<b>LCD_Row
        </b><font color="#008000"><b>ASM
    </b></font><font color="#000080">endif
    </font><font color="#008000"><b>ENDASM
        </b></font><b>LCD_Row </b>= <b>LCD_Row </b>+ (<b>LCD_Col </b>- <b>1</b>)
        <font color="#008000"><b>LCDOUT </b></font><b>$FE</b>, <b>LCD_Row  </b><font color="#0000FF"><b><i>; Send the command
    </i></b></font><font color="#008000"><b>ASM
    </b></font><font color="#000080">return
OverCode
    endm

</font><font color="#0000FF"><b><i>; --- Move LCD cursor to  Row, Column using constants --------------------------
</i></b></font><font color="#000080">LCDCUR?C  macro  Row, Col
    if MoveCursorExpanded == 0
        Expand_MoveCursor
    endif
    MOVE?CB   Row, LCD_Row
    MOVE?CB   Col, LCD_Col
    L?CALL    MoveCursor
    endm

</font><font color="#0000FF"><b><i>; --- Move LCD cursor to  Row, Column using Byte variables ---------------------
</i></b></font><font color="#000080">LCDCUR?B  macro  Row, Col
    if MoveCursorExpanded == 0
        Expand_MoveCursor
    endif
    MOVE?BB   Row, LCD_Row
    MOVE?BB   Col, LCD_Col
    L?CALL    MoveCursor
    endm

</font><font color="#008000"><b>ENDASM
</b></font>

Using them is still the same

<font color="#000080">@ LCDCUR?C 1,5          </font><font color="#0000FF"><b><i>; Move to Row1 Column5
  </i></b></font><font color="#008000"><b>LCDOUT </b></font><font color="#FF0000">&quot;R1C5&quot;         </font><font color="#0000FF"><b><i>; Display something

'-- OR --

</i></b></font><b>Row  </b><font color="#008000"><b>VAR BYTE  </b></font><b>system
Col  </b><font color="#008000"><b>VAR BYTE  </b></font><b>system

Row </b>= <b>2
Col </b>= <b>10
</b><font color="#000080">@ LCDCUR?B  Row, Col    </font><font color="#0000FF"><b><i>; Move to Row2 Column10
  </i></b></font><font color="#008000"><b>LCDOUT </b></font><font color="#FF0000">&quot;R2C10&quot;        </font><font color="#0000FF"><b><i>; Display something</i></b></font>

[forgie]

....haha I still have a tricky question for the masters around here..... is it possible to write a macro to accept arguments like this:

<code>
lcdline1 "this is line 1"
lcdline2 "this is line 2"
</code>

where "lcdline1 X" is equivalent to "lcdout $FE, $80, X".... with the small catch that X can be anything from a string to a list of arguments (basically it can be anything that lcdout can take as an arg). I'm thinking that this is impossible - I assume its the compiler that converts LCDOUT args and strings into seperate ASM statements - since it's not the assembler that's doing the parsing from a list of args, or a string, to a number of individual ASM statements.

BTW this is something that I would actually use, but it's only for extreme convenience and 'luxury' - it's always nicer to be able to write the highest level control/interface sections of a program in incredibly high-level, easy to understand language and syntax.

[Melanie]

http://www.picbasic.co.uk/forum/showthread.php?t=1999

I would draw your attention to Darrels link to his website in one of the early posts.

[Acetronics2]

Hi, Mel

just Take that as an info for our friend Forgie....

http://www.elabtronics.com/products_cat_CoreChart.htm

That's modular !!!

Alain

PS : No comments about gadgets ... Next step could be the voice or cerebral activity recognition compiler.
But what about the programmer snoring ??? must the compiler write a "sleep" line or wake up our friend from his dreams ???

Alain

[forgie]

Thanks for the macro examples Darrel, much appreciated.
I guess there's still two things that irritate me:

Assembly macros (and hiding them in an include file if you want to) are a great way to do your own simple 'custom instructions'..... but if you have a big block of complex code that has many indentations, the restriction of having to put the "@ MYMACRO" statement at column 1 is very annoying. Perhaps PBP could have a command called MACRO? Where you could write MACRO MYMACRO to run an asm macro that you've previously defined? This would make the code much, much more readable. Even changing the way PBP interprets the '@' symbol would fix it, if you made PBP interpret the start of the ASM line where the '@' symbol is.... that way you could put @ MYMACRO after three tabs and keep your pretty, readable code.

The second is local variables. I'm sorry, but I still can't quite be satisfied with the modularity of PBP until there are proper local variables implemented somehow. The implementation might be difficult to write, granted, but without local variables, you have to keep track of every variable that every little subrouting uses, and make sure that different subs don't use an already in-use 'counter1' or 'temp3' or whatever. Does anyone else find this annoying? With local variables, all of a sudden 'true modularity' becomes a reality, and you can copy a subroutine that say, does a math function, without worrying about variable naming or anything like that, because they're all local to that sub.

Just my thoughts.....