Just had a good look at one of my .lst files for a rather large program (80K on an 18F4685), using almost all the on chip ram. Went thru and eyeballed most of the MOVLB instructions along with anything else that modified the SFRs. As far as I can tell, PBP/MPASM do a very good job of keeping track where the BSR was to know if it has to be changed to what it needs to be. And I'm sure it's much, much worse on the 10/12/16 series PICs.
But yes, left to fend for itself, PBP CAN produce very bloated code. That's when it comes down to the keyboard operator to know that DEFINE NO_CLRWDT 1 can easily save a load of space (as is mentioned in the manual, but not directly in so many words), on most PICs, keeping commonly used variables in one bank can also save space/time by not switching banks all the time (mainly on the 10/12/16 series). Would the average programmer know that? Well, I didn't know it at first either. I figured it out accidentally by reading a datasheet one day after about a year of programming with PBP.
PBP doesn't come with optimizations built-in...true...
Among the more complicated projects, I've made it do an MP3 player (hard drive/CF based w/external USB support via FTDI), audio spectrum analyzer (128 channel), OBD2 interface (w/ 2 types of GLCD, no assembly required), 36 channel medium freq software based PWM (for LEDs), and so on. Only the spec'an required an assembly subroutine to function. The rest of them could've been done with bone stock PBP...but they weren't
Not arguing the point (well, maybe a little), just pointing out a few things that a programmer might learn over time to make PBP a more robust tool.
Why haven't I bought one of the other compilers with more options built in? Because I've already got a compiler with those options practically built-in (into my head anyways).
Besides, I've got enough to think about, let alone trying to remember which compiler I'm using for which individual project!
If you're so dead set against PBP, why are you here?
Bookmarks