Making PBP code more modular

[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.....

[Melanie]

> but without local variables, you have to keep track of every variable that every little subrouting uses...

I'm sure I've used @ beyond the first column... but @ has to be the first character encountered on the line. How far along the line PBP finds it, is I think not relevant. To be fair, I've not tried it with MPASM, but certainly with PM several Tab-Stops still finds it working.

The luxury of 'Local Variables' was extended to you first in Compilers or Interpreters that have access to near limitless resources. It's almost impossible to run out of RAM in a Visual Basic program for example - if you are the most wasteful shoddy programmer on the planet, how much RAM can you use? 100kb out of some 256Mb (or more) avaiable to you? This is not the case with most PICs, and certainly not the case with the 12F or 10F series! A couple of dozen variables and suddenly you're in deep trouble. So variables HAVE to be reused. So document your subroutines - it'll only take a minute. Indicate in a comment header at the start, what the entry variables should be, what the exit variables are, and the names of any working variables or other subroutines used internally. You only need to add this documentation once, and it's there for life. You can pick-up that subroutine in six months time and you KNOW where you stand.

> must the compiler write a "sleep" line or wake up our friend from his dreams ???

Hey, I always write my best code when I'm asleep. It's remembering what I wrote next morning that's the problem...

[Darrel Taylor]

You're welcome forgie!

The @ symbol in col 1 is more of a MicroCode Studio problem.

If the @ is in any other column, MCS won't highlight it as an ASM statement. It still compiles just fine in both PM and MPASM no matter how far it's indented. But, it can sure be confusing.<br><br>