Making PBP code more modular

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

[forgie]

Thanks Darrel, you are correct - I use MCS and I didn't even try compiling with tabs before the @ symbols - but I just indented all my @ statements and of course it compiles and works fine.

With the local variables - of course resources are limited, and the concept of local variables wouldn't be appropriate (or would they?) in a number of situations. What I'm thinking is this: you have different types of vars that you define as such:

<code>
SUB MY_SUB
i VAR LOCAL BYTE
temp VAR LOCAL WORD
x VAR WORD
.....
RETURN
END SUB
</code>

The 'LOCAL' VARs would be reallocated for each SUB. When programming, you would have to ensure that your LOCAL vars can lose their value whenever a GOSUB is used. Other variables defined locally will be have their own allocation. Given that the 18f452 has 1500 bytes of memory surely some other people would find this useful?

Perhaps you could solve all memory problems by using memory addresses (pointers) as arguments for SUBS:

<code>
..
GOSUB MY_SUB(a, b, c)
..


SUB MY_SUB(WORD x, WORD y, BYTE d)
i VAR LOCAL BYTE
temp VAR LOCAL WORD
.....
x = i + y
....
RETURN
END SUB
</code>

Then PBP would just have to make all those vars point to the same address. And perhaps spit out a type-check warning if you pass a byte where a word is expected or whatever.

Would anyone else find this to make PBP a much more pleasurable and professional compiler?

Please, please respond with criticism if you disagree with my comments, as that's the only way that I will see the reasons why it isn't a good idea....

[Darrel Taylor]

OK, so the head scratching worked a little.

As another example of why I feel that INCLUDE files and Macros's are two of the most usefull features of PicBasic Pro.

Here's an example of an INCLUDE file that uses a single macro to generate some pretty neat BARgraphs. Just Include the file, and away you go.

LCD BARgraphs
http://www.picbasic.co.uk/forum/showthread.php?p=12475
<br>

[mytekcontrols]

Hi Darrel,

I haven't been on this board in a while (busy doing some contract work --- gotta make money). I see besides writing a great LCD routine you have been enhancing your posts as well (I especially liked the video presentation). And hey it all looked great under FireFox.

Keep up the great work,
Michael

[Darrel Taylor]

Thanks Mikey,

I think it took longer to figure out how to post it, than it did to write it in the first place. Thanks for noticing.
And, thanks for the Firefox update. I always wonder if I'm getting that part right or not.

I hope that contract work is PIC related.
<br>

[Acetronics2]

Nice and useful ... Despite it keeps users from undestanding LCD use and special characters ...

New " pseudo-problem threads" in sight ...

Thanks for that nice work , Darrel