Making PBP code more modular

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

[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